A verified credential does not stay trusted if its status changes. Trust depends on current validity, issuer status, revocation, expiry, and any updates to the holder’s attributes or assurance level, so relying parties must check status at presentation or through an online status service before accepting it.
What changes when a credential’s status changes?
A verified credential is only trusted while its current state remains valid. If the issuer revokes it, it expires, or the holder’s assurance context changes, a relying party should treat the credential as no longer equivalent to the one that was originally verified. That is why status checking is part of the trust decision, not an afterthought.
Even a credential that was valid at issuance can become unsafe to rely on later. The practical question is whether the verifier is checking the latest issuer state at the moment of presentation, rather than assuming yesterday’s verification still holds today.
Why status, revocation, and expiry are part of trust
Trust in a verified credential is conditional, not permanent. The credential represents an assertion about an identity or attribute at a point in time, and that assertion can be withdrawn or weakened when the issuer updates records, the holder loses eligibility, or the credential reaches its expiry window.
This is especially important for credentials that are presented repeatedly across systems. A verifier that skips fresh status validation can accept an assertion that has already been revoked or superseded, which creates an integrity gap in downstream access or assurance decisions.
The current state of the credential matters more than the fact that it once passed verification. A credential that is still structurally intact can still be stale, invalid, or misleading if the issuer has changed the underlying record.
How verifiers should check status before accepting a credential
The safest pattern is to validate status at presentation time, or through an online status service that reflects issuer updates in near real time. That is the point where the relying party can confirm whether the credential is still active, still issued by the expected authority, and still aligned with the attributes or assurance level being requested.
For implementation, the control question is simple: does the verifier have a live path to current status, and does it fail closed when that path says the credential is no longer valid? If not, the system is relying on stale trust.
- Check revocation or status information at the time of use, not only at issuance.
- Reject credentials whose status cannot be confirmed when status checking is required.
- Re-evaluate any access or approval that depended on the now-changed credential state.
Risk and Threat Considerations
The main risk is stale trust, where a verifier continues accepting a credential after the issuer has changed its status. That creates an exposure window in which revoked, expired, or otherwise downgraded credentials can still be used for access or proof of eligibility.
Failure mechanism: A relying party caches or assumes old credential state, then skips a live status check at presentation time, so a no-longer-valid assertion is treated as current.
Impact: Unauthorized access, incorrect trust decisions, and delayed detection of credential misuse can follow, especially when the credential is used to unlock downstream systems or approvals.
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-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Status, revocation, and assurance are core to credential trust decisions. |
| Recommendation — Check current credential status before accepting any identity assertion. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential validity depends on lifecycle controls for issuance, rotation, revocation, and expiry. |
| Recommendation — Enforce credential lifecycle controls so stale authenticators are revoked or expired. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Changed status can make previously valid credentials unsafe to trust. |
| NHI-07 — Long-Lived Secrets | Time-bounded credentials reduce the chance of stale trust after status changes. | |
| NHI-04 — Insecure Authentication | Relying on stale verification weakens authentication and acceptance decisions. | |
| Recommendation — Revoke access paths promptly when the credential holder no longer qualifies. Prefer short-lived credentials and validate them against current issuer status. Require fresh verification or online status checks before trusting a credential. | ||
Practitioner Guidance
What to verify: Confirm that the verifier checks issuer status, revocation, and expiry at the moment of acceptance, and that it does not fall back to an old success decision when the live check fails.
Decision rule: If the credential’s status cannot be confirmed, treat it as untrusted until the issuer or status service can be reached and the result is positive. If your business process cannot tolerate that dependency, redesign the trust path rather than weakening the check.
What good looks like: The system accepts only credentials with current, confirmed status, and any post-issuance change in the issuer record automatically changes the trust outcome on the next presentation.
Practitioner takeaway: A verified credential is a time-bounded trust signal, so the real control is not the original verification step, but the ability to re-check status before every decision that depends on it.
Related resources from NHI Mgmt Group
- Who should own accountability when a PEP status changes after onboarding?
- Who is accountable when a compromised supplier credential is still trusted after offboarding?
- When should organisations require an additional authentication step after an EUDI credential has been verified?
- How should organisations respond when a certificate is still trusted after the workload changes?
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 November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org