.svg)
%201.svg)
.svg)
.svg)
What is the 47-day certificate rule?
In April 2025 the CA/Browser Forum approved Ballot SC-081v3, which cuts the maximum lifetime of publicly trusted TLS certificates in stages:
Effective date → Max certificate lifetime
- Before March 15, 2026: 398 days
- March 15, 2026: 200 days
- March 15, 2027: 100 days
- March 15, 2029: 47 days
The same ballot shrinks how long a CA can reuse domain validation, down to 10 days by 2029. Browsers enforce all of this, so a certificate issued outside the rules simply won't be trusted.
The math gets uncomfortable fast. Take an organization with 2,000 public certificates. At today's 200-day limit, that's about 3,650 renewals a year. At 47 days, it's more than 15,000, or roughly 300 a week. Every one of them has to be issued, installed on the right system, and checked. Spreadsheets and calendar reminders don't scale to that, and the scripts someone wrote three years ago usually don't cover everything.
How are 47-day certificates related to post-quantum cryptography?
Post-quantum migration means replacing RSA and elliptic curve cryptography with algorithms that hold up against quantum attacks. NIST published the first post-quantum standards in 2024. Its draft transition guidance, NIST IR 8547, proposes deprecating today's vulnerable public-key algorithms after 2030 and disallowing them after 2035. Federal agencies are already planning against those dates, and their suppliers will follow.
When people picture that migration, they tend to picture a cryptography problem. Mostly it isn't. Choosing an algorithm is the easy part. The hard part is finding every place your organization relies on a key or certificate, knowing who owns it, and replacing it without breaking whatever depends on it.
That's exactly what 47-day certificates force you to do. The industry has a name for this ability: crypto agility. It means you can swap out keys, certificates, or algorithms across your environment quickly and safely. If every certificate you own already rotates on its own every few weeks, changing the algorithm is a policy update. If rotation is still a manual project, PQC becomes a multi-year one.
Same capability, different trigger. One is a calendar date. The other is a cryptographic one.
What carries over from certificate automation to PQC?
If you scope your certificate automation work with PQC in mind, four capabilities carry straight over:
Discovery: 47-day certificates need every certificate, including ones nobody remembers issuing. PQC migration needs a full inventory of where cryptography is used.
Ownership: 47-day certificates need someone accountable when a renewal fails. PQC migration needs someone to approve and test each algorithm change.
Automated rotation: 47-day certificates need renewal and deployment with no ticket. PQC migration needs re-issuing everything with new algorithms on a schedule you control.
Policy control: 47-day certificates need lifetimes and issuers set centrally. PQC migration needs algorithms and key sizes set centrally, changed in one place.
The difference between a good rehearsal and a wasted one is scope. Automating renewal for the public web servers you already know about will get you past the March 2027 deadline. It won't help much with PQC, because most of your cryptography lives elsewhere: internal services, private CAs, devices, and machine identities that the CA/B Forum rules don't touch.
So the rehearsal only counts if it covers the whole estate, not just the part with a public deadline.
What doesn't certificate automation solve for PQC?
To be fair, certificate automation isn't the whole PQC story. A few things still need their own attention:
- Encrypted data at rest. Data stolen today can be decrypted later once quantum computers are capable enough. Certificate rotation doesn't fix that.
- Systems that can't handle new algorithms. Post-quantum keys and signatures are larger. Some older devices, protocols, and embedded systems won't support them without upgrades or replacement.
- Signatures and trust chains. Root and intermediate CAs, code signing, and firmware signing often have long lifetimes and slow change processes. They need a plan of their own.
None of these are reasons to separate the two programs. They're reasons to make sure the automation you build now has room to grow into them.
How should you plan for both deadlines?
The organizations that come out ahead won't be the ones who survived March 2027 and then started over on PQC. They'll be the ones who used the certificate deadline to build crypto agility on purpose, and found the post-quantum work was mostly done when they got to it.
Axiad CLM is built for that. It discovers certificates across your public and private authorities, assigns ownership, automates rotation at the 47-day cadence, and keeps the audit trail your compliance team needs. It also sits inside the Axiad platform, so certificate risk shows up alongside the rest of your identity risk instead of in its own silo.
Join Ian Farquhar and Bassam Al-Khalidi for their October 28, 2026, session "A Hundred to One," a practitioner's look at surviving the certificate deadline and the PQC one with the same plan.
Frequently asked questions
When do 47-day certificates take effect?
Publicly trusted TLS certificates are capped at 47 days starting March 15, 2029. Until then, the maximum is 200 days, dropping to 100 days on March 15, 2027.
Do the new limits apply to private or internal certificates?
No. The CA/Browser Forum rules only cover publicly trusted TLS certificates. Private CAs can set their own lifetimes. Internal certificates still need to be inventoried and managed, though, and they'll need to move to post-quantum algorithms like everything else.
How many more renewals will 47-day certificates mean?
About four times as many as today's 200-day limit, and roughly eight times as many as the old 398-day limit. An organization with 2,000 public certificates would go from about 3,650 renewals a year to more than 15,000.
What is crypto agility?
Crypto agility is the ability to replace keys, certificates, or cryptographic algorithms across an environment quickly and without outages. It depends on knowing where every certificate and key lives, who owns it, and being able to rotate it automatically.
When do organizations need to migrate to post-quantum cryptography?
NIST's draft guidance proposes deprecating RSA and elliptic curve algorithms after 2030 and disallowing them after 2035. High-risk systems are expected to move sooner, and federal agencies are already planning against the 2030 date.
Does automating certificate renewal make you post-quantum ready?
Not completely, but it covers much of the groundwork. Automated discovery, ownership, and rotation are what make an algorithm change manageable. Encrypted data at rest, legacy systems that can't support larger post-quantum keys, and long-lived signing keys still need their own plans.
About the author
Bassam Al-Khalidi is Chief Innovation Officer and co-founder of Axiad. Bassam has over 15 years of experience in designing and deploying identity and access management solutions across large government, enterprise, and healthcare organizations.
.svg)
.svg)
.svg)
.svg)
.svg)