In our previous posts about Verisign Informed™, we’ve talked about the importance of high-assurance infrastructure and how it is a critical underpinning for delivering at-time-of-use status information. We recounted some historical perspective on digital certificates that motivates the essential need to use evidence to build trust in internet security deployments, including revocation status which can change after the certificate is issued, and even after it expires. We then introduced an important idea—stale trust—and explained that failing to check for updated status, or relying on old data, results in stale (or absent) evidence, which is the essence of the stale trust problem. We will now discuss how, despite the importance of status to inform trust, browser makers have largely deprecated the Online Certificate Status Protocol (OCSP), one of the only tools available to determine certificate status on a per-certificate basis. While the reasoning behind that decision may be sound, we believe that the solution for certificate status in general lies in improving and modernizing the performance of OCSP, rather than abandoning it.

To illustrate the significance of the stale trust problem, we first need to explore the nature of stale trust in more detail, and how trends have caused the stale trust issue to become a more significant cybersecurity challenge in recent years. Specifically, we will examine how changing perceptions of OCSP contributed to the stale trust problem, leading to changes that impacted the use of certificates to identify and secure communications with web servers and, more importantly, broad assumptions that adversely influenced other use cases. We’ll further consider how these other certificate-powered use cases, including emerging ones, can benefit from OCSP-based status information to support their unique security and operational requirements.

The decision to deprecate OCSP appears to have been driven by a number of legitimate objectives, such as removing uncertainty in browser-to-website connection timing and removing external operational dependencies on the many Certification Authorities (CA) and their individual OCSP services. Shortened overall certificate lifespans have been implemented in an attempt to span the gap left by abandoning OCSP, but this is no substitute for a breach alerting mechanism, particularly in the face of AI-driven compromise and exploitation.

What’s even more important is to understand the difference between the web and other use cases, how compromises could happen, and how security status from a well-operated OCSP infrastructure remains the best defense against the vulnerabilities associated with stale trust.

OCSP saw tremendous growth following its launch in 1999 and through the next 10 years, powered largely by the rising tide of business-to-consumer e-commerce and the burgeoning need for security. During that same time, work was ongoing to understand and improve the use of OCSP, both to improve end-user privacy and to manage the rapidly increasing request volume and the resulting infrastructure costs to operators.

Operators of websites depend on visits and maximizing user activity, many of which take place over very short periods of time (i.e., milliseconds). With such short transactions, protections only last for seconds or milliseconds, so introducing anything up front, like online status checking, which could slow down a visitor, became a tradeoff with the risk that users would become victims of a Man in the Middle (MitM) attack leveraging compromised certificates. OCSP checking and validation at the initiation of a very short website session appear to have become more burdensome, both financially and technically, than beneficial. And, while investment could have delivered speed and reliability, for instance through “stapling,” eliminating OCSP checking delivered an immediate speed benefit, but at the cost of security.

While browsers focused on connection speed, the volume of connections grew dramatically. From 1999 to 2008, OCSP request volumes grew 184 percent year-over-year (see more detail below), and there was no direct cost recovery mechanism to fund scaling of OCSP infrastructure. Certificates were sold based on a fixed annual fee, and OCSP was a bundled cost of doing business with hard-to-estimate usage. But the costs to build and scale a high-performance infrastructure at those growth rates, multiplied by the number of certificate providers, seemed to be insurmountable. Slowly but surely, response times from OCSP responders increased, or failed to deliver a response at all. CAs looked to leverage outside providers to deliver cached responses to reduce costs, but introduced new external spending as a consequence.

All of this led to the period between 2008-2012, when discussion focused on minimizing cost and operational interdependency on status checking in the browser connection process. Without recognition of the foundational importance of status and trust, proposed security status improvements and workarounds were either disregarded or only implemented to minimum standards. Browsers started exhibiting ‘soft fail’ behaviors, where a missing OCSP response was ignored and the connection was allowed to proceed anyway. Thus, not only was stale trust discarded as a technical or security problem to be solved, but the incentive structure also actively worked against solving it.

