SaaS MFA for GDPR, NIS2, and DORA compliance

If I had to sum it up in one sentence: MFA is no longer just a SaaS security choice; it is something you need to justify, implement, and prove.

Here is what I take away straight away:

• GDPR: the regulation does not mention MFA by name, but Article 32 calls for risk-based measures. In France, on 20 March 2025, the CNIL clearly placed MFA among the baseline measures for remote access, administration, and sensitive data.
• NIS2: MFA is part of the access controls expected of entities within scope.
• DORA: the framework is more direct, especially for ICT assets, critical access, and incident monitoring.
• First reflex: cover admin accounts, SSO, remote access, SaaS consoles, and third parties first.
• Second reflex: keep clear logs of activations, bypasses, resets, and failures.
• Third reflex: connect everything to governance: RoPA, asset mapping, access reviews, the Register of Information, and audit trails.

One figure sets the tone: 83% of SaaS applications are used without IT approval. And 60% of companies fail audits because of poor SaaS data governance. So the question is no longer “do we need MFA?”. The question is: which access, with what evidence, and for which framework?

Quick comparison

Framework	What I need to remember about MFA	What is mainly expected
GDPR	Expected according to risk	Justify the choice, especially for remote access, admin access, and sensitive data
NIS2	Expected as part of access controls	Cover critical access and log incidents
DORA	Highly structured around access and ICT assets	Prove MFA coverage, incident monitoring, and governance

The rest of the topic can therefore be summed up in three words: cover, trace, prove.

Access control: what each framework really says about MFA

GDPR, NIS2, and DORA do not address MFA with the same level of detail. This is where many teams get it wrong.

The GDPR, for example, does not say in black and white: put MFA everywhere. Its Article 32 takes a risk-based approach. In other words, you must choose security measures that fit the situation. In France, the CNIL removed much of the uncertainty on 20 March 2025: MFA is an essential baseline measure for access to sensitive data, remote access, and administration interfaces [1].

NIS2 goes further. MFA is included in its access-control measures. DORA, for its part, links it to the protection of assets and critical access, within a much more prescriptive ICT risk-management framework.

Framework	MFA status	Basis
GDPR	Indirectly expected	Article 32 + CNIL recommendation of 20 March 2025
NIS2	Explicitly expected	Access-control measures
DORA	Highly prescriptive	ICT risk-management framework

In practice, this difference mainly changes how MFA is deployed. Under the GDPR, you need to justify your choices. Under NIS2 and DORA, you need to prove that the measure is in place and covers the right access.

The more prescriptive the framework, the more the organization must document MFA's actual coverage across its SaaS environment. The starting point is simple: show that MFA protects exposed access and sensitive accounts, such as administrators, remote access, and privileged accounts.

The real question is therefore no longer whether MFA is needed, but which accounts should receive it first.

Which accounts and access scenarios should be covered first?

When resources are tight, go straight to the point. Start with the most exposed access.

Priority goes to administrator accounts, SaaS administration consoles, and remote access [1].

Third-party access comes next. Providers and partners often open a door into the supply chain and critical functions. Once these accounts are covered, you need to be able to prove it: who activated MFA, when, and for which access?

Access scenario	Priority	Frameworks concerned
SaaS administration consoles and privileged accounts	Critical	CNIL / NIS2 / DORA
Remote access to internal systems and SaaS applications	Critical	CNIL / NIS2
Applications processing health or financial data	High	GDPR / DORA
Third-party access and digital service providers	High	DORA / NIS2
Standard employee access to non-sensitive SaaS applications	Moderate	GDPR (proportionality)

On the ground, the simplest order is often the right one: secure identity providers and SSO first, then the administration consoles of critical applications [1]. In other words, lock down the key ring first, then the most sensitive doors.

After that, one point matters as much as activation itself: the evidence. Coverage of priority accounts must be visible and verifiable in access logs.

Traceability, logs, and accountability for MFA events

Once critical accounts are protected, go further: you must be able to prove every MFA event. During an audit, logs and their retention period matter just as much as activating the control itself.

The rules change depending on the framework. The GDPR treats authentication logs as personal data, with a minimization approach and a limited retention period [3]. DORA requires a complete register of ICT incidents to support access reviews. NIS2, for its part, requires significant incidents to be documented for notification within 24 hours, followed by a full report within 72 hours to ANSSI.

These are the events to log as a priority.

Type of MFA event	Logging priority	Main framework
MFA bypasses or unauthorized access to critical systems	High (immediate)	DORA (automatic qualification as a major incident)
Successful and failed logins on privileged accounts	High	NIS2 (incident reporting)
MFA bypasses and administrator exceptions	High	GDPR (accountability)
MFA enrollments, resets, and recoveries	Medium	DORA (access reviews)
MFA authorization or blocking decisions	Medium	NIS2 (risk management)

Under NIS2, leadership must be able to show that it oversees MFA controls and access reviews. This is not simply a compliance item on a checklist. 60% of companies fail audits because of poor SaaS data governance [2].

To remain aligned with the GDPR, keep only useful events. In practice, this means:

• the timestamp
• the domain identifier
• the authentication result

There is no need to record everything. The aim is to retain what supports both risk governance and audit evidence.

SaaS risk governance and audit evidence

Once MFA events are logged, the real issue is no longer just having them. You need to show that they fit within formal SaaS governance.

In clear terms: logs alone are not enough. During an audit, you also need documented SaaS governance, including an application inventory, formalized access policies, and traceability of decisions.

