---
url: 'https://www.corbado.com/ru/blog/psd2-passkeys'
title: 'Passkeys и PSD2: устойчивая к фишингу MFA, соответствующая требованиям директивы'
description: 'Являются ли passkeys лучшей формой устойчивой к фишингу MFA, которая соответствует требованиям PSD2 и SCA? В этой статье мы отвечаем на все вопросы.'
lang: 'ru'
author: 'Vincent Delitz'
date: '2025-07-15T13:17:08.030Z'
lastModified: '2026-08-28T12:01:24.439Z'
keywords: 'psd2, соответствие psd2, sca, passkeys, ключи доступа'
category: 'Passkeys Strategy'
---

# Passkeys и PSD2: устойчивая к фишингу MFA, соответствующая требованиям директивы

## 1. Введение

В цифровом банкинге безопасность и пользовательский опыт больше не должны противоречить
друг другу. Passkeys объединяют эти два фактора, представляя собой устойчивую к фишингу
многофакторную аутентификацию (MFA), которая соответствует требованиям
[PSD2](https://www.corbado.com/blog/psd2-passkeys) и SCA. Passkeys — это самая безопасная и удобная форма
аутентификации, которую можно внедрить в финансовых услугах. Этот прорыв происходит в
решающий момент, когда банковская отрасль сталкивается с внедрением **Второй платежной
директивы (PSD2)** — нормативной базы, призванной повысить безопасность и
конкурентоспособность европейского банковского сектора.

**Passkeys** в этом контексте — не просто решение для соответствия требованиям, но и
отличная инновация, которая позволяет **выполнить строгие требования PSD2 без ущерба для
UX**. В этой статье мы анализируем нюансы [PSD2](https://www.corbado.com/blog/psd2-passkeys) и ее требования к
**строгой аутентификации клиента (SCA)**: становится ясно, что passkeys представляют собой
будущее устойчивой к фишингу [MFA](https://www.corbado.com/ru/blog/passkey-fallback-recovery) в банковской сфере.

## 2. Что такое PSD2?

[PSD2](https://www.corbado.com/blog/psd2-passkeys) — это законодательный акт, принятый Европейским союзом для
революционных изменений в сфере платежных услуг и банковского дела в Европе. Ее основные
**цели — усиление конкуренции, повышение защиты прав потребителей и стимулирование
инноваций** в сфере цифровых платежей. Обязывая предоставлять **открытый доступ** к
финансовой информации клиентов **одобренным третьим сторонам** (с согласия клиента), PSD2
открывает путь к более интегрированной, эффективной и удобной финансовой экосистеме.
Однако с большой силой приходит и большая ответственность, и PSD2 решает эту задачу,
**уделяя особое внимание безопасности**, в частности, через **протоколы аутентификации**.

> PSD2 — это директива, направленная на трансформацию платежей в ЕС за счет усиления
> конкуренции, безопасности и инноваций.

## 3. Что такое SCA?

В основе мер безопасности PSD2 лежит требование строгой аутентификации клиента (Strong
Customer Authentication, SCA) — протокол, разработанный для кардинального **сокращения
мошенничества и повышения безопасности электронных платежей**. SCA основана на принципе,
согласно которому электронные платежи должны быть не только **бесшовными, но и достаточно
безопасными**, чтобы противостоять различным угрозам. Эта система аутентификации
**обязательна** для поставщиков платежных услуг, банков и шлюзов электронных платежей,
действующих в рамках PSD2.

> SCA — это стандарт аутентификации в европейском банковском секторе.

### 3.1 Требования SCA

Реализация SCA в рамках PSD2 определяется несколькими критически важными требованиями:

#### Многофакторная аутентификация (MFA)

Аутентификация должна включать как минимум два элемента из следующих категорий:

- **Знание:** То, что знает только пользователь, например пароль или PIN-код.
- **Владение:** То, чем владеет только пользователь, например мобильное устройство,
  смарт-карта или аппаратный токен.
- **Неотъемлемое свойство:** То, что является неотъемлемой частью пользователя, включая
  биометрические идентификаторы, такие как отпечатки пальцев, распознавание лица или
  образцы голоса.

#### Динамическая привязка

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

#### Периодическая повторная аутентификация

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

#### Аутентификация для конкретной транзакции

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

#### Анализ на основе рисков

Поставщики платежных услуг должны использовать подход, основанный на оценке рисков, для
применения SCA, где транзакции с низким риском могут быть освобождены от SCA для упрощения
процесса оплаты без ущерба для безопасности (заметьте, здесь уже прослеживается связь с
passkeys).

#### Аудируемость

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

Вводя SCA, директива PSD2 значительно повысила стандарт безопасности транзакций в
банковском секторе. Далее мы сосредоточимся на различных факторах, участвующих в
многофакторной аутентификации (MFA). Эти факторы также влияют на требование аутентификации
для конкретной транзакции (подробнее об этом ниже).

### 3.2 Эволюция аутентификации в банковской сфере

Далее мы представим различные этапы эволюции аутентификации в банковском секторе.

#### 3.2.1 PIN-коды и TAN-коды (с 1990-х)

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

#### 3.2.2 Электронные и мобильные TAN-коды (с 2000-х)

С развитием технологий банки ввели **электронные TAN-коды (eTAN)** и **мобильные TAN-коды
(mTAN)**, которые генерировались и отправлялись на мобильное устройство клиента по SMS.
Этот метод повысил безопасность, связав TAN-код с устройством, но также создал новые
уязвимости, такие как **риск перехвата SMS** и **неудобство**, связанное с необходимостью
ожидать и управлять этими сообщениями. До появления passkeys SMS OTP все еще считались
самым удобным вариантом [2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)
для банков с точки зрения UX.

#### 3.2.3 Смарт-карты и токен-устройства (с 2000-х)

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

#### 3.2.4 Биометрия и мобильные банковские приложения (с 2010-х)

Последний этап эволюции банковской аутентификации включает
[**биометрию**](https://www.corbado.com/blog/passkeys-biometric-authentication) (отпечаток пальца или
распознавание лица) и **мобильные банковские приложения** со встроенными функциями
безопасности. Эти методы были направлены на достижение баланса между безопасностью и
удобством за счет использования уникальных биологических характеристик пользователя и
повсеместного распространения смартфонов. Однако они также требуют от клиентов проходить
процесс загрузки и настройки отдельного приложения для каждого банка, которым пользуется
клиент.

| Метод аутентификации         | Тип                            | Описание                                                                                                                                                                                                                                                         |
| ---------------------------- | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Пароли/PIN-коды              | То, что знает пользователь     | Традиционные секретные данные, которые легко внедрить и которые широко понятны.                                                                                                                                                                                  |
| SMS OTP (одноразовый пароль) | То, чем владеет пользователь   | Временный код доступа, отправляемый на телефон пользователя, представляющий фактор владения.                                                                                                                                                                     |
| Аппаратные токены            | То, чем владеет пользователь   | Физические устройства, генерирующие одноразовый код доступа для пользователя. Требует нативного приложения банка для iOS / Android.                                                                                                                              |
| OTP в мобильном приложении   | То, чем владеет пользователь   | Код доступа, генерируемый в банковском или аутентификационном приложении, часто защищенный привязкой к устройству. Требует нативного приложения банка для iOS / Android.                                                                                         |
| Биометрия                    | То, что является пользователем | Использование отпечатка пальца, распознавания лица или сканирования радужной оболочки глаза, обычно в качестве «ярлыка» в приложении банка для локальной биометрической разблокировки (например, Face ID). Требует нативного приложения банка для iOS / Android. |
| Push-уведомления             | То, чем владеет пользователь   | Подтверждение транзакций или попыток входа через уведомление в мобильном приложении. Требует нативного приложения банка для iOS / Android.                                                                                                                       |

### 3.3 Текущие проблемы аутентификации и трудности клиентов

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

- **Сложность и неудобство:** Наслоение нескольких этапов аутентификации, хотя и повышает
  безопасность, часто превращается в громоздкий процесс для пользователей. Эта сложность —
  не просто незначительное неудобство; она может отпугнуть клиентов от использования
  цифровых банковских услуг, подрывая саму цель цифровой трансформации.
- **Зависимость от устройства и платформы:** Переход к мобильной и биометрической
  аутентификации тесно привязывает пользователей к их устройствам. Эта зависимость создает
  хрупкое звено в случае кражи. Кроме того, технические сбои могут сделать банковские
  услуги недоступными, оставляя клиентов в затруднительном положении.
- **Уязвимости к фишингу:** Несмотря на улучшения, подверженность факторов аутентификации
  фишингу остается уязвимостью, которую SCA не устраняет. Традиционные факторы, такие как
  PIN-код, пароль, SMS OTP, email OTP, могут быть скомпрометированы с помощью изощренных
  фишинговых схем, подвергая риску данные и финансы клиентов.

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

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

В следующем разделе мы объясним, как это работает, на реальном примере.

## 4. Фишинг — главная проблема безопасности в банковской сфере

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

### 4.1 Теория фишинговых атак

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

1. **Инициация:** Мошенники отправляют сообщения (часто по электронной почте или SMS),
   которые имитируют официальные банковские сообщения, с логотипами и формулировками,
   которые выглядят достоверно. Эти сообщения обычно создают ощущение срочности,
   утверждая, что для решения проблемы или предотвращения закрытия счета требуются
   немедленные действия.
2. **Обман:** Сообщение содержит ссылку на мошеннический веб-сайт, который очень похож на
   официальный портал онлайн-банкинга. Не подозревая об обмане, жертва считает, что
   заходит на законный сайт своего банка.
3. **Захват:** Попав на фишинговый сайт, жертву просят ввести свои данные для
   аутентификации, например, PIN-код, или подтвердить транзакцию с помощью OTP,
   отправленного по SMS. Полагая, что они взаимодействуют со своим банком, жертва
   подчиняется, неосознанно передавая свои учетные данные злоумышленникам.
4. **Эксплуатация:** Вооружившись этими данными, мошенники могут получить доступ к
   банковскому счету жертвы, совершать несанкционированные транзакции или совершать кражу
   личных данных.

### 4.2 Пример из реальной жизни: фишинговая атака на Deutsche Bank

Представьте себе ситуацию, когда клиент Deutsche Bank получает SMS с предупреждением о
том, что его счет будет деактивирован. Сообщение содержит ссылку на веб-сайт для
подтверждения личности клиента, в URL которого есть слово deutschebank и соответствующий
SSL-сертификат. Этот сайт, точная копия страницы входа Deutsche Bank (как вы можете видеть
на скриншотах ниже), запрашивает у клиента PIN-код для онлайн-банкинга, а затем — SMS OTP
в реальном времени (не видно на скриншотах по соображениям безопасности). Клиент, не
подозревая об этом, вводит эту информацию на фишинговом сайте, что позволяет
злоумышленникам получить полный доступ к его счету в Deutsche Bank и потенциально
перевести огромные суммы денег на другие счета.

Это фишинговое SMS с призывом восстановить доступ к банковскому счету (скриншоты доступны
только на немецком языке):

![](https://www.corbado.com/website-assets/65c3d9a02574860c37bc3fe0_psd2_passkeys_sms_phishing_d07e47ea91.jpg)

Это фишинговый сайт злоумышленников
([https://deutschebank-hilfe.info](https://deutschebank-hilfe.info)):

![](https://www.corbado.com/website-assets/65c3d9ad744b9a3bf7bd3d17_psd2_passkeys_phishing_website_b89050fbac.jpg)

Это оригинальный сайт для сравнения
([https://meine.deutsche-bank.de](https://meine.deutsche-bank.de)), который злоумышленники
скопировали почти идеально (они только убрали предупреждение о фишинге внизу):

![](https://www.corbado.com/website-assets/65c3d9b8ebaa3c8363b9eb2d_psd2_passkeys_original_website_73c7e5cef5.jpg)

Клиенты, привыкшие входить в систему через этот идентичный интерфейс и использовать SMS
OTP в качестве фактора аутентификации, могут легко стать жертвами таких атак. Существует
значительная экосистема пакетов с открытым исходным кодом, предназначенных для фишинговых
атак на системы OAuth или банковские системы (например,
[https://github.com/gophish/gophish](https://github.com/gophish/gophish)) в целях
исследования безопасности. Однако эти системы могут быть легко адаптированы для
злонамеренных целей.

**Фишинг в банковском секторе становится все более точным** с каждой утечкой данных в
даркнете. Как правило, платежная информация, такая как IBAN, также является частью этих
утечек. Хотя эта информация не может быть использована для прямого хищения денег, ее можно
использовать в целевых фишинговых атаках, где злоумышленник знает, что цель действительно
является клиентом банка.

### 4.3 Важность факторов аутентификации, устойчивых к фишингу

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

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

> Passkeys можно использовать только на том домене, на котором они были зарегистрированы
> (ID доверяющей стороны). Технически невозможно использовать их на фишинговом домене или
> отправить passkeys злоумышленнику.

### 4.4 Как бороться с фишингом?

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

1. **Обучение клиентов:** Банки должны постоянно информировать своих клиентов о рисках
   фишинга и о том, как распознавать мошеннические сообщения.
2. **Внедрение аутентификации, устойчивой к фишингу:** Переход на методы аутентификации,
   которые не основаны на информации, которую можно выманить или перехватить, тем самым
   закрывая дверь для многих попыток фишинга.
3. **Усовершенствование систем обнаружения мошенничества:** Использование передовой
   аналитики и машинного обучения для обнаружения и предотвращения несанкционированных
   транзакций, даже если фишеры получают какие-либо данные для аутентификации.

Хотя фишинг остается серьезной угрозой для банковского сектора, внедрение методов
аутентификации, устойчивых к фишингу, таких как passkeys, представляет собой критический
шаг вперед в защите онлайн-банкинга от мошенников. **Устранив самое слабое звено —
подверженность факторов аутентификации фишингу — банки могут значительно повысить
безопасность активов и личной информации своих клиентов.**

До сих пор Европейский центральный банк и местные органы банковского надзора (например,
BaFin) не высказали свою позицию относительно того,
[будут ли passkeys в целом классифицироваться как 2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)
или как банки должны их использовать.

В следующем разделе мы постараемся объяснить, почему мы считаем, что passkeys
соответствуют требованиям PSD2.

## 5. Соответствуют ли passkeys требованиям PSD2?

В обсуждениях с заинтересованными сторонами из секторов платежей, финтеха и банковского
дела постоянно возникает вопрос: **Соответствуют ли passkeys требованиям PSD2 и могут ли
они служить единственной формой аутентификации в банковских сценариях?** Взаимосвязь между
passkeys и Второй платежной директивой (PSD2) в Европейском союзе является сложной и
требует детального изучения. Для пояснения, passkeys обычно делятся на два типа:
**синхронизируемые passkeys (для нескольких устройств)** и **несинхронизируемые passkeys
(для одного устройства)**, каждый из которых имеет свои особенности в отношении
соответствия PSD2:

|                                             | Синхронизируемые passkeys                                                                                                                                                                     | Несинхронизируемые passkeys         |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |
| **Доступность на устройствах**              | Несколько устройств                                                                                                                                                                           | Одно устройство                     |
| **Управляется**                             | Операционной системой                                                                                                                                                                         | Требуется дополнительное ПО         |
| **Приватный ключ**                          | Загружается в облачную учетную запись операционной системы <br/>(например, Связка ключей iCloud, Менеджер паролей Google) или сторонний менеджер паролей <br/>(например, 1Password, Dashlane) | Остается на устройстве пользователя |
| **Привязка к устройству**                   | Нет                                                                                                                                                                                           | Да                                  |
| **Создается резервная копия**               | Да                                                                                                                                                                                            | Нет                                 |
| **Традиционное мнение о соответствии PSD2** | Нет (?)                                                                                                                                                                                       | Да                                  |

Соблюдение нормативных требований очень важно для регулируемых организаций, таких как
банки и [страховые компании](https://www.corbado.com/passkeys-for-insurance). Однако изменение политик
соответствия может занять много времени. В случае с passkeys **главное преимущество в
безопасности — их устойчивость к фишингу,** поскольку клиенты не могут случайно раскрыть
эту информацию злоумышленникам.

## 6. Почему синхронизируемые passkeys не представляют риска

Хотя passkeys значительно повышают безопасность, будучи устойчивыми к фишингу, они
действительно переносят часть риска на облачную учетную запись клиента, такую как Связка
ключей iCloud от Apple. Это делает облачную учетную запись более привлекательной целью для
злоумышленников. Однако **сервисы, такие как Apple iCloud, имеют надежные меры
безопасности**, особенно для функций, поддерживающих passkeys.

Во-первых, использование passkeys в iCloud зависит от включенной
[двухфакторной аутентификации (2FA)](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)
в учетной записи, что добавляет дополнительный уровень безопасности. Это означает, что
даже если злоумышленник знает пароль от iCloud клиента, ему все равно потребуется доступ к
доверенному устройству или номеру телефона для получения кода
[2FA](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication).

Apple, и аналогично Google для своих учетных записей, вкладывают значительные ресурсы в
обеспечение безопасности этих облачных сервисов. Протоколы безопасности для учетных
записей, поддерживающих passkeys в облаке, строги, что делает **взлом практически
невозможным для неавторизованных пользователей**. Этот высокий стандарт безопасности
поддерживается постоянными обновлениями и исправлениями безопасности (и они также ввели
passkeys для своих учетных записей, см. эту статью в блоге).

Более того, кража устройств или облачных учетных записей, хотя и является потенциальным
риском, не является самым распространенным вектором атак для банковских приложений. В
случае повышенных требований к безопасности, например, для подозрительных транзакций,
банки могут продолжать использовать SMS OTP в качестве дополнительного фактора. **Заменив
PIN-код / пароль на passkeys**, первый фактор аутентификации становится неуязвимым для
фишинга, что значительно снижает риск успешных фишинговых атак. **Третий фактор может быть
введен для транзакций**, которые помечены как подозрительные, обеспечивая надежную защиту.

> Хотя поверхность атаки может сместиться, **общий уровень безопасности усиливается**, что
> делает passkeys привлекательным выбором для регулируемых организаций, таких как банки и
> [страховые компании](https://www.corbado.com/passkeys-for-insurance), стремящихся повысить безопасность
> клиентов без ущерба для удобства использования.

## 7. Как необанки заставляют регуляторов действовать

Вопреки традиционным (осторожным) взглядам на соответствие PSD2,
[Finom](https://www.corbado.com/blog/finom-passkeys) и [Revolut](https://www.corbado.com/blog/revolut-passkeys) решили, что **защита
данных клиентов важнее**, и поэтому используют passkeys, несмотря на отсутствие публичного
решения на европейском уровне о том, как банковский надзор должен рассматривать passkeys в
контексте соответствия PSD2. Необанки и финтех-компании, такие как
[Finom](https://www.corbado.com/blog/finom-passkeys) и [Revolut](https://www.corbado.com/blog/revolut-passkeys), бросают вызов
статус-кво и тем самым влияют на регуляторный ландшафт в отношении мер аутентификации,
предписанных PSD2.

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

Смелый шаг [Finom](https://www.corbado.com/blog/finom-passkeys) и [Revolut](https://www.corbado.com/blog/revolut-passkeys) по внедрению
passkeys подчеркивает критический аспект регуляторного соответствия: оно должно
заключаться не в жестком следовании стандартам, а в достижении основополагающих целей этих
стандартов, которыми в данном случае являются **максимальная безопасность данных и
транзакций клиентов**. Выбирая приоритет защиты данных над строгим соблюдением
традиционных моделей соответствия, эти необанки устанавливают новые стандарты для отрасли.

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

## 8. Какие регуляторные изменения необходимы?

С регуляторной точки зрения существует острая необходимость в ясности и адаптации для
учета таких достижений, как passkeys, в рамках соответствия PSD2. **Мы призываем ЕС занять
определенную позицию по passkeys,** признав их превосходной формой многофакторной
аутентификации (MFA), которая соответствует основным целям PSD2 по укреплению безопасности
и сокращению мошенничества в экосистеме цифровых платежей.

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

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

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

## 9. Рекомендации для банков и финтех-компаний

Внедрение passkeys в банковской и финтех-сфере является ярким примером инновации, которая
значительно повышает как безопасность, так и пользовательский опыт. В нашей статье мы
обосновали потенциал passkeys как передового решения для аутентификации, которое
соответствует строгим требованиям безопасности PSD2 и одновременно снижает
распространенные угрозы, такие как фишинг. Необанки / финтех-компании, такие как Finom и
Revolut, создали _прецедент, интегрировав passkeys_ в свои системы безопасности,
продемонстрировав их эффективность и клиентоориентированный подход.

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

1. **Взаимодействие с местными регуляторами:** Традиционные банки должны проактивно
   взаимодействовать со своими местными регуляторными органами и органами банковского
   надзора для обсуждения внедрения passkeys. Этот диалог должен быть направлен на
   прояснение регуляторных позиций и создание основы для интеграции passkeys в
   существующую структуру соответствия. Проявляя инициативу, банки могут способствовать
   формированию регуляторной среды, поддерживающей инновационные методы аутентификации.
2. **Изучение лучших практик необанков:** Традиционным банкам крайне важно наблюдать и
   учиться у необанков, которые успешно внедрили passkeys. Изучение этих лучших практик
   предоставит ценную информацию об операционных, технических и клиентских аспектах
   развертывания passkeys. Этот обмен знаниями может помочь традиционным банкам в
   разработке собственных стратегий по внедрению passkeys.
3. **Стратегический переход на passkeys:** Имея ясность в регуляторных вопросах и
   понимание лучших практик, традиционные банки могут разработать комплексный план по
   переводу клиентов на аутентификацию на основе passkeys. Этот план должен включать
   образовательные кампании для клиентов, объясняющие преимущества и использование
   passkeys, поэтапное внедрение для обеспечения плавного перехода и постоянную оценку для
   оперативного решения любых проблем. Оптимизированные
   [процессы создания passkeys](https://www.corbado.com/faq/optimize-passkey-creation-flows-mobile-desktop) с
   подсказками после входа и интеллектуальные процессы
   [входа по passkeys](https://www.corbado.com/blog/passkey-login-best-practices) критически важны для достижения
   порога внедрения в 50%+, когда от паролей можно будет отказаться.

## 10. Как Corbado помогает банкам внедрить passkeys, соответствующие требованиям PSD2

Переходя от теории к практике, банкам необходимы инструменты, которые сократят разрыв
между нормативными требованиями PSD2/SCA и реальным внедрением passkeys.
[Corbado Connect](https://www.corbado.com/connect) предлагает уровень
[интеллектуального управления passkeys (passkey intelligence)](https://docs.corbado.com/corbado-connect/features/passkey-intelligence),
который надстраивается над вашим существующим стеком идентификации — миграция
пользователей не требуется.

[Video: Passkey intelligence](https://www.corbado.com/videos/connect/passkey-intelligence.mp4) ([See how Corbado Connect ships this](https://www.corbado.com/connect))

### Доказательства для вопроса о факторе владения

Дискуссия, которую разбирает эта статья, сводится к одному вопросу, который может задать
регулятор: какая доля ваших учётных данных привязана к устройству, а какая
синхронизируется. [Authenticator](https://www.corbado.com/glossary/authenticator) Inventory в
[Corbado Observe](https://www.corbado.com/observe) отвечает на него на основе вашей собственной базы
пользователей, а не на основе трактовки. Он определяет аутентификатор, стоящий за каждыми
учётными данными, через [FIDO](https://www.corbado.com/ru/glossary/cda) Metadata Service, поэтому распределение
показывается по каждой модели аутентификатора вместе с её уровнем сертификации, а рядом
видна доля пользователей, у которых вообще есть аппаратный ключ.

Так ваша позиция по SCA становится тем, что можно показать. Какую трактовку вы
отстаиваете, по-прежнему остаётся вашей собственной оценкой рисков, но совокупность, к
которой она применяется, перестаёт быть оценкой на глаз.

### Правила раскатки во время отказа от OTP

Банки редко переключают метод аутентификации сразу для всех, а в рамках PSD2 они этого и
не могут. [Corbado Connect](https://www.corbado.com/connect) предоставляет постепенную раскатку в виде
настраиваемых наборов правил: условия по бренду и модели устройства, версии платформы,
браузеру и [WebView](https://www.corbado.com/blog/native-app-passkeys), решение allow, block или sampling для
каждого правила, а также kill switch, который возвращает трафик passkeys в существующий
поток.

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

> **Позиция Corbado относительно PSD2/SCA и passkeys:** Passkeys (как привязанные к
> устройству, так и синхронизируемые) могут соответствовать требованиям SCA. Каждое
> учреждение должно проводить собственную оценку рисков SCA, но очевидно одно: passkeys по
> своей сути обеспечивают два фактора SCA — владение (закрытый ключ в аппаратном модуле
> безопасности или облачной связке ключей) + неотъемлемое свойство (биометрия) или знание
> (PIN-код). Дебаты о факторе «владения» имеют нюансы, но разрешимы — отрасль сходится к
> трем подходам: (1) **Passkeys как есть** (например, Revolut, Finom) — неотъемлемое
> свойство + владение через устройство с приватным ключом, (2) **Passkeys + привязка к
> cookie/сессии** (например, [PayPal](https://www.corbado.com/blog/paypal-passkeys), Comdirect) — дополнительный
> сигнал владения для консервативной интерпретации, (3) **Криптографическая привязка
> (DBSC/DPoP)** — аппаратное подтверждение владения, самая надежная гарантия. Единой
> «правильной» интерпретации пока не существует. Требуется подход к SCA, ориентированный
> на результаты, с акцентом на доказуемую устойчивость к фишингу, а не на жесткую
> категоризацию факторов. [Динамическая привязка](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
> остается отдельным требованием для платежей даже при использовании passkeys.
