Проблемы ключей доступа на «День 2»: 5 рисков после запуска

1. Введение: Риски ключей доступа после запуска#

Не внедряйте ключи доступа.

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

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

Реализация сервера WebAuthn не слишком сложна. Настоящая проблема — это все остальное. Эффективная работа с ключами доступа в больших масштабах требует заблаговременного планирования. Вам нужно подумать обо всех проблемах «Дня 2» — операционных реалиях, которые всплывают только после того, как вы начали развертывание ключей доступа.

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

2. Что такое проблемы ключей доступа на «День 2»?#

В инженерии «День 1» — это когда вы создаете и запускаете продукт. «День 2» — когда вы эксплуатируете, обслуживаете и масштабируете то, что запустили. Для ключей доступа «День 1» может быть простым:

• интегрируйте сервер WebAuthn в ваш корпоративный стек
• добавьте фронтенд-процессы и запустите.

Большинство команд могут запустить базовую реализацию ключей доступа за несколько дней или недель.

«День 2» — это этап, на котором проекты терпят неудачу. Это момент, когда реальные пользователи на реальных устройствах с реальными пограничными случаями взаимодействуют с вашей системой ключей доступа. Это когда вы обнаруживаете, что блестящая демонстрация, которая идеально работала на вашем MacBook, ломается на ноутбуке Windows с Chrome за корпоративным прокси-сервером. Это когда ваша служба поддержки завалена тикетами «Я больше не могу войти».

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

Вот пять проблем «Дня 2», которые мы рассмотрим:

• Проблема 1: Восстановление и резервные варианты трудно обезопасить
• Проблема 2: Пограничные случаи между устройствами и экосистемами нарушают работу ключей доступа
• Проблема 3: Нативные приложения многократно усложняют работу с ключами доступа
• Проблема 4: Принятие пользователями — это продуктовая, а не техническая проблема
• Проблема 5: Изменения платформ незаметно ломают ключи доступа

3. Проблема 1: Восстановление и резервные варианты трудно обезопасить#

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

3.1 Риск блокировки учетных записей в больших масштабах#

Представьте пользователя, который регистрирует ключ доступа на своем iPhone, а затем теряет этот iPhone. Обычно большая часть этих случаев восстановления сейчас обрабатывается менеджером учетных данных (скорее всего, iCloud Keychain на iPhone). Пока у пользователя есть доступ к своей учетной записи Apple, у него есть синхронизируемые ключи доступа для входа на новом устройстве. Но что, если у него больше нет доступа к этой облачной учетной записи? Вот тут и вступает в игру ваш обычный путь восстановления.

Допустим, вы предполагаете, что закрытый ключ все еще доступен на устройстве, с которого пользователь пытается войти, поэтому вы запускаете церемонию входа WebAuthn. Это приведет к появлению модального окна ОС / браузера с просьбой к пользователю «войти с помощью вашего ключа доступа на другом устройстве». В принципе, пользователь теперь заблокирован в своей учетной записи. Нет другого устройства, где хранится ключ доступа. Пользователь крайне сбит с толку. Умножьте это на тысячи пользователей, и у вас возникнет кризис поддержки.

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

3.2 Проектирование резервного варианта без возврата к фишингу#

На наш взгляд, правильный подход — это многоуровневое восстановление:

1. Синхронизируемые ключи доступа как основная стратегия: убедитесь, что пользователи создают синхронизируемые ключи доступа (через iCloud Keychain, Google Password Manager или стороннего провайдера ключей доступа), чтобы потеря устройства не означала потерю учетных данных
2. Аутентификация между устройствами как второй уровень: позвольте пользователям проходить аутентификацию с другого устройства, где доступен другой ключ доступа, путем сканирования QR-кода
3. Проверка личности (IDV) как третий уровень: предложите автоматизированную IDV с проверками живости вместо возврата к паролям/OTP.
4. Цифровые проверяемые учетные данные (verifiable credentials) как четвертый уровень: это самая безопасная, сохраняющая конфиденциальность и удобная для пользователя версия восстановления учетной записи. Это позволяет пользователю использовать свои цифровые проверяемые учетные данные (например, цифровой национальный идентификатор или mDL) для подтверждения своей личности с использованием стандартных API (например, Digital Credentials API). Эта технология довольно новая, и ее внедрение невелико, но она будет играть важную роль в ближайшие месяцы и годы.

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

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

3.3 В чем ошибается большинство команд#

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

4. Проблема 2: Пограничные случаи между устройствами и экосистемами нарушают работу ключей доступа#

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

4.1 Фрагментация экосистемы реальна#

