What is Certificate Revocation?

The average enterprise manages thousands of certificates in 2026. The expanding attack surfaces increase the risk of security breaches and expose organizations to an estimated financial loss of $3.07 million annually.

Having a robust certificate management system that includes timely certificate revocation is central to any enterprise security program.

Certificate revocation is the process of invalidating a digital certificate before it reaches its scheduled expiration date. It lets RADIUS know to immediately stop authenticating a certificate.

In this blog, we explore when to revoke certificates, how certificate revocation works, and the benefits of automating the process with SecureW2 Managed PKI to streamline certificate lifecycle management.

When Is Certificate Revocation Required?

Organizations perform revocation either when the device is compromised or if an employee leaves the organization. These events are infrequent, so most organizations revoke certificates rarely.

However, more frequent revocations will become necessary after the CA/Browser Forum (CA/B Forum) approved Ballot SC-081v3 in April 2025 to reduce certificate lifetimes .

In an effort to improve security, the plan is to reduce SSL and TLS certificate lifespans in phases, with the maximum validity period expected to reach 47 days by 2029.

Revocation is also done in the case of a device re-enrolling for a certificate. Once this is done, the old valid certificates are added to the Certificate Revocation List (CRL).

What Is a Certificate Revocation List?

A certificate revocation list, more commonly called a CRL, is exactly what it sounds like: a list of digital certificates that have been revoked.

A CRL is an important component of public key infrastructure (PKI) . The CRL contains revoked certificates from a trusted certificate authority (CA), another part of the PKI. Importantly, only the CA that issued the certificate has the power to revoke it and place it on the CRL.

Reason Codes for Certificate Revocation

The reason for certificate revocation is actually recorded in the CRL, so you can reference it when deciding whether to reissue a certificate or keep it revoked. Here are the RFC 5280 revocation codes (called Reason Codes), usually just referred to by their assigned number.

• unspecified (0): A catch-all code for any reason that isn’t specified. Usually, the default option.
• keyCompromise (1): The certificate itself was compromised, specifically the private key contained in the certificate.
• cACompromise (2): The certificate authority that issued this certificate was compromised, which means all of the certificates it has ever issued are now compromised.
• affiliationChanged (3): The user to whom the certificate was issued to has left the organization.
• superseded (4): The certificate was revoked because user information had to be changed, such as the legal name of the user being changed.
• cessationOfOperation (5): This means the certificate was replaced.
• certificateHold (6): A generic code that indicates a certificate has been revoked only temporarily.
• removeFromCRL (8): Somewhat counterintuitively, this indicates that the certificate authority has been removed from the network, and thus, the CRL.
• privilegeWithdrawn (9): Similar to affiliationChanged, this code indicates the user of the certificate, a person or device, has had their network privileges revoked. This usually occurs when the person leaves the organization, or a device is decommissioned, and their certificate is retired.
• aACompromise (10): The RADIUS server handling the certificate authentication was compromised, and so any certificate that passed through may have also been compromised.

How Certificate Revocation Checking Works

Certificate revocation is set in motion when a certificate authority communicates the “bad news” (fraudulent issuance, compromised private key, or changed security status) to the devices.

There are three ways the CA can communicate the bad news:

• Certificate Revocation List
• Online Certificate Status Protocol (OCSP)
• OCSP Stapling

Certificate Revocation List

When a certificate is issued, the issuing CA embeds a CRL Distribution Point (CDP) URL directly in the certificate itself.

When a client connects to a resource, it fetches the CRL file from that CDP URL and checks whether the certificate’s serial number appears in the list. If the serial number is present, the certificate is considered revoked, and the connection is denied.

Limitations of Certificate Revocation Lists

CRL-based revocation has three well-known limitations that drive organizations toward alternatives:

• Not real-time: CRLs are issued periodically, not continuously. There is always a window between when a CA revokes a certificate and when clients download the updated CRL, during which a revoked certificate may still pass validation.
• File size growth: Because a certificate must remain on the CRL until it reaches its natural expiration date, large organizations accumulate thousands of entries. A large CRL file takes longer to download and parse, which slows authentication.
• HTTP-only distribution: CRL files must be served over plain HTTP, not HTTPS. Clients fetch them over an unencrypted channel because the CRL itself is used to validate certificates; using HTTPS would create a circular dependency.

Delta CRL

A delta CRL is an optional auxiliary CRL that only contains the changes made since the last base CRL update. A Base CRL is the same standard CRL we’ve been talking about this whole time; it’s just called “Base” in relation to a delta CRL if one is present.

Large organizations, or ones that need to revoke certificates regularly, often have CRLs that grow to huge lengths.

Since a certificate has to stay on the CRL until it reaches its natural expiry date, it may stay on the list for several years.

At some point, the CRL contains so many entries that it takes the RADIUS a significant amount of time to download and check it, which impacts authentication speed.

The delta CRL speeds up authentication by letting the RADIUS cache the base CRL and request only recent changes.

The RADIUS stores or caches a copy of the Base CRL internally, then during authentication, it only needs to request the delta CRL.

The delta CRL contains any certificates revoked since the last Base CRL update and is much shorter. Every week or so, the RADIUS downloads a new version of the Base CRL, and the delta CRL is emptied and refreshed.

OCSP

OCSP stands for Online Certificate Status Protocol . It’s a protocol described in RFC 6960 used to request the revocation status of a digital certificate.

For OCSP-based revocation checking, the client:

• Reads the OCSP Responder URL embedded in the certificate’s Authority Information Access (AIA) extension
• Sends a request to that responder with the certificate’s serial number
• Receives a status response of “good,” “revoked,” or “unknown”

This approach checks revocation status in real time rather than relying on a periodically distributed list.

