Что изменилось в перечнях 2026 года и как подготовиться к новым правилам лицензирования

Что изменилось в перечнях 2026 года и как подготовиться к новым правилам лицензирования.

В августе 2026 года ФСТЭК России утвердила новые редакции перечней оборудования и программных средств, необходимых для лицензируемой деятельности в области технической защиты информации и разработки средств защиты информации. Для разработчиков СЗИ это важное изменение: регулятор связал лицензионную готовность с реальными инструментами безопасной разработки – анализом кода, контролем зависимостей, фаззингом, динамическими испытаниями и исследованием выпускной сборки.

Главное:
Действующим лицензиатам необходимо привести оснащение в соответствие новой редакции до 1 марта 2027 года. Для соискателей лицензий новые перечни применяются с 1 декабря 2026 года.

Что именно изменилось

ФСТЭК утвердила два самостоятельных документа. Перечень от 10 августа 2026 года относится к деятельности по технической защите конфиденциальной информации в рамках постановления Правительства РФ № 79. Перечень от 11 августа 2026 года предназначен для разработки и производства средств защиты конфиденциальной информации по постановлению № 171. Для разработчиков программных и программно-технических СЗИ ключевым является второй документ.

Новый перечень включает 32 позиции. Программный блок сосредоточен в позициях 16–32. При этом приобретать все позиции подряд не требуется: состав оснащения определяется видами работ, включёнными в лицензию или заявляемыми соискателем. Поэтому проверку следует начинать не с каталога поставщика, а с сопоставления лицензионных работ с отметками «+» в соответствующих столбцах перечня.

1 декабря 2026 года	1 марта 2027 года
новые требования действуют для соискателей лицензий	срок приведения действующих лицензиатов в соответствие

Какой контур должен быть у разработчика СЗИ

Перечень фактически описывает полный цикл исследования программного продукта: от исходного кода и состава компонентов до поведения программы в рабочей среде. Для лицензирования важно не только наличие программ, но и возможность показать результаты их применения.

Задача	Необходимые средства	Доказуемый результат
Анализ кода	Статический анализатор, отладчик, анализ бинарного кода	Отчёты о дефектах и уязвимостях; сопоставление исходного и объектного кода
Исполнение	Динамический анализ, монитор активности, анализатор протоколов	Трассы выполнения, системные вызовы, информационные потоки
Негативные испытания	Фаззер и комплекс тестирования на проникновение	Покрытие, воспроизводимые отказы, подтверждённые уязвимости
Зависимости	Средство композиционного анализа	Машиночитаемый состав компонентов и статус известных уязвимостей
Сборка и выпуск	Компилятор, эмулятор, программатор, контроль целостности	Контрольные суммы и подтверждение состава выпускной сборки
Среда эксплуатации	Сканер защищённости и не менее двух антивирусов разных производителей	Результаты контроля конфигурации, уязвимостей и вредоносного кода

Для отдельных позиций перечень прямо требует сертификат соответствия ФСТЭК России: это средства поиска остаточной информации, контроля целостности, анализа защищённости и антивирусной защиты. Для статических и динамических анализаторов, фаззеров и средств композиционного анализа основное значение имеет соответствие установленным функциональным характеристикам и указанным методическим документам. В частности, для статического анализа названы Методика выявления уязвимостей и недекларированных возможностей от 16 мая 2026 года и ГОСТ Р 71207-2024.

Как новые требования связаны с РБПО

ГОСТ Р 56939-2024 рассматривает безопасную разработку как систему процессов: управление компонентами, анализ безопасности кода, проведение испытаний, контроль выпуска и устранение выявленных недостатков. Новый перечень не вводит самостоятельную обязанность подтверждать соответствие всей системы разработки этому стандарту. Он решает другую задачу – формирует инструментальную основу, без которой многие процессы РБПО невозможно выполнять и доказывать на практике.

Управление компонентами. Композиционный анализ позволяет вести состав продукта, сопоставлять зависимости с базами уязвимостей и актуализировать сведения при каждом выпуске.

Анализ безопасности. Статические, динамические и бинарные средства дают результаты по разным уровням продукта, а не только по исходному тексту.

Испытания устойчивости. Фаззинг и пентест проверяют поведение программы за пределами штатных сценариев и помогают подтвердить реализуемость атаки.

Контроль выпуска. Контрольные суммы, анализ сборки и трассировка результатов связывают проверенный исходный состав с передаваемым заказчику продуктом.

Важное различие:
Наличие лицензии на инструмент не подтверждает наличие процесса РБПО. Нужны правила применения, ответственные лица, критерии разбора результатов и доказательства устранения выявленных недостатков.

Что важно учесть при подготовке

Право использования. Оборудование и программы должны находиться в собственности либо использоваться на ином законном основании, предусматривающем владение и пользование. Договор или подписка должны охватывать лицензируемую деятельность.

Российские решения. Перечень устанавливает приоритет оборудования и программ российского происхождения, но не формулирует безусловный запрет на иностранные продукты. На практике следует оценивать происхождение, поддержку и устойчивость лицензирования.

Облачные сервисы. Функционально подходящий SaaS-сервис не всегда пригоден для лицензируемых работ. Нужно учитывать место обработки данных, режим информации, сохранность результатов и возможность предоставить их при проверке.

Доказательства применения. Установленного ПО недостаточно. Лицензиат должен сохранять отчёты, трассы, перечни компонентов, контрольные суммы, журналы анализа и сведения об устранении замечаний.

Что сделать действующим лицензиатам до 1 марта 2027 года

Определить лицензионный периметр. Сопоставить виды работ в лицензии с соответствующими столбцами нового перечня.
Провести инвентаризацию. Зафиксировать продукты, версии, места установки, лицензии, сертификаты, поверку и калибровку.
Собрать матрицу соответствия. Для каждой требуемой характеристики указать подтверждающий документ или результат проверки.
Закрыть дефициты. Запланировать закупку, внедрение, вычислительные ресурсы, обновления, обучение и поддержку.
Встроить инструменты в РБПО. Определить события запуска проверок, ответственных, критерии приемки и порядок устранения уязвимостей.
Актуализировать документы. Обновить регламенты разработки, производственного контроля, выпуска версий и формы отчётности.
Провести внутреннюю проверку. До контрольной даты воспроизвести сценарий лицензионного контроля и показать реальные результаты применения средств.

Соискателям лицензии

Организациям, которые подают документы после 1 декабря 2026 года, следует сразу формировать комплект по новой редакции. До закупки полезно подготовить функциональную матрицу, запросить у поставщиков письменное подтверждение характеристик и проверить статус сертификатов. Хорошая практика – заранее отработать демонстрационные сценарии: статический анализ, формирование состава компонентов, фаззинг, расчёт контрольных сумм и исследование тестовой сборки.

Вывод

Обновлённый перечень закрепляет переход от формального оснащения к проверяемой технологии безопасной разработки. К контрольной дате лицензиат должен быть готов показать не только договоры и установленные программы, но и работающий процесс: кто и когда запускает проверки, какие результаты получает и как устраняются выявленные уязвимости.