Для признания продукта «доверенным» разработчик должен подтвердить соответствие нескольким обязательным условиям:
- Программное обеспечение включено в Реестр отечественного ПО (формируемый Минцифры в 2025 году) или в перечень ПО для собственных нужд организаций;
- Хотя бы одна версия ПО протестирована и совместима с российскими процессорами (например, Эльбрус, Байкал, Нано-СИС);
- Обновления ПО могут производиться только с явного разрешения пользователя и без подключения к зарубежным серверам — исключается любая автоматическая передача данных за пределы РФ;
- Разработчик обязан обеспечить техническую поддержку и иметь инфраструктуру для учета, классификации и устранения уязвимостей — при обнаружении критической уязвимости исправление должно быть выпущено в течение 30 календарных дней;
- В случае использования компонентов с открытым исходным кодом (Open Source) — необходимо подтвердить соблюдение всех лицензионных требований и информировать пользователей о составе и происхождении таких компонентов.
При этом для отдельных категорий ПО, системного, офисного, антивирусного, промышленного, установлены
дополнительные требования, например, наличие сертификации по ФСТЭК, поддержка шифрования ГОСТ, интеграция с отечественными средствами защиты. Однако подача заявки на признание «доверенным» остаётся добровольной: несоответствие критериям не влечёт исключения из общего реестра отечественного ПО или перечня для внутреннего использования.
С 1 марта 2026 года
полномочия по аттестации и внесению ПО в реестр «доверенного» будут переданы правительственной комиссии по цифровому развитию. До этого момента будет сформирована сеть аккредитованных центров тестирования, которые проведут техническую экспертизу на соответствие требованиям: проверку архитектуры, анализ кода (в части отсутствия скрытых зависимостей), тестирование на совместимость с российскими ОС и процессорами, а также моделирование сценариев устранения уязвимостей.
Особое внимание уделено формированию реестра «значимых разработчиков» — российских ИТ-компаний, финансирующих собственные проекты без государственных субсидий и обязующихся в письменном соглашении не передавать права на интеллектуальную собственность иностранным лицам или компаниям. Такие
разработчики получат приоритет при участии в госзакупках и доступ к специальным инструментам поддержки.
Для ПО, уже включённого в реестры российского и ЕАЭС ПО, введены
новые требования: необходимо подтвердить совместимость не менее чем с двумя операционными системами, соответствующими критериям «доверенного» ПО (например, Astra Linux, «Альт Линукс», «Ред ОС»). Это исключает ситуации, когда ПО «отечественное» по происхождению, но работает только на Windows или macOS.
Допуск к КИИ даёт разработчику ключевые преимущества:
- Возможность участвовать в закупках для государственных и муниципальных организаций, работающих на объектах КИИ (энергетика, транспорт, здравоохранение, связь, финансы);
- Приоритет при распределении госзаказов — «доверенное» ПО получает тот же уровень приоритета, что и ранее признанное российское или ЕАЭС-ПО;
- Упрощённый доступ к инфраструктуре тестирования, сертификации и интеграции с государственными системами.
Сроки перехода КИИ на отечественное ПО были отложены с 1 января 2025 года до 1 января 2028 года. В случае, если в реестре «доверенного» ПО отсутствует аналог зарубежного решения, срок может быть продлён до 1 декабря 2030 года — но только при условии, что субъект КИИ представит утвержденный план доработки российской альтернативы и подтвердит её внедрение в течение установленного срока.
Это изменение — не просто административная процедура. Оно формирует новую экономическую модель:
частные компании, ранее не участвовавшие в госзакупках, получают возможность выйти на рынок КИИ, где ранее доминировали только крупные ИТ-гиганты с государственным участием. В то же время государство получает прозрачную картину: кто, что разрабатывает, как обеспечивает безопасность и насколько готов к масштабному внедрению.
Такой подход снижает риски, связанные с использованием «серых» решений — ПО, которое формально «российское», но содержит скрытые зависимости, не имеет поддержки или не проходит проверку на уязвимости. Теперь доверие не базируется на национальности бренда, а на доказанной технической надёжности, независимости и ответственности разработчика.