PQC and 47-Day TLS Certificates: Why Two Migrations Are Converging

Quick answer: Two independent PKI transformations are landing on the same infrastructure at the same time. The CA/Browser Forum’s Ballot SC-081v3 shortens maximum TLS certificate validity in stages, 200 days by March 2026, 100 days by March 2027, and 47 days by March 2029, forcing full issuance automation as a baseline requirement, not an optimization. PQC migration, on the same timeline, is expanding certificate and signature sizes by roughly 15 to 50 times over classical algorithms and introducing new compatibility requirements across that same certificate infrastructure. Neither transformation was designed with the other in mind, but they converge on the same CA hierarchy, the same automation tooling, and the same certificate population, which means planning for them separately is what actually creates risk, not planning for them together.

Most PKI teams are tracking these as two separate initiatives, a certificate lifetime compliance project and a quantum-readiness project, run by overlapping but not identical stakeholders on overlapping but not identical timelines. That separation is a mistake. Every certificate issued from this point forward has to satisfy both requirements simultaneously, which means the two initiatives share almost all of their real execution risk.

Key Takeaways

• CA/Browser Forum Ballot SC-081v3 sets a staged reduction in maximum TLS certificate validity: 200 days by March 2026, 100 days by March 2027, 47 days by March 2029.
• 47-day certificates make full issuance and renewal automation mandatory; manual certificate management becomes operationally impossible at that renewal frequency.
• PQC certificates run roughly 15 to 50 times larger than classical certificates depending on algorithm and parameter set, a size increase that automation infrastructure sized for classical certificates was not built to absorb.
• The convergence point is renewal frequency times certificate size: automation infrastructure now needs to handle both dramatically more frequent renewals and dramatically larger payloads at the same time.
• Treating these as one combined infrastructure investment, rather than two separate projects, avoids building automation twice.

The 47-Day Timeline

CA/Browser Forum Ballot SC-081v3 sets a staged reduction in maximum publicly trusted TLS certificate validity: 200 days effective March 15, 2026, 100 days effective March 15, 2027, and 47 days effective March 15, 2029. Each stage compounds the operational demand on issuance and renewal infrastructure, since a 47-day certificate needs to be renewed roughly 7.7 times per year versus once for a 398-day certificate under the previous maximum. At that frequency, manual certificate management is not a compliance risk, it’s an operational impossibility for any organization managing more than a small handful of certificates.

The PQC Size Problem, on the Same Timeline

PQC certificates carry substantially larger public keys and signatures than their classical counterparts, an ML-DSA-65 signature running roughly 3,309 bytes versus 64 bytes for ECDSA, a size increase covered in depth in our FIPS 203, 204, and 205 standards guide. That growth compounds across a certificate chain and directly affects TLS handshake size, certificate storage requirements, and validation time, exactly the infrastructure that also has to absorb the 47-day renewal frequency’s issuance volume increase.

Where the Two Transformations Actually Converge

The convergence isn’t conceptual, it’s infrastructural. Both transformations land on the same enrollment automation (ACME, EST, SCEP), the same CA hierarchy, and the same certificate management platform. An automation pipeline built to handle classical-sized certificates at annual renewal frequency needs to simultaneously handle PQC-sized certificates at near-weekly renewal frequency, a combined demand meaningfully higher than either transformation alone. Testing and validation infrastructure faces the same convergence: the enrollment protocol testing your 47-day certificate compliance requires needs to happen against the actual certificate sizes your PQC migration will introduce, not against today’s smaller classical certificates, or the testing validates the wrong future state.

Why Planning Them Separately Creates Risk, Not Reduces It

Organizations tracking these as two separate initiatives typically end up building automation infrastructure twice, once for short-lived classical certificates, then again when PQC certificates arrive and the first build’s size assumptions turn out to be wrong. Worse, a team focused solely on 47-day compliance may deploy automation infrastructure not sized for PQC certificate payloads, creating a second, avoidable remediation project on a compressed timeline once PQC migration catches up to it. Combining the two into a single infrastructure investment, sized for both requirements from the start, avoids that rework entirely.

What We’d Actually Recommend

Treat certificate lifetime compliance and PQC readiness as a single infrastructure investment, not two separate projects with separate budgets and separate timelines. Size any new automation infrastructure for PQC certificate payloads now, even if your PQC certificate rollout comes later, rather than building for today’s classical certificate sizes and rebuilding once PQC arrives. Test enrollment automation against both dimensions simultaneously, real renewal frequency and real certificate size, rather than validating each requirement in isolation against the other’s easier baseline.

How Encryption Consulting Can Help

CertSecure Manager is built to handle both dimensions of this convergence from a single platform: automated issuance and renewal at the 47-day cadence, sized for classical, hybrid, and pure PQC certificate payloads, so the infrastructure investment covers both requirements rather than needing to be rebuilt when the second one arrives.

Our PQC Advisory Services plan certificate lifetime compliance and PQC readiness as a combined program, sequencing the shared automation infrastructure investment against both the CA/Browser Forum’s staged deadlines and your own PQC migration timeline.

One Infrastructure Problem, Not Two

Certificate lifetime compression and PQC migration were designed by different standards bodies for different reasons, and they still land on exactly the same enrollment automation, the same CA hierarchy, and the same certificate management platform, at nearly the same time. Planning for them as two separate initiatives means building the same automation infrastructure twice, once sized wrong. Planning for them together, sized for both 47-day renewal frequency and PQC certificate payloads from the start, is what actually reduces the combined risk and cost of both transformations landing on the same infrastructure at once.

Frequently Asked Questions

What are the CA/Browser Forum’s staged TLS certificate lifetime reductions?

200 days effective March 15, 2026, 100 days effective March 15, 2027, and 47 days effective March 15, 2029, under Ballot SC-081v3.

Why does the 47-day certificate lifetime make automation mandatory rather than optional?

At a 47-day maximum validity, certificates need renewal roughly 7.7 times per year instead of once. Manual certificate management at that frequency becomes operationally impossible for any organization managing more than a handful of certificates.

Why should certificate lifetime compliance and PQC readiness be planned together?

Because both land on the same enrollment automation, CA hierarchy, and certificate management platform. Planning separately risks building automation infrastructure sized only for classical certificates, then needing to rebuild it once PQC certificates arrive with substantially larger payloads.

How much larger are PQC certificates than classical ones?

Roughly 15 to 50 times larger for signatures depending on the specific algorithm and parameter set, an ML-DSA-65 signature running about 3,309 bytes versus roughly 64 bytes for ECDSA.

Should enrollment automation be tested against today’s certificate sizes or future PQC sizes?

Future PQC sizes, even if PQC certificate issuance comes later in your timeline. Testing only against today’s smaller classical certificates validates infrastructure that will need rework once larger PQC certificates are introduced.