Series · Public Sector TLS Trends · Part 1

Public Sector TLS Trends, Issue 0: Methodology and Inaugural Snapshot

Bill Church

Bill Church

May 11, 2026

pqc_by_sector.png

The public Web PKI is in the middle of the largest set of changes since the CA/Browser Forum existed. Online revocation checking is being dismantled. Validity windows are dropping toward forty-seven days. The first post-quantum key exchange algorithms are showing up in real handshakes. Federal guidance documents still describe a world that no longer exists.

This is Issue 0 of a recurring series tracking what those changes actually look like in the federal public web. Weekly trackers will report what rotated, what broke, and what shifted. Monthly deep-dives will pull on a single thread (OCSP, PQC, validity rollback, hosting concentration) until it tells a coherent story. The first deep-dive ships after this issue under the title The Death of OCSP, Revisited.

Everything in the public posts is aggregated and anonymized at the entity level. Hosts are referenced by sector ("a civilian cabinet department", "a .mil combatant command") and never by name unless the posture is clean and the naming is positive. The de-anonymized dataset stays internal at Tailwind and exists so we can reach out and offer help when a real problem is visible.

Why now

Three changes converged this year and they will play out over the next three years.

  • The CA/Browser Forum ballot SC-081v3 passed April 11, 2025, with zero opposition. Public-trust TLS validity drops to 200 days starting March 15, 2026; 100 days starting March 15, 2027; 47 days starting March 15, 2029. The preamble to the ballot explicitly accepts that revocation does not work at scale, and uses shorter validity as the workaround.
  • Let's Encrypt turned off its OCSP service on August 6, 2025, on schedule. Peak load was roughly 340 billion requests per month. Six-day Let's Encrypt certs went generally available in 2025 with no OCSP URL and no CRL URL. Default Let's Encrypt validity drops to 64 days in February 2027 and 45 days in February 2028.
  • Post-quantum key exchange is rolling out in the wild. Cloudflare, Google, and a handful of others are negotiating hybrid KEMs (X25519+ML-KEM-768) by default. CAs are not yet issuing PQC-signed certificates, so today the PQC story is entirely about the handshake.

NIST SP 800-52 Rev. 2 (August 2019) is still active. It expects OCSP as the primary revocation check with CRL fallback. Rev. 3 is in pre-draft public comment as of May 2026; nothing has been published yet. Agency-specific TLS policy generally does not address the case where the public CA simply does not publish an OCSP URL.

What we measure

A full capture combines four layers per host:

  • Cert layer. Issuer, validity window, AIA OCSP URL, CRL distribution point, must-staple flag, SCT count, key algorithm, signature algorithm, chain length. Parsed from a live handshake against the host.
  • TLS layer. Protocols offered, forward-secrecy KEMs and curves (including PQC hybrids), OCSP stapling, HSTS, HSTS preload, and any HIGH/CRITICAL vulnerability findings from a full protocol scan.
  • Network layer. A and AAAA records, reverse DNS, BGP origin AS, HTTP server header, edge-network signals (Akamai, CloudFront, Cloudflare, Fastly, Azure), ALPN.
  • Posture layer. A coarse hosting-model bucket, a Labs-style proxy grade, sector classification (civilian / DoD / DIB / intelligence / vendor / GSE).

The capture happens against the apex host of each entity, with a www.<host> fallback when the apex refuses. The dataset is 110 entities plus a Tailwind-owned control: 44 civilian executive, legislative, and judicial sites; 35 .mil sites (29 reachable, 6 refused at the network layer); 18 defense industrial base companies; 6 intelligence community sites; 5 commercial security and CDN exemplars; 2 quasi-federal entities.

How we measure

The pipeline is a Tailwind tool. Each weekly capture combines the four data layers above into a single canonical record per host. The layers are gathered independently, joined on the entity, and reconciled before publication.

After joining, a deterministic transformation assigns each entity a stable identifier, strips re-identifying fields from the published view, and writes two parallel datasets: an internal enriched dataset used for operator outreach, and a published dataset anonymized at the entity level.

Each capture is then compared against the prior one. The diff is the input to the weekly tracker: certificate rotations, AIA OCSP and CRLDP profile changes, validity-window deltas, hosting changes, and reachability flips. The diff is reported in aggregate; the de-anonymized per-host detail stays in the internal dataset.

