A Status List is a cryptographically signed or referenced list used to show whether a credential remains valid, suspended, or revoked. Verifiers check it before accepting a presentation, because a compromised, expired, or cancelled credential can otherwise be used after issuance.
How Status Lists Work
A status list is a signed or referenced data structure that lets verifiers check whether a credential is still valid before they accept it. It shifts the trust decision from the holder's copy of the credential to an issuer-controlled status signal that can mark a credential as valid, suspended, or revoked.
That design matters because a credential can be genuine at issuance and still become unsafe later if it is lost, cancelled, or otherwise compromised. Status checking gives the verifier a way to make a fresh acceptance decision at presentation time rather than assuming issuance alone proves current validity.
Why Status Lists Exist
Status lists solve a common lifecycle problem in digital credentials, which is that issuance and continued validity are not the same thing. Without a revocation or suspension signal, a verifier may have no reliable way to tell whether a credential should still be trusted after a change in the underlying account, entitlement, or eligibility.
They are especially useful in distributed credential systems where the verifier may not contact the issuer for every presentation. A compact status reference can preserve privacy and scale better than ad hoc issuer lookups, while still giving the verifier a way to detect that a credential should no longer be accepted.
In practice, this is part of the broader verifiable credentials model described in Verifiable Credentials Guide, where status checking sits alongside issuance, presentation, selective disclosure, and trust registry patterns.
How Verifiers Use Status Information
At verification time, the verifier checks the credential against the current status source before making an acceptance decision. The exact mechanism varies by ecosystem, but the operational question is the same: does this credential still belong in the set of credentials this system will trust?
That check should be treated as part of the verification workflow, not as an optional enrichment. If the verifier skips status validation, an expired, suspended, or revoked credential can still be used to gain access, prove eligibility, or assert authority after it should have been withdrawn.
Organisations also need to consider how status data is published, cached, or refreshed, because stale status information weakens the control. A status list is only as trustworthy as the freshness and integrity of the verifier's lookup path.
Security and Trust Implications
Status lists are a trust-preservation control, not a mere administrative convenience. They reduce the chance that a previously issued credential remains usable after compromise, but they also introduce dependencies on issuer integrity, update discipline, and verifier implementation quality.
Because the list itself becomes part of the trust decision, it must be protected against tampering, replay of stale data, and implementation mistakes that let verifiers accept an outdated state. The control is strongest when issuers update status promptly and verifiers refuse to treat missing or stale status as equivalent to active validity.
In environments that use signed or externally referenced status data, readers should understand that the surrounding trust model also depends on the broader verification infrastructure, including how the source is discovered and authenticated. The IETF's IETF Datatracker is useful for tracking the RFC and draft lineage that shapes these patterns.
Risk and Threat Considerations
Status lists matter because a revoked or suspended credential is still dangerous if verifiers fail to consult current status before accepting it. The main exposure is post-compromise reuse, where an attacker or former holder continues presenting a credential that should no longer be trusted.
Failure mechanism: The verifier accepts stale or unvalidated status information, or never checks the status source at all, so the credential's original issuance remains the only thing that matters.
Impact: Unauthorized access, fraudulent presentation, and delayed detection of credential compromise can follow, especially when the credential is tied to sensitive access, regulated assertions, or high-value transactions.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Status lists govern whether a credential remains usable over its lifecycle. |
| IA-2 — Identification and Authentication (Organizational Users) | Verifiers rely on current status before accepting a presented credential. | |
| Recommendation — Track credential lifecycle state and revoke or expire authenticators when status changes. Require current authentication status checks before accepting organizational user credentials. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The term sits in the identity-verification lifecycle covered by digital identity assurance. |
| Recommendation — Apply digital identity assurance rules so verifiers consult current credential status before acceptance. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Revocation and suspension are the core failure modes status lists are meant to expose. |
| Recommendation — Revoke or suspend non-human credentials promptly when their use should end. | ||
Practitioner Guidance
Why practitioners should care: Status lists only work when verification logic consistently consults them at the point of acceptance. If presentation handling, caching, or offline verification bypasses status checks, the rest of the credential system can look correct while still admitting revoked credentials.
What to watch for: Treat stale status sources, unverifiable references, and unexpected acceptance of long-lived credentials as signals that the control path is incomplete. Verification failures should be visible enough that teams can distinguish a legitimate status outage from an unsafe fallback to trust.
Related resources from NHI Mgmt Group
- What is the difference between a Certificate Revocation List and Online Certificate Status Protocol?
- What breaks when CI/CD pipelines can list tables with long-lived credentials?
- Who should be able to manage vehicle access when ownership or service status changes?
- Who should own unsubscribe and suppression list governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org