Вход через Google и Apple ID: штраф до 700 000 ₽ для сайтов и приложений

ГЛАВНАЯ НОВОСТЬ

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

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

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

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

Часть 10 статьи 8 Федерального закона от 27.07.2006 № 149-ФЗ “Об информации, информационных технологиях и о защите информации” устанавливает специальные требования к авторизации пользователей, находящихся на территории Российской Федерации.

Если российский владелец сайта, страницы сайта, информационной системы или программы для ЭВМ предоставляет доступ к информации пользователям после авторизации, такая авторизация должна проводиться одним из предусмотренных законом способов:

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

Федеральным законом от 26.06.2026 № 199-ФЗ в КоАП РФ введена статья 13.55. Она предусматривает ответственность за неисполнение обязанности по проведению авторизации пользователей сети Интернет при предоставлении доступа к информации. Для юридических лиц штраф составляет от 500 000 до 700 000 рублей.

Почему проблема не только в кнопке

На практике недостаточно просто убрать кнопку «Войти через Google» с экрана приложения или сайта.

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

Поэтому проверять нужно не только интерфейс, а всю цепочку входа пользователя: frontend, серверную часть, мобильные сборки, настройки Firebase, Auth0, Supabase, Keycloak, Cognito или иных систем авторизации, если они используются в проекте.

Важно отличать почту от авторизации через внешний сервис

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

Одна ситуация — когда пользователь указывает e-mail как контактный адрес, а пароль проверяется внутри самого приложения. Другая ситуация — когда пользователь нажимает «Войти через Google» или «Войти через Apple», проходит проверку на стороне внешнего сервиса, а приложение получает токен для входа.

Наибольший риск возникает именно во втором случае: когда Google, Apple ID или иной иностранный сервис фактически используется как поставщик авторизации.

Отдельный риск — персональные данные

Для части проектов прежняя модель входа через Google или Apple ID была удобна не только технически, но и юридически. Приложение могло не собирать прямые идентификаторы пользователя: номер телефона, ФИО, паспортные данные или иной подробный профиль.

Переход на телефон, ЕСИА, биометрию или внешний российский ID может изменить эту модель. У владельца продукта может появиться новая цель обработки персональных данных, новый состав данных, обязанность обновить политику обработки персональных данных, пересмотреть согласия, проверить хранение данных и оценить необходимость уведомления Роскомнадзора.

Это особенно важно для приложений, которые изначально строились как privacy-friendly продукт и собирали минимальный набор сведений о пользователе.

Какой вариант может быть менее рискованным

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

Поэтому для части проектов наиболее разумным решением может быть не переход на избыточную идентификацию через ЕСИА или биометрию, а собственная российская система авторизации с минимальным набором данных: без ФИО, паспорта, адреса и иных сведений, которые не нужны для работы сервиса.

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

Что стоит проверить владельцам сайтов и приложений

Бизнесу стоит провести короткий юридико-технический аудит авторизации.

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

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

Практический вывод

Кнопка «Войти через Google» теперь может быть не просто удобным элементом интерфейса, а признаком юридического риска.

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

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

ВЕРНУТЬСЯ К НОВОСТЯМ СЛЕДУЮЩАЯ НОВОСТЬ