Because the risk sits in the verification process, not only in the card itself. Organisations still need to know who a person is, how the assertion was issued, whether the provider is certified and whether the disclosed attribute is sufficient for the decision being made.
What the real identity risk is when the card disappears
The risk does not come from the plastic or app shell alone. It comes from the chain that proves a person is entitled to present an identity, the issuer behind the assertion, and the relying party’s ability to trust enough of the disclosed data for the specific decision.
That is why a physical card, a wallet, or even a central registry can be removed without removing the underlying risk. If the verification process still depends on the same weak proofing, the same replayable assertion, or the same untrusted provider relationship, the exposure remains in a different form.
A useful way to think about it is that identity assurance is a process property, not a card property. The security question shifts from “Do we have the card?” to “Can we rely on the identity evidence, the issuer, the authentication step, and the attribute set in the moment it is used?”
Why decentralisation changes the attack surface, not the need for trust
Decentralising or removing a central ID card can reduce one concentration point, but it does not remove the need to trust identity proofing, credential issuance, holder binding, provider certification, revocation, and selective disclosure. Those functions still exist somewhere in the stack, even if they are split across wallets, issuers, and relying parties.
That is why identity programmes based on wallets or verifiable credentials still need clear assurance rules. The relying party must know whether the attribute presented was issued by a recognised source, whether it is current, whether it was bound to the presenter, and whether it is sufficient for the access or transaction being requested.
For a broader view of how wallets, national eID and reusable credentials alter the verification model, see Digital Identity, eID and Identity Wallets Guide. For country-level scheme differences and relying-party duties, the National Digital ID Schemes Map is the best companion reference.
When organisations treat “no central card” as “no central trust problem,” they usually underinvest in issuer governance and assurance checking. That is where the residual risk lives: not in the absence of a card, but in the quality of the surrounding trust framework.
What organisations still have to verify before they can rely on the identity
The practical control question is whether the identity evidence is good enough for the action being taken. A low-risk age check, a service eligibility check, and a high-consequence account opening decision do not need the same level of assurance, even if they use the same wallet or credential format.
That means teams should separately verify proofing strength, issuer trust, presentation integrity, revocation status, and attribute minimisation. If the decision only needs an “over 18” result, the relying party should not demand or store a full identity record. If the decision is material, the relying party should require stronger evidence and tighter logging.
The operational hazard is over-trusting the presentation layer and under-checking the provenance layer. A credential can look modern and decentralised while still being weakly proofed, poorly governed, or easy to reuse across contexts.
For assurance depth, the Identity Proofing and KYC Guide helps with the evidence and liveness side, while the UK Digital Verification Services Trust Framework Guide shows why provider certification and trust-mark style governance matter to the relying party.
Risk and Threat Considerations
Removing a central ID card can shift the threat from simple card fraud to issuer compromise, presentation abuse, replay, or weak relying-party validation. The surface changes, but attackers still look for the weakest trusted step in the identity chain.
Failure mechanism: If the issuer is not sufficiently trusted, if the credential can be replayed, or if the relying party accepts too little evidence for the decision, an attacker can present a seemingly valid identity without meeting the real assurance requirement.
Impact: Organisations can admit the wrong person, approve transactions on the basis of incomplete evidence, or create privacy exposure by collecting more identity data than the decision actually needs.
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, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | NIST SP 800-63-4 — Digital Identity Guidelines | Identity assurance and verification are central to this question. |
| Recommendation — Apply NIST 800-63 assurance rules to match verification strength to the transaction. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | The question concerns trusted identity verification for external users. |
| Recommendation — Use IA-8 to govern how external identities are authenticated and accepted. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The topic depends on governing identity lifecycle and trust relationships. |
| Recommendation — Define and maintain identity records, proofing and ownership under identity management. | ||
| OWASP ASVS | V10 — OAuth and OIDC | The question touches on assertion issuance and trust in federated identity flows. |
| Recommendation — Verify federation and token trust controls before accepting identity assertions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Identity acceptance still depends on account lifecycle, ownership and review. |
| Recommendation — Track, review and disable identities that no longer need access. | ||
Practitioner Guidance
What to verify: Decide which part of the chain carries the real trust burden for each use case, then test that step first. If the proofing, issuer, or presentation step is weak, changing the card format will not change the risk profile.
Decision rule: If the relying party cannot explain why the presented attribute is sufficient for the specific decision, treat the flow as under-assured even if the credential is technically valid. If the decision is high consequence, require stronger issuer trust and better evidence of binding and freshness.
What good looks like: The organisation can accept minimal disclosure for routine checks, demand stronger assurance for high-risk actions, and still prove who issued the assertion, how it was verified, and why it was accepted.
Practitioner takeaway: Identity risk moves with trust, proof, and verification, not with the physical or digital card alone.
Related resources from NHI Mgmt Group
- What is the difference between patching a dependency and removing its access risk?
- Why does identity-based segmentation reduce lateral movement risk for workloads?
- Why do short-lived federated tokens reduce agent identity risk?
- Why do PHP worker compromises create identity risk beyond the application itself?