Start by mapping each journey to the evidence needed for the risk involved, then require the same assurance level across channels that perform the same function. Identity proofing should be tied to policy, source quality, and error handling, not to whichever verification step is easiest to automate.
What assurance level should actually mean in a proofing policy
Assurance levels are not a label you assign to the form or the vendor flow. They should express how much confidence the organisation needs in a claimed identity for a specific journey, such as account opening, beneficiary change, or high-value access. The right level depends on the risk of impersonation, the consequences of error, and the evidence quality behind the proofing outcome.
That means security teams should define assurance from the outside in: start with the business action, the fraud or abuse impact if the identity is wrong, and the strength of evidence required to make that error acceptably unlikely. A low-risk journey may tolerate simpler checks, while a regulated or high-loss journey needs stronger evidence, stricter binding, and more rigorous exception handling.
The practical test is consistency. If two channels perform the same proofing function, they should not land at different assurance levels just because one channel is easier to automate. A browser flow, mobile flow, or assisted flow can all be held to the same policy outcome if they are proving the same identity claim.
How to tie assurance to evidence, not channel convenience
Security teams get the most value by defining the evidence package first, then mapping channels to that package. The question is not whether a tool can complete a step, but whether it can produce evidence strong enough for the target level and preserve the quality of the proofing record. That includes document authenticity, liveness or presentation attack resistance, and the reliability of any trusted source used to corroborate the claim.
NIST SP 800-63 Digital Identity Guidelines are a useful external reference because they frame identity proofing and authenticators around assurance, not convenience. For organisations serving European users or planning wallet-based proofing flows, eIDAS 2.0 is also relevant where the proofing process connects to regulated digital identity and trust services.
Internally, NHIMG’s Identity Proofing and KYC Guide is the closest match for teams that need to translate assurance thinking into onboarding controls, while the Digital Identity, eID and Identity Wallets Guide helps when the proofing decision must align with reusable identity and wallet-based journeys.
Where proofing policy usually breaks in practice
Most failures come from inconsistent treatment of equivalent journeys. If a remote flow uses strong checks but an assisted flow or fallback path accepts weaker evidence for the same identity outcome, the organisation has created a policy gap, not a usability improvement. The same problem appears when escalation rules are vague and reviewers can override evidence thresholds without a clear fraud or compliance basis.
Another common failure is treating automation as the control rather than the enabler. Automation can improve scale and consistency, but it cannot fix poor source quality, weak binding between the person and the evidence, or a missing rule for what happens when evidence is inconclusive. A proofing decision must specify what counts as pass, what counts as retry, and what triggers manual review.
For teams operating at scale, NHIMG’s Identity Security Posture Management (ISPM) Guide is useful because assurance settings should be measurable and auditable, not just documented. The Workforce Identity Security Guide is a broader control reference for teams that want to compare proofing strength against downstream identity recovery and reset paths.
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, CSA Cloud Controls Matrix, OWASP ASVS and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IA-2 — Identity Proofing and Authentication | Digital identity proofing assurance maps directly to identity proofing and authenticator strength. |
| Recommendation — Map each journey to the required assurance level and enforce matching proofing evidence across channels. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Proofing assurance depends on the handling and quality of identity evidence and related authenticators. |
| Recommendation — Set evidence quality and handling rules for proofing inputs and recovery paths. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Assurance levels are part of identity governance and proofing controls for onboarding and access decisions. |
| Recommendation — Align proofing policy with identity governance so equivalent journeys receive equivalent assurance. | ||
| OWASP ASVS | V6 — Authentication | Proofing assurance affects how identity confidence is established before authentication is trusted. |
| Recommendation — Require proofing outcomes to support the authentication strength the journey needs. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Identity proofing assurance is a core identity management and access-control governance decision. |
| Recommendation — Define proofing assurance as part of identity and access control policy for each journey. | ||
Practitioner Guidance
What to prioritise: Define assurance by journey criticality and evidence strength, then standardise the same proofing outcome across every channel that performs the same function. The policy should make it impossible for convenience to lower assurance without an explicit exception.
What to verify: Before trusting the design, verify that each assurance level has clear evidence requirements, a defined fallback path, and a documented rule for manual adjudication when signals conflict. If reviewers can “just approve” weak cases, the assurance model is already degraded.
Common mistake: Teams often copy a vendor flow and assume the assurance level is inherited. In practice, assurance is only as strong as the weakest accepted evidence source, the loosest exception path, and the least controlled recovery method.
Practitioner takeaway: Set assurance levels from the risk of identity error, not from the easiest implementation path, and keep equivalent journeys aligned so one channel cannot silently become the weak point.
Related resources from NHI Mgmt Group
- How should security teams set assurance levels in digital onboarding?
- How can security teams decide whether a digital identity flow is high assurance enough?
- How should security teams handle high-assurance identity proofing for remote users without creating unnecessary friction?
- How should security teams design digital agreement workflows so that speed does not weaken identity assurance?