Two-factor authentication (2FA) and regulatory compliance
Two-factor authentication (2FA) is now an explicit requirement under NIS2, Spain’s ENS, DORA and PSD2. It is also one of the first things an ISO 27001 auditor checks. This guide sums up what each regulation asks for, which methods resist phishing and where to start.
In 30 seconds: NIS2 requires multi-factor authentication “where appropriate” (Article 21(2)(j)). Implementing Regulation (EU) 2024/2690 then spells it out for digital providers. In addition, the ENS requires two factors from uncontrolled zones, ISO 27001 covers it in control A.8.5 and DORA demands strong authentication for remote and privileged access. PSD2, by contrast, imposes it on your customers when they pay. Start with remote access and administrator accounts.
What two-factor authentication is and why regulations require it
Two-factor authentication combines two factors of different types. For example, something you know (a password), something you have (a phone or a security key) or something you are (a fingerprint). As a result, a stolen password is no longer enough to get in. Legal texts speak of “multi-factor authentication” (MFA), which allows two or more factors.
In fact, credential theft is a common entry point for ransomware and impersonation fraud. That is why EU lawmakers have turned two-factor authentication into a baseline control. It is also why auditors ask for proof that it is switched on, not just a policy that mentions it.
NIS2 and Implementing Regulation (EU) 2024/2690
Article 21(2)(j) of the NIS2 Directive lists among the minimum measures “the use of multi-factor authentication or continuous authentication solutions”, “where appropriate”. However, that phrase is not a way out. Instead, it forces you to justify where you apply it and where you do not. Moreover, Article 20 makes management responsible for approving these measures.
What the Implementing Regulation specifies
Implementing Regulation (EU) 2024/2690 has been in force since 7 November 2024. In particular, it covers DNS, cloud, data centre, managed service, search engine, social network and trust service providers. Point 11.7 of its annex requires multi-factor or continuous authentication according to the classification of the asset. It also requires the strength of the method to match that classification.
If you are outside those sectors, the regulation does not bind you directly. Even so, it is the best guide to what counts as “appropriate”. In fact, ENISA expands on it in its NIS2 technical implementation guidance.
Two-factor authentication for privileged accounts
The same annex goes further for administrators. Specifically, point 11.3.2 calls for strong authentication, such as MFA, for privileged and system administration accounts. Therefore, this is the first place an auditor will look for two-factor authentication.
In Spain, the NIS2 transposition is still pending, so Royal Decree-law 12/2018 remains in force. Still, it pays to get ahead, as we explain in the state of NIS2 transposition in Spain.
ENS, ISO 27001 and DORA: two-factor authentication control by control
If you already work with the ENS, ISO 27001 or DORA, this requirement fits into controls you know. Next, the table shows where it appears in each framework.
| Framework | Where it applies | What it asks for |
|---|---|---|
| NIS2 | Article 21(2)(j) | Multi-factor or continuous authentication, where appropriate |
| Regulation (EU) 2024/2690 | Annex, points 11.3.2 and 11.7 | MFA based on asset classification and for privileged accounts |
| ENS (Royal Decree 311/2022) | op.acc.5 and op.acc.6 | Two factors from uncontrolled zones, with reinforcements by level |
| ISO/IEC 27001:2022 | Annex A, control A.8.5 | Secure authentication in line with the access policy |
| DORA (Delegated Regulation 2024/1774) | Article 21 | Strong authentication for remote, privileged and critical-function access |
| PSD2 | Article 97 | Strong customer authentication for payments and account access |
ENS. Annex II of Royal Decree 311/2022, Spain’s National Security Framework, covers authentication in op.acc.5 (external users) and op.acc.6 (the organisation’s users). Under op.acc.6, a password alone is only valid from controlled zones. By contrast, reinforcement R8 requires two factors for access from the internet. The CCN-STIC 804 and 808 guides set out the reinforcements for each level, as summarised in how to comply with Spain’s National Security Framework.
ISO 27001 and DORA
In ISO 27001, control A.8.5 (secure authentication) works alongside A.5.17 on authentication information and A.8.2 on privileged access rights. Although no control says “2FA” literally, an auditor will expect it for remote access, email and administration. We review these controls in the ISO 27001:2022 Annex A changes.
Under DORA, Article 21 of Delegated Regulation (EU) 2024/1774 requires strong authentication for remote access, privileged access and assets that support critical functions or are public. It applies to banks, insurers and payment institutions, as covered in our DORA explainer.
PSD2: strong customer authentication for payments
PSD2 (Directive (EU) 2015/2366) was the first EU law to impose two factors at scale. Its Article 97 requires strong customer authentication when a customer accesses their account online or initiates an electronic payment. That authentication combines two independent elements of knowledge, possession or inherence. Furthermore, the technical standards in Delegated Regulation (EU) 2018/389 have applied since 14 September 2019.
Note the difference: PSD2 protects your customers when they pay, while NIS2, DORA and the ENS focus on your workforce. So a fintech needs both. And although PSD3 and the new Payment Services Regulation will replace it, they keep strong customer authentication.
Phishing-resistant two-factor authentication methods
Not all second factors protect equally. For example, adversary-in-the-middle attacks steal the session even when the user types a valid code. That is why you should match the method to the risk.
| Method | Phishing resistance | Comment |
|---|---|---|
| FIDO2 security keys | High | Bind the credential to the real domain; ideal for administrators |
| Passkeys | High | FIDO credentials on a phone or computer |
| Smart card or national ID certificate | High | Common in the public sector |
| App with push and number matching | Medium | Better than a simple “approve”, which causes prompt fatigue |
| TOTP code in an app | Medium-low | Real-time phishing can capture it |
| SMS or voice call | Low | Exposed to SIM swapping; keep it as a fallback |
Specifically, FIDO2 keys and passkeys only respond to the legitimate domain. So even if someone clicks a fake link, the credential is useless to the attacker. An attacker, on the other hand, can relay a six-digit code in seconds. Even so, any two-factor authentication, even with TOTP, beats a password on its own.
Where to start: a five-phase plan
- Inventory your access points: email, VPN, remote desktop, cloud, ERP and admin panels.
- Prioritise by risk: privileged accounts and remote access first; email next.
- Choose the method: FIDO2 or passkeys for administrators and an app with number matching for everyone else.
- Close the back doors: disable legacy protocols without MFA and review service accounts.
- Document and measure: record justified exceptions, coverage per system and reviews.
In addition, set up a secure recovery process for when someone loses their phone. This is where many two-factor authentication rollouts fail, because a help desk that resets access over the phone undoes everything. Finally, keep coverage and exceptions as automated evidence for your audits.
Evidence auditors accept
Having two-factor authentication switched on is not enough. Auditors rarely ask whether you have it; they ask you to show that it is enforced on every account that matters and to justify each exception. This is the evidence that supports it.
1. Privileged-account inventory reconciled against actual enforcement. Start from the list of privileged accounts: domain and cloud administrators, infrastructure consoles, remote access and critical application accounts. Reconcile it against what your identity provider actually enforces. A user having registered a second factor does not mean it is required. What counts is the policy that enforces it, and any account left outside that policy is a coverage gap.
2. The policy, exported and dated. Keep the configuration that enforces the second factor (for example, conditional access rules) with its date and scope. Export it again after every change so the history is visible.
3. Sign-in logs. Retain the logs showing that privileged sign-ins went through the second factor. You do not need to review them all: a periodic sample is enough, focused on administrator accounts and remote access, recorded with the date of the review.
4. An exceptions register. Every account that cannot use a second factor needs a justification, an owner, compensating controls and a review date. There are two typical cases:
- Service accounts: they do not sign in interactively. Protect them by restricting where they can connect from, keeping their credentials in a secrets manager and rotating them.
- Emergency (break-glass) accounts: usually two, kept for when the identity provider fails. A FIDO2 security key held in custody is better than a long password in an envelope. Every use triggers an alert and a review afterwards, and they are tested periodically to confirm they still work.
5. Coverage metric and periodic review. Measure the share of privileged accounts with an enforced second factor and the number of open exceptions, and review them as often as your risk analysis requires. That figure, with its date, is the best answer to the auditor’s question.
Frequently asked questions
Is two-factor authentication mandatory under NIS2?
NIS2 requires it “where appropriate”, based on risk. In practice, it is hard to justify the absence of two-factor authentication for remote access or administrator accounts. So expect the supervisor to ask for it there.
Is SMS acceptable as a second factor?
It works as a minimum, because it is better than nothing. However, SMS is exposed to SIM swapping and real-time phishing. Use it as a fallback and keep FIDO2 or passkeys for critical access.
What is the difference between 2FA and MFA?
2FA uses two factors; MFA uses two or more. Regulations speak of MFA, but well-implemented two-factor authentication meets it. Still, the factors must be of different types: two passwords are not two factors.
Should every employee use two-factor authentication?
Ideally yes, starting with the riskiest access. The ENS requires it from uncontrolled zones, while ISO 27001 and NIS2 demand proportionality. Therefore, you should justify and review every exception.
Do passkeys count as two factors?
Yes, if you unlock them with biometrics or a PIN on a device you control. That way they combine something you have with something you are or know. They also resist phishing.
Reviewed on 14 October 2026. For information only, not legal advice.
How Atalaya GRC helps with two-factor authentication
Atalaya GRC tells you which regulations apply to you, service by service, and brings together what each one requires on authentication: Article 21(2)(j) of NIS2, measures op.acc.5 and op.acc.6 of the ENS and control A.5.17 of ISO 27001. You keep the evidence on each obligation and each ENS measure, record exceptions with their justification and review date, and the regulatory clock alerts you to every pending review. See our NIS2 guide or request a demo.
