control
multi-factor authentication
A second proof of identity at sign-in, so a stolen password alone does not get anyone in. NIS2 names it directly. The other rules expect strong authentication and leave the method to you.
- what it protects
- every sign-in, so a stolen password alone does not open a door
- who owns it
- head of IT
- start with
- administrator accounts, then remote access, then everyone
what it is
Multi-factor authentication, or MFA, asks for a second proof of identity at sign-in. Something you know, such as a password, goes together with something you have, such as a phone or a security key. A stolen password alone then does not get an attacker in.
NIS2 names it directly, where appropriate. The other rules ask for strong authentication or for access that fits the risk, and leave the method to you. The practical questions are where to start and how strong to make it.
Start with the accounts that can change things: administrators, finance and anyone who can reach the identity provider. Then extend it to remote access and to everyone. Strength varies. There are codes sent by text message, codes from an authenticator app, an approval tapped on a phone, and methods that cannot be tricked into approving a fake page, such as security keys and passkeys. Choose the last group for administrators.
basis NIS2 Art. 21(2)(j). The methods and the order are practice.
how a sign-in works with a second factor
- 1passwordthe first proof, something you know
- 2second proofthe system asks for something you have
- 3checkthe system decides, and a fake page cannot answer for you
- 4access and recordthe sign-in is logged with the factor used
ways to give the second proof, from weakest to strongest
- code by text messagecan be intercepted or talked out of someone
- code from an appbetter, but still typed into whatever page asks
- approval tapped on a phonecan be worn down by repeated prompts
- security key or passkeycannot be tricked by a fake page
basis working practice. No legal text sets this.
an example
Picture a company of 80 people that turned on a second factor last year.
The rule says everyone, but the finance lead and two administrators were exempted for now. Resets go through the help desk by phone. When a supplier account is phished, the attacker calls the desk, asks for a reset and is in.
Administrators and finance use security keys, everyone else uses an app. The exception list has three names, each with an owner and an end date. A reset needs a second person and a call back to a known number.
An illustration. It is not a real case.
what it has to do for each rule
| rule | where | what the text asks | what the control has to do |
|---|---|---|---|
| NIS2 | NIS2 Art. 21(2)(j) | Multi-factor or continuous authentication, where appropriate. | Cover administrators and remote access first. Record where you use it and why you do not use it elsewhere. |
| IR 2024/2690 | IR 2024/2690 Annex 11.7.1 | Listed digital providers: MFA or continuous authentication where appropriate, by asset classification. | Match the strength of the second factor to how critical the system is. |
| DORA | DORA Art. 9(4)(d) | Policies and protocols for strong authentication. | Write the policy and be able to show that it is enforced on the systems it names. |
| GDPR | GDPR Art. 32(1)(b) | Ongoing confidentiality of processing systems, sized to risk. | Protect the systems that hold personal data in proportion to the risk. |
basis NIS2 Art. 21(2)(j); IR 2024/2690 Annex 11.7.1 as a reference; DORA Art. 9(4)(d); GDPR Art. 32(1)(b). What the control has to do is practice.
what to look for when you choose
- Does it protect every way in: the web, the desktop, remote access, admin consoles and the older apps that still take a plain password?
- Does it offer a method that cannot be tricked by a fake page, such as a security key or a passkey, for administrators and finance?
- What happens when someone loses a phone or leaves the company? Who can reset a second factor, and how do they prove who is asking?
- Can you pull one report that shows who is covered and who is not?
- Can you set an exception with an owner and an end date?
- Does it record every sign-in, every failure and every change to a second factor, and for how long?
- Is there a documented way in when the service itself is down?
- What does it cost per user per month once administrator and guest accounts are counted?
basis working practice. No legal text sets this.
three levels, from first step to strong
Each level adds something visible. Stop where the risk you accepted allows.
- start
Turn it on for every administrator and for remote access. Write the exceptions down with an owner and a date.
- solid
Cover everyone, drop text messages for sensitive roles and run the coverage report every quarter.
- strong
Use security keys or passkeys for administrators and finance, require a second person for resets and test the reset path once a year.
basis working practice. No legal text sets this.
where it goes wrong
approvals people tap without reading
A prompt that approves with one tap can be repeated until someone gives in. Use number matching or a method that cannot be tricked, at least for administrators.
the reset desk is the back door
A second factor is only as strong as the way you reset it. If a caller can talk the help desk into a reset, the factor protects nothing.
exceptions with no end
An exception without an owner and a review date becomes permanent. Keep the list short and look at it every quarter.
administrators come last
Rolling it out to everyone before the administrator accounts leaves the most valuable accounts for the end. Do those first.
basis working practice. No legal text sets this.
the proof it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| coverage report: who has a second factor and who does not | head of IT | quarterly |
| exception list with owners and end dates | head of IT | quarterly |
| reset procedure and the log of resets | head of IT | yearly |
| sample of sign-in logs showing the second factor in use | head of IT | quarterly |
basis practice. The rhythms are your choice.
check it yourself
- Directive (EU) 2022/2555 (NIS2) (EUR-Lex)
- Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)
- Regulation (EU) 2022/2554 (DORA) (EUR-Lex)
- Regulation (EU) 2016/679 (GDPR) (EUR-Lex)
your next step
Run a coverage report today and count the administrator accounts that have no second factor.