The Role of Certificate Automation in PQC Migration

Key takeaways

• Post-quantum migration splits into two halves. The encryption half arrives through vendor updates you already installed. The authentication half is yours: every certificate reissued, every chain rebuilt, every trust store updated.
• The authentication work does not happen once. It repeats as hybrid certificates give way to pure post-quantum ones, and it runs against an estate that keeps growing, which is what makes it a lifecycle problem rather than a project.
• The 47-day TLS schedule raises the volume of exactly the work post-quantum migration depends on, so the two are better solved together than separately.
• Public trust stores cannot issue post-quantum certificates yet. But private PKI can, which is where the work available today sits.
• Certificate automation is what turns all of this into a process that runs rather than a program you staff.

Post-quantum cryptography reaches every certificate an organization holds, because each one is signed with an algorithm that will eventually be retired. Moving any single certificate to a post-quantum algorithm is a small piece of work. Doing it across several thousand, then repeating it as hybrid certificates give way to pure post-quantum ones, is what stretches the migration across years.

Automation is what makes repeated reissuance at that scale sustainable. When discovery, issuance, and renewal run without manual intervention, certificates get replaced correctly and on time, however many times the migration asks for it.

Why post-quantum migration cannot wait for quantum computers

Certificates, software signatures, and encrypted data all rest on the same foundation: a set of hard mathematical problems that are easy to compute in one direction and impractical to reverse. Deriving a private key from its public key means solving one of those problems, and no conventional computer can do that in a realistic timeframe.

A sufficiently large, fault-tolerant quantum computer running Shor’s algorithm could do it in days. The hardware capable of it does not exist today but published migration timelines assume it arrives during the 2030s, and the standards bodies have already chosen replacement algorithms on that basis.

The exposure, though, does not begin when the hardware does. Under “Harvest now, decrypt later”, an adversary captures encrypted traffic today and holds it until the hardware catches up. Any data that must stay confidential for a decade or more is already exposed to that risk, whatever date sits on your migration plan.

The encouraging part is that this is a solvable, well-defined engineering problem. What it takes is time, because replacing the cryptography across a large certificate estate means coordinated work between teams that do not report to each other. Time is the one input still available to you. Begin discovery and inventory in 2026, and the rest of the migration fits inside release cycles you already run.

What is driving PQC migration in 2026

The National Institute of Standards and Technology (NIST) finalized the first set of post-quantum cryptography standards, FIPS 203, 204, and 205, in August 2024. Those are the algorithms you migrate to, and they have been available to build against for two years.

What remains is the migration, and three separate forces now shape it. Regulation sets the deadline and decides who it applies to. The 47-day TLS schedule changes the operating conditions you will do the work under. Ecosystem readiness determines what you can actually issue, and when.

Regulation set the deadline, and extended it to suppliers

Executive Order 14412 was signed in June 2026. It splits the federal migration into two stages. High value assets and high impact systems, excluding national security systems, move to post-quantum key establishment by the end of 2030 and to post-quantum digital signatures by the end of 2031.

It also directs the Federal Acquisition Regulatory Council to publish a proposed FAR rule, due by roughly December 2026, requiring covered contractors to comply with NIST FIPS, including those incorporating post-quantum algorithms, by December 31, 2030.

Two days later, OMB M-26-15, turned the order into an operating plan, with agency migration plans due in 120 days and a requirement for an automated, continuously updated cryptographic inventory rather than a point-in-time one.

Contractor compliance is where the order reaches beyond government. An organization with no federal systems of its own still answers post-quantum questions during procurement review, and answering them means knowing which algorithms are in use across its own estate.

Framework	Milestone	Date
NIST CMVP	FIPS 140-2 validated modules move to the Historical list	September 21, 2026
US Executive Order 14412	Federal HVAs and high impact systems on PQC for key establishment	December 31, 2030
	Federal HVAs and high impact systems on PQC for digital signatures	December 31, 2031
	Covered contractors to comply with NIST FIPS including PQC algorithms	December 31, 2030
UK NCSC	Discovery complete and migration plan in place	2028
	Highest-priority migration activities complete	2031
	Migration complete	2035

The 47-day TLS schedule makes the same work harder

The CA/Browser Forum’s phased schedule is already underway. Maximum validity for public TLS certificates dropped to 200 days in March 2026, falls to 100 days in March 2027, and reaches 47 days in March 2029. Each reduction raises renewal frequency, which makes preparation for the 47-day mandate an operational exercise. Domain control validation reuse falls further to 10 days in 2029, which for most teams is the harder of the two changes to absorb manually.