Under the GDPR, MFA must appear in the RoPA, remain proportionate to the risk, and rely on a documented legal basis [3]. The common thread across the three frameworks is simple: document choices and responsibilities. NIS2 requires active management oversight of access controls. DORA, for its part, requires a Register of Information (RoI) linking ICT assets to critical functions, with board validation.

The table below presents the audit evidence expected under each framework [4].

Evidence category	GDPR	NIS2	DORA
Access control	MFA policy documented for access to sensitive personal data	MFA policy documented for critical access at essential and important entities	MFA policy documented across all ICT systems supporting critical functions
Sensitive accounts	DPO documentation and high-privilege access records	Identification of critical assets and supply-chain risks	Register of Information linking assets and critical functions
Logs	Retention, review, and export of authentication logs according to a defined period	Incident logs available for notification to ANSSI	Cascading incident reporting (4 hours / 72 hours / 1 month) with investigation capability
Governance	Record of processing activities (RoPA) and periodic access reviews	Management approval and periodic access reviews	Board approval of ICT risk frameworks and resilience testing

One point often flies under the radar: periodic access-rights reviews. Yet this is where many of the important controls come together.

Documenting account creation and deactivation, then checking that access remains aligned with the principle of least privilege, provides direct evidence that an MFA control is not merely enabled “on paper” but actually governed [4].

These records can then be used to prioritize concrete actions by team and across the SaaS estate.

What this means in practice for French compliance and security teams

Once the audit evidence is defined, it is time to execute in the field. The useful sequence remains simple: SaaS inventory, classification, MFA, then continuous monitoring.

Start by mapping the SaaS estate, including Shadow IT and usage outside SSO. Then classify applications according to their sensitivity and criticality. Next, enforce MFA on privileged accounts, remote access, and administration consoles. Finally, feed the SIEM to enable continuous SOC monitoring.

This hierarchy forms the basis for deciding which controls to address first under each framework. In practice:

• GDPR: RoPA and DPIA
• NIS2: asset mapping and notification within 24 hours / 72 hours
• DORA: Register of Information (RoI) and notification within 4 hours

The key point is no longer theory. What matters is the ability to see, block, and prove continuously. In this area, Avanoo helps detect Shadow IT, identify accounts without MFA, and centralize audit evidence.

Strengths and limitations of each framework for SaaS MFA

Once the requirements and evidence are clear, the real question is straightforward: what does each framework actually say about MFA in SaaS? The issue is less whether MFA exists than how much precision is required and what evidence must be supplied during an inspection.

The GDPR approaches MFA through risk. The CNIL presents it as a baseline measure whenever sensitive data, remote access, or administration interfaces are involved.

Framework	Strengths	Limitations	Effect on SaaS
GDPR	Broad scope: any processing of personal data. Fines up to €20 million or 4% of worldwide turnover [2].	Limited technical precision: MFA is not explicitly named, with a proportionality-based approach [1].	MFA becomes a priority for sensitive data, remote access, and administration. A DPIA helps formalize this proportionality [1].
NIS2	MFA is explicitly expected in access-control measures. Active management oversight is required.	Scope limited to essential and important entities; other organizations are not directly covered.	MFA is mandatory for critical access, with incident documentation for notification to ANSSI within 24 hours / 72 hours.
DORA	Highly prescriptive ICT framework: MFA is linked to the protection of assets and critical access. Board validation is required.	Scope focused on the financial sector; other sectors are outside scope.	MFA is integrated into the Register of Information (RoI), with cascading incident reporting (4 hours / 72 hours / 1 month) and documented resilience testing.

Put differently, the GDPR leaves more room for judgment, but requires you to justify your choices. NIS2 and DORA are more prescriptive, especially for critical access, governance, and incident management. For a SaaS provider, the difference is not theoretical: it changes what needs to be deployed, traced, and shown during an audit.

Conclusion

Ultimately, the difference between these three texts is less about whether MFA is present than about the level of evidence required. GDPR, NIS2, and DORA all point in the same direction on MFA, but with different levels of expectation: first risk-based justification, then explicit implementation, and finally evidence maintained over time.

The right question is therefore not just: “do we have MFA?” The better question is: “can we prove it continuously?” Without SaaS governance, isolated MFA is not enough to pass an audit.

For French teams, the priority is fairly clear: start by covering the most exposed access, then document every control. In practice, address remote access, administration interfaces, and sensitive data first, then formalize the evidence associated with each of these areas.

SaaS MFA is not just a security setting. It is a governance control.

FAQs

::: faq

Is MFA mandatory under the GDPR?

The GDPR does not impose MFA in every situation. It does, however, require a level of security appropriate to the risk.

In practical terms, for sensitive access — such as health data, financial information, or administration interfaces — the absence of MFA may be considered a failure to meet this obligation. This is not a minor issue: it can result in CNIL sanctions. :::

::: faq

Which SaaS access should be protected first?

For GDPR, NIS2, and DORA, start by protecting the most exposed SaaS access according to the level of risk and the sensitivity of the data.

In clear terms, priority goes to:

• administration interfaces;
• applications that process sensitive data;
• remote access.

You must also classify SaaS assets according to their criticality, the data they process, and your level of dependence on the provider. :::

::: faq

What evidence should be kept for an audit?

Keep documentation up to date and traceable. In clear terms, you must be able to retrieve the inventory of ICT assets and providers, the risk register, security policies, incident reports, resilience tests, and the history of access measures, including MFA.

Do the same for third-party provider contracts. Keep audit clauses, SLAs, data locations, and exit plans readily available. The goal is simple: during an audit, you need to show these items quickly, in the right format, and without ambiguity.

Avanoo can help centralize these documents and simplify their presentation during an audit. :::