By volume, this is not a surprising outcome. Consider these figures:

They show us that Web PKI (“website/server certificates”) was the major driver of all certificate validity status checks during OCSP’s first growth period. The next two largest use cases—centering around Microsoft’s Authenticode, and the EAP-TLS authentication mechanism—both grew even faster than Web PKI, but the combined volume was only a quarter of the total.

Then, in 2012, Chrome disabled OCSP by default and instead adopted CRLSets, a partial solution to status checking. Web trust had moved from current, to stale, to absent altogether (in some cases), under the tradeoff given that the absence didn’t matter because the unexamined risk was not perceived to be big enough to make a difference or would be absorbed elsewhere in the system. Moreover, while blocking compromised certificates via CRLSets would protect some browser users, effective interventions for other users and applications would involve additional steps beyond the simplicity of an OCSP response—a point illustrated in a recent incident.

Fast forward to 2023, when the CA/Browser Forum voted to make OCSP optional for Web PKI TLS certificates. By then, all participants who focused specifically on the website use case (not just browser vendors, but CAs, OS vendors, and site operators) had apparently concluded that OCSP was unnecessary. It appeared to be that, without universal Service Level Agreements (SLAs) directly responsive to the needs of the web use case, operational reliance introduced too much interdependency and failed connection risk. OCSP was effectively sidelined for mainstream consumer browser use cases, and it appeared to some as if the industry might stop using certificate revocation status altogether. For those in the web ecosystem, the generalization that “OCSP was done” became the common punchline. Were other OCSP use cases, where trust data was still an integral part of the solution, overlooked in this debate? Stale trust was the inevitable result—since no alternative high-assurance approach was available.

Since 2008, private enterprise use of certificates and OCSP validation for internal applications—including network access, Authenticode, email, VPN authentication, device authentication, and now agentic AI communication—has grown tremendously and may well eclipse publicly visible use as measured by total OCSP status request volume. Agentic AI tools in particular are driving an enormous increase in the creation and management of machine identities, almost all of which are tied to digital certificates which need ongoing status checks to evaluate permissions and contain unanticipated actions.

And while the assessments which led to OCSP’s deprecation for Web PKI use cases were performed with one set of needs and constraints in mind, other use cases, subjected to a similar assessment, have already proven to arrive at a very different conclusion. To this exact point, our previous blog and technical report illustrate the need for trust and the foundational role of security status via OCSP.

At its core, stale trust is not just a security risk, but also a business risk. Failure to validate trust can lead to exfiltration of customer data, compromise of systems, and hijacking of confidential company information.

Nowhere is this more important than in new certificate-powered use cases, working at machine speed and via automation and AI. This new environment forces a revisitation of those assumptions about how big the risk of ignoring trust really is. Industry reports frequently cite agentic AI ‘red team’ tools (designed to find and exploit security vulnerabilities) as being able to successfully compromise systems in under a minute.

The need for trust validation in such circumstances is clear and consistent with overarching Zero Trust principles already being pursued by enterprises across industries and geographies. Making decisions without sufficiently fresh trust data is increasingly dangerous, since old assumptions that vulnerabilities are unlikely to be discovered and exploited no longer hold true.

Stale trust is not new. The decaying confidence that arose from long-validity-period OCSP responses was noted in the early days, and attention faded as the dominant use case—Web PKI certificates—moved away from the protocol. Less visibly, strong adoption of OCSP continued in code signing, authentication, and more recently, digital provenance, and machine and agentic identity applications—anywhere that revalidation of an object or identity is critical for security. In that sense, perhaps OCSP was ahead of its time, where the utility of up-to-date, per-certificate status information was waiting for higher-value use cases to present themselves.

Rather than abandoning OCSP, Verisign Informed builds on its strong foundation, leveraging new approaches to accelerate its performance, maximize its benefit, and re-insert this critical tool in the trust chain. With Verisign Informed, we seek to preserve the interoperability and worldwide standardization that made OCSP so effective, while adding a new layer of performance, and backing it with a high-assurance infrastructure that can meet the volume and demand of modern use cases.