Пилотировать — да. Отключать пароль и SMS одним днём — нет
Passkeys уже достаточно зрелы, чтобы малый бизнес начинал пилоты. Но большинству компаний не стоит одномоментно удалять пароль и SMS. Сначала ключ доступа добавляют как основной удобный способ входа, проверяют реальные устройства, восстановление аккаунта и нагрузку на поддержку, и только потом сокращают привычные методы.
Главный принцип: не начинайте с отключения паролей и SMS. Начинайте с жизненного цикла: регистрация ключа → вход → несколько ключей → восстановление → телеметрия → пилот → постепенное предпочтение passkey.
Четыре термина, без которых легко запутаться
Passkey / ключ доступа — криптографическая учётная запись для входа без пароля: закрытый ключ остаётся у пользователя, сервер хранит открытый.
WebAuthn — веб-стандарт, через который браузер и сервер создают и проверяют такие ключи.
FIDO2 — семейство стандартов беспарольной и устойчивой к фишингу аутентификации, куда входит WebAuthn.
Recovery / восстановление аккаунта — процедура возврата доступа, если пользователь потерял устройство или все ключи.
Passkeys перестали быть экспериментом
Ещё несколько лет назад passkeys можно было воспринимать как перспективную замену паролям. В 2026 году это уже не экспериментальная функция браузера: 25 августа WebAuthn Level 3 получил статус W3C Recommendation, а FIDO Alliance оценивает число активных passkeys примерно в 5 млрд.
Одновременно крупные платформы начинают выталкивать SMS из роли основного метода аутентификации. Microsoft с 1 сентября 2026 года делает passkeys направлением по умолчанию для затронутых пользователей Entra ID и объявила о прекращении собственной доставки SMS/voice для MFA с 1 февраля 2027 года.
Для малого бизнеса это не означает, что «SMS завтра перестанут работать». Смысл другой: технологический риск passkeys заметно снизился, а слабые места паролей и одноразовых кодов стали достаточно дорогими — с точки зрения атак, пользовательского опыта и иногда прямых расходов на сообщения и поддержку.
Что такое passkey и почему биометрия не уходит на сайт
Passkey — это не ещё один секретный код, который пользователь должен запомнить. При регистрации устройство создаёт криптографическую пару: закрытый ключ остаётся в устройстве или менеджере учётных данных пользователя, а сервер получает только открытый ключ. При входе сервер отправляет одноразовый криптографический вызов, устройство подписывает его закрытым ключом, а сервер проверяет подпись.
Face ID, отпечаток пальца или PIN используются локально — чтобы разблокировать ключ на устройстве. Сайт не получает фотографию лица, шаблон отпечатка или локальный PIN; он получает криптографическое подтверждение успешной проверки.
Ключ привязан к конкретному relying party и домену. Поэтому пользователь не может случайно «ввести passkey» на фишинговом сайте так же, как пароль или SMS-код: браузер и операционная система не дадут чужому origin воспользоваться credential, созданным для настоящего сервиса.
Почему passkey устойчивее, чем пароль + SMS
| Риск | Пароль + SMS/OTP | Passkey |
|---|---|---|
| Фишинговая копия сайта | Пользователь может отдать пароль и вручную ввести одноразовый код. | Ключ привязан к домену; фишинговый origin не получает credential настоящего сервиса. |
| Повторное использование секрета | Пароли часто повторяются; утечка может использоваться в credential stuffing. | Для каждого сервиса создаётся отдельная пара ключей. |
| Утечка базы сервера | Хэш пароля остаётся ценным объектом атаки. | Сервер хранит публичный ключ; его кража не позволяет войти как пользователь. |
| Перехват/перенос SMS | Код можно выманить, переслать или получить через уязвимые телеком-сценарии. | Для входа нужна криптографическая подпись credential, связанного с сервисом. |
| Человеческая ошибка | Пользователь должен распознать поддельный сайт и не сообщить код. | Часть проверки правильного сервиса выполняет клиентская платформа. |
NIST прямо указывает: аутентификаторы, где человек вручную переносит OTP в сессию, не считаются phishing-resistant. Доставка out-of-band секретов через PSTN, включая SMS, в SP 800-63B отнесена к restricted authenticator. Это не запрет SMS для коммерческого сайта, но важный сигнал о направлении риск-модели.
Что passkeys не лечат
- кражу уже созданной сессии или cookies после успешного входа;
- уязвимости приложения, XSS, ошибки разграничения прав и слабую серверную авторизацию;
- компрометацию разблокированного устройства или локальной учётной записи ОС;
- слабый процесс восстановления аккаунта;
- общие аккаунты нескольких сотрудников;
- ошибки offboarding и неотозванные права уволенного сотрудника.
Самая опасная ошибка — сделать recovery слабее основного входа
Если основной вход защищён passkey, но поддержка может заменить credential после одного слабого подтверждения, злоумышленник просто атакует восстановление. Поэтому recovery — не приложение к passkeys, а равная по важности часть внедрения.
Для потребительского сервиса разумно предусмотреть несколько ключей на аккаунт, синхронизируемый менеджер учётных данных, вход с другого устройства и резервный канал восстановления. Для сотрудников с повышенным риском могут использоваться device-bound passkeys или аппаратные FIDO2-ключи и более строгая процедура восстановления.
Можно ли заменить SMS полностью
Технически — во многих сценариях да. Практически — не сразу. Passkey способен заменить и пароль, и второй фактор в регулярном входе. Но номер телефона или email могут остаться как идентификатор, канал уведомлений или часть recovery. Это разные функции, и их не нужно смешивать.
| Сценарий | Рекомендация |
|---|---|
| Внутренние кабинеты, администраторы, CRM, финансы | Начинать раньше: риск фишинга высок, пользователей мало, обучение и recovery проще контролировать. |
| Клиентский личный кабинет с тысячами повторных входов | Добавить passkey как предпочтительный способ, собирать adoption и сокращать SMS только после стабильного пилота. |
| Редкие входы раз в несколько месяцев | Не строить обоснование только на SMS; важнее UX и риск. Окупаемость разработки может быть медленнее. |
| Старые устройства, WebView, терминалы, общие ПК | Не убирать fallback до фактического device coverage и теста cross-device входа. |
| Гостевой checkout | Не превращать passkey в дополнительный барьер; предлагать создать ключ после покупки или регистрации. |
Не нужно строить криптографию с нуля, но нужна нормальная архитектура
WebAuthn — стандарт браузера и платформы. Серверу нужны корректные registration/authentication ceremonies: challenge, RP ID, стабильный user handle, проверка origin, credential ID и подписи. Google в технической документации рекомендует использовать серверную WebAuthn/FIDO библиотеку вместо самостоятельной реализации низкоуровневой криптографии.
Если авторизация уже делегирована Identity Provider, сначала нужно проверить его поддержку passkeys и модель recovery. Если учётная система собственная, внедрение обычно затрагивает обработка данных, пользовательский интерфейс, хранение учётные данные, сбор показателей, recovery и поддержку.
Совместимость проверяется на собственной аудитории
Современные Android, iOS/iPadOS, macOS и Windows, а также основные браузеры уже поддерживают WebAuthn/passkeys в разных комбинациях. Но реальный путь различается: synced passkeys, сторонние менеджеры, QR для cross-device authentication, аппаратный security key, локальная биометрия или системный PIN.
Правильный критерий — не «стандарт поддерживается», а «95% нашей реальной аудитории проходит нужный путь без тупика».
SMS — только одна статья эффекта
ROI passkeys часто пытаются посчитать как «сколько SMS перестанем отправлять». Это слишком узко. У проекта есть как минимум четыре денежных контура: стоимость сообщений и шаблонов, обращения в поддержку из-за паролей/кодов, стоимость разработки и сопровождения, а также потери на неуспешных входах. Последний пункт лучше не монетизировать без собственной аналитики.
Российские тарифы на SMS зависят от оператора, типа сообщения, уникальных абонентов, пакетов, альфа-имён и шаблонов. МТС Exolve в 2026 году публиковала отдельную пакетную логику для авторизационных SMS и изменения платы за шаблоны. Поэтому корректный расчёт нельзя строить по «средней цене SMS из интернета»: в XLSX нужно подставлять фактическую среднюю стоимость OTP по своим счетам.
Экономический gate: если после подстановки реальных SMS-расходов, поддержки и стоимости внедрения окупаемость хуже 18–24 месяцев, passkeys всё ещё могут быть оправданы безопасностью — но их нельзя продавать руководству как проект экономии.
Как переходить без большого риска
- Снять baseline: логины, SMS, неуспешные входы, password reset, обращения в поддержку, устройства и браузеры.
- Добавить passkey как опциональный способ после успешного обычного входа. Не удалять fallback.
- Разрешить несколько passkeys на один аккаунт и проверить вход с другого устройства.
- Спроектировать recovery до массового enrollment: потерянный телефон, смена ОС, удаление всех ключей.
- Запустить пилот на 50–200 пользователях или одной группе сотрудников/клиентов.
- Сравнить успешность входа, время, долю SMS fallback, тикеты поддержки, lockout и recovery success.
- Сделать passkey предпочтительным только после прохождения gate-метрик.
- Отключать пароль/SMS для отдельных сегментов последним этапом, а не первым.
Gate: когда пилот можно расширять
| Метрика пилота | Ориентир для расширения | Если не выполнено |
|---|---|---|
| Доля создавших passkey | ≥ 60% среди приглашённых | Перепроверить UX, объяснение ценности и поддержку устройств. |
| Успешность входа passkey | ≥ 98% | Искать device/browser/WebView проблемы до расширения. |
| Доля legacy/SMS входов | Снижается ≥ 40% относительно baseline | Не заявлять экономию на SMS; выяснить причину fallback. |
| Recovery success | ≥ 95% в тестовых кейсах | Не отключать привычные методы. |
| Обращения в поддержку | Не растут >20% в первые 2 недели и затем снижаются | Нужны инструкции или изменение flow. |
| Критические lockout | 0 | Стоп расширению до устранения. |
Шесть красных флагов
- нет стабильного HTTPS/домена или авторизация живёт на нескольких несогласованных доменах;
- команда не понимает, как восстанавливать аккаунт после потери всех passkeys;
- основной трафик приходит из встроенных WebView, терминалов или старых корпоративных окружений, которые не протестированы;
- используются общие логины вместо персональных аккаунтов;
- нет сбор показателей входа — невозможно отличить реальное улучшение от красивого запуска;
- SMS почти не используются и support-нагрузка минимальна: безопасность может улучшиться, но финансовая окупаемость неочевидна.
Что это значит для российского малого бизнеса
Passkeys не являются продуктом одного зарубежного сервиса. Основа — открытые стандарты WebAuthn/FIDO2, реализованные в браузерах и операционных системах. Российскому бизнесу не требуется отправлять биометрию во внешний сервис или покупать «FIDO как услугу», чтобы использовать базовый WebAuthn в собственном приложении.
Но зависимость от клиентских менеджеров учётных данных всё равно существует: пользователи хранят синхронизируемые passkeys в экосистемах своих устройств или сторонних менеджерах. Поэтому особенно важно не строить recovery, который работает только через одного конкретного иностранного провайдера, и фактически протестировать Android/iOS/Windows/macOS, браузеры и cross-device flow на своей аудитории.
Стратегия на 2026 год — passkey-first, а не passkey-only
Вопрос уже не звучит как «готовы ли passkeys вообще». Для большинства современных веб-сервисов технология готова к пилоту. Настоящий вопрос — готов ли конкретный бизнес к жизненному циклу вокруг неё: enrollment, несколько устройств, recovery, fallback, сбор показателей и поддержка.
Для администраторов, сотрудников с доступом к деньгам и чувствительным данным passkeys стоит внедрять быстрее. Для массового B2C разумнее сначала дать безопасный и удобный путь большинству пользователей, доказать показатели, затем сокращать пароль и SMS. Отключить привычную авторизацию до проверки recovery — значит не убрать риск, а перенести его в другое место.
Источники и границы фактчека
- W3C — Web Authentication Level 3 Recommendation → Нормативная спецификация WebAuthn Level 3.
- FIDO Alliance — The State of Passkeys 2026 → Оценка масштаба внедрения passkeys в 2026 году.
- FIDO Alliance — Passkeys → Phishing-resistant модель, отсутствие паролей на сервере и роль локальной биометрии.
- NIST SP 800-63B — Authenticators → OTP с ручным вводом не считается phishing-resistant; PSTN/SMS относится к restricted authenticator.
- Google for Developers — Passkeys user journeys → Постепенный переход, несколько ключей, recovery и fallback.
- Google for Developers — Server-side passkey registration → Серверная регистрация и использование проверенных WebAuthn/FIDO библиотек.
- passkeys.dev — Device Support → Поддержка passkeys и cross-device authentication на основных платформах.
- Microsoft Learn — passkeys by default и retirement SMS/voice → Изменения Microsoft для затронутых пользователей Entra.
- FIDO Alliance — миграция password + OTP на passkeys → Пилотирование, enrollment и account recovery.
- МТС Exolve — изменение тарифов на SMS с 1 августа 2026 → Пример пакетной тарификации сервисных и авторизационных SMS.
- МТС Exolve — плата за шаблоны SMS на Мегафон с 1 сентября 2026 → Пример дополнительных расходов на шаблоны.
Фактчек: 09.09.2026. Сценарные цифры и управленческие пороги в документах не являются рыночными нормативами. Для расчёта окупаемости нужно заменить их фактическими данными конкретного бизнеса.
Обсуждение
Комментарии пока недоступны. Если вы заметили неточность или хотите поделиться опытом, напишите редакции.