Коротко
- Постквантовая миграция начинается не с замены алгоритмов, а с инвентаризации криптографии.
- Приоритет получают системы с долгоживущими секретами, внешними TLS-точками, PKI и критичными архивами данных.
- Без тестов совместимости переход может сломать интеграции, HSM, старые клиенты и внутренние сервисы.
- В 2026 году разумная цель - управляемый план миграции, а не хаотичная закупка “post-quantum ready” решений.
Что произошло
Cloudflare в июне 2026 года снова вынесла post-quantum cryptography из исследовательской темы в операционную: организациям пора готовить практические планы перехода. Это хорошо ложится на более широкий контекст NIST, где постквантовая криптография давно ведется как отдельная программа стандартизации.
Для ИБ-команд главный вывод не в том, что классические алгоритмы мгновенно стали бесполезны. Практический риск другой: если компания не понимает, где у нее используются TLS, сертификаты, криптобиблиотеки, HSM, архивное шифрование и подписи, она не сможет мигрировать без сбоев.
Почему это важно для ИБ
Постквантовый риск особенно неприятен для данных с длинным сроком чувствительности. Если перехваченные сегодня зашифрованные данные должны оставаться секретными много лет, сценарий harvest now, decrypt later становится управленческим риском, а не абстрактной криптографической дискуссией.
Вторая зона риска - зависимость от поставщиков. TLS-терминация, VPN, сервисные mesh-сети, мобильные клиенты, старые агенты, аппаратные модули и встроенные устройства могут иметь разные сроки поддержки новых алгоритмов. Без карты зависимостей миграция превращается в серию неожиданных отказов.
Что делать в первую очередь
Первый шаг - криптографический инвентарь. Нужно собрать список мест, где используются сертификаты, ключи, алгоритмы, протоколы, подписи и шифрование данных at rest. Отдельно стоит отметить владельца системы, срок жизни секрета, критичность данных и возможность обновления клиента.
Второй шаг - приоритет. Не все нужно менять одновременно. В верхней части списка должны быть публичные TLS-точки, системы с долгоживущими секретами, критичные архивы, PKI, VPN, межсервисная аутентификация и инфраструктура, где обновление зависит от внешнего поставщика.
Третий шаг - тестовый контур. Переход на новые алгоритмы нужно проверять на совместимость до production. Особенно это касается старых клиентов, встраиваемых систем, прокси, HSM, мониторинга TLS и внутренних политик инспекции трафика.
Материал не утверждает, что конкретные алгоритмы в вашей инфраструктуре уже непригодны. Он фиксирует практический вывод из текущей post-quantum повестки: без инвентаря и плана организация не сможет безопасно перейти, когда требования станут жестче.
Как это превратить в рабочую задачу
Для CISO и архитекторов задача должна выглядеть как программа миграции: владелец, scope, реестр криптографии, пилотные сервисы, критерии совместимости, бюджет времени на поставщиков и план отката. Для SOC это отдельная линия наблюдения: изменения TLS и сертификатов не должны ломать мониторинг и реагирование.
Для платформенных команд полезно уже сейчас добавить в change management поле “криптографическая зависимость”: какие алгоритмы и библиотеки используются, как обновляются, кто владелец и где хранится документация. Это дешевле, чем собирать такие данные в момент срочного регуляторного дедлайна.