How do teams know whether MFA is actually meeting AAL2 or AAL3 expectations?

What AAL2 and AAL3 Really Mean in Practice

AAL is not a product feature, it is an assurance outcome. Teams need to evaluate the actual authenticators and the way they are bound to the user, because AAL2 and AAL3 are driven by the strength of the factor, resistance to phishing, and whether the protected factor can be used without exposing reusable secrets or easily replayed approvals. That makes the implementation details more important than the MFA checkbox.

For AAL2, the question is usually whether the factor combination is strong enough and resistant enough to common interception or relay attacks to support the needed assurance. For AAL3, the bar is higher because the authenticator must use hardware-backed or otherwise protected cryptographic material, and the design should make simple phish-and-replay paths materially harder.

The practical test is whether the factor can be satisfied by something a phisher, attacker, or help desk workaround could easily capture and reuse. If the answer is yes, the assurance claim is likely overstated even if the sign-in flow still looks like MFA.

How to Validate the Real Assurance Level

Start with the authentication method inventory, not the policy label. List every allowed path to sign in, then check whether each path meets the assurance properties you think you deployed. SMS, email one-time links, weak TOTP-only flows, and push prompts without phishing resistance commonly fall short of the expectations many teams attach to AAL2, let alone AAL3.

Next, verify the authenticator class and whether it is bound to the right device, user, or cryptographic material. A passkey or FIDO2 security key path may be capable of meeting stronger expectations, but only if the deployment and recovery flow do not quietly reintroduce weaker fallback methods.

Recovery and exception handling matter as much as primary sign-in. If users can regain access through a weaker channel, the effective assurance level becomes the weakest successful path, not the strongest advertised one.

Where Teams Usually Misread MFA Strength

Teams often confuse “multi-factor” with “high assurance.” That mistake happens when any second step is treated as equivalent, even though factor type, phishing resistance, enrollment controls, and fallback options change the actual security outcome.

Another common error is assuming that a control is strong because it blocks casual password-only attacks. AAL2 and AAL3 are about more than stopping old-school password reuse. They are about whether the system can withstand realistic phishing, relay, token theft, and account recovery abuse without collapsing into a weaker form of access.

In maturity reviews, the sign-in policy page is usually the least reliable evidence. Better evidence comes from configuration, user journey testing, recovery procedures, and logs showing which authenticators are actually accepted in production.

Risk and Threat Considerations

Misstated assurance levels create a false sense of protection. If a system is described as AAL2 or AAL3 but still accepts weak or phishable methods, attackers can target the weaker path, bypass the intended control, and gain access through the easiest entry point rather than the strongest one.

Failure mechanism: The deployed MFA stack may include fallback factors, recovery flows, or prompt-based methods that do not meet the stated assurance bar, so the effective security level is determined by the weakest accepted authenticator.

Impact: Access decisions, trust decisions, and downstream security assumptions become unreliable, which can expose accounts, sessions, and protected resources even when the directory or IdP appears “MFA enabled.”

Practitioner Guidance

What to verify: Validate the exact authenticators accepted for primary login, step-up, and recovery. If any path relies on SMS, email, or other weak fallback methods, treat the assurance claim as not yet proven.

What good looks like: The strongest assurance path is the default path for the intended population, fallback methods are tightly constrained, and recovery does not quietly downgrade the user to a weaker factor class.

Decision rule: If a user can satisfy access with a factor that is easily phished, relayed, or recovered through a low-friction support process, do not describe the implementation as meeting the higher assurance expectation.

Practitioner takeaway: MFA labels tell you almost nothing until you inspect the allowed authenticator paths, because assurance is set by the weakest usable route, not the strongest one on paper.

Related resources from NHI Mgmt Group

• How do teams know whether external MFA is actually improving security?
• How do organisations know whether their resilience testing programme is actually meeting DORA expectations?
• How do security teams know whether their MFA programme is actually defensible?
• How do security teams know whether MFA enforcement is actually working across privileged and remote access accounts?