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.
What “same assurance level for everyone” gets wrong
Uniform assurance treats all access as equally sensitive, but assurance only has value when it matches the consequence of compromise. A read-only status dashboard, a payroll system, and a production admin console do not justify the same sign-in strength or recovery process. Risk-proportionate assurance reduces friction where exposure is low and concentrates stronger controls where misuse would matter most.
assurance level is not a badge for the user; it is a control decision about the transaction, application, and permission set involved. That is why many programmes treat baseline workforce sign-in differently from privileged access, regulated data handling, or high-value actions such as payment release, account change, or configuration updates.
The practical implication is that “one level for all” often creates two failures at once, under-protecting sensitive paths and over-protecting low-value ones. Over time, that leads teams to bypass the control, weaken recovery, or carve out exceptions that quietly erode the whole model.
How to think about AAL as a risk-proportionate control
The better model is to align assurance with the access decision being made. AAL2 is a common baseline for routine workforce and customer use because it balances usability and resistance to common attacks, while AAL3 is reserved for the highest-impact paths where phishing resistance, stronger authenticator binding, and tighter recovery are worth the added friction. The NIST SP 800-63 Digital Identity Guidelines are the clearest reference point for that risk-based split.
In practice, the assurance decision should follow the sensitivity of the action, not just the identity type. A single user may need AAL2 for everyday sign-in, step-up authentication for sensitive changes, and AAL3 for privileged or regulated operations. That is a normal pattern in mature programmes, because the same person can move across very different risk zones during one session.
Application context also matters. The assurance level for a low-risk internal tool should not automatically be reused for a customer onboarding flow, a high-value financial action, or an administrative workflow that can change entitlements or data integrity. Where the action creates irreversible business impact, stronger assurance and tighter recovery controls become part of the control design, not an optional enhancement.
Why consistency still matters, even when assurance is not uniform
Risk-based assurance does not mean ad hoc decisions. The organisation still needs a clear policy for which application classes, user roles, and transaction types require which assurance level, so teams do not negotiate security on every project. The strongest programmes define repeatable triggers for step-up, explicit exceptions for lower-risk paths, and measurable recovery standards for stronger authenticators.
Consistency is especially important in recovery and exception handling. If a high-assurance authenticator can be weakened through easy reset paths, the nominal AAL no longer reflects real protection. Guides such as NHIMG’s MFA Guide and Passwordless and Passkeys Guide are useful for understanding why phishing-resistant sign-in and secure recovery have to be designed together.
For customer identity flows, assurance often starts even earlier, at proofing and enrollment. NHIMG’s Identity Proofing and KYC Guide is a helpful reminder that higher assurance is not only about login, it is also about how confidently the organisation knows who it is binding to the account in the first place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authenticator Assurance Level | AAL selection directly governs assurance strength by risk and transaction sensitivity. |
| Recommendation — Set AAL by action risk and step up for privileged or high-value transactions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Workforce sign-in strength must match user access sensitivity and role impact. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | External-user assurance needs vary by account risk, onboarding and transaction value. | |
| Recommendation — Apply stronger identification and authentication for higher-impact organizational access. Use stronger authentication for external users when account impact is material. | ||
| OWASP ASVS | V6 — Authentication | Application authentication requirements should vary with the sensitivity of protected actions. |
| V10 — OAuth and OIDC | Federated sign-in and step-up assurance depend on the identity flow used by the app. | |
| Recommendation — Align authentication requirements to the sensitivity of each application action. Validate federated assurance and step-up handling for sensitive sign-in paths. | ||
| NIST SP 800-57 | Key Management | Stronger authenticators often rely on managed cryptographic keys and recovery protections. |
| Recommendation — Manage authenticator keys and recovery material with strict lifecycle controls. | ||
Practitioner Guidance
What to prioritise: Tie assurance to the highest-impact action a session can perform, not to the broadest label on the user or application. If a workflow can move money, expose regulated data, or change privileges, its assurance target should be higher than a normal read-only or collaboration path.
What to verify: Check whether recovery, reset, federation, and help-desk override paths are held to the same standard as primary sign-in. Weak backdoor recovery often becomes the real ceiling on assurance, no matter what the policy says.
Decision rule: If the consequence of compromise is limited and reversible, keep the assurance burden light enough that people will actually use it; if compromise can create material loss, fraud, or privilege abuse, require stronger authentication and tighter step-up controls.
Practitioner takeaway: The goal is not uniformity, it is proportionality, because assurance only works when the control strength tracks the business impact of the access path.
Related resources from NHI Mgmt Group
- Should organisations use the same authentication method for all users and use cases?
- Should organisations allow AI workers to use the same privileges as users?
- Should crypto exchanges use the same assurance level for recovery as onboarding?
- What common vulnerabilities do cloud applications face with OAuth tokens?