Post-Quantum Cryptography Migration: Why Infrastructure Beats Algorithms

Part of the Certificate Intelligence Implementation Hub

The transition to post-quantum cryptography (PQC) isn't primarily a cryptography problem—it's an infrastructure problem. Organizations fixated on algorithm selection miss the real challenge: building the operational capability to switch cryptographic algorithms without disrupting business operations. If you can't change certificates quickly and safely today, you won't be ready for mandatory PQC migration by 2030.

Executive Summary

The quantum computing threat to current encryption is real, with NIST estimating that large-scale quantum computers capable of breaking RSA and ECC encryption could emerge within 10-15 years. Federal mandates already require migration planning, with hard deadlines approaching for government contractors and regulated industries.

But here's what most organizations get wrong: They treat PQC migration as a one-time algorithm upgrade project—select new algorithms, replace certificates, done. This approach fails because:

1. Algorithm uncertainty remains - Even NIST's newly standardized algorithms may need replacement if cryptanalytic advances occur
2. Hybrid certificates are temporary - You'll run both classical and quantum-safe algorithms during transition, then need to remove classical
3. Efficient truststore updates - you need to establish new long-term root certification authorities - something you haven't done yet as yours is probably valid for 20-30 years
4. Continuous evolution - PQC isn't the endpoint; it's the first of many mandatory algorithm transitions

The real challenge: Building agility across the whole of certificate lifecycle: trust stores, client software, revocation checks. All these aspects need to be automated for your operational capability to change cryptographic algorithms across your entire certificate infrastructure in days or weeks, not years.

Cost of getting this wrong: Organizations that treat PQC as a one-time migration will likely wait till the last moment - making the change incredibly expensive with a high business risk - or re-doing it 2-3 times as new standards settle down. Organizations that build crypto-agile infrastructure can manage PQC transition as an operational task, with minimum capex / project expenditure.

Timeline: Federal contractors face 2027-2030 deadlines. Financial services regulations expected 2028-2032. Everyone else should start planning now—3-5 year migrations are realistic for large enterprises.

Practice: Organizations that have automation in place can practice PQC transitions in advance, with small-to-none impact. Changing a root CA (certification authority) is operationally identical. Let's be honest - how many people know which algorithms and trust stores you use now - it's a technical detail.

What You'll Learn in This Guide

For Engineering Leaders & CTOs

The Crypto-Agility Imperative

After implementing PKI transformations at major financial institutions and rescuing failed migrations, I've learned this: the organizations that struggle with PQC migration are the same ones that struggle with certificate renewals today.

If renewing 100 certificates in your production environment requires:

• 3 weeks of planning
• Change management approvals
• Manual coordination across 5 teams
• Testing in isolated staging environments
• Weekend deployment windows

Then migrating to post-quantum algorithms will require that same overhead—multiplied by every certificate in your infrastructure. For organizations managing 50,000+ certificates, this becomes impossible.

The uncomfortable truth: PQC migration is forcing organizations to confront infrastructure debt they've been deferring for years.

What Crypto-Agility Actually Means

Crypto-agility isn't about having multiple CAs or supporting different key sizes. It's the operational capability to answer "yes" to these questions:

Discovery & Inventory:

• Can you identify every certificate in your infrastructure within 24 hours?
• Do you know which applications will break if you change certificate algorithms?
• Can you map certificate dependencies across hybrid and multi-cloud environments?
• Do you know owners of those applications?

Deployment Capability:

• Can you deploy new certificates to production without service downtime?
• Do your automation systems support protocol-based certificate enrollment (ACME, or less efficient ones: SCEP, EST)?
• Can you switch between certificate authorities without modifying application code?

Operational Readiness:

• Do your teams have runbooks for certificate authority migration?
• Can you test algorithm changes in production-like environments? (you can work with RSA v ECC today - changes can easily break your applications now)
• Do you have rollback procedures if new algorithms cause compatibility issues?

