WebAuthn Level 3 стал стандартом W3C: что это значит для passkeys

25 августа 2026 года Web Authentication Level 3 перешёл в статус W3C Recommendation. FIDO Alliance отдельно отметил это событие 31 августа: WebAuthn Level 3 теперь является стабильной рекомендацией W3C и продолжает стандарт, на котором строятся современные passkeys.

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

Ниже — что такое WebAuthn, как он связан с passkeys и какие практические вопросы нужно решить до внедрения.

Что произошло в августе 2026 года

FIDO Alliance сообщил, что 25 августа 2026 года WebAuthn Level 3 стал полной W3C Recommendation. В рабочей повестке W3C Web Authentication Working Group от 26 августа уже указана опубликованная версия REC-webauthn-3-20260825.

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

Что такое WebAuthn

WebAuthn — браузерный API для создания и использования публично-ключевых учётных данных. Сайт, или relying party, получает публичную часть ключа и проверяет криптографическое подтверждение входа. Секретный приватный ключ остаётся у аутентификатора и не передаётся сайту как обычный пароль.

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

Как WebAuthn связан с passkeys

FIDO Alliance описывает passkeys как учётные данные FIDO, построенные на стандартах WebAuthn и CTAP. WebAuthn отвечает за взаимодействие веб-приложения с браузером, а CTAP используется для взаимодействия платформы с внешними аутентификаторами.

Почему passkeys устойчивее к фишингу

Ключевой принцип WebAuthn — credential привязан к конкретному relying party. Пользователь не вводит общий секрет, который можно скопировать с фальшивой страницы и повторно использовать на настоящем сайте.

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

Что меняется для разработчика сайта

Переход WebAuthn Level 3 в Recommendation — хороший повод пересмотреть архитектуру входа, особенно если продукт уже планирует passwordless или phishing-resistant authentication.

• проверить поддержку нужных WebAuthn-возможностей в целевых браузерах и устройствах;
• отделить регистрацию credential от обычной пользовательской сессии;
• на сервере валидировать challenge, origin, RP ID и подпись;
• продумать добавление и удаление нескольких credential;
• сделать понятный recovery без возврата к самому слабому каналу;
• логировать чувствительные изменения учётной записи.

Passkeys не равны «одна кнопка и готово»

Самый сложный участок часто находится не в WebAuthn API, а вокруг него. Пользователь меняет телефон, теряет аппаратный ключ, входит с нового устройства или хочет отключить старый credential. Эти сценарии нужно проектировать до production-запуска.

Пример текущего движения рынка

14 августа 2026 года FIDO Alliance описал совместную работу OpenAI и Yubico над аппаратно защищёнными passkeys для Advanced Account Security. Это не означает, что всем сайтам нужен физический ключ, но показывает направление: для чувствительных аккаунтов passkeys могут дополняться hardware-backed аутентификаторами.

Выбор между синхронизируемыми passkeys, платформенным аутентификатором и аппаратным ключом зависит от модели угроз и аудитории.

Нужно ли полностью убирать пароль

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

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

WebAuthn на WordPress

На WordPress passkeys могут применяться к администраторам, редакторам или пользовательским аккаунтам. Но устанавливать первый найденный security-плагин без теста не стоит: авторизация связана с критичным доступом к сайту.

Перед внедрением нужно проверить совместимость с текущей формой логина, WooCommerce-аккаунтами, кастомным кабинетом, SSO, кешированием и защитными плагинами.

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

Что проверить перед production

Когда passkeys особенно полезны

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

Когда не стоит делать миграцию в спешке

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

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

Вывод

WebAuthn Level 3 в статусе W3C Recommendation — ещё один сигнал, что passkeys становятся нормальной частью веб-аутентификации. Но качество внедрения определяется не названием стандарта, а серверной проверкой, управлением credential и recovery-сценариями.

Если нужно оценить passkeys для WordPress, личного кабинета или кастомного сайта, можно прислать текущую схему авторизации в A.S Groups. Сначала разберём роли, fallback и риски, затем выберем вариант реализации.

Официальные источники

• FIDO Alliance — WebAuthn Level 3 becomes a W3C Recommendation
• W3C — Web Authentication Level 3
• W3C Web Authentication Working Group — 26 Aug 2026 agenda
• FIDO Alliance — OpenAI and Yubico passkeys case