The licence was revoked in March. The credential still verifies.

A credential is issued once and checked many times, and its status can change at any point in between. Almost every verification in the world checks the signature and not the status, which produces a specific and dangerous artifact: a credential that is cryptographically perfect and semantically dead.

The Wednesday shift that should not have happened

Picture a staffing coordinator at an agency that places nurses into hospitals. It is Wednesday morning and she is filling a night shift. She pulls up a candidate she has placed a dozen times, checks the file, and sees a licence record that was verified at onboarding, a background check from fourteen months ago, and a credential packet the hospital's credentialing team already accepted. Everything is green. She books the shift.

What she cannot see is that on Tuesday afternoon, a state board voted to suspend that licence. The vote is public. It is in a database, published on a website, available to anyone who thinks to look. Nobody looked, because nothing in her workflow was designed to look again. The verification happened once, at the boundary, and after that the file said verified, and files do not change their minds.

The nurse works the shift. Maybe nothing happens, which is the most common outcome and the reason this problem stays invisible. Maybe something does, and then a hospital, an insurer, a malpractice carrier and a regulator all discover simultaneously that the credential everyone relied on was valid in exactly one sense: it had been correctly issued, and correctly signed, by an authority that had already withdrawn it.

This is not a story about paper being unreliable. Digitising the credential does not fix it. A cryptographically signed digital credential in a wallet behaves identically: the signature verifies flawlessly forever, because a signature is a statement about the past. It says this was issued. It has never said this is current, and it cannot, because the issuer's opinion changed after the ink dried.

What is a credential zombie?

A credential zombie is a credential that is cryptographically valid and semantically dead. It verifies. It should not be honoured. Nothing about the artifact itself will ever tell you the difference.

The population is larger than most people assume, because it includes every credential where the issuer's opinion can change:

• A professional licence suspended, restricted or revoked by a board.
• An employment credential belonging to someone terminated last Friday.
• A contractor authorisation for a firm whose insurance lapsed.
• A safety or compliance certification that expired quietly.
• A diploma withdrawn after an academic integrity finding.
• A notary commission that was cancelled.
• A security clearance that was pulled.

In each case the holder retains a perfectly good artifact and a verifier checking that artifact reaches a confident, wrong conclusion. It is one of the fourteen patterns catalogued in the Identity Failure Map. Note that this has nothing to do with forgery. Forgery is the problem everyone worries about and the one cryptography genuinely solves. Zombies are the opposite failure: the credential is entirely genuine, and genuineness is not the property anyone actually cared about.

The milk carton

A useful way to hold this. A signature on a credential is like a label on a carton saying this milk was produced by a licensed dairy on the third of the month. It is true, it is verifiable, and you can check it years later and it will still be true.

It is not the thing you want to know. What you want to know is whether the milk is still good, and that question has an answer that changes over time, is not knowable from the label alone, and requires either a date you can compare against now or a fresh check. Every credential system in the world prints the dairy licence beautifully. Very few print a usable date, and almost none check it.

Why does this become expensive?

Because credential fraud already has an established cost base and revocation lag multiplies it.

The clearest anchor is the federal enforcement action known as Operation Nightingale, announced by the Department of Justice in early 2023, which targeted a scheme selling fraudulent nursing diplomas and transcripts issued through Florida-based nursing schools. Public reporting on the case described roughly 7,600 fraudulent credentials sold over a period of several years, and a substantial fraction of buyers went on to sit for national licensing examinations. Treat those counts as reported figures rather than settled numbers, since they varied across coverage and across the multiple prosecutions involved. The structural lesson survives whichever count you use: credentials entered the workforce, were verified by employers, and continued to verify for as long as nobody re-asked the question.

The same pressure shows up in hiring, where cheap generative tooling has made document forgery a commodity, a shift we covered in resume fraud in the AI era. Around that sit two softer but consistent signals. Industry estimates put diploma mill and academic credential fraud in the billions of dollars annually, with one widely quoted estimate placing the surrounding academic fraud market at roughly twenty one billion dollars. Employer surveys similarly report that a large majority of businesses encountered at least one candidate misrepresentation or scam in the preceding year. Both are vendor and survey figures with the usual methodology caveats, and both point the same direction.

The per-incident arithmetic is what makes this a budget line rather than a curiosity. One unlicensed clinician working shifts produces patient harm, malpractice exposure, payer clawbacks for services billed under an invalid credential, and a regulatory finding against the facility that placed them. In finance, a barred representative holding a credential that still checks out is a restitution problem. In construction or aviation maintenance, an expired certification is a safety finding. In none of these does the organisation get to say the credential looked fine, because the whole point of the credentialing function was to know.