Governance & Compliance:

• Can you prove which algorithms are deployed where for audit purposes?
• Do you have approval workflows for algorithm policy changes?
• Can you report on migration progress to regulators?

Most organizations answer "no" to most of these questions. That's not a PQC problem—that's an infrastructure maturity problem that PQC migration will expose painfully.

The Algorithm Switch Is the Easy Part

Here's what surprises executives: Switching from RSA to ML-DSA (NIST's post-quantum signature algorithm) takes 30 seconds—if you have the infrastructure.

The actual algorithm change in a certificate authority configuration:

That's it. The cryptographic primitives are well-understood, standardized, and increasingly supported in commercial PKI vendors.

What takes 3-5 years:

• Discovering the 47,000 certificates you didn't know existed
• Identifying which legacy applications can't parse post-quantum certificates
• Building automation to deploy certificates without manual intervention
• Migrating applications from hard-coded certificate paths to automated enrollment
• Creating centralized trust stores instead of scattered root CA installations
• Implementing certificate monitoring so you know what's actually deployed
• Training teams on protocols (ACME, SCEP, EST) instead of manual processes
• Testing algorithm changes without breaking production services

The brutal math: If you have 50,000 certificates and each requires 12 hours of manual effort to migrate (discovery, testing, approval, deployment), that's 600,000 person-hours = 288 FTEs working full-time for one year.

Automation reduces this to 50 FTEs for 3-4 months—but only if you build the automation capability BEFORE the deadline.

Why Traditional PKI Vendors Create Lock-In

Most commercial PKI vendors will happily sell you post-quantum capable certificate authorities. What they won't tell you: their architecture creates vendor lock-in that makes future algorithm changes equally expensive.

The vendor lock-in pattern:

1. Proprietary enrollment clients - Applications use vendor-specific agents/SDKs for certificate requests
2. Embedded CA certificates - Applications have vendor's root CA hard-coded in trust stores
3. Custom protocols - Certificate renewal uses vendor APIs instead of standard protocols
4. Siloed management - Each CA vendor requires separate management platform

What this means for PQC migration:

• Switching to PQC-capable vendor = migrate every application to new vendor's client
• Testing new algorithms = deploy vendor's updated client software enterprise-wide
• Future algorithm change = repeat full migration to different vendor or version

You don't have a crypto-agility problem—you have a vendor lock-in problem that PQC migration exposes.

The Infrastructure You Actually Need

Based on implementations at major UK banks and Fortune 500 enterprises, crypto-agility requires three infrastructure components:

1. Protocol Abstraction Layer

Applications must request certificates using standard protocols (ACME) or a lightweight RESTful API calls that require zero dependencies, not vendor-specific APIs. This decouples application code from certificate authority implementation.

This layer must be transactional, automated, API-based. It MUST integrate with your Configuration Management Database (CMDB), where you manage owners, applications, change management, etc.

With protocol abstraction:

• Application: "I need a certificate for app.example.com" (via ACME)
• Abstraction layer: Routes to appropriate CA based on policy
• Backend CA: Can be any vendor, can change anytime, application doesn't know or care

Without protocol abstraction:

Multiply the below with the number of your certificate clients.

• Application: Hard-coded to "Vendor A's API for app.example.com certificates"
• Algorithm change: Update application code, redeploy, hope nothing breaks
• Vendor change: Rewrite integration, full regression testing, high-risk migration

2. Centralized Trust Store Management

Applications must retrieve trusted root CAs from central repositories, not have them embedded in application packages or OS images. It is ONE centralized, reference distribution point that anyone can pull up-to-date list of all trusted certification authorities at any time.

With centralized trust:

• New quantum-safe root CA: Add to central repository - your reference distribution point
• Applications: Automatically trust new roots on next sync or CI/CD pipeline execution (minutes to days)
• Rollback: Remove from repository if issues detected

Without centralized trust:

I've seen a 3 year program to replace a root CA and it was still marked as "high risk", despite the company having strong in-house engineering teams. The main reason: engineering teams had no idea about the processes and usage.

• New root CA: Manually update every application, container image, VM template
• Timeline: Months to reach all systems
• Audit: Impossible to verify what's actually trusted where

3. Curated Automation Clients

Certificate enrollment must use well-tested, standardized clients (certbot, ACME clients, SCEP/EST libraries), not custom-built per-application solutions.

With curated clients:

Clients are built so they regularly check for new version and self-update.

• PQC algorithm support: Update client library, applications inherit automatically
• Policy changes: Modify client configuration centrally
• Security patches: Update client once, protect all consumers

While you can do other common cyber security tasks: code review, security analysis, protection from attacks on upstream repository.

Without curated clients:

• 47 different "certificate fetching scripts" across applications
• Each needs individual update for algorithm changes
• Testing burden: 47 different implementations × all certificate types × all scenarios

This Is Why We Built CertBridge

After rescuing yet another failed PKI migration—where a major UK company spent 2 years to build a migration architecture that was leaky as a pasta sieve we realized why companies end up in the situation where their barely turns positive.

They try to hire people with skills that cover a number of technologies they need to integrate. The assumption is that they need them long-term. Nothing is further from truth - what you need is experts on operations - supporting users, understanding your engineering needs. What we regularly see is the budget runs out before they realize this need.

The pattern across all failed migrations:

• Organizations chose a CA vendor first (usually based on sales pitch or analyst report)
• Vendor's architecture required proprietary clients and tight integration
• Migration became "rip out old vendor, install new vendor"
• Massive disruption, extended timeline, high failure risk
• Even if successful: locked into new vendor, same problem repeats for next change

CertBridge solves this by inverting the architecture:

1. Deploy protocol abstraction in customer's infrastructure (AWS account, their control)
2. Applications talk to CertBridge using standard protocols (ACME, SCEP, EST)
3. CertBridge routes to backend CAs based on policy (can be any vendor, can change anytime)
4. Algorithm changes become routing decisions, not application changes

For PQC migration:

• Deploy CertBridge today using existing CAs as backends
• Migrate applications to protocol-based enrollment (ACME, SCEP, EST, simple RESTful protocol)
• When ready for PQC: Add quantum-safe CA as backend, route hybrid certificates
• Applications don't change—they request certificates the same way
• Test algorithm changes by routing subset of traffic to PQC-capable backend
• Roll back algorithm changes by reverting routing policy

The economic difference:

• Traditional migration to PQC-capable vendor: $3M-$8M, 24-36 months
• CertBridge with PQC backend routing: $400K-$1.2M implementation, then algorithm changes are policy updates

More importantly: Every future algorithm change follows the same pattern—add new backend, update routing policy, done. You're not just solving PQC; you're solving crypto-agility permanently.

Migration Strategy Overview

Federal Mandate Timeline

NIST SP 800-208 requires federal agencies and contractors to:

• By 2025: Complete inventory of cryptographic systems
• By 2027: Begin migrating to post-quantum algorithms
• By 2030: Complete migration for classified systems
• By 2035: Full migration including legacy systems

Financial services and critical infrastructure expected to follow similar timelines, with regulations likely finalized 2026-2028.

Realistic Enterprise Timeline

Based on actual enterprise PKI transformations, you have 2 options. Go slow or agile.

The slow approach - like the timeline below - works, the problem is that there's no pressure on your teams to automate any of the tasks. If you have 15 months to do certificate discovery, nothing will happen first 10 months. As it a) simply is not priority, b) your team is busy with other things, c) they 'kind of' already know the answer: "It's not good".

Year 1: Infrastructure Assessment & Capability Building (12-18 months)

