Topic starter
22/06/2026 4:56 pm
TL;DR: NIST Authenticator Assurance Levels define how strongly an authentication ceremony proves the same person is presenting the credential, with AAL2 the default for most enterprise use and AAL3 reserved for the highest-risk paths, according to Scramble ID. The key governance issue is that assurance is a property of the ceremony, not the authenticator alone, so recovery and fallback flows can quietly lower security.
Editorial analysis by NHI Mgmt Group, based on content published by Scramble ID: “What Are NIST AAL Levels? AAL1, AAL2, and AAL3 Without the Standards Headache”.
Key questions
Q: What breaks when a user can bypass a strong authenticator through recovery or fallback?
A: The intended assurance level breaks down because the session inherits the weakest path in the ceremony, not the strongest credential on file.
Q: Why do AAL2 controls sometimes fail to protect privileged access?
A: AAL2 is strong enough for many enterprise uses, but it does not guarantee verifier-impersonation resistance or the hardware binding expected at the highest assurance level.
Q: How can security teams tell whether their authentication ceremony really meets the intended AAL?
A: They should test the complete flow, not just the primary login method.
Practitioner guidance
- Audit every recovery path Map password reset, alternate factor, help-desk verification, and emergency access flows to the assurance level they actually deliver, then compare them with the primary login ceremony.
- Set AAL3 for privileged access Use hardware-bound, phishing-resistant authentication for admin and high-impact transaction paths where verifier impersonation or compromise would materially increase blast radius.
- Treat step-up as a control boundary Require stronger assurance before privileged actions, not just at initial sign-in, and ensure the step-up path cannot be satisfied by a weaker fallback route.
Bottom line: AAL is a property of the authentication ceremony, which means deployment details can change the real assurance level even when the authenticator looks strong.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/06/2026 5:08 pm
Ceremony assurance, not authenticator branding, is the real governance unit: NIST AAL only makes sense when teams evaluate the full authentication ceremony, including attestation, verifier behaviour, and recovery. A passkey, push flow, or hardware token can still produce different assurance outcomes depending on how the path is deployed. Practitioners should govern the ceremony, not the marketing label.
A question worth separating out:
Q: Should organisations use the same assurance level for all applications and users?
A: No. AAL should follow risk, not uniformity. Low-risk read-only services can tolerate weaker assurance, while privileged users, regulated systems, and high-value transactions need stronger control. The right model is risk-proportionate access, with AAL2 as a common baseline and AAL3 reserved for the highest-impact paths.
👉 Read our full editorial: NIST AAL levels and what they mean for authentication risk