Without revocation and status checking, verifiers may accept credentials that are expired, replaced, or compromised. That creates a false sense of assurance and can let unauthorized users pass identity checks. A wallet programme only remains trustworthy when status is checked at presentation time, not only when the credential was originally issued.
Why This Matters for Security Teams
digital identity wallet only improve trust when the verifier checks whether a credential is still valid at the moment of presentation. If revocation and status checking are missing, a wallet can present a credential that is expired, replaced, or compromised and still appear trustworthy. That is a control failure, not just a UX flaw, because the assurance decision is being made against stale information.
For security teams, the risk is amplified by the gap between issuance and use. In real environments, credentials are copied, cached, reissued, and reused across business processes, so the original issuance event says little about present risk. NHIMG’s Ultimate Guide to NHIs shows how often identity controls fail when lifecycle management is weak, and wallet flows suffer from the same pattern if status is treated as optional. The policy direction in eIDAS 2.0 also reinforces that identity assurance depends on verifiable status, not just issuance. In practice, many teams only discover this gap after a revoked credential has already passed an access check.
How It Works in Practice
A robust wallet flow separates issuance from verification. The issuer signs the credential, but the verifier must also query or validate current status before accepting it. That status check can be implemented through revocation registries, status lists, short-lived credentials, or cryptographic freshness signals, depending on the wallet architecture and trust model. Current guidance suggests that verification should happen at presentation time, not only during enrolment.
Commonly used patterns include:
- Checking a status list or revocation registry during each presentation.
- Using short-lived credentials so trust naturally expires if refresh does not occur.
- Binding proof of possession to the presentation so copied artifacts are less useful.
- Rejecting credentials that are expired, suspended, or superseded by a newer issuance.
This matters because the wallet is only one side of the trust decision. The verifier must know whether the credential was revoked for fraud, changed because the subject was reissued, or remains valid under the current policy. NHIMG’s 52 NHI Breaches Analysis and Top 10 NHI Issues both show the operational cost of stale identity artefacts: once a secret or identity artifact is no longer current, it becomes an attack path. These controls tend to break down when offline verification is required for long periods because the verifier cannot confirm current status in real time.
Common Variations and Edge Cases
Tighter revocation checking often increases latency and dependency on issuer availability, so organisations must balance stronger assurance against resilience and user experience. There is no universal standard for this yet, and wallet programmes often adopt different status models based on regulatory and operational constraints.
Offline use is the biggest edge case. If a verifier must operate without network access, teams may rely on short credential lifetimes, cached status with tight expiry, or selective disclosure schemes that reduce exposure when live revocation cannot be confirmed. The tradeoff is clear: the longer a verifier can operate offline, the more risk it accepts from stale status. That risk is especially visible in high-volume environments where credentials are reissued often or where users switch roles frequently.
NHIMG’s Ultimate Guide to NHIs highlights how lifecycle controls fail when offboarding is incomplete, and wallet status checks fail for the same reason: if revocation is not operationalised, trust decays silently. Best practice is evolving toward real-time status validation with short-lived credentials as the default, especially where identity assurance supports regulated access or fraud-sensitive workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and validation depend on current credential status. |
| NIST SP 800-63 | 5.6 | Digital identity assurance depends on revocation and authenticator lifecycle controls. |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero Trust requires continuous verification, not one-time trust at issuance. |
| NIST AI RMF | GOVERN | Identity governance for automated trust decisions needs accountable lifecycle controls. |
| EU AI Act | Identity assurance failures can undermine compliance where automated access decisions are used. |
Ensure wallet-based decisions remain auditable, current, and proportionate to risk.
Related resources from NHI Mgmt Group
- What should security teams evaluate before adopting digital wallet identity flows?
- What breaks when verifier identity is not governed in wallet-based flows?
- What breaks when digital identity workflows do not track application status end to end?
- What breaks when a digital identity wallet relies on a unique identifier?
