Совместимость ПО с двумя ОС: какие сроки Минцифры предлагает перенести и что делать разработчику

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

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

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

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

1. Правило двух ОС: действующий график и предложенный перенос

Какие документы нужно сопоставить

Основу действующего регулирования составляют правила формирования и ведения реестра российского ПО, утверждённые постановлением Правительства РФ № 1236, с внесёнными изменениями. Переходные сроки по группам программ установлены пунктом 6 постановления Правительства РФ от 28 ноября 2025 года № 1937.

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

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

Как соотносятся сроки

Действующие даты приведены по пункту 6 постановления № 1937. Правая колонка показывает предлагаемый перенос и не должна восприниматься как самостоятельное подтверждение изменения законодательства.

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

Почему класс программы влияет на план подготовки

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

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

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

Что означает проект для офисного ПО

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

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

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

2. Когда требуется две ОС и в каких случаях обсуждается одна

Речь идёт не о любых двух операционных системах

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

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

Фраза «поддерживается Linux» слишком широка для технической работы. Различия между дистрибутивами, версиями библиотек, политиками безопасности и средствами установки могут существенно влиять на приложение. Даже если исходный код переносим, это не гарантирует одинакового поведения готового продукта во всех средах.

Какие исключения предусмотрены действующими правилами

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

Каждое основание требует содержательной проверки. Сотрудничество с разработчиком ОС, партнёрское соглашение или участие в общей маркетинговой программе не следует автоматически приравнивать к принадлежности к одной группе лиц.

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

Что предлагается для облачных решений

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

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

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

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

Что предлагается для программ защиты информации

Ещё одно предложенное основание связано с ПО, основной функцией которого является защита конфиденциальной информации. Здесь существенна именно основная функция продукта.

Наличие шифрования, управления доступом или журналирования не превращает любую корпоративную систему в программу соответствующей категории. Такие возможности могут быть вспомогательными для CRM, системы документооборота или аналитической платформы.

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

Почему браузерный интерфейс не решает весь вопрос совместимости

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

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

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

Как рассматривать ПО в составе ПАК

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

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

Подробнее эту связь рассматриваем в материалах о программно-аппаратных комплексах в реестре Минцифры и о разделении оборудования и ПО между реестрами Минпромторга и Минцифры.

3. Как подготовить подтверждение совместимости ПО с двумя ОС

Сначала определите границы проверяемого продукта

Техническую подготовку стоит начинать с ответа на вопрос: что именно проверяется? Один исполняемый файл, клиент-серверная система, набор микросервисов, платформа с модулями или программная часть комплекса?

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

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

Такая схема полезна не только для реестра. Она помогает разработчикам оценить объём переноса, службе поддержки — подготовить инструкции, а коммерческому отделу — корректно описывать поддерживаемые среды.

Составьте матрицу конфигураций

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

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

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

Проверяйте пользовательские функции, а не только установку

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

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

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

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

Учитывайте обновление и восстановление

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

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

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

Проверьте внешние зависимости

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

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

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

Подготовьте доказательства, которые можно понять и воспроизвести

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

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

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

Более подробно подготовку документов рассматриваем в статье о подтверждении совместимости с доверенными ОС.

4. Как спланировать работы, пока перенос сроков остаётся проектом

Разделите юридическую и техническую готовность

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

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

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

Выделите работы, которые сохраняют ценность при любом решении

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

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

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

Планируйте зависимости от внешних участников

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

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

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

Не обещайте заказчикам больше подтверждённого

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

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

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

Пример: настольная программа

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

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

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

Пример: облачная платформа с локальной поставкой

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

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

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

Как следить за изменением проекта

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

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

Общую основу требования рассматриваем в материале о совместимости ПО с двумя российскими ОС. Настоящая статья дополняет её разбором октябрьских предложений и подходом к планированию.

5. Частые вопросы о переносе сроков и подготовке продукта

Можно ли уже считать сроки перенесёнными?

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

Достаточно ли того, что программа работает в браузере?

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

Можно ли выбрать любые две российские ОС?

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

Если программу можно поставить на оборудование, считается ли она частью ПАК?

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

Нужно ли останавливать технические работы до принятия проекта?

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

С чего начать разработчику

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

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

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