Who should own MFA governance when DORA compliance spans identity, infrastructure, and security teams?

MFA governance should sit with the teams that control identity policy and access enforcement, but it needs coordination across security, infrastructure, and application owners. Identity teams define the rules, infrastructure teams keep the authentication layer stable, and security teams validate that monitoring and response are in place. Clear ownership prevents gaps between compliance intent and operational execution.

Where MFA Governance Should Sit in a DORA Operating Model

MFA governance should be owned by the function that sets identity policy and access rules, because that is where the control’s intent can be defined consistently. Operationally, it cannot be managed as a single-team checkbox: infrastructure owns availability and integration stability, security owns oversight and validation, and application or platform owners must implement the control without breaking business workflows.

That division matters under DORA because MFA is not only an authentication setting, it is part of the broader ICT control environment. If ownership is unclear, teams tend to optimise for their local objective, such as uptime or user convenience, while the compliance requirement needs a coordinated control that is actually enforceable, monitored, and auditable.

For the identity side of the control model, the governance layer should treat policy, exception handling, and access enforcement as one managed system rather than separate tasks. NHIMG’s Ultimate Guide to NHIs is useful here because it frames ownership, lifecycle, and auditability as governance problems, not just configuration work.

How to Split Accountability Without Splitting the Control

The cleanest model is a single accountable owner with defined contributing owners. Identity teams usually own MFA policy design, factor standards, enrolment rules, and exception criteria. Infrastructure teams own the systems that make MFA reachable and resilient, including directories, authentication services, network dependencies, and recovery paths. Security teams own control assurance, logging expectations, detection use cases, and incident follow-up.

That model prevents a common failure mode: each team assumes another team owns the end-to-end outcome. A policy can be technically sound and still fail compliance if the authentication service is unstable, if bypass paths exist, or if no one verifies that exceptions are time-bound and approved. Governance should therefore be documented as a control lifecycle, not a one-time decision.

Practitioners should also separate “who sets the rule” from “who can break glass.” The rule belongs with identity governance, but any emergency override, legacy accommodation, or platform-specific workaround needs explicit approval, expiry, and review. Otherwise MFA becomes fragmented across products and the actual control state becomes hard to prove during audit or incident review.

For implementation guidance on that lifecycle view, NHIMG’s Lifecycle Processes for Managing NHIs is a relevant navigation point because it links governance to provisioning, review, rotation, and offboarding discipline.

Risk and Threat Considerations

MFA governance fails when ownership gaps create inconsistent enforcement, weak exception handling, or untested recovery paths. In a DORA context, that is not a paperwork issue, it can become an operational resilience issue if privileged or remote access depends on a control that is not reliably enforced across systems.

Failure mechanism: Policy drift, unmanaged exceptions, or authentication-service fragility can leave some environments protected while others quietly bypass the intended MFA standard. That creates audit gaps, weakens incident containment, and can expose privileged access paths that attackers actively seek.

Impact: The organisation may meet the appearance of compliance while still carrying a real access-control weakness. If MFA is bypassed in a critical workflow, a compromise of credentials or session material can lead to broader unauthorised access and slower detection.

Where this is the concern, NHIMG’s Microsoft Midnight Blizzard breach and Uber Breach are useful reminders that authentication weakness and social-engineering pressure often become enterprise-wide problems when governance is fragmented.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 set the technical controls, and DORA and ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
DORA	Digital Operational Resilience Act	MFA governance is part of ICT risk, resilience, and access control under DORA.
Recommendation — Assign clear control ownership for MFA across ICT risk, resilience, and access enforcement.
NIST CSF 2.0	PR.AC-1 — Identity Management, Authentication, and Access Control	MFA governance directly concerns authentication and access control outcomes.
	PR.PT-3 — Platform Security	MFA depends on stable authentication platforms and resilient supporting infrastructure.
	DE.CM-8 — Vulnerability and Control Monitoring	MFA governance needs monitoring to confirm enforcement, exceptions, and failures are visible.
Recommendation — Define MFA policy ownership and enforce consistent authentication rules across systems. Operate the authentication platform as a controlled service with resilience and availability targets. Monitor MFA enforcement, exception activity, and failed authentication patterns continuously.
ISO/IEC 42001:2023	5.2 — AI policy	Not selected
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	MFA governance overlaps with access control and credential handling in identity ecosystems.
Recommendation — Map MFA exceptions and credential dependencies to a single governed access policy.

Practitioner Guidance

What to prioritise: Assign one accountable owner for MFA governance, then make every other team a named contributor with documented responsibilities for policy, platform reliability, and assurance. If you cannot answer who approves exceptions, who monitors failures, and who tests recovery, the control is not yet governed.

What to verify: Check that MFA policy covers all in-scope user paths, including privileged access, remote access, and any legacy or emergency routes. Verify that exceptions are time-bound, reviewed, and visible to security so they do not become permanent shadow controls.

Practitioner takeaway: Under DORA, MFA governance should be owned centrally for policy and accountability, but operated jointly so that control intent, technical resilience, and assurance stay aligned.