Should organisations use the same assurance level for all applications and users?

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.

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?