The tooling is proprietary to Tailwind.

Each capture is keyed by date. The 2026-05-03 capture is the inaugural baseline. The 2026-05-11 capture is the first weekly delta.

Tailwind Assessment: The point of describing the methodology in this much detail is to set the standard for what a serious posture review looks like. Federal CISOs do not need another vendor report; they need a method run against their own boundary and an interpretation of what it finds. The methodology section above describes the shape. The aggregations below are the interpretation. If you want this run on your own property, that is what Tailwind does.

Inaugural snapshot: 2026-05-03

CA distribution

CA family distribution by sector, 2026-05-03 inaugural snapshot

Three CAs account for nearly four-fifths of the leaves in the dataset. DigiCert dominates the long-validity (300+ day) end of the distribution because it is the incumbent provider for cabinet-level civilian agencies and most DIB primes. Let's Encrypt dominates the short-validity end and sits as the only CA in the dataset that has dropped OCSP URLs from its issuance profile. Google Trust Services covers a smaller but growing slice, mostly behind Cloudflare's hosting tenants.

The .mil sector is the most concentrated. Eighteen of twenty-nine reachable .mil sites run on a single CDN with Let's Encrypt 89-day certs. The pattern is consistent with a single contract-level default propagating to eighteen tenants rather than eighteen independent procurement decisions. The civilian sector is more varied because each cabinet department procures TLS independently.

The OCSP question

OCSP URL presence by CA family, 2026-05-03

Let's Encrypt is the only CA in the dataset that has fully dropped OCSP URLs from its leaf AIA. Every other CA family ships an OCSP responder URL on every leaf, with one notable exception: a particular Sectigo public DV profile that ships an OCSP URL but no CRL distribution point. Two civilian agency leaves currently use this profile. If Sectigo follows Let's Encrypt and shuts down its OCSP responder, those leaves become structurally uncheckable for revocation by clients that do not yet implement CRLite.

The headline number: of 103 reachable hosts in the inaugural capture, 35 percent have no OCSP URL in the leaf certificate. Every one of those leaves is a Let's Encrypt leaf.

Tailwind Assessment: The federal client posture is the part of this story that does not get enough attention. The CA side is doing the rational thing. NIST 800-52 Rev. 2 is unchanged since 2019 and does not describe the situation where a public CA does not publish revocation information. Federal services that consume the public Web PKI as clients (proxies, gateways, integrations) generally have not been updated to handle this case. That is the actual exposure.

Validity windows

Certificate validity-window distribution, 2026-05-03

The 89-day and 90-day buckets are dominant: that is the Let's Encrypt default plus the Google Trust Services WE1 default. The 364-396 day cluster is the legacy DigiCert / Entrust / Sectigo OV cohort, mostly issued before March 15, 2026. The CA/B Forum 200-day milestone took effect that day; certs issued before the milestone are grandfathered through their natural expiry and only the next renewal must comply.

The cluster of long-validity (above 200 days) certs in the dataset, 43 in the baseline capture, is the renewal cliff. Every one of those certs must come back at 200 days or fewer at next rotation. That includes most of the cabinet-level civilian sites and most of the DIB primes.

PQC adoption

Post-quantum hybrid handshake adoption rate by sector, 2026-05-03

The single most striking aggregate finding in the inaugural capture: the defense industrial base outpaces the Department of Defense itself in post-quantum handshake adoption. Just over half of reachable DIB sites negotiate a hybrid PQC KEM. Zero reachable .mil sites do.

The explanation is straightforward. PQC support in this dataset is concentrated by CDN, not by sector. Cloudflare, Google's edge, and Fastly all default-negotiate PQC hybrids today. The DIB has migrated heavily to those edges; the .mil sector is on an Akamai contract that has not enabled PQC at the public-edge tenant level.

Tailwind Assessment: This is not a claim that the DIB is more secure than DoD. Hybrid PQC in the handshake hardens against harvest-now-decrypt-later attacks against the session key. It does nothing for cert signature integrity, which is unchanged. The distinction matters because DoD acquisition will look at this gap and ask the wrong question.

A week of motion: 2026-05-03 to 2026-05-11

The point of running this on a weekly cadence is to show that the dataset is not static. Seven days produced material change.