Why do licensing boards run lookup portals at all?

Here is the detail that gives the game away, and it is sitting in plain sight.

Nearly every serious credentialing authority operates a public verification service. Nurse licensure has Nursys. Academic records have the National Student Clearinghouse. Securities registration has BrokerCheck. State boards run their own portals for medicine, law, engineering and dozens of trades.

Background check vendors resell exactly these lookups, which is the business model examined in the comparison with traditional screening. Ask why those registries exist. They exist because the credential in the holder's possession is not trusted. If a diploma or a licence certificate were sufficient, nobody would need a registry. The registry is the authority's admission, built into the infrastructure and paid for annually, that the artifact it issued cannot be relied on by itself and that the only source of truth is the authority's live database.

So the industry already knows the answer to the question this article is asking. It solved the problem by making everyone call. That works, and the cost of it is the subject of the next section.

How can you attach status to a credential?

There are exactly three mechanisms. Every real system is one of them or a blend, and each buys something by paying for it somewhere else.

Model one: ask the issuer at verification time

The verifier queries the authority when the check happens. Maximum freshness: you learn the status as of this second.

The costs are structural rather than incidental. Availability becomes coupled: if the board's portal is down, verification fails or gets skipped, and in practice it gets skipped. It does not scale to high-volume or offline checks. It creates a gatekeeper, because the authority can decline to answer, rate limit, or charge. And it leaks: the issuer learns every place the holder presents the credential, which is a surveillance property with real consequences. A licensing board that can see every employer a nurse applied to knows something it has no business knowing.

Model two: short validity and reissuance

The credential carries a short expiry and the holder refreshes it. A verifier checks the signature and the clock, with no callback at all.

No availability coupling at verification time, no privacy leak to the issuer about verification events, and it works offline. The cost is a staleness window equal to the validity period, plus the operational burden of reissuance on both sides. If a credential is valid for seven days, a revocation on day one is invisible until day seven.

Model three: status lists

The issuer publishes an aggregate list of revoked entries. The verifier fetches the whole list periodically and checks locally.

This is the design behind the W3C Bitstring Status List, which encodes status as a compressed bitstring where each credential holds an index. Fetching the list reveals nothing about which credential you are checking, so the holder's privacy is preserved by the herd. The costs are freshness bounded by the publication interval, distribution mechanics, and the requirement that verifiers actually fetch the list. That last one is not a technicality, as we are about to see.

What the web already learned about revocation

This is the part worth reading slowly, because it is not an analogy. It is the same problem, fought to a conclusion in a different domain, by people who were extremely motivated and had two decades to work on it.

Web PKI has exactly this structure. A certificate authority signs a certificate. The signature proves issuance. The certificate can be revoked afterwards, for key compromise or misissuance. Browsers need to know.

First attempt: certificate revocation lists. The authority publishes a list of revoked serial numbers and clients download it. This is model three. It worked until the lists became enormous, and downloading megabytes of revocations before establishing a connection was untenable.

Second attempt: OCSP. The Online Certificate Status Protocol, specified in RFC 6960, lets a client ask about one certificate. This is model one, and it inherited model one's problems precisely. It added latency to every connection. It coupled availability, so a responder outage broke browsing. And it leaked: the responder learned which sites a user visited, which is a privacy disaster.

What actually happened next is the important part. Because outages were unacceptable, browsers implemented soft-fail. If the status check failed, proceed anyway. Read that again in security terms: a revocation mechanism that an attacker can neutralise by blocking a network request is not a revocation mechanism. An attacker holding a stolen key wants the check to fail, and making it fail is trivial. The industry shipped a control that was reliably absent exactly when it was needed.

Third attempt: stapling. Have the server fetch its own signed status and attach it to the handshake. This is clever, it removes the privacy leak and the latency, and it is essentially a short-lived status assertion carried by the party presenting the credential. Hold that thought, because it is the shape of the answer.

Fourth attempt: aggressive compression. Mozilla's CRLite line of work showed you could push the entire revocation set to clients in a form small enough to be practical, which is model three done properly.

Where it landed: shorter lifetimes. The direction of travel across the industry has been to shrink certificate validity, with the CA/Browser Forum voting to step maximum lifetimes down substantially over the coming years, and Let's Encrypt introducing certificates measured in days. The reasoning is blunt and correct: if a certificate only lives for a few days, revocation matters far less, because expiry does the job automatically and cannot be soft-failed by an attacker.

That is the intellectual payoff of this whole topic, and it transfers directly:

The practical answer to revocation is usually expiry.

