How can organisations tell whether their MFA programme is actually strong enough?

Why This Matters for Security Teams

MFA is often treated as a checkbox, but assurance depends on whether every path to a protected resource is equally resistant to phishing, replay, coercion, and reset abuse. The real test is not whether MFA exists, but whether weaker fallback paths quietly undermine it. NIST’s NIST Cybersecurity Framework 2.0 pushes teams to examine protection outcomes, while NHIMG research shows how identity shortcuts become operationally dangerous when they are left unreviewed.

That matters because attackers do not need to break the strongest factor if they can exploit the weakest exception. Recovery codes, SMS fallback, help desk resets, device re-enrolment, and session reauthentication can all become bypasses if they are not governed as rigorously as primary sign-in. In practice, many security teams discover MFA weakness only after an incident shows that a “protected” account still had a less secure route into the same sensitive system.

NHIMG’s analysis of the Microsoft Midnight Blizzard breach illustrates a recurring lesson: identity assurance fails when operational convenience outruns policy enforcement.

How It Works in Practice

A strong MFA programme is measured by assurance consistency. Every authentication path should be mapped, tested, and rated by resistance level so that the organisation knows which paths are truly phishing-resistant and which are only partially protective. Current guidance suggests treating MFA as a set of control paths rather than a single control, because the security value is determined by the weakest available option.

Practical evaluation usually starts with these questions:

• Are high-risk roles and sensitive apps protected by phishing-resistant methods such as FIDO2 or passkeys?
• Can users bypass stronger factors through SMS, email, backup codes, or knowledge-based reset flows?
• Are help desk and self-service resets subject to the same identity proofing and approval standards?
• Do policy and conditional access rules block weaker methods for privileged accounts?
• Are authentication logs reviewed for factor changes, repeated resets, and unusual fallback use?

For broader identity hygiene, the findings in the Ultimate Guide to NHIs are useful because they show how assurance degrades when credentials, tokens, and privileged access are not governed across their full lifecycle. The same logic applies to MFA: a method is only as strong as its enrolment, recovery, revocation, and monitoring controls. Teams should also align enforcement and telemetry with identity guidance in the NIST Cybersecurity Framework 2.0, especially where access control and detection need to reinforce each other.

Operationally, the best way to test strength is to walk the path an attacker would take: recover the account, rebind the factor, exploit the help desk, or use a less strict application entry point. These controls tend to break down when legacy systems, shared accounts, or unmanaged support processes allow a lower-assurance route to reach the same privilege boundary.

Common Variations and Edge Cases

Tighter MFA usually increases friction, so organisations must balance user experience, support load, and risk reduction. That tradeoff is real, especially where frontline staff, contractors, and legacy applications still depend on older methods. Best practice is evolving, but current guidance suggests that high-risk access should get stronger treatment than low-risk routine sign-in.

Edge cases matter because they are where MFA programmes often look strong on paper and weak in reality. Examples include:

• Federated identity where the upstream identity provider is less secure than the target application
• Break-glass accounts that are exempt from normal MFA policy but are rarely tested
• Shared administrative accounts where one factor effectively protects many users
• Device-bound methods that weaken if unmanaged endpoints are allowed onto the network
• Step-up authentication that is triggered too late to stop privilege escalation

NHIMG research on the Microsoft Midnight Blizzard breach is a reminder that recovery and exception handling can be as important as the primary factor. For programme design, the NIST Cybersecurity Framework 2.0 supports a continual improvement approach: test, measure, remediate, and re-test. Organisations that do not inventory every fallback path usually overestimate how strong their MFA is until an attacker proves otherwise.

Related resources from NHI Mgmt Group

• How can organisations tell whether credential management is actually working?
• How can organisations tell whether their data security programme is actually improving?
• How can organisations tell whether MFA enforcement is actually consistent across identities?
• How can organisations tell whether authentication is actually phishing-resistant?