How should organisations choose the right NIST AAL level for an application?

Start with the impact of compromise, then match assurance to the action. Low-risk read-only access may tolerate AAL1, most workforce and customer access should begin at AAL2, and privileged or high-risk transactions should move to AAL3. The correct choice also depends on recovery flows, regulatory obligations, and whether phishing resistance or verifier-compromise resistance is required.

Why This Matters for Security Teams

Choosing the wrong Authentication Assurance Level, or AAL, is usually not a login problem. It is an exposure problem. If assurance is too weak, attackers get a path to high-value actions after a single credential event. If it is too strict, users and service teams fall back to workarounds that weaken the control in practice. NIST SP 800-63 Digital Identity Guidelines ties assurance to the risk of the transaction, not to identity type alone, which is why the same application can justify different AALs for different actions.

For organisations managing large numbers of NHIs, the decision becomes sharper because service accounts and API keys often outnumber human users by 25x to 50x, and compromised NHIs are a common breach path. NHI Management Group’s Ultimate Guide to NHIs — Standards also notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams discover the AAL mismatch only after a sensitive workflow has already been abused, rather than through intentional risk-based design.

How It Works in Practice

The practical way to choose an AAL is to start with what the application can do, then ask what a compromised authenticator would enable. AAL1 can be acceptable for low-impact, read-only access where compromise creates limited harm. AAL2 is the common baseline for workforce and customer applications because it adds meaningful confidence without creating excessive friction. AAL3 is appropriate when the action is privileged, irreversible, regulated, or capable of causing material operational harm.

That choice should be made per workflow, not per product. For example, a portal may allow AAL2 for viewing records but require AAL3 for changing payment details, approving policy exceptions, or performing administrative actions. Current guidance suggests that phishing resistance becomes a deciding factor when the transaction is sensitive enough that credential replay is unacceptable. NIST’s digital identity guidance and the NIST Cybersecurity Framework 2.0 both support aligning assurance to risk, while NHI-specific controls in the Ultimate Guide to NHIs — Standards reinforce that identity governance must account for lifecycle, rotation, and privilege exposure.

• Use AAL2 as the default starting point for most interactive access unless the transaction is clearly low risk.
• Escalate to AAL3 where compromise could enable fraud, privilege escalation, or regulatory breach.
• Test recovery flows, because step-up authentication is only useful if account recovery is at least as strong as primary login.
• Separate authentication strength from authorisation strength; strong login does not justify broad access.

For NHIs, apply the same logic to workload authentication rather than human MFA. That usually means pairing workload identity, short-lived credentials, and policy checks with the action being requested. These controls tend to break down when legacy applications require shared secrets or when the recovery process is weaker than the authentication path, because attackers target the easiest bypass, not the nominal AAL target.

Common Variations and Edge Cases

Tighter assurance often increases operational overhead, so organisations have to balance stronger protection against user friction, support load, and application complexity. That tradeoff is especially visible in mixed environments where one application serves both employees and external customers, or where an older system cannot support modern phishing-resistant methods.

There is no universal standard for this yet on how every edge case should be mapped, but current guidance suggests treating AAL as contextual rather than static. A read-only reporting app may be fine at AAL1, while the same app should step up if it exposes export functions, bulk actions, or account administration. Likewise, service-to-service traffic should not be forced into human authentication patterns; the better fit is workload identity and short-lived credentials, with assurance driven by the sensitivity of the calling workload and the action requested.

Two situations deserve special attention. First, recovery and help-desk processes often become the weakest link, so if password reset or identity proofing is easier to abuse than the primary login, the effective assurance level drops. Second, regulatory or contractual requirements may override a simple risk judgement, especially in sectors that require phishing resistance or stronger verifier-compromise resistance. NIST AI 600-1 and NIST IR 8596 are also relevant when the application is part of an AI-enabled workflow, because the assurance decision should account for machine-driven actions that can scale quickly and unpredictably.

Security teams usually get this wrong when they treat AAL as a one-time procurement decision instead of a control that has to track transaction risk, recovery design, and privilege growth over time.

Related resources from NHI Mgmt Group

• How should organisations choose the right assurance level for electronic signatures?
• Should organisations choose NIST CSF or ISO 27001 for NHI governance first?
• How should organisations use cryptographic verification at physical sites?
• When should organisations investigate Microsoft 365 application identities first?