OCSP is simpler and faster than CRLs because the certificate check is performed by the (usually public) CA instead of your PKI, shifting the burden to them. It also carries fewer data and is easier for the CA to parse.

However, OCSP is less secure than a full PKI with CRL for several reasons.

OCSP has no requirement for encryption, which is inherent in the authentication process used by a PKI. Attackers can intercept and use the information sent in clear text against the organization.

OCSP is also less informative as the only information you can receive from an OCSP request is whether a certificate is “good,” “revoked,” or “unknown.”

But the worst flaw of OCSP is that it is vulnerable to replay attacks. A hacker can intercept a certificate’s “good” response and then replay it to another OCSP request later.

In addition, there are privacy risks as CAs can track browsing behavior. These risks prompted Let’s Encrypt to decommission its OCSP service in August 2025.

Since OCSPs conserve server resources by giving their responses a validity period measured in days, they can reduce the number of necessary responses but risk being compromised in that time period.

OCSP Stapling

OCSP Stapling is an extension to the standard OCSP protocol that shifts the responsibility for fetching the revocation status response from the client to the server.

Instead of the client contacting the CA’s OCSP Responder directly during a TLS handshake, the server queries the OCSP Responder in advance, caches the signed response, and then attaches (“staples”) that response to the TLS handshake it sends to the client.

This design eliminates the separate OCSP request the client would otherwise make, improving connection performance.

It also reduces privacy exposure: because the client never contacts the CA’s OCSP Responder directly, the CA cannot log which clients are connecting to which servers.

The stapled response is signed by the CA, so the client can verify its authenticity without making an additional network request.

CRL vs. OCSP vs. OCSP Stapling: Certificate Revocation Methods Compared

The following table compares the three methods of certificate revocation:

Feature	CRL	OCSP	OCSP Stapling
Method	Downloaded revocation list	Live CA query	Server-provided OCSP response
Speed	Slow	Fast	Fastest
Bandwidth usage	High	Low	Very Low
Privacy	Strong	Weak	Strong
Real-Time status	No	Yes	Yes
Offline support	Yes	No	Limited
Security	Strong	Moderate	Strong
Primary drawback	Large lists, latency	Privacy & replay risks	Server configuration dependency

How SecureW2 Simplifies Certificate Revocation Management

A well-configured certificate management system is the foundation of network security. The SecureW2 platform automates certificate revocation through an intuitive graphical user interface (GUI) and Identity Lookup Technology.

Graphical User Interface

SecureW2 provides an admin GUI that lets teams revoke certificates with a single action, without touching a command line or editing a configuration file.

Admins can search by name, MAC address, computer model, or any certificate attribute to locate the right certificate fast.

Role-based access controls within the GUI mean IT teams can grant revocation permissions without exposing full PKI administration rights, reducing the risk surface of certificate operations.

Identity Lookup Technology

During the authentication process, identity lookup validates that a user is active within the organization by checking the identifying information against the existing users in the Identity Provider.

This works as a last line of defense if a disgruntled employee were to perform any malicious activity before the CRL was updated to revoke their network access.

SecureW2 Identity Lookup Technology for Security Assertion Markup Language (SAML)-based Identity Providers eliminates the need for an on-premises Active Directory or Lightweight Directory Access Protocol (LDAP) server.

This gives cloud-first organizations the same last-line-of-defense protection during 802.1X certificate-based authentication .

SecureW2 JoinNow Cloud RADIUS integrates with the SecureW2 Managed PKI to handle certificate revocation checking at the point of network authentication.

When a certificate is presented to Cloud RADIUS for network access, it checks the CRL in real time before granting access, so a revoked certificate is blocked at the network edge, not just at the application layer.

SecureW2 Managed PKI enables admins to revoke certificates in one step without touching a command line.

Schedule a demo to see how SecureW2 handles the full certificate lifecycle.

---

Frequently Asked Questions

What is the difference between certificate revocation and certificate expiration?

Certificate expiration is the automatic end of a certificate’s validity period, determined at the time the certificate was issued.

Certificate revocation is an explicit action taken before that expiration date, invalidating a certificate because of a security event, personnel change, or policy requirement.

Expired certificates are rejected automatically and do not appear on the CRL; revoked certificates are listed on the CRL until they reach their natural expiration date.

Who maintains a Certificate Revocation List (CRL)?

A Certificate Revocation List is a file maintained by a certificate authority (CA) that contains the serial numbers of certificates the CA has revoked before their expiration date.

During authentication, the verifying party fetches the CRL from the CA’s distribution point and checks whether the presented certificate’s serial number appears in the list.

What is OCSP and how does it differ from a CRL?

OCSP (Online Certificate Status Protocol) is a protocol for checking the revocation status of a single certificate in real time by querying an OCSP Responder.

A CRL is a downloadable list of all revoked certificates; OCSP returns a per-certificate status response without requiring the client to download the full list.

OCSP is faster and more bandwidth-efficient but is less secure than CRL checking and is vulnerable to replay attacks.

When should a certificate be revoked?

A certificate should be revoked when:

• The private key is compromised
• The certificate authority that issued it is compromised
• The certificate holder leaves the organization
• The holder’s network privileges are withdrawn
• The certificate information (such as the user’s name) needs to change

Routine certificate expiration does not require revocation.

What is OCSP Stapling and why does it matter?

OCSP Stapling is an extension that moves the OCSP revocation check from the client to the server. The server queries the CA’s OCSP Responder, caches the signed response, and attaches it to the TLS handshake sent to the client.

This eliminates the extra round-trip the client would otherwise make, improves connection speed, and prevents the CA from tracking which clients are connecting to which servers.