Planning an MFA rollout: phishing-resistant authentication under NIS2 and DORA

Who owns this decision

CISO with IT operations and HR/change management. Data Protection in the steering group (biometrics review).

Key criteria to weight

• Phishing resistance per NIST AAL3

  FIDO2 / WebAuthn with hardware attestation is state of the art.

• Coverage of all apps and devices

  An MFA gap is an attack surface. Legacy apps need a gateway solution.

• User experience and acceptance

  Passkeys win because of comfort. Hardware tokens only for privileged roles.

• Backup factor and lost-token process

  Without recovery, MFA blocks productivity.

• Integration with IAM and IGA

  Factors must be differentiated by role, risk and app.

• Conditional Access and risk-based MFA

  Adaptive MFA reduces friction and catches anomalies.

Step-by-step decision flow

1. 1

   Inventory

   Which apps have MFA active, which factors, which user groups. Find gaps.

2. 2

   Factor strategy

   Per role and app: drop SMS OTP, TOTP for standard users, FIDO2/Passkeys for privileged.

3. 3

   Pilot with power-user group

   Admins and power users with hardware keys (YubiKey, SoloKey). Lessons feed the rollout concept.

4. 4

   Phased rollout

   Wave 1 admins, wave 2 Finance/HR/Legal, wave 3 all staff, wave 4 externals and sub-suppliers.

5. 5

   Memo, training, telemetry

   Decision memo with stakeholder alignment. Training. Telemetry to detect MFA bypass.

Compliance note

NIS2 Art. 21 (j), DORA Art. 9, BAIT BTO 6, ISO 27002 A.8.5.

Common pitfalls

• MFA is only enabled in Microsoft 365; other apps remain open.
• SMS OTP is kept 'because easier'. AiTM phishing breaks it.
• Backup factor missing. Helpdesk overwhelmed with reset requests.
• Externals and sub-suppliers exempt. Supply-chain risk persists.

FAQ