5 MIN READ
Most enterprises will hand an auditor a 2019 spreadsheet when asked for the certificate inventory, and any auditor will know within ten seconds. The contradiction is not a secret. PKI has been the layer holding the rest of the enterprise together for two decades, and almost nobody has been counting what is in it.
Google started rejecting TLS certificates over 90 days in 2025, NIST published the post quantum algorithm standards (FIPS 203, 204, 205) in 2024, and Apple’s Safari has been pushing shorter lifetimes since 2024. The deadlines are visible. The inventory problem has been the one nobody has been looking at, and it tends to surface at exactly the wrong moment.
What the inventory problem looks like in practice
A typical enterprise that thinks it runs around 5,000 certificates actually runs closer to 30,000 once a continuous scanner (Venafi, Qualys TLS, testssl.sh, Keyfactor) has done a full pass. The gap is shadow certificates. Dev environments hand out long lived certs and never revoke them. IoT devices, network gear, internal load balancers, Kubernetes ingress controllers, the forgotten test infrastructure from the project that shipped in 2021 and nobody decommissioned. The CISO who gets the real number back from a scan almost always responds with the same question. How did this happen.
One expired certificate on a network device is enough to take corporate email down for a working day. One revoked root the client does not know about is enough to break the API auth for an entire vendor stack. The single point of failure is not the cryptography. It is the visibility into what certificates are running, where, and for how long.
What the audit and the regulator now require
SOC 2 has been asking for evidence of certificate lifecycle management since 2022. PCI DSS v4 made the key management controls explicit. ISO 27001:2022 added Annex A control 8.24 on cryptographic key management. The auditor expects a live view of the inventory, evidence that the rotation has been happening, and a written policy for post quantum migration. The spreadsheet from 2019 fails every one of those checks.
The post quantum deadline is the part that surprises most security leaders. NIST finalised the standards in 2024, NSA has been recommending hybrid classical plus ML-KEM since 2025, and the major browsers (Chrome, Firefox, Safari) have been running experiments with Cloudflare and Google since 2024. The migration is not a 2030 problem. It is a 2027 problem for any cert with a lifetime over two years.
How to make PKI actually hold up
Three pieces, in this order. Continuous scanning first, Venafi or Keyfactor for the enterprise, testssl.sh as a free baseline, the scanner running on a daily cadence with the results landing in a live dashboard. ACME protocol second, either Let’s Encrypt for the public facing certs, the internal CA for the private ones, or the cloud provider’s managed CA (AWS Private CA, Azure Key Vault Managed HSM, Google Cloud Certificate Manager). Automation removes the human from the rotation loop, and the human has been the bottleneck for the last decade. Post quantum migration third, starting with the long lived certs, the code signing certs, the IoT device certs, the things that will still be running when the deadline lands. The CISO who has the scanner, the ACME, and the migration plan in place is the one whose next audit starts with the live dashboard instead of the 2019 spreadsheet.
The bottom line
Continuous scanning, ACME automation, post quantum migration plan. The 2019 spreadsheet era is the era the next audit ends, and the audit is closer than most security leaders think.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
