If you sat your platform or security team down today and asked what they should actually be working on in 2026, the answer should sound something like this:
- Evaluating ML-KEM hybrid handshakes and what they break in your stack: the older middleboxes, the legacy clients, the load balancers that haven't been updated since 2019.
- Planning for 47-day certificate validity that lands in March 2029, with the 100-day rule in March 2027 as the next checkpoint. Both require automation your team probably doesn't have yet.
- Tracking which DCV methods (HTTP-01, DNS-01, TLS-ALPN-01, and the email-based ones still alive in commercial CA portals) are being added, deprecated, or restricted by the CA/Browser Forum and individual CAs.
- Reading the Chrome and Mozilla CA program announcements so you're not the team that finds out about a root distrust event from a customer ticket.
- Maturing your internal PKI: rotating intermediate CAs in your kubernetes mesh, replacing the self-signed certificates your test environments accumulated over five years, deciding whether Vault, AWS Private CA, or smallstep is the right call for the next round.
That's the shifting PKI baseline. It's strategic work. It protects you from the next major ecosystem event - the next Entrust-scale distrust, the next forced cipher migration, the next validity cliff.
Here's what your team is actually doing instead: chasing expired Let's Encrypt renewals because the cron script broke after the Ubuntu upgrade. Debugging "why is Safari throwing a warning but Chrome isn't" (it's the intermediate chain). Hunting shadow certificates that someone issued from the AWS console two years ago and forgot about. Writing yet another monitoring dashboard because the last one didn't catch a hostname mismatch on a wildcard SAN.
This is the boring operational PKI work. It's necessary. It also fills the entire week.
The PKI ecosystem is moving faster than it has in a decade
A short list of what's happened in the last three months alone:
- Chrome stopped trusting public TLS certificates that include the clientAuth EKU (June 15, 2026). If you use public certs for mTLS or API client authentication, you're rebuilding that flow right now.
- Mozilla and Chrome distrusted three DigiCert G1 roots on April 15. Any TLS server still chaining through DigiCert Assured ID, Global Root CA, or High Assurance EV stopped working in major browsers that day.
- The CA/Browser Forum 200-day maximum validity took effect March 15. Any certificate issued after that date expires within 200 days, not 398. The renewal cadence for new infrastructure doubled overnight.
- Post-quantum hybrid key agreement is shipping to defaults. Akamai turned on ML-KEM + X25519 by default for browser-to-Akamai connections in February. Cloudflare crossed the threshold where more than a third of human HTTPS traffic on their network is already using hybrid handshakes.
Each of these has downstream effects on your monitoring, your configuration, your alerting thresholds, and what counts as a "healthy" cert. Your team should be reading the announcements, modeling the impact on your stack, and adjusting your standards accordingly. That's the real PKI work.
But they can't, because they're chasing renewals.
The "accidental PKI person" problem
If your shop doesn't have a dedicated PKI team, the same problem hits even harder. One engineer becomes the de facto PKI person. They didn't ask for it; they were just unlucky enough to fix the cert outage in February. Now they get every cert ticket and every on-call page when something breaks at the TLS layer. They aren't reading CA program updates. They aren't planning for 47-day validity. They're firefighting.
Multiply that across the small and mid-sized companies running production today and you get an entire industry where the people best positioned to think about the shifting PKI baseline have no time to do it. The operational layer eats the week. The strategic work waits for "after this fire is out," which means it waits forever.
What outsourcing the operational layer actually buys you
TLS Radar watches the operational layer. The certificates that need renewing. The chains that broke after an intermediate rotation. The configurations that drifted from your standard. The hostnames you forgot you bought. The ciphers that became "weak" overnight when a new attack hit the news. We send the alert when something is actually broken or about to break, to the team that owns the service, with enough context that they can fix it without becoming a TLS expert first.
We are the TLS experts so your team doesn't have to be.
The trade isn't "save engineering hours." It's "free your PKI bandwidth for the work that actually moves the needle." When the next root distrust event happens - and there will be one - the difference between a team that handles it cleanly and a team that gets hit hard isn't talent. It's whether they had spare cycles to read the announcement six weeks before it landed.
Cert monitoring is a solved problem. It just isn't solved by every engineering team building their own version of it.
If your team is spending more time on certificates than on the work that actually advances your security posture - PQC readiness, automation for the new validity floors, distrust-event playbooks, internal PKI maturity - that's the trade we're built for.
Free your PKI team for the work that actually matters
TLS Radar continuously monitors every certificate across your domains and alerts you weeks before anything expires, including the silent failure modes (chain breaks, weak ciphers, hostname mismatches) that expiry-only monitoring misses. Built to scale from a handful of sites to enterprise portfolios with API integration, SAML/SSO, and pricing tailored to your certificate volume.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.