When does AAL2 stop being enough for identity governance?

Why This Matters for Security Teams

AAL2 is often treated as a universal answer because it adds a second factor, but identity governance fails when the question is not “was a user present?” and instead “what can a stolen session do before it expires?” For privileged administration, regulated transactions, and systems that drive material loss, the security requirement shifts from simple authentication strength to phishing resistance, verifier resistance, and session protection. Current guidance in NIST SP 800-63 Digital Identity Guidelines makes that distinction explicit, and NHIMG’s Ultimate Guide to NHIs shows why governance breaks down once credentials or sessions become the real attack surface.

The issue is not that AAL2 is weak in every context. The issue is that it does not, by itself, prevent replay, token theft, or post-authentication abuse when the downstream action is high impact. In practice, identity teams often validate the login control while leaving the session, device binding, and step-up requirements underspecified. That gap is exactly where attackers focus, especially in environments with remote access, SSO, and broad API-enabled administration. In practice, many security teams encounter the failure only after a session has already been abused, rather than through intentional identity design.

How It Works in Practice

Operationally, the right threshold is determined by impact, not by a blanket rule that “AAL2 is enough” or “AAL3 is required.” NIST identity guidance frames AAL as an authenticator assurance level, but governance teams should map the level to the action being protected: read-only access, standard employee workflows, privileged changes, financial transfers, and regulated record updates all carry different risk. The best practice is to combine authentication strength with session controls, conditional access, and explicit privilege controls, because AAL alone does not solve authorization.

For teams that are tightening identity governance, a practical pattern is:

• Use AAL2 for lower-impact access where stolen sessions are unlikely to create severe harm.
• Require phishing-resistant MFA, hardware-bound authenticators, or step-up authentication for privileged and high-value actions.
• Bind sessions to device posture, location, and risk signals where the platform supports it.
• Shorten session lifetime and force reauthentication before sensitive operations.
• Pair authentication with least privilege and privileged access workflows, not broad standing access.

This matters even more once identities extend beyond people. NHIMG’s 52 NHI Breaches Analysis and the Top 10 NHI Issues show how quickly compromised credentials, tokens, and overbroad access become an operational problem when governance is not tied to actual risk. For human identities, the same principle applies: if the action can trigger financial fraud, infrastructure change, or regulatory exposure, AAL2 should be treated as a baseline, not a finish line. These controls tend to break down in federated enterprise environments with long-lived sessions and inconsistent step-up enforcement because the policy decision is fragmented across multiple systems.

Common Variations and Edge Cases

Tighter authentication often increases user friction and support load, so organisations need to balance security gain against operational disruption. That tradeoff is real, especially where executives, administrators, and external partners rely on mobile devices, legacy SSO, or remote access portals.

There is no universal standard for this yet, but current guidance suggests several edge cases deserve special treatment. First, privileged administrators should usually be held to a higher bar than ordinary staff because the blast radius of compromise is much larger. Second, high-value financial workflows often need step-up controls at the transaction level, not just at login. Third, environments with shared devices, call centres, or contractor access may need different patterns because device binding and hardware keys are harder to deploy consistently.

NHIMG’s Ultimate Guide to NHIs and the Regulatory and Audit Perspectives section also reinforce a related point: auditors increasingly expect the organisation to justify why a given assurance level is acceptable for a given risk. If the answer is simply “AAL2 is the standard,” that is usually not enough for material-loss scenarios. The governance question is not whether AAL2 exists, but whether it matches the business consequence of compromise.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• Why is single-provider AI agent governance not enough for enterprise security?
• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?