How do you revoke access when devices are offline?

Credentials get revoked for ordinary reasons. RFC 5280 lists a change of name, a change of association, such as an employee leaving an organisation, and the compromise or suspected compromise of a private key. In each case the issuer decides the credential should stop working, but the decision lives with the issuer. Every verifier has to hear about it.

Even online, that takes time. RFC 5280 explains that a certificate revocation list (CRL) is a signed, time-stamped list of revoked certificates that a certificate authority issues periodically, and that the time granularity of revocation is limited to that issue period: a revocation reported now may not reach relying systems until the next scheduled list, which could be an hour, a day or a week later.

Offline devices add their own delay. Offline Protocol’s security documentation puts it plainly: an offline verifier cannot learn a new central revocation until it receives updated information, so an application has to define credential expiry and revocation behaviour for disconnected periods. Revocation for offline devices is about shrinking that window and deciding what to do inside it.

The simplest revocation is one you never have to send. If a credential is valid only for a short time, a revoked person loses access when it lapses and they cannot get a new one.

RFC 9608 describes this approach for certificates. It notes that short-lived certificates are seeing greater use and that, in many cases, their issuers publish no revocation information, because the certificate’s lifespan is shorter than the time needed to detect, report and distribute a revocation. The RFC defines the noRevAvail extension so a certificate can say so. Verifiable credentials can do the same with validUntil, and signed tokens with an exp claim.

The trade-off is renewal. A short lifetime means devices have to reach the issuer regularly. Pick the lifetime from how long your devices are actually out of contact, not from what is convenient for the server.

Where credentials must last longer, give devices the list of what has been revoked.

• Certificate revocation lists. Because a CRL is signed, RFC 5280 notes it can be distributed by the same means as certificates, over untrusted servers and untrusted communications. A CRL can travel from device to device and still be trusted.
• Status lists for verifiable credentials. The W3C Bitstring Status List publishes revocation or suspension as one bit per credential. The default list has 131,072 entries, equivalent to 16 KB, and the specification says that when only a handful of credentials are revoked, GZIP compresses it to a few hundred bytes, which is small enough to load before a shift or pass between devices. An optional ttl property says how long before a refresh should be attempted, and verifiers can cache lists they have fetched.
• Pre-produced status responses. The Online Certificate Status Protocol (OCSP, RFC 6960) answers status questions without CRLs. Responders may pre-produce signed responses, and each response carries the time its status was known to be correct (thisUpdate) and when newer information will be available (nextUpdate). A response fetched while online can still be checked later, with those times saying how fresh it is.

Each of these tells a device what was true when the list was made. None of them can report a revocation that happened after the device last received an update.

Some access can be withdrawn at the source as well. NIST SP 800-63B describes invalidation of an authenticator, sometimes called revocation, as removing its binding to the subscriber account, and requires it promptly when an authenticator is compromised or when the subscriber asks. Once an account binding is gone, the server will not renew that device’s credentials, so short expiry finishes the job.

Encrypted groups need their own step: the device has to be removed from each group it belongs to. What happens when a phone holding keys is lost covers how that works and what it does and does not protect.

The last piece is a written rule, applied on every device:

1. Set a maximum age for revocation data, using the list’s own times, such as nextUpdate or ttl.
2. Tier actions by risk. A device with old data might still open a work order but refuse to release stock or sign off a safety check.
3. Spread updates opportunistically. Any device that has fresh signed revocation data can pass it to the devices it meets.
4. Log decisions made on stale data, so they can be reviewed once devices reconnect.

There is no way to make an offline device know something it has not been told. The aim is a known, bounded window, chosen deliberately.