Экосистема ключей доступа охватывает три основные платформы (Apple, Google и Microsoft), несколько браузеров (Chrome, Safari, Firefox и Edge), десятки провайдеров ключей доступа / менеджеров учетных данных (например, 1Password, Bitwarden, Dashlane и другие) и бесчисленное множество комбинаций ОС/браузера/устройства. Каждая комбинация может вести себя немного по-разному, например:

• Apple по умолчанию синхронизирует ключи доступа через iCloud Keychain на iOS, iPadOS и macOS, но не на Windows или Android
• Google выполняет синхронизацию через Google Password Manager на Android и Chrome, но работа на iOS отличается (вам нужно настроить ее вручную)
• Windows имеет собственное поведение ключей доступа, которое существенно отличается от других платформ
• Менеджеры паролей каждый по-своему обрабатывает создание и выбор ключей доступа, иногда конфликтуя с собственными подсказками платформы

4.2 Процессы аутентификации на разных устройствах#

Когда пользователь создает ключ доступа на своем iPhone, но хочет войти на ноутбуке Windows, он может использовать аутентификацию между устройствами (обычно через QR-код и Bluetooth). Этот процесс работает, но он хрупкий:

• Требуется, чтобы Bluetooth был включен на обоих устройствах
• Корпоративные брандмауэры и политики MDM могут мешать, поскольку в фоновом режиме настраивается туннель
• UX сильно различается в разных браузерах
• Пользователи часто не понимают, что происходит или почему они сканируют QR-код

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

4.3 Несогласованность браузеров и ОС#

Даже на одном и том же устройстве разные браузеры ведут себя по-разному. Chrome на macOS показывает другие модальные окна ключей доступа, чем Safari на macOS. У Firefox свое собственное поведение. Client hints и обнаружение user agent становятся критически важными для предоставления правильных процессов нужному пользователю, но их правильный парсинг для всех комбинаций — это бремя обслуживания, которое никогда не заканчивается.

5. Проблема 3: Нативные приложения многократно усложняют работу с ключами доступа#

Тестирование ключей доступа и QA уже являются проблемой для веб-приложений (мы подробно рассматриваем это в Проблеме 5: Изменения платформ). Но если в вашем продукте также есть нативные приложения для iOS и Android, сложность возрастает многократно из-за архитектурных решений и специфичного для платформы поведения, с которым никогда не сталкиваются команды, работающие только с вебом.

5.1 Решения: нативные приложения против WebView#

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

Только на iOS вы можете выбирать между WKWebView, SFSafariViewController, SFAuthenticationSession и ASWebAuthenticationSession — каждый с различными характеристиками поддержки ключей доступа. На Android Chrome Custom Tabs ведут себя иначе, чем стандартные WebViews. Это решения, которые веб-командам никогда не приходится принимать, и каждый выбор создает свою собственную поверхность обслуживания.

5.2 Поведение, специфичное для платформы, в нативных приложениях#

Помимо архитектурного решения, iOS и Android обрабатывают ключи доступа по-разному на уровне ОС:

• iOS глубоко интегрирует ключи доступа в системный менеджер учетных данных со специфическим поведением автозаполнения, которое может меняться с каждой версией iOS
• Android маршрутизирует запросы ключей доступа через Credential Manager API, который взаимодействует с несколькими провайдерами ключей доступа одновременно
• Состояния ошибок, поведение при тайм-аутах и запросы к пользователю различаются в зависимости от платформы. Та же самая отмена пользователем проявляется как NotAllowedError в вебе, но как SimpleAuthenticationServices.AuthorizationError на iOS и User cancelled the operation в Credential Manager на Android — см. ошибки WebAuthn в продакшене для полного кроссплатформенного сопоставления ошибок
• Циклы проверки в магазинах приложений добавляют задержки, когда вам нужно выпустить срочные исправления для регрессий ключей доступа

5.3 Утроенная поверхность QA#

Если вы управляете как веб-приложением, так и нативными приложениями, вы не просто удваиваете усилия по QA, но вы их утраиваете. Web, iOS и Android — каждый из них работает как отдельная среда ключей доступа, требующая независимого сквозного тестирования и мониторинга. И в отличие от веба, где вы можете развернуть исправление мгновенно, исправления нативных приложений ограничены циклами проверки в магазинах приложений.

6. Проблема 4: Принятие пользователями — это продуктовая, а не техническая проблема#

«Ключи доступа поддерживаются» не означает «ключи доступа используются». Если у вас нет стратегии развертывания и измерения, уровень принятия вас разочарует, и проект будет признан неудачным внутри компании.

