The uncomfortable truth about MFA is that its implementation can start running into trouble before the technical rollout is even finished.
IT switches it on, and then a senior calls to ask whether they can be excluded. Perhaps they fear that the extra authentication step will slow them down. The request sounds minor. Grant it, though, and the organization now has an MFA policy that does not apply equally to all the people.
NIS2 makes that harder to dismiss as an implementation detail. Article 21 requires MFA “where appropriate,” which in practice makes it mandatory, while Article 20 requires management bodies to approve cybersecurity risk-management measures and oversee their implementation. Management bodies can also be held liable for infringements by the entity, subject to national law.
A leader asking to be exempted from a control they have approved creates a governance problem for the security team expected to enforce it. It also demonstrates a cultural problem, which may be the hardest problem to solve.
Key insights
- NIS2 Article 21 requires MFA “where appropriate,” and Article 20 holds management bodies responsible for approving and overseeing the measures.
- MFA rollouts break most often through leadership exemptions, not user resistance or technical limits.
- “Where appropriate” covers legacy systems and operational constraints; a job title is not a justification.
- Executives hold access to sensitive information and are prime phishing targets, which makes their accounts the hardest to justify exempting.
- Contributors to a 2026 NIS2 access management report by Passwork describe CISOs held accountable for controls they lack the authority to enforce.
- Every exemption needs a documented reason, a named risk owner and a review date; Article 21 infringements can carry fines of €10 million or 2% of turnover.
The first MFA exemption may arrive within hours
MFA looks straightforward when discussed in a meeting. Deployment exposes all the awkward cases that have accumulated underneath.
Consider a public-sector organization switching on mandatory MFA on Monday morning. Within the next few hours, technical accounts begin failing because long-standing integrations were never designed to handle a second factor. Poor planning and decisions siloed from all departments can be held accountable for this failure.
These technical problems, however frustrating, may take time to untangle, but they can be solved.
What is harder to solve is when a senior office asks IT for an exception. And this is a cultural problem to solve. Later, the senior-user exemption can be granted with a phone call, but security teams may struggle when asked to push back against somebody higher up than them. That puts the CISO in a difficult position. They are responsible for implementing the control, yet the person asking them to weaken it may have more authority than they do.
The broken MFA problem does not stop at the executive’s door. Other employees see the exception, too. Once senior management can negotiate its way around MFA, resistance elsewhere becomes harder to challenge. What started as one executive request can change how seriously people take the rollout.
The organization ends up with having an MFA policy on paper, but no identity protection in reality.
Article 20 puts the decision back upstairs
This problem predates NIS2. CISOs have long been expected to manage risks that depend on decisions made elsewhere in the business.
Jane Frankland MBE, CEO and founder of KnewStart, describes it as an accountability gap during an interview for a NIS2 access management report by Passwork. “CISOs are often held accountable for managing cyber risk, but they don’t actually have the authority to make sure that those things happen. They’re responsible for cybersecurity and resilience, their name sits on the risk register, but patching sits in IT and budgets elsewhere.”
Executive MFA exemptions fit neatly into that gap. Security can identify the risk and recommend the control. It may still lack the authority to tell a senior leader that the policy applies to them, too.
But Article 20 changes the governance around that decision. Management bodies must approve the cybersecurity risk-management measures required to comply with Article 21 and oversee their implementation. The directive also requires members of management bodies to undertake training to identify risks and assess cybersecurity risk management practices.
For CISOs, that creates grounds for a different discussion with the board. MFA does not need to be presented as an authentication feature that inconveniences an executive. The discussion is about access risk, the reason for the exception, and who has accepted the resulting exposure. Ultimately, the discussion is about business risk.
Dr Yiannis Pavlosoglou, Deputy Governor at the Greek National Cybersecurity Authority, highlights this necessity: “The board needs to understand what inadequate MFA coverage means for the organisation, what the exposure risk could cost, and what the plan is to address it.”
“Where appropriate” still needs a reason
Article 21(2)(j) requires the use of MFA or continuous authentication solutions “where appropriate.” That wording leaves room for organizations to apply controls based on risk and circumstances.
There are plenty of circumstances that need careful handling. For instance, an old application that does not support modern authentication, or a production environment that restricts employees from carrying mobile phones. Technical accounts embedded in long-running integrations have been known to fail when an interactive authentication requirement is introduced.
Those problems need to be dealt with as part of the rollout. Some may require architectural changes. A senior employee who wants to avoid MFA because it is inconvenient does not have the same justification. “Where appropriate” should only allow for genuine operational constraints.
Any exemption should have a reason tied to the account, the system being accessed, or a genuine operational constraint. A job title alone doesn’t tell you whether an authentication control is appropriate or not.
In fact, the access held by senior employees can make an exemption particularly difficult to justify. Executives commonly have access to sensitive communications and information and this is why they are popular targets for social engineering and phishing attacks.
Credentials are still useful to attackers
Stolen credentials are still a problem even when MFA is deployed. Verizon’s 2026 DBIR found credential abuse in 39% of breaches, though credentials were not necessarily the attacker’s initial entry point.
Given that IBM’s 2026 Cost of a Data Breach report put the global average breach cost at $4.99 million, deliberately leaving a senior account without MFA is a risk that warrants a better reason than mere inconvenience.
MFA will not stop every attack involving an account. Some forms of MFA are more resistant to phishing and interception than others, so all rollouts need to account for the strength of the second factor and use phishing-resistant authentication where the risk warrants it.
An exemption needs a record and an owner
Some MFA exceptions will be unavoidable. A rollout needs a process for handling them before requests start arriving.
When someone requests an exemption, record the accounts and systems affected, the reason MFA cannot be applied, the risk created by the exception, and any measures being used to limit that risk. The exemption should also have a review point so that a temporary workaround does not quietly become permanent.
Article 21 infringements can carry substantial administrative fines. For essential entities, member states must provide for maximum fines of at least €10 million or 2% of worldwide annual turnover, whichever is higher.
That does not make an individual MFA exception an automatic regulatory breach or fine. It does make informal, undocumented exceptions harder to defend if access controls come under scrutiny later. And it makes providing evidence even harder, which, in turn, may result in a NIS2 violation.
Before enabling MFA across the workforce, decide who can approve exemptions and what evidence they must provide. Record who accepted the risk and when the exception will be reviewed. Senior management must not be exempt from that process.
