Notifications
Clear all
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.
NHIMG editorial — based on content published by Scramble ID: What Are NIST AAL Levels?
By the numbers:
- NIST SP 800-63-4 was finalized in July 2025 and supersedes 800-63-3.
- AAL2 requires reauthentication at least once per 12 hours, or after 30 minutes of inactivity.
Questions worth separating out
Q: How should organisations choose the right NIST AAL level for an application?
A: Start with the impact of compromise, then match assurance to the action.
Q: When does AAL2 stop being enough for identity governance?
A: AAL2 stops being enough when the resource or action creates material loss if the session is phished, replayed, or hijacked.
Q: What do teams get wrong about NIST AAL levels?
A: The most common mistake is treating AAL as a property of the authenticator alone.
Practitioner guidance
- Inventory every authentication path Map primary sign-in, step-up, recovery, and administrator override paths to the assurance level actually delivered in practice.
- Set different AAL targets by action risk Require AAL3 for privileged and highest-risk transactions, use AAL2 as the default for most workforce and customer access, and reserve AAL1 only for truly low-risk read paths with no sensitive data.
- Test recovery like an attacker would Verify whether account recovery, help-desk resets, and fallback MFA can access the same protected systems as the primary ceremony.
What's in the full article
Scramble ID's full article covers the operational detail this post intentionally leaves for the source:
- Detailed AAL mapping for common authenticators such as passwords, TOTP, push, passkeys, PIV, and CAC
- Specific guidance on how attestation and verifier behaviour change the effective assurance level
- Practical decision flow for selecting AAL based on privileged access, regulated workloads, and recovery design
- The article's full FAQ coverage on common misconceptions about AAL3, synced passkeys, and step-up authentication
👉 Read Scramble ID's guide to NIST AAL levels and authentication risk →
NIST AAL levels: are your authentication controls matching risk?
Explore further
22/06/2026 5:08 pm
AAL is a human identity control, but its governance value extends into NHI and agentic programmes. The same assurance logic that governs workforce sign-in also shapes delegated access, service-console approvals, and administrator recovery paths. When identity programmes ignore that overlap, they end up with strong primary authentication and weak fallback governance. The practitioner conclusion is that assurance must be evaluated across every route into the account, not only the main login ceremony.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
A question worth separating out:
Q: How do AAL, IAL, and FAL work together in access decisions?
A: They answer different questions. AAL measures how strongly the user is authenticated now, IAL measures how well the person was proofed at enrollment, and FAL measures how strong the federated assertion is across trust boundaries. Mature identity programmes set each one deliberately rather than using a single control to cover all three problems.
👉 Read our full editorial: NIST AAL levels and what they mean for authentication risk