6.1 Почему низкое принятие убивает ваш проект#

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

Бизнес-кейс внедрения ключей доступа силен, но только если внедрение действительно происходит. Мы видели, как компании запускали ключи доступа с отличной технической реализацией, которая достигала менее 5% внедрения, потому что никто не думал о стратегии развертывания и принятия.

6.2 Внедрение требует целенаправленной продуктовой работы#

Стимулирование внедрения ключей доступа — это продуктовая задача, требующая:

• Прогрессивной регистрации: подталкивание пользователей к созданию ключей доступа в нужные моменты (например, после успешного входа, во время проверки безопасности учетной записи)
• Четкой коммуникации с пользователями: объяснение того, что такое ключи доступа и почему они лучше, на языке, понятном нетехническим пользователям
• Запросов с учетом устройства: предложение создания ключа доступа только тогда, когда устройство пользователя действительно его хорошо поддерживает, избегая разочаровывающего опыта на неподдерживаемых конфигурациях
• Инфраструктуры измерения: отслеживание показателей создания ключей доступа, показателей успешности входа, резервных вариантов и отказов для выявления и устранения узких мест

6.3 Как выглядит «хорошее» внедрение#

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

Если ваши цифры принятия выглядят как колонка «слабо» через три месяца, проект в беде. Без аналитики для измерения этого вы даже не узнаете об этом.

7. Проблема 5: Изменения платформ незаметно ломают ключи доступа#

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

Недавно мы опубликовали всесторонний обзор ошибок WebAuthn, возникающих в продакшене.

7.1 Почему ключи доступа уникальным образом страдают от изменений платформы#

В отличие от паролей (которые являются просто строками, проверяемыми вашим сервером), ключи доступа зависят от глубокой интеграции с операционной системой, браузером и менеджером учетных данных. Когда Apple выпускает новую версию iOS, запросы на создание ключей доступа могут выглядеть иначе. Когда Chrome обновляет свою логику автозаполнения, ваш процесс входа может сломаться. Когда менеджер паролей выпускает новую версию, он может начать перехватывать запросы ключей доступа способами, которые вы не предвидели.

Один из недавних примеров — баг в iOS 26.2, из-за которого isUserVerifyingPlatformAuthenticatorAvailable() возвращает false во всех браузерах, отличных от Safari (Chrome, Edge, Firefox), что требует обходного пути — логики обнаружения с учетом платформы с использованием getClientCapabilities().

7.2 Мониторинг не является необязательным#

Чтобы быть в курсе всех возможных ошибок и отслеживать внедрение, вам нужно настроить стек наблюдаемости аутентификации. Мы рекомендуем иметь как минимум следующее:

• Аналитику аутентификации в реальном времени: отслеживание показателей успеха и неудач по комбинациям ОС, браузера и провайдера ключей доступа
• Мониторинг с учетом версий: обнаружение того, когда новая версия ОС или браузера вызывает всплеск ошибок или возвратов к резервным вариантам. Различайте ожидаемые ошибки (прерывания пользователем, проявляющиеся как NotAllowedError) и неожиданные ошибки (всплески AbortError из-за багов параллелизма или новые ошибки ключей доступа Credential Manager после обновления Android)
• Оповещения: получение уведомлений до того, как ваши пользователи начнут отправлять тикеты в поддержку
• Возможность быстрого реагирования: способность быстро применять исправления или отключать ключи доступа для затронутых комбинаций устройств

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

7.3 Текущие расходы на техническое обслуживание#

Истинная стоимость реализации ключей доступа — это не первоначальная сборка. Это постоянное техническое обслуживание:

• Мониторинг изменений платформ в iOS, Android, Windows, macOS и во всех основных браузерах
• Тестирование каждого обновления на предмет регрессий
• Обновление фронтенд SDK при изменении API браузеров
• Поддержание совместимости с растущей экосистемой провайдеров ключей доступа
• Документирование и информирование вашей службы поддержки об изменениях

8. Когда вам следует (или не следует) внедрять ключи доступа#

Учитывая эти проблемы «Дня 2», вот честная оценка того, когда вам следует, а когда не следует запускать ключи доступа.

8.1 Не внедряйте ключи доступа, если#

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

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

8.2 Внедряйте ключи доступа, если#

• Вы учли все пять проблем «Дня 2», описанных выше
• У вас есть продуктовые, инженерные, безопасные и аналитические возможности для поддержки постоянного развертывания
• Вы заложили в бюджет постоянное обслуживание, а не только первоначальную сборку
• У вас есть стратегия поэтапного развертывания с четкими целями внедрения
• Вы работаете с таким партнером, как Corbado, который берет на себя операционную сложность

