Короткий ответ: как перейти на passkeys безопасно
Passkey — это способ входа, при котором пользователь подтверждает доступ на доверенном устройстве, а сервис проверяет криптографическую пару ключей. Пароль или одноразовый код не передаётся сайту и не может быть введён на поддельной странице. Для бизнеса переход означает не простое включение новой кнопки, а управляемый проект: определить критичные учётные записи, выбрать допустимые устройства, подготовить восстановление доступа, провести пилот и только затем расширять охват.
Начинать лучше с администраторов, финансовых ролей и сотрудников, работающих с CRM, почтой и документами. При этом старые методы нельзя отключать до проверки сценариев потери телефона, замены ноутбука, увольнения сотрудника и аварийного доступа. Цель — убрать фишинговые способы входа, не создавая обходных путей через службу поддержки.
Почему тема стала практической именно сейчас
Крупные корпоративные платформы переводят пользователей с SMS и голосовых кодов на устойчивые к фишингу методы. Например, в Microsoft Entra ID с 1 сентября 2026 года началось включение passkeys как предпочтительного метода для пользователей, у которых были настроены SMS или звонки. На 1 февраля 2027 года заявлено прекращение встроенной доставки SMS и голосовых кодов для большинства категорий пользователей. Конкретные исключения, доступность функций и условия зависят от платформы и договора компании, поэтому их нужно проверять перед проектом.
Для руководителя это не повод немедленно отключить SMS. Это срок для инвентаризации: какие системы зависят от кодов, кто владеет учётными записями, какие устройства используются и как будет подтверждаться личность при восстановлении доступа.
Что такое passkey и почему его сложнее похитить
При регистрации passkey создаётся пара ключей. Открытая часть сохраняется у сервиса, а закрытая остаётся на устройстве или в защищённом хранилище пользователя. Вход подтверждается локально — например, биометрией, PIN-кодом устройства или аппаратным ключом. Сервис получает криптографическое доказательство, но не получает секрет, который можно повторно использовать.
Passkey привязан к реальному домену сервиса. Поддельная страница с похожим дизайном не сможет запросить корректное подтверждение для другого домена. Это отличает passkeys от пароля и одноразового кода, которые сотрудник может сообщить злоумышленнику. Синхронизация между устройствами, перенос и восстановление зависят от выбранной экосистемы. Эти функции следует оценивать отдельно, особенно если компания применяет личные телефоны сотрудников.
Passkey не отменяет социальную инженерию
Устойчивый к фишингу метод защищает сам процесс аутентификации, но не делает сотрудника неуязвимым. Злоумышленник может представиться специалистом поддержки, попросить зарегистрировать новый способ входа, подтвердить код устройства или авторизовать неизвестный сеанс. В 2026 году исследователи описывали атаки, где тема настройки passkey использовалась как предлог, а настоящей целью было получение действующего сеанса или добавление чужого метода аутентификации.
Поэтому политика должна запрещать регистрацию ключа по инструкции из неожиданного звонка или сообщения. Любое добавление нового метода, изменение номера и аварийное восстановление требуют проверки личности по независимому каналу. Для привилегированных ролей полезно уведомление администратора и журнал, который показывает, кто, когда и с какого устройства изменил способы входа.
Сначала составьте карту учётных записей
Переход начинается не с сотрудников, а со списка систем. Включите корпоративную почту, CRM, облачные панели, 1С и связанные веб-сервисы, документооборот, VPN, администрирование доменов, хостинг, резервные копии и социальные сети компании. Для каждой системы зафиксируйте владельца, тип учётной записи, доступные методы входа, резервный способ и последствия компрометации.
Отдельно отметьте общие и технические учётные записи. Их нельзя автоматически переводить по правилам обычного пользователя: у сервисного процесса может не быть телефона, а общий пароль отдела уже сам по себе создаёт проблему ответственности. Там, где возможно, заменяйте общие аккаунты персональными ролями, API-ключами с ограниченными правами или управляемыми сервисными идентификаторами. Карта покажет, где passkeys применимы сразу, а где сначала нужно изменить архитектуру доступа.
| Группа | Приоритет | Основной метод | Резерв |
|---|---|---|---|
| Администраторы | Критический | Passkey или аппаратный ключ | Отдельный аварийный ключ |
| Финансы и руководители | Высокий | Passkey на управляемом устройстве | Проверенный резервный метод |
| CRM, почта, документы | Высокий | Passkey | Процедура восстановления |
| Технические интеграции | Отдельный контур | Сервисная идентичность | Ротация секрета и журнал |
Определите модель устройств и хранения ключей
Компания должна решить, где разрешено создавать passkeys: только на корпоративных устройствах, на личных телефонах либо в смешанной модели. Корпоративное устройство проще включить в единые правила блокировки, обновлений и удаления рабочего профиля. Личное устройство снижает порог входа, но усложняет поддержку, увольнение и разделение личных и рабочих данных.
Уточните, синхронизируются ли ключи через учётную запись производителя устройства, можно ли применять аппаратные ключи и поддерживает ли платформа централизованную политику. Для критичных ролей стоит предусмотреть два независимых аутентификатора, хранящихся раздельно. Решение необходимо закрепить документом: допустимые устройства, минимальные требования к блокировке экрана, запрет передачи ключей и порядок действий при потере устройства.
Проведите пилот на небольшой группе
Выберите 10–20 пользователей с разными сценариями: руководитель, менеджер продаж, бухгалтер, IT-администратор и удалённый сотрудник. Не ограничивайтесь успешным входом. Проверьте первый запуск, работу на втором устройстве, смену телефона, удаление рабочего профиля, отсутствие интернета, вход из другой страны и доступ к приложению, которое использует единую аутентификацию.
Для каждого теста запишите ожидаемый результат, фактическое поведение и владельца исправления. Измеряйте не только число успешных регистраций, но и количество обращений в поддержку, время восстановления и долю пользователей, у которых остался небезопасный резервный метод. После пилота обновите инструкции и только затем подключайте подразделения волнами. Так переход не превращается в одновременную блокировку всей компании.
- Подтвердить вход на основном и резервном устройстве.
- Проверить потерю телефона и замену ноутбука.
- Проверить отзыв доступа при увольнении или смене роли.
- Убедиться, что старый SMS-метод действительно отключается после миграции.
Спроектируйте восстановление до массового запуска
Самая опасная часть проекта — не ежедневный вход, а исключение. Если сотрудник потерял единственное устройство, служба поддержки должна вернуть доступ без импровизации. Опишите, кто принимает заявку, какие сведения проверяет, кто подтверждает личность и кто имеет право добавить новый метод. Не используйте вопросы, ответы на которые можно найти в социальных сетях или CRM.
Для администратора и владельца бизнеса подготовьте аварийный доступ, который не зависит от обычного телефона. Резервные ключи хранятся раздельно, выдача фиксируется, а каждое использование расследуется. После восстановления следует отозвать старые сеансы и потерянные аутентификаторы, проверить изменения ролей и уведомить владельца учётной записи. Хорошая процедура одновременно помогает законному пользователю и не даёт злоумышленнику обойти сильную аутентификацию разговором с оператором.
Защитите службу поддержки от срочных просьб
Сценарий «директор потерял телефон перед важной встречей» создаёт давление и часто приводит к нарушению правил. Подготовьте для поддержки короткий регламент: не регистрировать новый метод по ссылке из письма, не принимать подтверждение только от руководителя в мессенджере и не сообщать временные коды третьему лицу. Заявка должна проходить через известный канал, а изменение критичного доступа — через второго уполномоченного сотрудника.
Полезно заранее провести учебный звонок и проверить, следует ли оператор процедуре. Руководители должны публично поддержать правило, что срочность не отменяет проверку. Иначе технически устойчивый passkey будет обходиться через самый мягкий организационный процесс. Все операции восстановления и добавления способов входа нужно собирать в журнал и регулярно просматривать.
Не оставляйте SMS как незаметный обход
Если после регистрации passkey пользователь может в любой момент выбрать SMS, общая устойчивость остаётся на уровне слабого метода. Переход завершён только тогда, когда для выбранной группы отключены фишинговые способы входа или строго ограничены политикой. Делать это нужно поэтапно: сначала убедиться, что у пользователя есть рабочий основной и резервный способ, затем убрать старый канал и проверить повторный вход.
Исключения фиксируйте с владельцем и сроком. Например, устаревшее приложение может временно не поддерживать современную аутентификацию. Тогда определяют компенсирующие меры: отдельную учётную запись, ограничение сети, минимальные права и усиленный мониторинг. Постоянное исключение без срока быстро превращается в основной путь атаки.
Контролируйте не только вход, но и права
Сильная аутентификация подтверждает, кто вошёл, но не отвечает, что этому человеку разрешено. После внедрения passkeys пересмотрите административные роли, доступ к экспорту CRM, почтовым архивам, облачным файлам и настройкам интеграций. Сотруднику не нужны постоянные права администратора только потому, что иногда он выполняет одну служебную операцию.
Разделяйте обычную и привилегированную учётные записи, выдавайте повышенные права на ограниченное время и фиксируйте критичные действия. Направление ZXC SECURE охватывает защиту данных, мониторинг и управление доступами; конкретные механизмы зависят от выбранной платформы и инфраструктуры. Passkeys следует включать в общую модель: идентичность, устройство, минимальные права, журнал и реакция на отклонения.
Условный сценарий: торговая компания в Казахстане
Условная компания использует корпоративную почту, CRM, облачный диск и панель хостинга. Проект начинают с пяти администраторов и финансового директора. Им регистрируют passkeys на управляемых ноутбуках и отдельные аппаратные ключи для резерва. Затем тестируют потерю телефона, блокировку сотрудника и аварийный вход владельца. После двух недель без критичных сбоев подключают отдел продаж группами по десять человек.
SMS отключают только после подтверждения двух рабочих способов. Для хостинга вводят отдельные административные аккаунты, а общий пароль исключают. Служба поддержки получает сценарий проверки личности и запрещает добавление нового метода по просьбе из мессенджера. Это условный пример последовательности, а не обещание результата или готовая конфигурация для любой платформы.
Что проверять после внедрения
Ежемесячно просматривайте долю пользователей с passkeys, оставшиеся SMS-методы, новые регистрации аутентификаторов, необычные входы и обращения на восстановление. Для привилегированных ролей отдельно отслеживайте добавление способа входа, выдачу прав, экспорт данных и создание API-ключей. Метрика «все зарегистрировали passkey» недостаточна, если половина сотрудников продолжает использовать пароль и SMS.
После изменения платформы или парка устройств повторяйте тесты восстановления. Проверяйте актуальность списка владельцев аварийных ключей и наличие доступа у уволенных сотрудников. Инцидент или подозрительная регистрация требуют отзыва сеансов, удаления неизвестного метода, проверки действий в почте, CRM и файловом хранилище и сохранения данных журнала для разбирательства.
Практический следующий шаг
Соберите таблицу из двадцати наиболее критичных учётных записей и отметьте для каждой владельца, текущий метод входа, наличие passkey, резерв, административные права и процедуру восстановления. Затем выберите пять пользователей для пилота и согласуйте четыре теста: первый вход, второе устройство, потеря основного устройства и отзыв доступа. Не отключайте старый метод, пока эти сценарии не пройдены.
Если нужна связанная модель защиты идентичностей, устройств и привилегий, начните с обследования в контуре ZXC SECURE. На встречу полезно принести перечень платформ, ролей и действующих способов MFA — это позволит обсуждать конкретную последовательность перехода, а не абстрактный набор функций.
Частый вопрос: passkey — это то же самое, что биометрия?
Нет. Биометрия или PIN-код обычно разблокируют использование ключа на устройстве. Отпечаток или изображение лица не передаются корпоративному сервису как пароль. Сам сервис проверяет криптографическое доказательство, созданное закрытым ключом. Конкретный способ локального подтверждения зависит от устройства и политики компании.
Частый вопрос: можно ли сразу отключить пароли и SMS?
Только после пилота и проверки восстановления. Сначала пользователю настраивают основной и допустимый резервный способ, затем тестируют реальные рабочие приложения и только после этого отключают слабый метод. Для устаревших систем оформляют временное исключение с владельцем, сроком и компенсирующими мерами.
Частый вопрос: что делать при потере телефона?
Пользователь обращается по заранее утверждённому каналу, служба поддержки проверяет личность по независимой процедуре и регистрирует новый метод только после необходимого подтверждения. Потерянный аутентификатор и активные сеансы отзываются. Для критичных ролей должен существовать отдельный резервный ключ или аварийная учётная запись с контролируемым хранением.