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

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

Что меняет новый статус

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

Смысл статуса прежде всего в закупках. Если хотя бы одна заявка предлагает доверенное ПО, все остальные программы без такой отметки приравниваются к иностранным — даже если они уже включены в реестр российского ПО.

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

Где кроются главные сложности

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

С 2026 года и дальше для разных классов ПО начнут действовать требования к совместимости минимум с двумя операционными системами, соответствующими условиям доверенного ПО. Офисный софт должен уложиться в эти рамки с 1 сентября 2026 года, серверное ПО, виртуализация, СУБД и инструменты разработки — с 1 января 2027 года, прикладное и отраслевое ПО — с 1 июня 2027 года, промышленное — с 1 января 2028 года.

Здесь появляется новая экономика. Компании придётся решать, под какие системы портировать продукт, где держать тестовые стенды и сколько денег закладывать на проверку совместимости.

Три узких места: структура, разработка, обновления

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

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

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

Для обычной команды это серьёзная перестройка. Привычные внешние репозитории, облачные сборки и сторонние сервисы тестирования больше не выглядят нейтральной технической деталью.

Третье узкое место — обновления. Их можно ставить только с согласия пользователя, а серверы распространения должны находиться в России. Компаниям придётся отдельно описывать, как они выпускают патчи, как сообщают об уязвимостях и как подтверждают, что обновление не ломает требования статуса.

В таких сценариях полезно заранее продумать и приватность канала связи, особенно если команда работает в поездках или через чужие сети. Для этого используют инструменты шифрования трафика на личных устройствах — не как замену корпоративной защите, а как дополнительный слой для критичных коммуникаций.

Кому статус пригодится, а кому — нет

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

Меньшим компаниям, которые делают узкие прикладные решения, требования могут показаться тяжёлой бюрократией. Если у продукта простая архитектура и нет сложной инфраструктуры поставки, жить с новыми правилами будет легче.

Отдельно важно не путать новый перечень с требованиями для объектов критической информационной инфраструктуры. Сам по себе статус доверенного ПО не создаёт обязанности использовать именно его на значимых объектах КИИ.

Что делать разработчику уже сейчас

Самый разумный шаг — проверить не только код, но и организацию вокруг него. Статус доверенного ПО смотрит на владение, сборку, обновления и контроль среды, а не только на красивую презентацию для закупки.

Если продукт уже включён в реестр Минцифры, это не конец истории, а только начало следующего этапа. Доверенное ПО — это не знак качества в привычном смысле, а новый фильтр, через который рынок будут проверять на зрелость и управляемость.

В такие моменты полезно держать под рукой не только юристов и инженеров, но и короткий список проверок для самой команды.

Чек-лист для разработчика

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