• Complete certificate inventory (typically discover 3-5x more certificates than expected)
• Assess application compatibility with post-quantum algorithms
• Build protocol abstraction layer (CertBridge deployment)
• Migrate applications from manual enrollment to automated protocols
• Establish centralized trust store management
• Train teams on crypto-agility operations

Year 2: Hybrid Certificate Deployment (12-18 months)

• Deploy hybrid certificates (classical + quantum-safe) to non-production
• Test application compatibility, identify issues
• Gradual production rollout by application criticality (low → high)
• Monitor for performance impacts (PQC signatures are larger)
• Refine rollback procedures

Year 3: Classical Algorithm Removal (12-18 months)

• Remove classical algorithms from hybrid certificates
• Full quantum-safe deployment
• Decommission legacy systems that can't support PQC
• Compliance validation and audit evidence collection

Total: 36-54 months for large enterprises (50,000+ certificates)

We install and make CertBridge available at the beginning. This means that you can not only 'assess' but also fix/improve at the same time. In terms of the schedule above, you can execute Assessment and Deployment at the same time. You get the automation in place.

Investment Required

Infrastructure-first approach (builds long-term crypto-agility):

• Initial implementation: $800K-$2.5M (varies by certificate count, complexity)
• Annual operations: $150K-$400K
• Future algorithm transitions: <$200K (policy/routing changes)

Algorithm-first approach (solves PQC only):

• Initial PQC migration: $3M-$8M
• Annual operations: $500K-$1.2M
• Next algorithm transition: Another $3M-$8M project

The infrastructure investment pays for itself on the second algorithm transition—and there will be more than one.

Technical Deep Dive: Infrastructure Components

For engineering teams implementing crypto-agility

Protocol Abstraction Architecture

Traditional PKI architecture tightly couples applications to certificate authorities:

This creates brittle dependencies where algorithm changes require application modifications.

Protocol abstraction decouples applications from CA implementation:

Key insight: Applications request certificates by proving control of identifiers (domain ownership, device identity), not by choosing CAs. The abstraction layer makes routing decisions based on policy.

For PQC migration:

Algorithm changes don't touch application code—they're policy changes in the routing layer.

Centralized Trust Store Management

Problem: Applications typically bundle trusted root CAs in three ways:

• OS trust store (Windows, Linux, macOS)
• Language-specific trust store (Java keystore, Python certifi)
• Application-embedded certificates (hard-coded PEM files)

All three create operational problems for algorithm transitions:

• OS trust stores require system updates (slow, requires reboots)
• Language trust stores require application redeployment
• Embedded certificates require code changes

Solution: Applications retrieve trusted roots from central repository at runtime or using scheduled tasks.

Implementation pattern:

For PQC migration:

• Day 1: Add hybrid root CA to repository
• Hours 1-24: Applications automatically trust hybrid certificates
• No application changes, no redeployment, no change windows

Automated Certificate Monitoring

You can't manage what you can't see. Crypto-agility requires real-time visibility into:

Certificate inventory:

• What algorithms are deployed where?
• Which certificates are hybrid (classical + PQC) vs. classical-only?
• Migration progress: % of infrastructure on quantum-safe algorithms

Application behavior:

• Which applications are requesting which certificate types?
• Are applications successfully validating post-quantum signatures?
• Performance impacts: Are PQC certificates causing latency issues?

Trust chain verification:

• Are applications trusting the correct root CAs?
• Which applications are still using classical-only trust chains?
• OCSP/CRL monitoring: Are revocation checks working with PQC?

Implementation via CMDB integration:

CertBridge integrates with configuration management databases to provide continuous discovery:

• Network scanning identifies active certificates
• Application metadata links certificates to owners and business services
• Algorithm reporting tracks migration progress
• Automated alerts flag non-compliant deployments

CertBridge Architecture for PQC Migration

Core design principle: Protocol abstraction deployed in customer's infrastructure (AWS account) to eliminate vendor lock-in and enable algorithm agility.

Architecture components:

1. ACME/SCEP/EST endpoints (serverless AWS Lambda)
   • Applications connect via standard protocols
   • Protocol translation to backend CA APIs
   • Policy enforcement: routing decisions based on certificate type, application identity, compliance requirements
2. Backend CA integrations (pluggable)
   • Public CAs: Let's Encrypt, DigiCert, Sectigo, etc.
   • Private CAs: AWS Private CA, Microsoft AD CS, Google Certificate Authority Service
   • Post-quantum CAs: Any vendor implementing NIST PQC standards
   • Multiple backends active simultaneously
3. Policy engine (DynamoDB + Lambda)
   • Route certificate requests based on:
     • Certificate type (TLS, code signing, S/MIME)
     • Algorithm requirements (RSA, hybrid, PQC-only)
     • Application classification (dev/test/prod, criticality tier)
     • Compliance requirements (regulated vs. non-regulated)
   • Policy changes propagate within seconds
4. CMDB integration (event-driven)
   • Certificate issuance events published to customer's asset management
   • Automatic inventory reconciliation
   • Ownership assignment based on application metadata
   • Lifecycle tracking: issuance → renewal → revocation

PQC migration workflow:

Phase 1: Deploy CertBridge with existing CAs

• Week 1: CertBridge deployed in customer's AWS account (UK/US/EU region based on requirements)
• Week 2-8: CMDB integration, continuous discovery running
• Month 2-6: Applications migrate to ACME/SCEP/EST enrollment (gradual, non-breaking)
• Result: Protocol abstraction operational, applications decoupled from CA choice

Phase 2: Add hybrid CA backend

• Day 1: Configure hybrid CA (classical + PQC) as CertBridge backend
• Policy: Route test applications to hybrid CA
• Week 1-4: Test compatibility, identify issues
• Month 2-6: Gradual production rollout via policy changes
• Result: Hybrid certificates deployed without application changes

Phase 3: Transition to PQC-only

• Policy change: Route new certificates to PQC-only backend
• Gradual rollout: Test → non-prod → low-criticality prod → high-criticality prod
• Classical certificates expire naturally over 90-365 days
• Result: Full post-quantum deployment, classical algorithms removed

Phase 4: Next algorithm transition

• Future: NIST announces ML-DSA-87 (larger key size) required
• Action: Add new backend with ML-DSA-87, update routing policy
• Timeline: Weeks, not years
• Cost: <$200K (policy change, no application work)

Key advantages:

1. Customer owns infrastructure: CertBridge runs in customer's AWS account, not Axon Shield's. Customer controls data, encryption keys, access policies.
2. No vendor lock-in: Backend CAs are interchangeable. Switching from Vendor A to Vendor B is a routing policy change, not a migration project.
3. Incremental testing: Route 1% of traffic to new algorithm, measure impact, roll back if needed. Traditional approaches are "all or nothing."
4. Compliance benefits: Data sovereignty maintained (UK region for UK banks, etc.). Audit trail shows exactly which algorithms are deployed where.
5. Cost optimization: Route low-value certificates to Let's Encrypt ($0), high-value to commercial CA. Algorithm choice independent of cost optimization.

Common Objections & Responses

"We'll just upgrade our existing PKI vendor to PQC-capable version"

Why this fails:

Vendor upgrades typically require:

• New client software deployed to all certificate-consuming applications
• Updated trust roots installed enterprise-wide
• Testing every application against new client/server combination
• Vendor's timeline (often 12-24 month upgrade cycle)
• Vendor lock-in persists—next algorithm change repeats this process

Infrastructure approach:

• Applications already use protocol-based enrollment
• Backend CA upgrade is transparent to applications
• Add new PQC-capable CA as backend, route traffic via policy
• Test incrementally, roll back if issues
• Same pattern works for any future algorithm

"Post-quantum algorithms might change, why invest now?"

Exactly the point: Algorithm uncertainty is why you need crypto-agility.

