What breaks when a verifiable digital credential is not checked for revocation and device binding?

If revocation and device binding are not checked, a bank can accept a credential that is no longer valid or is being replayed from the wrong device. That creates a gap between the credential and the real customer, which weakens fraud controls and can undermine the bank’s reasonable belief that it knows who is opening the account. The result is avoidable trust in altered or stale identity data.

What breaks in the trust chain when revocation is skipped?

A verifiable digital credential only remains trustworthy while the relying party confirms it is still valid. If revocation is not checked, the verifier can accept a credential that should have been invalidated, so the credential’s current status no longer matches the issuer’s intent. In practice, that weakens fraud controls, creates stale trust, and can let an attacker keep using a credential after compromise.

That gap matters because revocation is part of the control that turns a signed credential into a live trust decision. Without it, you are relying on issuance alone, not on the ongoing state of the credential. For a bank or similar verifier, that can mean accepting an identity assertion that should no longer be relied on for account opening or step-up decisions.

When revocation checking is treated as optional, the system may still validate signatures and claims while missing the fact that the credential has been cancelled, superseded, or withdrawn. The result is not a broken signature, it is a broken assurance model. That is why revocation belongs in the verification path, not just in issuer policy.

Why device binding changes the meaning of possession

device binding adds a second trust signal: the credential is not only valid, it is being presented from the expected device or holder environment. If device binding is not checked, a stolen or replayed credential can be replayed from another device and still look legitimate at the protocol level. That removes an important barrier between a live customer session and a copied credential.

This is especially important for credentials used in remote onboarding, login, or account opening flows, where the verifier is trying to distinguish a real holder from a replay or transfer. Without device binding, possession becomes too easy to counterfeit. The system may still see a valid credential, but it loses confidence that the person or device presenting it is the one originally bound to it.

Device binding is therefore not just a nice-to-have hardening measure. It is what helps the verifier interpret presentation context correctly. If the credential can travel freely between devices, then a valid signature alone does not tell you whether the right holder is in control.

What the verifier loses when both checks are missing

Missing both revocation and device binding creates a compound failure. Revocation protects against stale or withdrawn credentials, while device binding helps resist replay and unauthorized reuse. If both are absent, the verifier can no longer tell whether the credential is current, whether it is being replayed, or whether the presentation path is the one originally intended by the issuer.

For the relying party, that usually shows up as weaker assurance, higher fraud exposure, and more reliance on downstream controls such as manual review or post-transaction detection. It also increases the chance that the verifier builds policy decisions on altered identity data, which can distort onboarding, KYC-like checks, and account lifecycle decisions.

The practical breakage is subtle: the credential may still validate cryptographically, but the surrounding trust assumptions no longer hold. That is why a verifier needs to treat revocation status and holder binding as part of the same assurance decision, not as separate hygiene checks.

Risk and Threat Considerations

When revocation and device binding are skipped, the main risk is accepting an identity assertion that is technically valid but operationally untrustworthy. That creates a clear fraud path: a revoked, stolen, or replayed credential can be used to impersonate the real holder, especially where onboarding or access decisions depend on the credential alone.

Failure mechanism: The verifier accepts a signed credential without confirming that the issuer has not revoked it and without confirming that it is being presented from the bound device or expected holder context. That allows stale, copied, or replayed credentials to pass as current.

Impact: Fraud controls weaken, unauthorized account opening becomes more likely, and the organisation may build business decisions on identity data that is no longer accurate or current.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Revoked or replayed credentials are still bearer secrets.
	NHI-04 — Insecure Authentication	Missing revocation and device binding weaken authentication assurance.
	NHI-07 — Long-Lived Secrets	Stale credentials create replay risk when status is not rechecked.
Recommendation — Check revocation and rotate exposed credentials immediately. Enforce fresh validation and holder binding before accepting the credential. Shorten credential lifetime and require revocation-aware verification.
OWASP API Security Top 10	API2 — Broken Authentication	Accepting stale or replayed credentials is an authentication failure mode.
Recommendation — Require robust credential validation and reject replayed assertions.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Credential lifecycle and revocation are central to this trust break.
	IA-9 — Service Identification and Authentication	Binding a credential to the correct presenting device is an authentication concern.
Recommendation — Manage issuance, revocation, and replacement of authenticators. Bind authenticators to the expected client or device context.
NIST SP 800-63	4.2 — Authenticator and Verifier Requirements	Verifier checks must cover current validity and resistant presentation.
	4.3 — Federation Assertions	Verifiable credentials rely on current assertion validity at the relying party.
Recommendation — Verify credential status and use holder-binding protections during authentication. Validate assertion freshness and reject revoked credentials.
CIS Controls v8	5 — Account Management	Credential validity and revocation are core account lifecycle controls.
	6 — Access Control Management	Device binding helps enforce that access comes from the intended holder.
Recommendation — Review and revoke credentials promptly when trust conditions change. Restrict credential use to approved contexts and devices.

Practitioner Guidance

What to verify: Confirm that revocation status is checked at the point of verification, not only at issuance, and that the check is operationally reliable under normal latency and outage conditions. Also verify that device binding is enforced in a way that the relying party can actually evaluate, not merely documented as a policy.

Decision rule: If the credential can authorize a high-impact action, treat revocation and device binding as part of the minimum acceptance criteria. If either check can fail open, the control is too weak for identity-sensitive flows and should be treated as a security exception.

What good looks like: The verifier can reject revoked credentials quickly, distinguish a genuine holder from a replayed presentation, and produce evidence showing when those checks were performed. That gives the bank or verifier a defensible basis for saying the credential was current and presented in the expected context.

Practitioner takeaway: The real failure is not “bad cryptography,” it is trusting a credential after you have stopped validating its current status and holder context. If those checks are absent, the system may still authenticate a token, but it can no longer reliably authenticate the trust decision.