What are the key Status List best practices?

Why Status List Checks Belong at Verification Time

Status lists are a verification-time control, not a one-time issuance control. The verifier has to confirm that the credential is still valid when it is presented, because revocation and suspension are only useful if they are checked before acceptance. That makes the status source part of the trust path, so its integrity and freshness matter as much as the credential format itself.

The design choice also affects user experience and security posture. If a verifier cannot reach current status data, the system needs an explicit policy for fail-closed, retry, or exception handling. Treating status uncertainty as normal access is a control failure, not a convenience feature.

Good implementations also separate “credential is cryptographically valid” from “credential is currently acceptable.” A signature can still verify even when the credential should no longer be honored, which is why status checks must be wired into the acceptance decision rather than added later in monitoring.

Protecting the Status Source and Keeping Lookups Fresh

The status source should be treated as sensitive infrastructure because tampering, stale caching, or inconsistent replication can turn a revoked credential back into an accepted one. That is why source authenticity, cache expiry, and refresh cadence are core operational controls rather than implementation details.

Refresh intervals should be chosen to match the risk of delayed revocation, the expected credential lifetime, and the reliability of the status service. A long-lived cache lowers lookup cost, but it also widens the window in which a revoked credential can remain usable if the cache is not refreshed promptly or is allowed to drift out of sync.

When the lookup path fails, the safest default is to follow policy deliberately and consistently. Silent fallback to acceptance is especially dangerous because it hides the failure from both operators and downstream audit evidence. Where verification depends on a status list, failure to retrieve status is itself a security-relevant event.

Operational Signals That Status Handling Is Slipping

Weak status handling usually shows up as stale caches, inconsistent entries, or repeated lookup errors before it becomes a visible security incident. Those are not just reliability defects, they are signs that the verifier may be making decisions on outdated trust state.

It is also worth watching for status latency that grows over time, because that often indicates overload, bad cache invalidation, or an unhealthy dependency in the status path. If the status check is slow or noisy, teams may be tempted to bypass it or extend cache lifetimes, which quietly weakens the control.

For deployments using privacy-preserving status mechanisms, the operational discipline is the same: verify freshness, confirm consistency, and validate that the verifier actually consults the status source during acceptance. The mechanism can differ, but the control objective does not.

Practitioner Guidance

What to verify: Confirm that every relying party checks status at presentation time, not just during enrollment or periodic cleanup. Also verify that cache expiry, refresh intervals, and fallback behavior are documented and tested under outage conditions.

• Review whether status failures are denied, retried, or escalated according to policy.
• Check that the status source is authenticated and protected from unauthorized modification.
• Test revoked, suspended, and recently changed credentials to prove the verifier uses current state.
• Alert on inconsistent status responses, stale cache indicators, and lookup-path failures.

Common mistake: Teams often assume a valid signature means the credential should be accepted, then discover too late that revocation was never enforced at the point of use. Another common error is relying on overly long cache windows because they reduce load, even though they extend exposure after revocation.

Practitioner takeaway: The real control is not the status list itself, but the verifier’s discipline in consulting fresh, trustworthy status data before it grants access.

Related resources from NHI Mgmt Group

• Guide: Verifiable Credentials Guide
• How should security teams make NHI best practices usable across the business?
• What is the difference between role-based access and API key governance for NHI security?
• When does a short-lived API key still create material risk?
• What are the best practices for collecting employee vaccination status in the workplace?