8.3 Решение: создать или купить#

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

9. Как Corbado решает проблемы ключей доступа на «День 2»#

Corbado существует именно потому, что проблемы «Дня 2» сложны. Наша платформа берет на себя операционную сложность, поэтому вам не нужно создавать и обслуживать ее самостоятельно.

9.1 Восстановление и резервные варианты#

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

9.2 Совместимость с различными устройствами#

Наши фронтенд SDK предварительно протестированы на тысячах комбинаций ОС, браузеров и провайдеров ключей доступа. Обнаружение устройств, обработка условного пользовательского интерфейса (conditional UI) и маршрутизация резервных вариантов происходят автоматически. Когда новая версия браузера что-то ломает, мы исправляем это в нашем SDK до того, как ваши пользователи это заметят.

9.3 Поддержка нативных приложений#

Corbado поддерживает реализацию ключей доступа как в нативных приложениях, так и в WebView с помощью SDK, которые абстрагируют различия платформ. Вы фокусируетесь на UX вашего приложения, в то время как мы занимаемся инфраструктурой ключей доступа для iOS и Android.

9.4 Аналитика внедрения#

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

9.5 Мониторинг изменений платформы#

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

10. Заключение#

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

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

Моя честная рекомендация: если у вас нет ноу-хау и ресурсов, чтобы сделать ключи доступа правильно, не внедряйте их. Либо инвестируйте в возможности (продукт, инженерия, безопасность и аналитика), либо работайте с партнером, который уже решил эти проблемы. Худший исход — это полусырое развертывание ключей доступа, которое откатывается назад, потому что никто не планировал «День 2».

О Corbado

Corbado — это Passkey Intelligence Platform для CIAM-команд, обеспечивающих аутентификацию пользователей в крупных масштабах. Мы показываем то, что не видят логи IDP и общие инструменты аналитики: какие устройства, версии ОС, браузеры и менеджеры учётных данных поддерживают passkey, почему регистрации не превращаются в логины, где сбоит WebAuthn-поток и когда обновление ОС или браузера тихо ломает вход — всё это без замены Okta, Auth0, Ping, Cognito или вашего собственного IDP. Два продукта: Corbado Observe добавляет наблюдаемость для passkey и любых других способов входа. Corbado Connect даёт managed passkey со встроенной аналитикой (рядом с вашим IDP). VicRoads использует passkey для более чем 5 млн пользователей с Corbado (+80 % активации passkey). Поговорить с экспертом по passkey →

Часто задаваемые вопросы#

Какие 5 проблем «Дня 2» приводят к провалу проектов с ключами доступа после запуска?#

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

Как обрабатывать аутентификацию по ключу доступа с нескольких устройств для корпоративных пользователей на Windows, которые зарегистрировались на iPhone?#

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

Какие метрики внедрения ключей доступа следует выбрать в качестве целевых и отслеживать после запуска?#

Высокий уровень внедрения означает уровень создания ключей доступа выше 60% от числа подходящих пользователей и уровень входа по ключам доступа выше 40% от всех входов. Показатели ниже 10% для создания и ниже 5% для входа после трех месяцев сигнализируют о провальном развертывании. Для измерения этого требуется выделенная инфраструктура, отслеживающая показатели создания, успешного входа, резервных вариантов и отказов в разбивке по комбинациям устройств и ОС.

Следует ли создавать ключи доступа нативно в мобильном приложении или использовать WebView?#

Нативная реализация обеспечивает лучший в своем классе UX, но требует отдельных кодовых баз для iOS и Android со специфичной для платформы обработкой API и независимыми конвейерами QA. Подходы на основе WebView используют общую веб-логику, но вносят несоответствия в поддержку ключей доступа в зависимости от типа WebView. Только на iOS выбор между WKWebView, SFSafariViewController и ASWebAuthenticationSession влечет за собой различные характеристики поддержки ключей доступа, которые необходимо оценить до принятия решения об архитектуре.

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

Упрощенное восстановление, такое как сброс по электронной почте, снова вводит каналы, подверженные фишингу, в то время как чрезмерно строгое восстановление, такое как обязательные аппаратные ключи безопасности, приводит к отказам от использования. Рекомендуемый подход является многоуровневым: синхронизируемые ключи доступа как основная стратегия, кросс-платформенная аутентификация по QR-коду как второй уровень, автоматизированная проверка личности с проверкой живости (liveness checks) как третий и цифровые проверяемые учетные данные (verifiable credentials) как четвертый. Какие уровни реализовывать, зависит от вашей модели угроз, пользовательской базы и нормативных требований.