NIST standardized ML-KEM, ML-DSA, and SLH-DSA in August 2024. But:

• Cryptanalytic advances could weaken these algorithms
• Performance considerations might favor different algorithms
• Quantum computing progress might accelerate timeline

If you build vendor-locked, algorithm-specific infrastructure:

• Each algorithm change is a multi-million dollar migration
• You're betting that NIST's current choices are final
• High switching costs create resistance to necessary security updates

If you build crypto-agile infrastructure:

• Algorithm changes are policy updates, not migrations
• You can adopt new algorithms as soon as they're available
• Low switching costs encourage proactive security posture

"Our vendors say they'll handle PQC migration for us"

What vendors actually handle:

• Their CA software supporting post-quantum algorithms
• Maybe: client library updates to request PQC certificates

What vendors don't handle (your responsibility):

• Discovering all certificates in your infrastructure
• Testing application compatibility with larger PQC certificates/signatures
• Migrating from manual to automated certificate enrollment
• Building centralized trust store management
• Training your teams on new operational procedures
• Compliance evidence collection for auditors

The algorithm is 5% of the work. Infrastructure is 95%.

"We're a Microsoft shop, won't AD CS handle this?"

Microsoft AD CS will absolutely support post-quantum algorithms. But:

AD CS doesn't solve:

• Discovery of certificates outside Active Directory
• Applications using non-Windows certificate stores
• Cloud workloads (AWS, Azure, GCP) using different PKIs
• Code signing and S/MIME certificates not in AD CS
• Hybrid CA deployments during transition
• Vendor interoperability (applications trusting multiple CAs)

You still need:

• Protocol abstraction for non-AD-CS certificates
• Centralized trust management across heterogeneous environments
• Monitoring and compliance reporting across all certificate sources

AD CS is a component, not a complete solution.

Getting Started

1. Assess Current State

Key questions to answer:

• How many certificates do you actually have? (Most organizations discover 3-5x more than expected)
• How are applications requesting certificates today? (Manual, vendor APIs, or protocols)
• Do you have centralized trust store management?
• Can you monitor what algorithms are deployed where?

2. Understand Timeline & Requirements

Determine:

• Are you subject to federal mandates? (Government contractor, critical infrastructure)
• What's your industry's expected compliance timeline?
• Do you handle long-lived sensitive data? ("Harvest now, decrypt later" threat)

3. Build Migration Strategy

Realistic planning:

• 3-5 year timeline for large enterprises
• Infrastructure-first approach (build automation, then migrate algorithms)
• Incremental rollout (test → non-prod → prod-low → prod-high)

Want Expert Help?

We've implemented crypto-agile PKI architectures at major UK banks, preparing them for post-quantum migration while eliminating vendor lock-in.

What we provide:

• Crypto-agility assessment (current state, gap analysis, 3-5 year roadmap)
• CertBridge implementation (protocol abstraction deployed in your infrastructure)
• Migration strategy development (hybrid certificates, phased rollout)
• Team training (ACME/SCEP/EST protocols, operational procedures)

What makes us different:

• Infrastructure-first approach (algorithm changes become easy after infrastructure is right)
• No vendor partnerships (we help you choose best backends for your needs)
• Customer owns everything (your AWS account, your data, your control)
• Post-quantum ready: CertBridge already supports hybrid certificates

Contact us for a crypto-agility assessment

We'll honestly tell you whether your current infrastructure is ready for PQC, or if you need to build automation capabilities first.

Related Resources

References

1. National Institute of Standards and Technology (NIST). (2024). Post-Quantum Cryptography Standards: ML-KEM, ML-DSA, SLH-DSA.
2. NIST. (2024). SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes.
3. National Security Agency (NSA). (2022). Quantum Computing and Post-Quantum Cryptography FAQ.
4. European Telecommunications Standards Institute (ETSI). (2024). Quantum-Safe Cryptography Guidelines.
5. Moody, D. et al. (2024). Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process. NIST.