MFA helps when it is resistant to phishing, replay, and session abuse, and when logs show how it was used. It is not enough when factors are reusable, poorly bound to the session, or applied without risk context. DORA expects controls that reduce incident likelihood and support investigation.
Why This Matters for Security Teams
DORA is not asking whether MFA exists in the abstract. It is asking whether the control meaningfully reduces operational risk, resists common attack paths, and gives investigators evidence after an incident. That means phishing-resistant MFA, strong session binding, and usable logs matter far more than box-ticking. Weak MFA can still leave service access, API consoles, and admin portals exposed when credentials are replayed or sessions are hijacked.
The risk is especially visible where human approvals, service accounts, and machine-to-machine access intersect. NHI sprawl means a single weak factor can be amplified across many systems, and the NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives. Under the DORA — Digital Operational Resilience Act, that lack of visibility weakens the ability to prove control effectiveness.
Practitioners often discover the gap after a session token is abused, not during an MFA design review.
How It Works in Practice
MFA helps most when it is one part of a layered access decision. For DORA-aligned environments, the question is whether the factor is resistant to phishing, whether it is bound to the right device or session, and whether the logging shows who approved access, when, and from where. If the factor can be replayed, shared, or accepted long after the original challenge, the security value drops quickly.
Operationally, strong MFA should sit alongside PAM, RBAC, and just-in-time elevation so that privileged access is granted only when needed and then removed. That is especially important for admin accounts, cloud consoles, and CI/CD access where a single login can reach many workloads. For machine access, the same principle applies through workload identity and short-lived secrets rather than reusable shared credentials. The Microsoft Midnight Blizzard breach is a reminder that identity controls fail when attackers can pivot through trusted access paths rather than force noisy password attacks.
- Use phishing-resistant methods where possible, not SMS or reusable one-time codes.
- Bind the factor to the session, device, or transaction context where the platform supports it.
- Log the authentication event, step-up decision, and privilege granted in a way investigators can reconstruct.
- Pair MFA with JIT access, so approval does not create standing privilege.
That is consistent with the intent of the EU Digital Operational Resilience Act (DORA), which expects controls to reduce incident likelihood and support analysis. These controls tend to break down in legacy VPN, RDP, and shared-admin environments because the session is already trusted once the factor is presented.
Common Variations and Edge Cases
Tighter MFA often increases user friction and recovery overhead, so organisations have to balance resilience against operational delay. Current guidance suggests that this tradeoff is acceptable for high-risk access, but there is no universal standard for every workflow yet. That is why step-up MFA for sensitive actions is usually more defensible than forcing the same control everywhere.
The main edge case is non-human access. Secrets used by scripts, agents, and integrations are not improved by human MFA prompts; they need short-lived credentials, rotation, and strong workload identity instead. Another edge case is offline or emergency access, where break-glass accounts may need special treatment, separate monitoring, and rapid post-event review. The control also loses force when logs are incomplete, because DORA assessment is not only about prevention but also about traceability during incident response.
In practice, many weaknesses become obvious only when teams review the account lifecycle. The Schneider Electric credentials breach shows how credential compromise can become an enterprise problem when access paths are not sufficiently constrained. For that reason, MFA should be treated as a resilience layer, not a substitute for least privilege, JIT access, and secret hygiene. In highly distributed environments with shared consoles and third-party access, MFA alone can still leave too much room for abuse.
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 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | DORA requires controls that reduce risk and support investigation after incidents. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | NHI access paths often fail when credentials or sessions are reusable. |
| NIST CSF 2.0 | PR.AC-7 | Authentication strength and session handling map directly to identity assurance. |
Use phishing-resistant MFA with auditable logs and combine it with least privilege and recovery procedures.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
