The clearest signs are repeated dependence on SMS or email OTP, poor visibility into authentication events, inconsistent controls across channels, and exceptions for third-party identity flows. If the team cannot explain how authentication behaves during phishing or session theft scenarios, then the control is probably too weak to support resilience claims.
What failing MFA looks like in a DORA context
Under DORA, MFA is not “working” just because users complete a second step. The control starts to fail when that step is weak, bypassable, or unevenly applied. Repeated use of SMS or email OTP, weak recovery paths, and gaps between primary login and step-up authentication are strong signs that the organisation is treating authentication as convenience rather than resilience.
Visibility matters as much as method. If authentication events are incomplete, hard to correlate, or missing across brokers, VPNs, SaaS apps, and delegated third-party flows, the team cannot prove the control behaves consistently under stress. That is especially important when authentication is supposed to support DORA’s operational resilience expectations.
Where the control usually breaks down
The most common failure mode is treating MFA as a single product choice instead of a policy enforced across all access paths. A strong sign of weakness is inconsistent treatment of employee access, administrator access, partner access, and machine-to-human handoffs, because attackers usually take the weakest path rather than the most important one.
Another sign is excessive reliance on legacy authenticators that are easy to intercept or fatigue. If SMS OTP, email OTP, or push approval remain the dominant methods, the organisation is still exposed to relay attacks, social engineering, and session theft. The fact that a user “approved” access does not matter if the approval was induced or replayed.
DORA also raises the bar on third-party dependency. If external identity providers, outsourced support desks, or federated partner logins are exempt from the same assurance level, the control is fragmented. That fragmentation is often visible in exceptions, manual approvals, and undocumented recovery procedures rather than in the authentication method itself.
How practitioners should read the warning signs
Look first for evidence of assurance, not just enrollment. A control is weak if the team cannot explain which phishing-resistant methods are in use, how step-up decisions are made, or what happens during a stolen-session scenario. The most useful sign is whether the authentication design still holds when the attacker already has a password, token, or active session.
For baseline comparison, NIST SP 800-63 Digital Identity Guidelines is the clearest reference point for authenticator assurance, phishing resistance, and recovery design. If the operational model cannot be explained against that kind of assurance thinking, the organisation is probably overestimating its MFA posture.
Risk and Threat Considerations
Weak MFA becomes a resilience problem when the control is easy to replay, bypass, or sidestep through recovery and federation paths. The practical risk is not only account takeover, but loss of confidence that access controls behave predictably during a phishing or session theft event, which is exactly when DORA scrutiny matters most.
Failure mechanism: Attackers exploit weak factors, OTP relay, session theft, mfa fatigue, or inconsistent third-party enforcement to turn “multi-factor” into a recoverable login path rather than a barrier.
Impact: The organisation loses assurance over authentication, expands blast radius across systems and suppliers, and may be unable to defend resilience claims after a real incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), OWASP ASVS and NIST SP 800-63 set the technical controls, while DORA defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MFA failures often show up in weak authenticator lifecycle and recovery handling. |
| IA-2 — Identification and Authentication (Organizational Users) | DORA-relevant MFA issues affect user login assurance and access enforcement. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Third-party identity flows and partner access are central failure points in the question. | |
| Recommendation — Tighten authenticator lifecycle controls and remove weak fallback methods. Require stronger authentication for user access paths that handle sensitive business functions. Apply the same authentication standard to external and third-party access paths. | ||
| NIST Zero Trust (SP 800-207) | ID — Identity Management | DORA expectations depend on consistent identity assurance across all access paths. |
| Recommendation — Bind authentication strength to risk and remove exceptions across trust boundaries. | ||
| OWASP ASVS | V6 — Authentication | The question asks for concrete signs that authentication strength is insufficient. |
| Recommendation — Verify phishing-resistant authentication, recovery, and step-up behavior under attack scenarios. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | MFA adequacy is best judged against assurance and recovery expectations. |
| Recommendation — Map each access path to the assurance level it actually achieves. | ||
| DORA | ICT third-party risk management — ICT third-party risk management | Exceptions for suppliers and federated flows are a core DORA concern. |
| operational resilience testing — Operational resilience testing | The question is about whether MFA still holds during phishing or session theft scenarios. | |
| incident reporting — Incident reporting | Weak MFA often becomes visible only after compromised authentication events. | |
| Recommendation — Extend authentication requirements and monitoring to every third-party access path. Test authentication under realistic attack conditions, not just enrollment success. Capture authentication telemetry needed to detect and report access compromise quickly. | ||
Practitioner Guidance
What to verify: Confirm that phishing-resistant authentication is actually required for privileged and remote access, and that recovery, exception handling, and third-party flows meet the same standard. If any high-value path still depends on SMS, email OTP, or a manual override, treat that as a material gap rather than a minor usability issue.
What good looks like: The control is coherent across channels, produces clear logs, and can be explained in one sentence for phishing, token theft, and session hijacking scenarios. If the security team cannot show that, the MFA programme is not yet DORA-ready.
Practitioner takeaway: In a DORA assessment, the question is not whether MFA exists, but whether it remains effective when attackers target the weakest factor, the recovery path, or the supplier boundary.
Related resources from NHI Mgmt Group
- What are the signs that insurance onboarding is failing to meet customer expectations?
- What are the signs that a financial app is failing to meet Gen Z expectations?
- What are the signs that an SSH deployment is failing to meet secure baseline expectations?
- What are the signs that a global product strategy is failing to meet local data security expectations?