Renewal frequency roughly doubles at each step. Teams renewing twice a year now will renew quarterly from 2027, and close to eight times a year from 2029, and those renewals arrive during exactly the years when the algorithm inside the certificate is also changing.

The compounding effect is the point. Post-quantum migration asks you to change what is inside every certificate. The 47-day schedule asks you to touch every certificate far more often. A team that can only just keep up with renewals today has no capacity left for the first thing, and a missed renewal during that period is both an outage and a gap in the migration record.

Ecosystem readiness decides what you can issue

Several major providers moved their own post-quantum readiness deadlines earlier during 2026 following research advances in quantum hardware. Cloudflare and Google now aim for full post-quantum readiness by 2029. Microsoft, which had held a 2033 completion date since August 2025, moved to 2029 in June this year.

These dates matter for planning because they set the pace of the surrounding ecosystem. Certificate authorities, hardware security module vendors, and protocol implementations follow the same curve, and when that support arrives, it only benefits an organization that can reissue its certificates at scale.

Read the three together and the shape of the problem is clear. The deadline is fixed, the volume of work rises steeply before it, and the tooling you need arrives late in the window. The only variable you control is how much of the work is already automated when it does.

Why PQC migration is a certificate lifecycle management problem

Post-quantum migration has two parts, encryption and authentication.

• Encryption: Browsers, content delivery networks, and TLS libraries have adopted hybrid key exchange pairing X25519 with ML-KEM, the post-quantum standard for key establishment. Client software largely inherits it by staying current. Server-side, it usually still takes a configuration decision, but the path is well worn, and someone else built it.
• Authentication: Moving classical signatures to ML-DSA, the equivalent standard for digital signatures, means reissuing certificates, rebuilding chains from root to leaf, updating trust stores, and confirming that every endpoint accepts the new format. Nothing upstream does that for an organization.

Reissuing, rebuilding, and validating certificates is certificate lifecycle management work. Most organizations will issue hybrid certificates first, because pure post-quantum breaks legacy applications. They will move to pure post-quantum later as support matures. Between those passes the estate keeps moving: new services in cloud accounts, workloads in Kubernetes, certificates minted by build pipelines nobody registered. What you inventory at the start is not what you will be migrating at the end.

So the work is not “replace N certificates.” It is “keep replacing an N that changes, across more than one algorithm generation, for several years.” Discovery has to repeat. The inventory has to stay current. Issuance must follow policy rather than tickets. That is the certificate lifecycle, running continuously under load.

Which makes the real question a different one. Not whether your organization can migrate to post-quantum cryptography, but whether your certificate lifecycle can absorb a change of this size without stopping. Whatever handles renewals today is what you will migrate with.

Understanding certificate automation

Certificate automation means the full certificate lifecycle running without a person in the loop at any stage: finding certificates wherever they are issued, issuing certificates from an approved authority, installing them on the systems that present them, renewing them before expiry, and revoking them when trust ends. Most organizations already run some of this for TLS renewals. Post-quantum migration adds three demands on top of that baseline. Certificates have to be reissued on a new algorithm, classical and post-quantum certificates have to run side by side for a period, and the whole exercise repeats when the algorithms change again.

Why certificate automation is necessary for PQC migration

• Volume: An organization with 1,000 certificates will handle over 7,700 renewals a year at 47-day validity, and more in practice, since certificates are renewed before they expire rather than on the day. Post-quantum reissuance layers on top of that.
• Continuity: Discovery, inventory, issuance, and monitoring run for the length of the migration, so each one either has automation behind it or becomes a permanent draw on engineering time that nobody budgeted for.
• Risk: Reissuing certificates at scale is when outages happen. Automated issuance with validation removes the manual steps where mistakes occur, which keeps the work inside normal maintenance windows.
• Future changes: NIST is still developing additional post-quantum standards as backups and alternatives, and its dates for retiring today’s algorithms sit in an initial public draft. Crypto-agility means each of those changes becomes a policy update, which only holds where automation is already running.

How certificate automation supports PQC migration

Six points, each answering a question the migration will ask you.:

1. Discover every certificate (What do we actually have?)

Automated discovery runs on a schedule across every environment, repeating for the length of the migration. Certificates are issued every day across cloud accounts, container platforms, and build pipelines, so a scan taken six months ago describes an estate that has already changed.

