Реестр отечественного ПО в 2026 году: ПП №1236, доверенное ПО и совместимость с двумя ОС

Представьте разработчика CRM, который десять лет продавал продукт частным компаниям, а в 2025 году выиграл тендер у регионального министерства. И тут выясняется: без записи в реестре отечественного ПО контракт подписать нельзя, заказчик госсектора обязан закупать российские решения, если они есть на рынке. Это конкретное постановление Правительства РФ от 16.11.2015 №1236, которое запрещает госорганам и муниципалитетам закупать иностранное программное обеспечение при наличии отечественного аналога в реестре.

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

Кто ведёт реестр и что проверяет

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

Ключевые условия, по которым отказывают чаще всего:

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

Для компании, которая строит CRM, ERP или мобильное приложение с нуля под заказ, а это как раз профиль заказной разработки, большинство этих пунктов решаются на этапе архитектуры, а не постфактум. Если с самого начала не закладывать облачный SDK американского вендора push-уведомлений или платёжный шлюз с иностранной юрисдикцией в ядро системы, записать продукт в реестр становится заметно проще.

Доверенное ПО — отдельная история

Запись в реестре отечественного ПО и статус доверенного продукта — разные вещи, и их часто путают. Реестр решает вопрос госзакупок: может ли ведомство купить этот продукт вместо иностранного. Доверенность — вопрос критической информационной инфраструктуры: банков, энергетики, транспорта, связи. Указ Президента РФ от 30.03.2022 №166 обязал субъекты критической информационной инфраструктуры перейти на доверенное программное обеспечение и отечественные программно-аппаратные комплексы, причём для значимых объектов КИИ запрет на использование иностранного ПО действует с 1 января 2025 года.

Для разработчика это означает дополнительный слой требований сверх базовых условий реестра: отдельные процедуры подтверждения доверенности программно-аппаратного комплекса устанавливает Правительство РФ профильными актами, и туда обычно входит проверка цепочки поставки компонентов, возможность технического аудита кода регулятором и требования к безопасной разработке. Если клиент — банк или оператор связи, прежде чем обещать ему реестр и доверенность одним пакетом, стоит отдельно уточнить, под какой именно контур идёт продукт: обычный госзаказчик или объект КИИ. Требования отличаются по объёму работ в разы.

Почему реестр требует совместимости с двумя ОС

Это правило вызывает больше всего вопросов у разработчиков, которые привыкли собирать продукт под одну платформу и не трогать эту тему. Логика у регулятора простая: если программа работает только под одной операционной системой, заказчик фактически попадает в зависимость не от иностранного, а теперь уже от отечественного монопольного вендора ОС. Поэтому по правилам ведения реестра для многих классов программ, особенно системного и прикладного ПО для рабочих станций и серверов, нужно подтвердить работоспособность минимум на двух операционных системах из реестра, обычно построенных на разных ядрах или дистрибутивах Linux.

На практике это означает, что компания должна протестировать продукт хотя бы на двух из следующих систем:

Операционная система	Разработчик	Где чаще встречается
Astra Linux	ГК «Астра»	госорганы, силовые структуры, крупные корпорации
РЕД ОС	«РЕД СОФТ»	госучреждения, образование, корпоративный сектор
ОС «Альт»	«Базальт СПО»	госсектор, промышленность, рабочие станции
РОСА	НТЦ ИТ РОСА	корпоративные серверы и рабочие станции

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

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

Как это выглядит в разработке на практике

Мясокомбинат из Якутии, для которого студия ведёт несколько проектов, в 2026 году строит ERP-контур на платформе Odoo 17 Community Edition — открытой системе без лицензионной привязки к одному зарубежному вендору. Решение возникло не из темы реестра, а из экономики: сравнение показало, что реализация блока учёта маркировки «Честный знак» на 1С обходится в несколько раз дороже, чем на Odoo, плюс отдельная лицензия платформы и оплата каждой пользовательской подписки. Но итог тот же, что требует регулятор от претендентов на реестр: система не завязана на закрытый код одного иностранного поставщика, работает на Linux-сервере и теоретически переносима между дистрибутивами без переписывания с нуля.

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

Для серверных систем с интеграцией в 1С — а это постоянная часть нашей работы, от ERP для транспортной компании с интеграцией ГЛОНАСС и 1С до двусторонней синхронизации заказов с 1С 7.7 для оптового B2B-канала мясокомбината — вопрос совместимости с ОС решается на уровне серверной части: сам 1С работает на нескольких отечественных Linux-дистрибутивах официально, и если бэкенд вокруг него не тянет за собой проприетарные зависимости, подтвердить работу на двух системах из реестра требует в первую очередь времени на тестирование, а не переписывания логики.

Что это стоит и сколько занимает

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

Техническая часть, которой занимается разработчик, распадается на понятные блоки:

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

Последний пункт — ровно то место, где подходит обычная техническая поддержка после запуска. У нас три тарифа: Базовый на 10 часов в месяц за 25 000 ₽, Стандарт на 20 часов за 45 000 ₽ и Расширенный на 40 часов за 85 000 ₽, с часами сверх тарифа по 2 500 ₽ в час. Для продукта из реестра отечественного ПО такая поддержка обычно закрывает именно регулярную проверку совместимости после каждого обновления дистрибутива или выхода новой версии Astra Linux и РЕД ОС — задача рутинная, но предсказуемая по объёму.

Саму разработку CRM или ERP-системы с нуля, если речь о продукте под реестр, правильнее оценивать не по готовому прайсу «от», а по конкретному техническому заданию: требования к совместимости с двумя ОС и к независимости от иностранных компонентов сильно влияют на архитектуру с первого дня, и экономия на этом этапе почти всегда выливается в переделку позже.

Частые вопросы

Можно ли попасть в реестр с продуктом на иностранном фреймворке, если весь код написан нашей командой? Сам факт использования открытого иностранного фреймворка или библиотеки обычно не блокирует включение в реестр — важнее, кому принадлежат исключительные права на итоговый продукт и нет ли встроенной обязательной связи с зарубежными серверами. Но конкретный ответ по спорным случаям в итоге даёт экспертный совет при рассмотрении заявки, а не общее правило.

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

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

Чем заказная разработка CRM/ERP под реестр отличается от обычного проекта по срокам и цене? Ориентир по обычной CRM или ERP-системе у нас — от 500 000 ₽ и от двух месяцев, но для продукта под реестр к этому добавляется время на тестовые стенды под вторую ОС и на сопровождение после обновлений. Точная цена и срок фиксируются в договоре после разбора технического задания — слишком много зависит от того, какие интеграции и зависимости уже есть в системе.

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