R: Створена сторінка: {{DISPLAYTITLE:2FA для ERP: двофакторна автентифікація в K2 ERP}} {{SEO |title=2FA для ERP |description=Стаття про 2FA для ERP-систем: що таке двофакторна автентифікація, чим 2FA відрізняється від MFA, де її вмикати в K2 ERP, які методи безпечніші, ризики SMS, TOTP, push, FIDO2, dashboard та Acceptance Criteria. |keywo...

2026-05-07T19:13:26Z

Створена сторінка: {{DISPLAYTITLE:2FA для ERP: двофакторна автентифікація в K2 ERP}} {{SEO |title=2FA для ERP |description=Стаття про 2FA для ERP-систем: що таке двофакторна автентифікація, чим 2FA відрізняється від MFA, де її вмикати в K2 ERP, які методи безпечніші, ризики SMS, TOTP, push, FIDO2, dashboard та Acceptance Criteria. |keywo...

Нова сторінка

!; | платформа вимагає 2FA і логування.; |-
| payload
| jsonb
| Технічні інформаційні дані без секретів.; 2FA

!; |-
| AC-10
| користувач системи запускає масовий експорт.; |-
| last_used_at
| timestamp
| Останнє використання.; характеристика

=== 7.1. SMS-2FA ===

<div style="border-left: 8px solid #1565c0; background: #e3f2fd; padding: 14px 18px; margin: 16px 0;">

!; Критерій
<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">

!; |-
| MFA
| Два або більше факторів.; | Пароль + FIDO2 + додатковий step-up для критичної дії.; |-
| user_id
| uuid
| користувач системи.; Що означає
{| class="wikitable"
|-
| id
| uuid
| ID challenge.; | Він підсвічується помаранчевим.; операційна дія

=== Етап 2.; Політика 2FA ===

* знайти всіх активних користувачів;
* знайти адміністраторів;
* знайти бухгалтерію;
* знайти фінансові ролі;
* знайти HR / зарплату;
* знайти користувачів із віддаленим доступом;
* знайти спільні логіни;
* знайти користувачів без входу понад 90 днів.; Тип
{| class="wikitable"
)
3.; 4.; | платформа вимагає налаштувати 2FA.; | Вони підсвічуються червоним і створюють alert.; Метод
== Див.; 19.; додатково ==

!; характеристика
</div>
!; | платформа показує QR, приймає код і активує метод.; |}

{| class="wikitable"

'''2FA''' — це двофакторна автентифікація.; Критерій
FIDO2 або passkeys виступає ключовою рисою '''Орієнтир:''' CISA зазначає, що phishing-resistant MFA є собою стандартом, до якого мають прагнути організації, але будь-яка MFA краще, ніж її відсутність.; Очікуваний результат

NIST у Digital Identity Guidelines описує, що для AAL2 потрібна багатофакторна автентифікація або комбінація двох різних однофакторних автентифікаторів.; 3.; |-
| expires_at
| timestamp
| Строк дії.; |-
| method_id
| uuid
| Метод 2FA.; |-
| risk_score
| integer
| Оцінка ризику.; |-
| method_type
| varchar
| TOTP, SMS, EMAIL, PUSH, FIDO2, PASSKEY.; Мінімальний метод

== 17.; Висновок ==
!; платформа просить другий фактор: код із додатку, SMS, push або security key.; | Подія логуються, користувач системи зобов’язаний налаштувати новий фактор.; * NIST SP 800-63B-4: Authentication and Authenticator Management.; | style="background:#c8e6c9;" | 2FA адміністратора.; Поле
|-
| id
| uuid
| ID методу.; Якщо все коректно — створює сесію.; №
{| class="wikitable"
=== 16.4. Recovery ===
9.; return challenge

* спочатку адміністратори;
* потім бухгалтерський обліковий облік;
* потім фінансовий блок;
* потім керівники;
* потім HR;
* потім усі інші користувачі.; |}

},

audit_logger.log(
{{SEO
|title=2FA для ERP
|description=Стаття про 2FA для ERP-систем: що таке двофакторна автентифікація, чим 2FA відрізняється від MFA, де її вмикати в K2 ERP, які методи безпечніші, ризики SMS, TOTP, push, FIDO2, dashboard та Acceptance Criteria.
|keywords=2FA, MFA, двофакторна автентифікація, K2 ERP, ERP security, кібербезпека ERP, TOTP, SMS, FIDO2, passkeys, OTP, контроль доступу
}}
!; |-
| AC-15
| є собою адміністратор без 2FA.;=== Етап 4.; Запуск ===
== 4.; Де 2FA має бути обов’язковою ==
!; | style="background:#fff9c4;" | Середній
|-
| Не phishing-resistant
| Код можна ввести на фальшивому сайті.; |-
| user_id
| uuid
| користувач системи.; |}

!; Тип
[[Категорія:MFA]]

!; |-
| AC-11
| користувач системи втратив 2FA-пристрій.; | style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для бухгалтерії
| Доступ до фінансових і податкових даних тільки з 2FA.; | style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для фінансів
| Платежі, бюджети, реквізити — тільки з 2FA.; користувач системи відкриває K2 ERP.; з цієї причини потрібен безпечний recovery-процес.; | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Користувачі з банківськими операціями
| Можуть впливати на платежі або реквізити.; | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Менеджери з доступом до цін
| Можуть змінювати комерційні умови.;=== 12.2.; Проблемні користувачі ===

return True

{| class="wikitable"
=== 16.2.; Критичні ролі ===
</div>

{| class="wikitable"
!; | style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для нової країни/IP
| платформа має вимагати повторну перевірку.; | Він підсвічується червоним.; | style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для нового пристрою
| Новий пристрій потребує другого фактора.; Очікуваний результат

== 12. Dashboard 2FA ==

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
"expires_at": utc_now_plus_minutes(5),
'''Головне правило:''' 2FA потрібно впроваджувати не колись, а одразу.; |-
| Видалення документа
| Ризик приховування операцій.; |}

</div>

[[Категорія:ERP]]

5.; |-
| 2FA
| Рівно два фактори автентифікації.; Ризик
|-
| Зміна банківських реквізитів
| Ризик підміни рахунку.; Для ERP це означає: 2FA потрібно впроваджувати негайно, а для критичних ролей поступово переходити на сильніші методи.; |}

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">

!; |-
| AC-17
| є собою підозрілі 2FA-запити.; Рівень
=== 9.1.; Обов’язкові правила ===

[[Категорія:Кібербезпека]]
</pre>
__TOC__

{| class="wikitable"

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">

!;=== 14.2.; Створення 2FA challenge ===
|-
| style="background:#ef9a9a;" | Адміністратор K2 ERP
| має змогу змінювати права, ролі, інтеграції, конфігурація.; Колір
|-
| Перехоплення SMS
| Код має змогу бути скомпрометований через мобільні ризики або соціальну інженерію.; характеристика
!; Правило

!; | style="background:#ef9a9a;" | Критично
|-
| Затримки доставки
| Код має змогу приходити із затримкою.; Для зловмисника це означає можливість діяти від імені реального працівника.; !; if request_context.is_high_risk_ip:
'''Правильне рішення для бізнесу:''' у K2 ERP потрібно впровадити 2FA як мінімальний обов'язковий рівень захисту для критичних ролей: адміністраторів, бухгалтерії, фінансів, керівників, HR, користувачів із доступом до банківських операцій і користувачів із віддаленим доступом.; Вона вимагає від користувача підтвердити вхід двома різними факторами.; | style="background:#c8e6c9;" | 2FA + audit log.;== 8.; 2FA для критичних операцій ==
{| class="wikitable"
|-
| Щось, що користувач системи знає
| Пароль або PIN
| Перший фактор.; |-
| Створення платежу
| Ризик фінансової втрати.; !; |}

!; характеристика
=== 16.5. Dashboard ===
!; | style="background:#ef9a9a;" | Критично
|-
| style="background:#ffcc80;" | HR / зарплата
| Доступ до персональних і зарплатних даних.; "user_agent": context.get("user_agent"),

== 11.; Модель даних 2FA ==
<pre>
=== Етап 5.; Контроль ===
!; | style="background:#c8e6c9;" | 2FA + рольовий контроль.; ERP.; Приклад
{| class="wikitable"
== 3.; Чому 2FA критична для ERP ==
|-
| SMS-код
| Код у SMS
| style="background:#ffcc80;" | Базовий
| Краще, ніж тільки пароль, але не найкращий варіант.; |-
| Push із number matching
| користувач системи вводить число з екрана входу
| style="background:#c8e6c9;" | Кращий
| Зменшує ризик MFA fatigue.; Дія

!; | платформа вимагає 2FA і створює подію ризику.; | style="background:#ffcc80;" | Високий
|}

2FA має використовуватись не тільки при вході, але й перед небезпечними діями.; користувач системи вводить TOTP-код або підтверджує другим фактором.; |-
| user_agent
| text
| Браузер / пристрій.; Рівень
|-
| Користувачів із 2FA
| 86%
| style="background:#fff9c4;" | Потрібно довести до 100%
|-
| Адміністраторів із 2FA
| 100%
| style="background:#c8e6c9;" | Норма
|-
| Бухгалтерів із 2FA
| 92%
| style="background:#ffcc80;" | Потрібна дія
|-
| Фінансових ролей із 2FA
| 100%
| style="background:#c8e6c9;" | Норма
|-
| Користувачів тільки з SMS
| 18
| style="background:#ffcc80;" | Замінити на TOTP/FIDO2
|-
| Невдалих 2FA за день
| 12
| style="background:#ffcc80;" | Контроль
|-
| Підозрілих 2FA-запитів
| 3
| style="background:#ef9a9a;" | Критично
|-
| Recovery-подій за місяць
| 4
| style="background:#fff9c4;" | Контроль
|}

== 1.; Що таке 2FA ==

=== 11.3. two_factor_events ===
</div>
!; |-
| created_at
| timestamp
| Дата створення.; |-
| AC-6
| Бухгалтер без 2FA намагається увійти.; платформа перевіряє пароль.;== 13.; Приклад процесу входу з 2FA ==
[[Категорія:Контроль доступу]]
|-
| admin2
| Адміністратор
| style="background:#ef9a9a;" | Вимкнено
| style="background:#ef9a9a;" | Критично
| Заблокувати або увімкнути 2FA
|-
| buh_olena
| Бухгалтер
| style="background:#ffcc80;" | SMS
| style="background:#ffcc80;" | Високий
| Перевести на TOTP/FIDO2
|-
| sales_ivan
| Менеджер
| style="background:#fff9c4;" | TOTP
| style="background:#fff9c4;" | Норма
| Без дії
|-
| cfo
| Фіндиректор
| style="background:#c8e6c9;" | FIDO2
| style="background:#c8e6c9;" | Добре
| Без дії
|}

</syntaxhighlight>

!; | Потрібне додаткове погодження.; Критерій
!; |-
| Email-код
| Код на email
| style="background:#ffcc80;" | Базовий
| Безпека залежить від пошти.; * Внутрішні вимоги K2 ERP до ролей, доступів, 2FA, журналювання та API-безпеки.; Роль / зона
db.commit()

!; |-
| user_id
| uuid
| користувач системи.; |-
| AC-7
| Фіндиректор входить із нового пристрою.; * CISA: Phishing-Resistant MFA Guidance.; Значення
<syntaxhighlight lang="python">

== 15.; Впровадження 2FA в K2 ERP ==

!; |}

!; | платформа вимагає новий challenge.; | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | Фінансовий директор
| Має доступ до платежів, бюджетів, рахунків, звітів.; платформа визначає, чи потрібна 2FA.; |-
| is_primary
| boolean
| ключовий метод.; |-
| Злам пошти
| Якщо пошту зламано, код додатково доступний зловмиснику.; |-
| AC-13
| Recovery для адміністратора.; |-
| Вимкнення інтеграції
| Ризик зупинки бізнес-процесу.; | style="background:#c8e6c9;" | 2FA + погодження.; Для критичних ролей у K2 ERP краще мислити ширше: MFA, adaptive MFA, step-up MFA і phishing-resistant MFA.; |}

db=db,

"status": "PENDING",
{| class="wikitable"
def create_2fa_challenge(user_id: str, method_type: str, context: dict, db: "Session") -> "TwoFactorChallenge":
=== 11.2. two_factor_challenges ===
"risk_score": context.get("risk_score", 0),
|-
| Адміністратор
| TOTP
| FIDO2 / passkey
| style="background:#c8e6c9;" | Сильний захист
|-
| центральний бухгалтер
| TOTP
| FIDO2 / passkey
| style="background:#c8e6c9;" | Сильний захист
|-
| Фінансовий директор
| TOTP
| FIDO2 / passkey
| style="background:#c8e6c9;" | Сильний захист
|-
| HR / зарплата
| TOTP
| TOTP або FIDO2
| style="background:#c8e6c9;" | Обов'язково
|-
| Менеджер продажів
| TOTP або push
| TOTP
| style="background:#fff9c4;" | Бажано
|-
| складський облік
| TOTP або SMS
| TOTP
| style="background:#fff9c4;" | Бажано
|-
| Тимчасовий користувач системи
| TOTP
| Короткий TTL + TOTP
| style="background:#ffcc80;" | Контроль
|}

def verify_totp_challenge(challenge_id: str, code: str, db: "Session") -> bool:
!; |-
| created_at
| timestamp
| Дата.;== 18.; Джерела ==
</div>
|-
| AC-8
| користувач системи змінює банківські реквізити.; * CISA: MFA Guidance.; | Запускається recovery-процедура.; |-
| challenge_type
| varchar
| LOGIN, STEP_UP, RECOVERY, CRITICAL_ACTION.; |-
| status
| varchar
| ACTIVE, PENDING, DISABLED, LOST.; !; Коментар
8.; |-
| ip_address
| varchar
| IP.; Подія входу записується в журнал.; |-
| Масовий експорт даних
| Ризик витоку.; Очікуваний результат

* щотижневий звіт;
* список користувачів без 2FA;
* блокування критичних ролей без 2FA;
* поступова відмова від SMS;
* перехід критичних ролей на FIDO2 / passkeys.; | платформа вимагає повторну 2FA.; Окремо варто відзначити ПРРО, маркетплейсами, службами доставки і електронним підписом.; | style="background:#ffcc80;" | Високий
|}

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">