Not because status lists are bad, they are good and should exist, but because a mechanism that requires a verifier to do extra work at the right moment will fail at scale, whereas a mechanism where doing nothing produces the safe outcome will not. Expiry is fail-closed by construction. That is the property you are actually buying.

Why do verifiers skip the status check?

Because skipping is invisible and checking is expensive, and every incentive points one way.

A verifier who checks status and finds a problem creates work: a shift to refill, a candidate to reject, a conversation with a client. A verifier who skips the check gets a clean result, immediately, with no friction. The failure is silent and deferred, and it usually lands on someone else. This is the same gradient that produced OCSP soft-fail, and expecting a different outcome in credentialing because the stakes are higher is not supported by the evidence from an industry where the stakes were also high.

Digital wallets make this sharper rather than softer, and that is the uncomfortable part of the current moment. As credential ecosystems move from paper to signed objects, driven by the European digital identity wallet rollout and mobile driving licence deployments under ISO 18013-5, verification gets faster, cheaper and far more confident. The signature check is trivial to implement and produces a satisfying green tick. The status check is optional, requires infrastructure, and produces occasional red. You can predict which one gets shipped in version one.

The result is a larger population of credentials that verify beautifully and mean less than the verifier thinks. Better cryptography, applied to the wrong question, at greater scale.

What should a high-consequence credential look like?

Combine the lessons. For anything where being wrong is expensive, the credential should be accompanied by a short-lived, offline-verifiable status assertion, and the verifier should treat staleness as a failure rather than as an absence of information.

Concretely, a status receipt is a small signed object saying: as of this moment, this issuer considers this credential to be in this state, and this assertion is good until then.

{
  "credentialId": "nur-fl-1180432",
  "issuer": "did:web:board.example.gov",
  "subjectKey": "ed25519:9c4b...e17a",
  "status": "active",
  "statusAsOf": "2026-09-10T06:00:00Z",
  "notAfter":   "2026-09-13T06:00:00Z",
  "statusListRef": "https://board.example.gov/status/2026#4193",
  "signature": "ed25519:..."
}

Three properties matter here and each earns its place.

It is short lived, so a revocation propagates within the window without anybody remembering to look. It is held by the holder, so verification requires no callback, which removes the availability coupling and the issuer's view of where the credential is being used. And it is bound to the subject's key, so a credential lifted from someone else does not verify without that person's device, which is where credential status meets the continuity question we cover in identity continuity across an employment relationship.

The verifier's job then becomes short, and the shape of the code is the entire argument:

def verify(credential, status_receipt, now):
    if not sig_ok(credential, issuer_key(credential.issuer)):
        return REJECT("credential signature invalid")

    # The part almost everyone skips.
    if status_receipt is None:
        return REJECT("no status assertion presented")   # fail CLOSED

    if not sig_ok(status_receipt, issuer_key(credential.issuer)):
        return REJECT("status signature invalid")

    if status_receipt.credentialId != credential.id:
        return REJECT("status does not match credential")

    if now > status_receipt.notAfter:
        return REJECT("status stale, refresh required")   # fail CLOSED

    if status_receipt.status != "active":
        return REJECT("credential %s" % status_receipt.status)

    return ACCEPT(as_of=status_receipt.statusAsOf)

The two fail CLOSED lines are the whole design. Everything else is bookkeeping. A missing or stale status is not a neutral condition to be shrugged past; it is a rejection. If that sounds operationally aggressive, note that it is exactly the property the web PKI wished it had for twenty years and could not retrofit, because by the time everyone agreed it was necessary, soft-fail was load-bearing.

Comparing the models honestly

None of these is universally correct. The engineering question is where you set the freshness dial for a given decision's value, and the honest observation is that most systems today have the dial at infinity and have never framed it as a dial at all.

What this does not fix

Five limits, and they matter more than usual here because this topic invites overreach.

Manav is not a credential issuer. We do not license nurses, confer degrees, or replace state boards. Only the authority can say what a credential's status is. What a receipt layer can do is carry that authority's statement in a form a verifier can check without calling anyone. If the board does not publish status, no amount of cryptography invents it.

Issuer data quality is upstream of everything. If a board takes three weeks to record a suspension, a status receipt faithfully reports stale truth for three weeks. This design shortens the gap between the issuer's knowledge and the verifier's knowledge. It does nothing about the gap between the world and the issuer's knowledge.

This composes with W3C Verifiable Credentials rather than competing. The Bitstring Status List is the right primitive for issuers publishing at scale, and any serious deployment should interoperate with it. A holder-carried short-lived receipt is a complement for the offline and high-consequence cases, not a replacement. Manav does not ship a status list client or SD-JWT status claims today, and selective disclosure remains roadmap.