Headline numbers:

Metric Prior week This week Delta
Reachable hosts 103 104 +1
OCSP URL present 67 65 -2
CRL URL present 100 101 +1
Let's Encrypt leaves 32 35 +3
Validity > 200 days 43 42 -1
Validity <= 100 days 49 50 +1

Highlights:

  • Twenty-two leaves rotated.
  • Two civilian agency sites (the .gov properties of two independent research-oriented agencies) moved off Google Trust Services and onto Let's Encrypt. Both lost their OCSP URL in the process. The no-OCSP cohort grew from 35 to 38 percent of reachable hosts.
  • One commercial security vendor visibly complied with the SC-081v3 200-day cap at renewal. Palo Alto Networks rotated its main corporate site from a 364-day DigiCert cert to a 198-day DigiCert cert. As of this capture, that is the first observed instance in the dataset of a non-Let's Encrypt issuer pushing a renewal under the new cap rather than waiting out a grandfathered cert. Named because the posture change is unambiguously positive.
  • A .mil host that refused to connect during the inaugural capture is back online. It runs on the same Akamai / Let's Encrypt / no-OCSP profile as the rest of the .mil cohort, bringing the post-OCSP .mil count to nineteen and the reachable .mil count to thirty.
  • One civilian agency runs two parallel issuance regimes on the same domain. The www subdomain sits on a CDN edge with a fresh ECDSA cert on a normal renewal cadence. The apex sits on the agency's own origin IP with an RSA cert from a different DigiCert intermediate that expired five days before this capture. The apex's HTTP layer redirects to its own HTTPS surface, not to www, so a user typing the bare domain lands on the expired cert and the browser blocks the connection. Two different cert programs, two different renewal workflows, only one of them watched. This is a single-agency operational failure noted here in aggregate as a data point on hygiene. The operator has been notified through the channel described at the top of this post. The shape of the failure is worth holding onto, though: it is the kind of split that any agency with a CDN-fronted www and a legacy apex can quietly accumulate.
  • Eleven .mil hosts share the same 2026-06-03 expiration date, all on the same CA. None have rotated yet. As of this capture they sit roughly three weeks from expiration. The next weekly tracker will tell us whether they rotate synchronously again, which would confirm a single-batch issuance pattern at the CDN tenant level.

The remaining rotations were within-issuer-family renewals at 89 or 90 days, holding existing posture. Apart from the Palo Alto Networks rotation noted above, none of the long-validity certs issued before March 15, 2026 have rotated yet; those certs remain grandfathered through natural expiry and only the next renewal must come back at 200 days or fewer.

OCSP URL presence by CA family, week of 2026-05-11
Trendline of OCSP-bearing leaves across weekly captures

What we are watching

The next four to eight weeks are unusually rich. Specific things to track:

  • The eleven .mil hosts on the 2026-06-03 expiration. Synchronous rotation versus staggered rotation is the difference between "this agency outsourced TLS hygiene to a CDN" and "this agency outsourced TLS issuance to a CDN."
  • The long-validity cohort. Roughly forty cabinet-level and major agency certs sit at 350-plus day validity today. Every one of them must come back at 200 days or fewer at next rotation. The first agency to noticeably push a sub-200-day cabinet renewal is a bellwether.
  • Any second public CA in the dataset that follows Let's Encrypt and shuts down OCSP. The Sectigo DV profile (no CRLDP) is the most exposed.
  • Net Let's Encrypt migration. Two civilian agencies migrated from Google Trust Services to Let's Encrypt in week one. If that pattern continues, the no-OCSP share will keep climbing.
  • Any agency procurement signal that requires a particular CA, posture, or validity floor.

Cadence and where to follow

Weekly tracker every Sunday with the prior week's diff, the headline counts, and one updated chart. Monthly deep-dive at the end of each month on a single thread. The inaugural deep-dive (The Death of OCSP, Revisited) ships after this issue.

The tooling is proprietary to Tailwind. The published dataset that backs these articles is anonymized; the internal dataset is not, and exists so Tailwind can reach out and help when the data shows a real operational problem. If you operate a federal public web property and want a private posture review, that is a conversation we are happy to have.

tls web-pki ocsp federal cybersecurity pqc
Bill Church

Bill Church

Vice President, Engineering & Services

LinkedIn