The proofing decision becomes a dead signal. A user may be verified at enrolment, then later receive privileges or access paths that do not reflect that original assurance level. That creates a governance gap where trust is created once but never enforced again.
Why assurance has to follow the user into policy
Identity assurance only matters if downstream policy can still see it. The moment an assurance level stops at onboarding, access decisions begin to drift from the original proofing strength. That weakens trust propagation across the identity lifecycle and turns a one-time verification into a stale record rather than an active control.
When policy does not inherit assurance, the organisation can no longer distinguish between users who were strongly proofed and users whose access should be constrained, stepped up, or reviewed differently. The result is not just inconsistency, but a broken relationship between who was verified and what they are allowed to do.
That gap is especially visible when access is granted through identity and access management or governed through identity governance. If the policy layer cannot consume assurance attributes, the original proofing decision stops influencing entitlements, recertification, or privilege boundaries.
Where the break shows up operationally
The practical failure is that the identity system may still authenticate a user correctly while the access layer makes decisions as if all users were equivalent. That can produce overly broad roles, weak step-up triggers, or access reviews that miss the fact that some accounts began life with a lower or higher trust level than others.
This is why assurance has to be carried into identity proofing and assurance records, then reflected in authorisation logic. The policy engine needs a usable signal, not just an audit note, so that trust can shape access rules, escalation paths, and exception handling.
A useful way to think about the break is that the verification event and the authorisation event are no longer joined. The proofing outcome may still be true, but it is no longer operationally relevant if policy cannot consume it at login, request time, or review time.
That is also why standards for identity security matter here: they reinforce the idea that assurance is not a one-off artifact, but a control input that must remain usable across the access lifecycle.
Why governance and review processes fail when assurance is detached
Once assurance is not propagated, governance teams lose a meaningful way to compare access against the quality of the original identity evidence. Reviews can still happen, but they become flatter and less risk-aware because they lack context about how strongly the account was established in the first place.
That matters for access recertification, exception approvals, and privilege reviews. A user who was lightly verified should not be treated exactly like one who was strongly proven, yet that distinction disappears if assurance never reaches the policy model. The same issue appears in mixed environments where people, service accounts, and delegated access all share the same approval workflow.
For practitioners, the cleaner model is to bind assurance to the identity record and then make it available to authorisation and governance controls as a decision attribute. Otherwise, the organisation is forced to compensate manually every time access changes, which is usually where gaps and policy drift appear.
Risk and Threat Considerations
The main risk is trust inflation: access can expand while the original proofing strength stays hidden or ignored. That creates a path where an identity that should have been constrained or reverified can accumulate privileges, especially after role changes, delegation, or account recovery events.
Failure mechanism: The assurance signal becomes non-operative, so downstream policy and review systems treat all identities as equally trusted even when the proofing evidence differs materially. That makes privilege growth, exception approval, and account recovery decisions less defensible.
Impact: Organisations can end up authorising access that exceeds the trust level actually established at enrolment, which raises the likelihood of inappropriate access, governance failures, and harder-to-detect account abuse.
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 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Level | Assurance levels must inform downstream access decisions and trust requirements. |
| Recommendation — Propagate assurance attributes into access policy and reverify when the requested access exceeds the original trust level. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | External identity trust and proofing must carry through to access enforcement. |
| AC-6 — Least Privilege | When assurance is ignored, privilege can exceed the strength of identity evidence. | |
| IA-5 — Authenticator Management | Assurance drift often becomes visible when authenticators and access lifecycles are not managed together. | |
| Recommendation — Tie proofing outcomes to authorization checks so verified identities do not receive mismatched access. Limit entitlements so higher-risk access requires stronger identity assurance. Align authenticator lifecycle and access policy with the assurance state of the identity. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity records must remain usable in access governance and lifecycle decisions. |
| Recommendation — Maintain identity attributes, including assurance, so access governance can apply them consistently. | ||
| OWASP ASVS | V8 — Authorization | Authorization must enforce context, not just authenticate a user once. |
| Recommendation — Require authorization decisions to use current identity context, including assurance-related attributes. | ||
Practitioner Guidance
What to verify: Check that your assurance level is a live attribute in policy, not just a stored enrollment field. If access decisions, recertification, or step-up logic cannot read it, the control is already degraded.
Decision rule: If the access request can lead to privileged or sensitive access, require policy to evaluate the assurance state before approval, not after the fact. If it cannot, treat the workflow as incomplete.
What good looks like: The account’s proofing strength is visible at access time, review time, and exception time, so reviewers can see whether the requested privilege is consistent with the original trust level.
Practitioner takeaway: The control fails when identity assurance is treated as a historical event instead of a policy input; the fix is to make assurance continuously actionable wherever trust is used to grant or retain access.
Related resources from NHI Mgmt Group
- What breaks when organisations define identity access rules only from policy documents and not actual usage patterns?
- What breaks when public services rely on online access without enough identity assurance?
- What breaks when identity silos prevent consistent access policy enforcement?
- How should security teams run access reviews for non-human identities?