Short windows trade against offline use. A three day receipt is useless to a verifier working somewhere with no connectivity for a week. Real deployments will need graduated windows by consequence, and somebody has to own that policy.

It does not detect a credential that should never have been issued. Operation Nightingale credentials were fraudulent at origin. Status checking tells you what the issuer thinks now, and if the issuer was deceived, it will faithfully report active. Issuance integrity and status currency are two separate problems and only the second is addressed here.

What to do this week

1. List the credentials you rely on and write down, for each, when it was last verified and what would happen if it had been revoked the following day. Most teams have never written this down and the exercise is uncomfortable in a productive way.
2. Find your fail-open paths. Anywhere a status lookup times out, errors, or is skipped for performance, determine what your system currently does. If the answer is proceed, you have found your OCSP soft-fail.
3. Set re-verification intervals by consequence, not by calendar. An annual re-check for a credential that gates patient contact is a policy decision to accept up to a year of exposure. State it that way in writing and see whether it survives.
4. Ask your background check vendor what they monitor continuously versus what they re-run only at hire. The answer is frequently narrower than the contract implies.
5. If you are building a wallet or verifier, implement status before you launch. Retrofitting fail-closed behaviour after verifiers depend on fail-open is the single hardest lesson from web PKI, and it is available to you for free right now.
6. If you are an issuer, publish status in a fetchable form. A signed status list is not a large project and it converts your registry from a portal people forget to call into infrastructure that works by default.
7. Bind the credential to the holder's key so a stolen or shared credential fails without the person. The verification demo shows the enrolled-human binding and the docs cover the receipt format.

Frequently asked questions

How do you know a digital credential is still valid and not revoked? The credential's signature only proves it was issued. To know it is current you need a separate, fresh status assertion from the issuer: either a live query, a published status list you fetch, or a short-lived signed status receipt the holder presents alongside the credential. If your verifier checks only the signature, it cannot distinguish an active credential from one revoked months ago.

What is a credential zombie? A credential zombie is a credential that is cryptographically valid but semantically dead: correctly issued and correctly signed by an authority that has since suspended, revoked or withdrawn it. It verifies perfectly and should not be honoured. Because nothing in the artifact reflects the change, a verifier checking only the signature reaches a confident and wrong conclusion.

What is a Bitstring Status List? It is a W3C mechanism for verifiable credential revocation in which the issuer publishes a compressed bitstring where each credential occupies an index. A verifier fetches the whole list and checks the relevant bit locally. Because the verifier retrieves the entire list rather than asking about one subject, the holder gets herd privacy and the issuer does not learn where the credential is being presented.

Why do verifiers skip revocation checks? Because skipping is invisible and cheap while checking creates friction and occasional bad news. The same incentive gradient produced soft-fail in web PKI, where browsers proceeded when status checks failed, which meant an attacker could neutralise revocation by blocking a request. Any design that depends on verifiers doing optional extra work at the right moment will degrade the same way.

How often should employers re-verify professional licences? Set the interval by consequence rather than convention. An annual re-check is a decision to accept up to a year of exposure between a board action and your knowledge of it. For credentials gating patient contact, controlled substances, client funds or safety-critical work, continuous status or short-lived assertions are proportionate. Write the accepted exposure window down explicitly.

Does a blockchain fix credential revocation? Not usefully. The hard parts are the issuer publishing status promptly, the verifier actually checking it, and doing both without leaking the holder's activity. A signed status list on ordinary web infrastructure addresses all three. Putting revocation entries on a ledger adds cost and permanence without changing whether verifiers fetch them or whether issuers publish in time.

Sources

1. Bitstring Status List v1.0, W3C. The status mechanism for verifiable credentials.
2. Verifiable Credentials Data Model 2.0, W3C.
3. RFC 6960, Online Certificate Status Protocol, IETF. The canonical query-the-issuer design.
4. RFC 5280, Certificate and CRL Profile, IETF. Certificate revocation lists.
5. CA/Browser Forum Baseline Requirements. Certificate lifetime reductions.
6. Let's Encrypt engineering blog. Short-lived certificate issuance.
7. Mozilla Security Blog. CRLite and revocation compression research.
8. US Department of Justice newsroom. Operation Nightingale prosecutions concerning fraudulent nursing credentials.
9. Nursys, NCSBN. Primary source nurse licensure verification.
10. National Student Clearinghouse. Academic credential verification.

A signature tells you a credential was issued. Only a clock tells you it is still true.