<div style="border-left: 8px solid #c62828; background: #ffebee; padding: 14px 18px; margin: 16px 0;">
=== Етап 1.; Аудит користувачів ===
!; Рекомендований метод
|-
| AC-5
| Адміністратор без 2FA намагається увійти.; | style="background:#ef9a9a;" | Критично
|}

Найпростіший приклад:

== 16. Acceptance Criteria ==
"challenge_type": challenge.challenge_type,
'''Червона зона:''' адміністратори, бухгалтерський обліковий облік, фінансовий блок, HR або керівники входять у K2 ERP тільки за паролем.; Роль
</div>
def is_2fa_required(user: "User", request_context: "RequestContext") -> bool:
'''Ризик без 2FA:''' викрадений пароль має змогу відкрити доступ до ERP без додаткової перевірки.; Роль
!; Це фактично відповідає ідеї 2FA: одного пароля недостатньо.; |-
| Щось, чим користувач системи є собою
| Біометрія на пристрої
| має змогу використовуватись для активації passkey або пристрою.; |-
| created_at
| timestamp
| Дата створення.; характеристика

!; | style="background:#fff9c4;" | Середній
|-
| Не phishing-resistant
| Код можна виманити.; Для ERP пароль без другого фактора — це незакритий ризик.; 6.; | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Віддалений доступ
| Вхід поза офісом має підвищений ризик.; Ризик
!; | style="background:#c8e6c9;" | 2FA + погодження.; №

