Why do flexible levels of identity assurance matter when a wallet is used across different services?

Different services need different proof thresholds. A restaurant only needs age verification, while a prescription workflow may need stronger identity proofing, address validation, and issuance confidence. Flexible assurance lets organisations request only the attributes needed for the transaction, reducing privacy exposure while still meeting risk, compliance, and trust requirements.

Why This Matters for Security Teams

Flexible identity assurance matters because a wallet is not one fixed trust event. The same holder may only need to prove they are over 18 for one service, then prove stronger identity, address, or entitlement for another. That means assurance has to scale with the transaction, not with the application owner’s preference. Current guidance in NIST SP 800-63 Digital Identity Guidelines supports this risk-based approach, and it aligns with NHIMG’s broader warning that weak governance across identities creates avoidable exposure in production systems.

For security teams, the real issue is not whether a wallet can present credentials, but whether each verifier can trust the right evidence for its own risk level. Over-asking for proof increases privacy exposure and user friction. Under-asking creates fraud, compliance gaps, and poor decision quality. NHIMG’s Ultimate Guide to NHIs shows how quickly weak identity controls turn into operational risk, especially when credentials and access boundaries are too broad. In practice, many security teams encounter assurance failures only after a high-risk transaction has already been approved with low-quality evidence, rather than through intentional policy design.

How It Works in Practice

A flexible wallet model separates identity proofing from presentation. The issuer establishes who the person is and at what confidence level, then the wallet presents only the minimum attributes needed for a given service. That service can ask for different assurance levels based on policy, such as a low-friction age check, a medium-assurance account recovery step, or a high-assurance regulated workflow. This is consistent with the direction of NIST SP 800-63 Digital Identity Guidelines and the control discipline reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practical terms, teams usually define assurance tiers around transaction risk, then map those tiers to required evidence. A wallet may hold multiple verifiable credentials with different trust levels, and a verifier may require only one of them, or a combination. That lets organisations avoid asking for full identity proof when a single attribute will do. It also reduces the chance that a low-risk service becomes a data sink for excessive personal information. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that overexposed credentials and weak validation habits tend to compound into broader trust failures.

• Set assurance tiers by use case, not by organisation-wide default.
• Require the minimum proof necessary for the decision being made.
• Separate identity proofing, credential issuance, and attribute disclosure.
• Re-evaluate trust when a transaction changes risk, value, or regulatory scope.

Teams should also validate how the wallet handles selective disclosure, credential freshness, revocation, and audit logging. These controls tend to break down when a single wallet is reused across consumer, workforce, and regulated-service environments because each environment expects different proof strength and retention rules.

Common Variations and Edge Cases

Tighter assurance often increases friction and implementation cost, requiring organisations to balance privacy minimisation against regulatory and fraud constraints. There is no universal standard for wallet assurance levels yet, so many programmes use policy-led mapping rather than a single global scale. That means two services can both accept the same wallet while still demanding very different proof combinations.

One common edge case is reauthentication. A user may start a low-risk flow with minimal proof, then trigger a higher-risk action that requires step-up assurance. Another is delegated access, where a wallet proves the person but not the authority to act on behalf of an organisation. In those cases, identity assurance alone is not enough; entitlement, purpose, and context also matter. eIDAS 2.0 will likely influence some trust frameworks in Europe, but implementation patterns still vary by sector and jurisdiction.

The most important design choice is to avoid treating “wallet accepted” as “fully trusted.” Best practice is evolving toward context-specific proof, where each verifier decides what level of confidence is sufficient for its own decision. That approach is safer than one-size-fits-all verification, but it demands tighter policy design and more careful service classification.

Related resources from NHI Mgmt Group

• Who is accountable when a passwordless rollout fails to meet required identity assurance levels?
• Who remains accountable when wallet-based identity is used across banks and fintechs?
• When should organisations prioritise FIPS-compliant cryptography in identity platforms and token services?
• Who should be accountable for identity context in SOC workflows, and why does that matter?