Certificate discovery pairs scheduled network scanning with certificate authority integrations and cloud API access, which is what surfaces internal certificates, service mesh identities, and keys held in cloud key stores. Discovery is where most of the gap between what teams think they have and what they actually have tends to sit.

2. Build a live inventory (What is each certificate made of, and what breaks if it changes?)

The inventory records algorithm, key size, expiry date, issuing certificate authority, owner, and dependent systems, and updates itself as certificates are issued and retired. That record is a cryptographic bill of materials.

EO 14412 also directs CISA and NIST to publish minimum elements for a cryptographic bill of materials, with the stated requirement that those elements enable automated assessment of cryptographic assets. The guidance is due around March 2027, and the phrasing is worth noting: the expectation is machine-readable, not a document.

The inventory has to be searchable by algorithm. When ML-DSA issuance becomes available for a given use case, or a classical algorithm is deprecated, the question is which certificates are affected and what depends on them.

3. Set issuance policy (What should new certificates look like, without anyone deciding case by case?)

Policy decides what gets issued and to whom, so every new certificate inherits the right algorithm, key size, validity period, and issuing certificate authority automatically. Systems protecting data with the longest confidentiality requirements move to post-quantum algorithms first, external services follow, and long-lived embedded systems get their own track.

Hybrid certificates are set here too. Pairing a classical algorithm with a post-quantum one in a single certificate keeps legacy applications working and defining it as policy means the choice is made once and applied everywhere.

4. Connect certificate authorities and hardware security modules (Can we even issue what the policy asks for?)

You can only issue a certificate using an algorithm your certificate authority supports, and the authorities are not all moving at the same speed. The CA/Browser Forum TLS Baseline Requirements do not yet permit ML-DSA in publicly trusted certificates, no ML-DSA root has been accepted into the major browser trust stores, and the ballot to change that is still in revision.

Private PKI has no such dependency. Post-quantum certificates can be issued internally today, which is why internal mTLS, code signing, and service mesh identities are where most real migration work is happening right now. Automation removes that as a constraint. Requests go to the automation platform, and the platform decides which certificate authority issues the certificate. Switching to one that supports post-quantum algorithms becomes a configuration change. Hardware security modules need the same check, since they need firmware that supports ML-DSA.

5. Streamline issuance and deployment (How does the certificate get onto the system that presents it, again and again?)

A certificate does nothing until it is installed. Getting it from the certificate authority onto the load balancer, the Kubernetes cluster, or the application server is deployment, and doing that again before it expires is renewal. Both are manual steps in most environments, and both are where post-quantum migration multiplies the work.

Size is the reason to test before you deploy. Post-quantum signatures are considerably larger than elliptic curve ones, which increases certificate size and TLS handshake payloads, so constrained devices and older load balancers need testing before they receive one. Automation handles that as a phased rollout, with validation at each step and a defined rollback.

6. Monitor and report (Where does the migration actually stand?)

Monitoring tracks expiry, flags certificates still using deprecated algorithms, and reports migration progress against the estate. Percentage of the estate on post-quantum or hybrid algorithms, segmented by business unit, is the number a board will ask for and the one a procurement questionnaire will eventually want evidence of.

Very little of this ends in a pure post-quantum certificate in 2026. Public TLS cannot get there yet, HSM firmware support is uneven, and constrained devices will not accept the payload sizes. The work that is available right now is discovery, live inventory, private PKI, hybrid issuance, and getting renewal off manual processes. Every one of those is a prerequisite for the work that comes later. Organizations that do the work now will be able to move when the ecosystem does. Organizations that wait for the ecosystem will start their inventory in 2029.

How AppViewX delivers certificate automation for PQC migration

The AppViewX platform handles discovery, inventory, policy, issuance, renewal, and reporting from one place, on top of the PKI it already runs for certificate lifecycle management.

• Hybrid composite certificates. A single certificate carrying both a classical algorithm, RSA or ECC, alongside the post-quantum, ML-DSA. Legacy applications validate the classical component and keep working. Quantum-capable systems validate the post-quantum one. Nothing has to be replaced before migration starts.
• Full hierarchy support: Post-quantum algorithms are available for root, intermediate, and end-entity certificates, so the whole chain can migrate.
• Post-quantum during PKI modernization: Organizations replacing Active Directory Certificate Services can turn on post-quantum algorithms as part of that same project instead of running two migrations.
• Agility built into policy: Algorithms and certificate authorities change centrally, so the applications requesting certificates are never touched.