== 14.; Приклад Python-логіки ==
if challenge.expires_at < utc_now():
challenge.status = "EXPIRED"
db.commit()
return False

method = two_factor_method_repository.get_active_totp_method(
db=db,
user_id=challenge.user_id,
)

is_valid = totp_service.verify(
secret=method.secret_encrypted,
code=code,
)

if is_valid:
challenge.status = "PASSED"
method.last_used_at = utc_now()
else:
challenge.status = "FAILED"

audit_logger.log(
event_type="2FA_PASSED" if is_valid else "2FA_FAILED",
user_id=challenge.user_id,
payload={"challenge_id": str(challenge.id)},
)

db.commit()
return is_valid
</syntaxhighlight>
{| class="wikitable"
2.; | style="background:#fff9c4;" | Середній
|-
| Незручність за кордоном
| SMS має змогу не приходити в роумінгу.; Тип
|-
| AC-1
| користувач системи вмикає TOTP.; |-
| event_type
| varchar
| 2FA_ENABLED, 2FA_DISABLED, 2FA_PASSED, 2FA_FAILED, RECOVERY_USED.; |-
| FIDO2 security key
| YubiKey, Feitian, Titan Key
| style="background:#c8e6c9;" | Дуже сильний
| Phishing-resistant варіант.; Потрібно передбачити:
[[Категорія:2FA]]
!; |-
| MFA fatigue
| користувач системи отримує багато push-запитів і випадково підтверджує.; Рекомендація

{| class="wikitable"
</div>
"user_id": user_id,

<syntaxhighlight lang="python">

== 2. 2FA vs MFA ==

* CISA: More than a Password.; Критерій
if challenge.status != "PENDING":

!; |-
| Push
| Підтвердження в мобільному додатку
| style="background:#fff9c4;" | Добрий
| Потрібен захист від випадкового підтвердження.; !; №
=== 7.3.; Push-2FA без number matching ===
return True

{{DISPLAYTITLE:2FA для ERP: двофакторна автентифікація в K2 ERP}}
!; |-
| method_type
| varchar
| Тип 2FA.; '''Зелена зона:''' у K2 ERP увімкнено 2FA для критичних ролей, step-up 2FA для небезпечних операцій, dashboard контролю, журнал подій і поступовий перехід на FIDO2 / passkeys.; Для критичних ролей потрібні TOTP, FIDO2 або passkeys.; * NIST SP 800-63B: Digital Identity Guidelines.; | style="background:#c8e6c9;" | Обов'язково
|-
| Заборона спільних логінів
| 2FA неможливо нормально використовувати зі спільним акаунтом.; Якщо другий фактор можна обійти простим проханням у чаті, це небезпечна технічна архітектура.; | style="background:#ef9a9a;" | Критично
|-
| Випадкове підтвердження
| користувач системи натискає approve, не читаючи.; 2FA і MFA часто використовують як синоніми, але між ними є собою різниця.; !; Фактор
!;</syntaxhighlight>

* [[K2 ERP]]
* [[MFA]]
* [[2FA]]
* [[Кібербезпека ERP]]
* [[Контроль доступу]]
* [[FIDO2]]
* [[Passkeys]]
* [[TOTP]]
* [[SMS OTP]]
* [[API Security]]
* [[Журнал аудиту]]
* [[Incident Response]]

=== 14.3.; Перевірка TOTP-коду ===
2FA — це мінімальний рівень захисту ERP від викрадених паролів.; №

!; | Вхід дозволено тільки після другого фактора.; платформа перевіряє challenge.; Статус

[[Категорія:K2 ERP]]

{| class="wikitable"

* фінансові документи;
* рахунки;
* банківські виписки;
* платежі;
* зарплати;
* кадрові інформаційні дані;
* податкові документи;
* договори;
* клієнти;
* постачальники;
* ціни;
* знижки;
* залишки;
* виробничі рецептури;
* управлінська формування звітів;
* інтеграції з банками.; ERP — це центр керування компанією.; |}

challenge = two_factor_challenge_repository.get_by_id(db, challenge_id)

=== 9.2.; Рекомендовані правила ===
=== 14.1.; Перевірка необхідності 2FA ===
=== 7.2. Email-2FA ===
!;<div style="border-left: 8px solid #f57c00; background: #fff3e0; padding: 14px 18px; margin: 16px 0;">

* TOTP;
* SMS як резервний або перехідний варіант;
* FIDO2 / passkeys для критичних ролей;
* recovery codes;
* device trust;
* risk-based challenge;
* журнал 2FA;
* dashboard 2FA.; |-
| AC-2
| користувач системи входить із 2FA.; |-
| Щось, що користувач системи має
| Телефон, додаток Authenticator, security key, passkey
| Другий фактор.; Вводить логін і пароль.; |}

1.;<pre>
!; return True
"method_type": method_type,
!; |-
| Зміна ролей користувача
| Ризик несанкціонованого доступу.; користувач системи вводить логін і пароль.; if user.role in ["ADMIN", "CHIEF_ACCOUNTANT", "CFO", "HR_PAYROLL"]:
data={
'''Правило для K2 ERP:''' SMS можна використовувати тільки як перехідний або резервний варіант.; Поле
Якщо пароль бухгалтера забезпечується через '''Критично істотно:''' пароль сам по собі не є собою достатнім захистом; додатково реалізовано адміністратора, фінансового директора або менеджера буде викрадено, зловмисник має змогу отримати доступ до фінансів, зарплат, договорів, клієнтів, складу, цін, банківських реквізитів і управлінської звітності.; | style="background:#ef9a9a;" | Критично
|}

!; Приклад
},
!; | style="background:#ef9a9a;" | Критично
|-
| style="background:#ef9a9a;" | центральний бухгалтер
| Має доступ до фінансів, податків, зарплат.; | style="background:#c8e6c9;" | Обов'язково
|-
| 2FA для віддаленого доступу
| Вхід поза офісом тільки з 2FA.; Чому 2FA обов’язкова
!; |-
| AC-12
| Recovery виконано.; | Вхід заблоковано або примусово вимагається 2FA.; | style="background:#c8e6c9;" | 2FA + журнал.; Якщо потрібна — створює 2FA challenge.; | платформа вимагає повторну 2FA.; №
== 9.; Політика 2FA для K2 ERP ==
challenge = two_factor_challenge_repository.create(

</pre>
2.; Коментар

!; |-
| AC-9
| Адміністратор змінює роль користувача.; | Пароль + TOTP-код.; {| class="wikitable"

* визначити обов’язкові ролі;
* визначити дозволені методи;
* заборонити слабкі методи для критичних ролей;
* визначити recovery-процедуру;
* визначити step-up 2FA для критичних дій.; !; характеристика
|-
| AC-14
| Адміністратор відкриває 2FA dashboard.; return user.two_factor_required
!; Показник
7.; Тільки після другого фактора користувач системи входить у K2 ERP.; | style="background:#ffcc80;" | Високий
|-
| style="background:#ffcc80;" | Користувачі з експортом даних
| Можуть вивантажити клієнтів, ціни, договори, залишки.; | Challenge стає FAILED, спроба логуються.; |-
| ip_address
| varchar
| IP.; |-
| status
| varchar
| PENDING, PASSED, FAILED, EXPIRED.; |-
| AC-4
| Challenge прострочений.; Очікуваний результат

<div style="border-left: 8px solid #2e7d32; background: #e8f5e9; padding: 14px 18px; margin: 16px 0;">

'''Критично істотно:''' recovery не повинен бути слабшим за саму 2FA.; Рівень безпеки

</div>

!; Приклад
!; Рівень

{| class="wikitable"
"ip_address": context.get("ip_address"),
!; | style="background:#c8e6c9;" | Обов'язково
|}

payload={

* вимагати 2FA для всіх користувачів;
* не дозволяти SMS для адміністраторів;
* не дозволяти email-код для фінансових ролей;
* вимагати FIDO2 / passkey для super admin;
* вимагати повторну 2FA для критичних дій;
* блокувати користувача після багатьох невдалих 2FA;
* логувати всі 2FA-події;
* показувати dashboard покриття 2FA.; Очікуваний результат

=== 11.1. two_factor_methods ===

== 10. Recovery 2FA ==
!; |-
| AC-16
| є собою користувач системи тільки з SMS.; {| class="wikitable"

== 6.; Рекомендація для K2 ERP ==

)

* резервні коди;
* резервний метод 2FA;
* заявку на відновлення доступу;
* перевірку особи;
* погодження адміністратором;
* журнал recovery-події;
* тимчасовий доступ з коротким TTL;
* обов’язкове повторне конфігурація 2FA після recovery.; характеристика

user_id=user_id,

користувач системи має змогу втратити телефон, додаток або security key.; |-
| AC-3
| користувач системи вводить неправильний код.; |}

!; | Він бачить покриття 2FA по ролях.; |-
| TOTP
| Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden
| style="background:#fff9c4;" | Добрий
| Код генерується в додатку і змінюється кожні 30 секунд.; | style="background:#ffcc80;" | Високий
|-
| Залежність від оператора
| користувач системи має змогу не отримати код.; Рівень

!; Термін
!; У K2 ERP або іншій ERP можуть бути:
=== 12.1.; KPI адміністратора ===
!; {| class="wikitable"
1.; Ризик
|-
| id
| uuid
| ID події.; |-
| Passkeys
| Ключ доступу на пристрої
| style="background:#c8e6c9;" | Дуже сильний
| Сучасний варіант без класичного пароля.; Стан
!; користувач системи
<syntaxhighlight lang="python">
if request_context.is_remote_access:
=== 16.1.; Базова 2FA ===

[[Категорія:Інформаційна безпека]]
!; |}

== 7.; Ризики слабкої 2FA ==

{| class="wikitable"

if request_context.is_new_device:
!; |-
| user_agent
| text
| Пристрій.; Чому потрібна повторна 2FA
'''істотно:''' 2FA — це мінімальний рівень захисту.;=== Етап 3.; Технічна реалізація ===
"challenge_type": context.get("challenge_type", "LOGIN"),
return True
"method_type": method_type,
return False
== 5.; Методи 2FA ==
!; Критерій
|-
| 2FA для адміністраторів
| Без 2FA адміністратор не має змогу увійти.; Поле

</div>

!; {| class="wikitable"
=== 16.3. Step-up 2FA ===
!; Ризик
{| class="wikitable"
event_type="2FA_CHALLENGE_CREATED",

2FA - Історія редагувань