PQC Migration Strategy: Why Post-Quantum Exposes Your Operational PKI Failure

Part of the Post-Quantum PKI Migration Guide

The uncomfortable truth: Post-quantum cryptography doesn't create a new problem. It exposes the operational PKI failure you've been paying for — invisibly — for years. Organisations that can't reliably renew 100 certificates without manual heroics will not migrate 50,000 to quantum-resistant algorithms on any timeline. The hard part isn't switching from RSA to ML-DSA. It's building the automation, ownership, and lifecycle discipline that makes switching trivial. This page explains why, and what to do about it.

The Problem PQC Actually Reveals

Every organisation running PKI at scale pays an invisible infrastructure tax — a hidden operational cost that compounds silently until it becomes an outage, a compliance finding, or a breach. You pay this tax through:

• Engineering hours firefighting expired certificates at 3AM
• Audit failures from undocumented or rogue certificates
• Outages caused by certificates issued outside governance frameworks
• Security exposure from long-lived, unrotated credentials

The tax is invisible because it's distributed — no single line item captures the true cost. But it's real. The pattern is the same everywhere.

Now add post-quantum migration to that picture.

CNSA 2.0 mandates PQC for classified systems by 2030. Financial services regulators are targeting 2028–2032. State-sponsored actors are already harvesting your encrypted traffic to decrypt when quantum computers mature. The timeline is not theoretical.

And every certificate in your infrastructure — every TLS cert, code-signing key, Vault secret, mTLS credential — needs to transition. If your operational processes can't handle routine renewals without manual coordination, PQC migration at scale is impossible.

PQC doesn't break your PKI. It reveals that your PKI was already broken.

The Certificate-Industrial Complex Has It Backwards

The dominant vendor ecosystem — large CA providers, ITSM integrations, certificate management platforms — profits from complexity, not clarity. They have a structural incentive to make PQC migration appear more opaque than it is, creating dependency and recurring licence revenue.

Most Organisations Focus on the Wrong Question

What executives ask: "Which post-quantum algorithm should we deploy?"

What actually determines success: "Can we change algorithms without rearchitecting our infrastructure?"

The cryptographic primitives work. ML-KEM and ML-DSA are standardised and well-understood. Commercial PKI vendors support them. The algorithm is the solved part.

What's actually hard:

• Discovering the 47,000 certificates you didn't know existed (typical: 3–5x more than estimated)
• Migrating from manual certificate requests to automated protocols
• Building trust store management that works across 200+ applications
• Testing compatibility without breaking production at 3AM on a Sunday
• Training teams on protocols they've never used (ACME, SCEP, EST)

Vendors sell you discovery tools because you don't know what certificates you have — but the real failure is the absence of operational discipline, not the absence of a scanner. Managed PKI services abstract control away from you — but control is exactly what mature security posture requires. Automation platforms are positioned as end-states — but automation applied to a broken process produces a faster broken process.

The brutal reality: If renewing 100 certificates in production requires 3 weeks of planning and manual coordination, then migrating 50,000 certificates to post-quantum algorithms is impossible on federal timelines. No amount of tooling changes that.

Three PQC Migration Approaches (Only One Works)

Organisations pursue PQC migration through three patterns. Two fail predictably. One succeeds — because it solves the operational problem first.

Approach 1: Algorithm-First (Fails 80% of the Time)

1. Select PQC-capable CA vendor
2. Discover vendor requires new client software/APIs
3. Realise applications are tightly coupled to old vendor
4. Spend 18–24 months rearchitecting integrations
5. Miss deadline, exceed budget by 2–4x

Why it fails: Optimises for algorithm choice while ignoring infrastructure reality. Vendor lock-in creates multi-million dollar switching costs. You've bought a faster broken process.

Cost: $5M–$8M for PQC migration + $5M–$8M for the next algorithm change

Approach 2: Vendor-First (Fails 60% of the Time)

1. Evaluate PQC-capable vendors (RFP, demos, POCs)
2. Select "best" vendor based on features/price
3. Discover vendor's architecture requires application changes
4. Application teams resist changes (other priorities, risk aversion)
5. Migration stalls at partial deployment, mixed infrastructure

Why it fails: Vendor selection before understanding operational requirements. Creates lock-in that makes future changes equally expensive. The certificate-industrial complex's preferred outcome.

Cost: $3M–$6M for PQC migration + ongoing vendor lock-in costs

Approach 3: Infrastructure-First (Succeeds 90% of the Time)

1. Build protocol abstraction (applications decoupled from CA choice)
2. Migrate applications to automated enrolment (ACME - with residual use-cases integrated with SCEP, EST)
3. Deploy centralised trust management
4. Add PQC-capable CA as backend (a routing decision, not a migration)
5. Algorithm changes become policy updates — no application deployments

Why it succeeds: It solves the operational problem first. CA vendor choice becomes secondary — switch vendors via routing policy, not $2M migration projects. Automation on a sound process produces a faster sound process.

Cost: $800K–$2.5M for infrastructure + $200K–$400K for PQC deployment + <$200K for every future algorithm change

This is why we built the 3AM platform. After rescuing 7 failed PQC/PKI migrations — at organisations running 8,000 to 250,000 certificates — we saw the same pattern. The industry's approach was fundamentally broken. Organisations need protocol abstraction and operational ownership before algorithm migration. Not after. Not alongside. Before.

Timeline Reality: What Starting in 2025 Actually Looks Like

Federal deadline: 2030 for classified systems, 2035 for all federal infrastructure

Financial services/healthcare: 2028–2032

Other industries: 2032, under board/regulator pressure

For detailed mandate analysis: PQC Timeline & Mandates →

Infrastructure-First Timeline (Starting 2025)

• 2025–2027: Build crypto-agility — protocol abstraction, automation, trust management, operational discipline
• 2027–2029: Deploy PQC algorithms incrementally via policy
• 2029–2030: Finalise transition, compliance validation
• Result: Deadline met comfortably. Low risk. No 3AM crises.

Algorithm-First Timeline (Starting 2025)

• 2025–2026: Vendor selection, contract negotiations
• 2026–2028: Discover vendor architecture requires application changes
• 2028–2030: Frantically rearchitect integrations
• Result: High stress, likely miss deadline or cut corners. 3AM becomes your normal.

The difference: Starting with infrastructure gives 2–3 years of learning and iteration. Starting with algorithms gives 6–12 months of crisis management.

10-Year Cost Comparison

Infrastructure-First (3AM platform)

• Year 1: Infrastructure implementation — $1.2M
• Year 2: PQC deployment — $300K
• Years 3–5: Operations — $200K/year = $600K
• Year 6: Next algorithm change — $150K
• Years 7–10: Operations — $200K/year = $800K
• 10-year total: $3.05M

Algorithm-First (Traditional)

• Years 1–2: PQC vendor migration — $5.5M
• Years 3–5: Operations — $500K/year = $1.5M
• Years 6–7: Next algorithm migration — $5M
• Years 8–10: Operations — $500K/year = $1.5M
• 10-year total: $13.5M

Savings: $10.45M over 10 years by building crypto-agility once instead of repeating vendor migrations. And the next algorithm change — because there will be one — costs under $200K instead of $5M+.

The Infrastructure-First PQC Migration Strategy

For engineering leaders and CISOs who need to present a credible plan to the board — grounded in real implementation data, not vendor marketing.

Phase 1: Make the Invisible Visible (Months 1–18)

Objective: Understand the true state of your certificate estate, quantify the invisible infrastructure tax, and build the missing operational capabilities.

Months 1–3: Discovery & Inventory

Complete certificate discovery — and prepare to be surprised:

• Network scanning for TLS certificates (public-facing and internal)
• Application inventory for embedded certificates
• Code signing and S/MIME certificate discovery
• IoT and device certificates
• Typical finding: 3–5× more certificates than initially estimated

Dependency mapping:

• Which applications trust which Certificate Authorities?
• Which applications are hard-coded to specific CA vendors?
• What happens if you change trust stores?
• What is the blast radius of CA changes?

This is where most organisations first see the invisible infrastructure tax in concrete terms. At one major internet company, the estimate was 8,000 certificates. Discovery found 23,000. That 3× undercount is the tax made visible.

Deliverable: Complete certificate inventory with dependency map

Months 4–6: Capability Gap Analysis

Assess current operational maturity:

• How are certificates requested? (Manual forms, vendor APIs, or standard protocols)
• How are certificates renewed? (Manual tracking, automated alerts, fully automated)
• How are trust stores managed? (Embedded in apps, OS-level, centralised)
• How are certificate changes deployed? (Manual, orchestration, fully automated)

Identify gaps against crypto-agility requirements:

• What percentage of certificates depend on manual processes?
• How long to deploy a certificate change to production?
• Can you switch Certificate Authorities without application changes?
• Do you have monitoring and compliance reporting?

Deliverable: Gap analysis report with remediation priorities

Months 7–12: Architecture Design

Design the protocol abstraction layer:

• ACME endpoint for TLS certificates
• Simple RESTful integration protocol
• SCEP endpoint for Microsoft AD integration
• EST endpoint where required
• Backend CA routing based on certificate type and policy

Select deployment approach:

Option A: Build In-House

• Full control, no vendor dependencies
• 12–18 months development, ongoing maintenance burden
• Cost: $800K–$1.5M development + $200K–$400K annual maintenance
• Only for organisations with strong internal automation expertise

Option B: Deploy the 3AM (Our Recommendation)

• Proven architecture, deployed in your AWS account, 4–6 weeks implementation
• Axelspire implementation required — but you own everything after handover
• Cost: $400K–$1.2M implementation + $70K–$230K annual operations
• Best for organisations wanting crypto-agility without multi-year development

Option C: Vendor "Abstraction" Layer

• May be included with CA vendor licensing
• Still vendor-locked — the abstraction layer is the vendor
• Appears cheaper upfront, far more expensive long-term
• Avoid — this is vendor lock-in with extra steps

Deliverable: Architecture design, vendor contracts, implementation timeline

Months 13–18: Pilot Implementation

Deploy protocol abstraction to non-production:

• Set up ACME/SCEP/EST endpoints in staging environment
• Integrate with existing CA (no algorithm changes yet — that's the point)
• Migrate 10–20 pilot applications to protocol-based enrolment
• Test automation, monitoring, alerting
• Refine operational procedures and runbooks

Deliverable: Operational protocol abstraction in staging, ready for production

Phase 2: Build Operational Ownership (Months 19–36)

Objective: Decouple applications from CA vendor lock-in. Establish the governed, automated certificate lifecycle that makes algorithm changes routine.

Months 19–24: Production Pilot (20% of Applications)

Select pilot applications:

• Low-risk, non-critical applications first
• Applications with engaged teams willing to collaborate
• Mix of types (web apps, APIs, services) to test patterns
• Avoid high-risk production systems initially

Migration pattern per application:

1. Application requests certificate via ACME/SCEP/EST (not vendor API)
2. Protocol abstraction layer routes to backend CA
3. Certificate delivered automatically
4. Application deploys certificate with no manual steps
5. Renewal happens automatically 30–60 days before expiration

No heroics. No 3AM pages. No manual tracking spreadsheets. This is what operational ownership looks like.

Deliverable: 20% of applications using protocol-based enrolment

Months 25–30: Accelerated Rollout (Next 40%)

Apply lessons from pilot, scale migration:

• Target 40–60% total coverage by month 30
• Focus on applications with active development teams
• Defer legacy systems to later phase
• Maintain velocity: 20–40 applications per month
• Refine runbooks and documentation with each batch

This is where the invisible infrastructure tax starts dropping measurably. Engineering hours spent on certificate firefighting decline. Audit evidence generates itself. The CISO starts getting dashboards instead of incident reports.

Deliverable: 60% of applications using automated enrolment

Months 31–36: Final Migration (Remaining 40%)

Handle the challenging cases:

• Legacy applications requiring custom integration
• Vendor-locked applications needing workarounds
• High-risk production systems needing extra testing
• Applications maintained by external contractors

Decommission decisions — because not everything should be migrated:

• Some legacy systems cannot be migrated cost-effectively
• Options: isolate on separate network, accept classical-only algorithms, or decommission
• Business case required for each legacy exception
• Document everything — compliance auditors will ask

Deliverable: 90%+ of certificates using automated enrolment (remaining 10% documented as legacy exceptions with clear risk acceptance)

What you now have: A governed, automated, auditable certificate lifecycle. Applications request certificates via standard protocols. Renewals happen without human intervention. You own the infrastructure. No vendor controls your operational capability. And critically — you haven't changed a single algorithm yet. That's the point. The operational transformation is the product. PQC is just the next policy update.

Phase 3: Deploy Post-Quantum Algorithms (Months 37–54)

Objective: Deploy PQC algorithms using the crypto-agile infrastructure you now own. This phase is straightforward because the hard work is done.

With protocol abstraction operational, PQC deployment becomes what it should always have been: a routing decision.

Months 37–42: Hybrid Certificate Testing

Add hybrid CA (classical + PQC) as a 3AM backend:

• Configure 3AM to route to hybrid CA
• No application changes — applications still use ACME/SCEP/EST
• Policy determines which certificates get hybrid algorithms

Test in non-production:

• Deploy hybrid certificates to test environments
• Validate application compatibility (can they parse larger certificates?)
• Performance testing (CPU, memory, network impact)
• Trust chain validation

Identify compatibility issues early:

• Legacy applications unable to parse hybrid certificates
• Network appliances with certificate size limits
• Mobile apps with timeout issues on slow networks
• Document workarounds or isolate incompatible systems

Deliverable: Hybrid certificates validated in test, compatibility issues documented

Months 43–48: Production Hybrid Deployment

Gradual rollout by risk level — all via policy changes, not application deployments:

Low risk (Months 43–44):

• Internal tools, dev/test systems, non-customer-facing applications
• The 3AM routes 10–20% of certificates to hybrid CA
• Quick rollback if issues detected — change policy back

Medium risk (Months 45–46):

• Employee-facing applications, internal APIs and services
• The 3AM routes 40–60% of certificates to hybrid CA
• Business-critical but not customer-facing

High risk (Months 47–48):

• Customer-facing websites and APIs, revenue-critical applications
• Payment processing, authentication systems
• The 3AM routes 80–90% of certificates to hybrid CA

The rollout mechanism matters:

• Update routing policy: "Route certificates for [app group] to hybrid CA"
• Applications request certificates via ACME (same as before — they don't know anything changed)
• The 3AM returns hybrid certificate instead of classical
• Application deploys automatically (no human intervention)
• Rollback: change policy back to classical CA. Done.

Compare this to the algorithm-first approach: every application deployment requires a change window, risk assessment, rollback plan, and on-call engineer. That's why algorithm-first fails. Not because the cryptography is wrong — because the operations can't sustain it.

Deliverable: Hybrid certificates deployed to production, <5% exceptions

Months 49–54: Classical Algorithm Removal

Transition from hybrid to PQC-only:

• Month 49–50: Add PQC-only CA (ML-DSA, no RSA) as a 3AM backend
• Month 50–51: Route new certificates to PQC-only (existing hybrid certificates remain)
• Month 51–52: Hybrid certificates expire naturally (90-day lifespan)
• Month 52–53: 90%+ certificates are PQC-only
• Month 54: Classical algorithms deprecated, PQC becomes default

Why gradual works: Applications that can't support PQC-only become obvious during the hybrid phase. You can isolate or decommission before full transition — no surprises, no 3AM outages.

Deliverable: PQC-only deployment complete, federal/regulatory compliance achieved

Your 12-Month PQC Migration Playbook

The timeline above is 54 months for a complete, zero-risk migration. But if you're starting from a strong operational foundation (automated certificate lifecycle, ACME protocol, crypto-agility architecture), you can compress this to 12 months:

12-Month Accelerated PQC Migration (Starting from Operational Excellence)

Prerequisites: You must already have:

• Automated certificate lifecycle management (ACME protocol)
• Complete certificate inventory (no shadow IT)
• Protocol abstraction layer (or plan to deploy one)
• Hybrid certificate support in your infrastructure

Month 1-2: Assessment & Planning

• Audit current certificate infrastructure for PQC readiness
• Identify applications that can't support hybrid certificates
• Plan protocol abstraction layer deployment (if not already done)
• Select PQC algorithms (NIST recommendations: ML-DSA-65, ML-KEM-768)

Month 3-4: Infrastructure Deployment

• Deploy protocol abstraction layer (ACME/SCEP/EST endpoints)
• Integrate with existing CA infrastructure
• Deploy hybrid CA (supports both classical and PQC algorithms)
• Test with non-production certificates

Month 5-6: Pilot Deployment (10% of Certificates)

• Route 10% of new certificate requests to hybrid CA
• Monitor hybrid certificate performance
• Test renewal automation with hybrid certificates
• Validate client compatibility (browsers, APIs, devices)

Month 7-8: Accelerated Rollout (50% of Certificates)

• Route 50% of new certificate requests to hybrid CA
• Existing classical certificates renew as hybrid
• Monitor performance metrics and client compatibility
• Document any compatibility issues and workarounds

Month 9-10: Full Hybrid Deployment (100% of Certificates)

• All new certificates are hybrid (classical + PQC)
• Existing certificates renew as hybrid
• Monitor for any remaining compatibility issues
• Prepare for PQC-only transition

Month 11-12: PQC-Only Transition

• Deploy PQC-only CA (ML-DSA-65, no classical algorithms)
• Route new certificates to PQC-only CA
• Hybrid certificates expire naturally (90-day validity)
• Achieve PQC-only compliance by month 12

Key insight: Axelspire's platform already supports PQC-ready ACME flows. If you're using our infrastructure, you can start hybrid certificate deployment immediately — no waiting for vendor support.

Why 12 Months Works (When 54 Months Is Standard)

The 54-month timeline assumes you're starting from broken PKI operations. The 12-month timeline assumes you've already fixed the operational foundation:

• Automated renewal: No manual certificate management = faster iteration
• Complete visibility: No shadow IT = no surprises during migration
• Protocol abstraction: Algorithm changes are policy updates, not deployments
• Hybrid certificate support: Gradual transition without breaking changes

If you don't have these foundations, start with the 54-month timeline. If you do, 12 months is achievable.

Technical Deep Dive: How Protocol Abstraction Solves PQC Migration

For teams implementing the infrastructure-first approach

Why Tight Coupling Kills PQC Migration

Traditional PKI architecture creates direct coupling between applications and Certificate Authorities:

// Tightly coupled — every algorithm change requires code change
  CA_VENDOR_API.request_certificate(
    common_name = "app.example.com",
    api_key = VENDOR_API_KEY,
    algorithm = "RSA-2048"    // Hardcoded. PQC = code change + deployment.
  )

This is why PQC migration becomes a multi-million dollar project:

1. Algorithm is application configuration: Changing to ML-DSA-65 requires changing application code
2. Vendor lock-in: Application knows vendor API — can't switch without rewriting
3. No incremental testing: Can't route 10% to new algorithm to test safely
4. Deployment risk: Algorithm change = application deployment = change window = 3AM risk

Protocol abstraction eliminates every one of these problems:

// Decoupled — algorithm is a policy decision, not code
  ACME_CLIENT.request_certificate(
    domains = ["app.example.com"]
  )
  // Algorithm, CA vendor, routing = policy decisions, not application code
  // PQC migration = policy update, not deployment

What this enables:

1. Algorithm is policy: Change routing config, not application code
2. Vendor independence: Applications use standard protocols, don't know which CA is behind them
3. Incremental testing: Route 10% of traffic to new CA/algorithm, measure, adjust
4. Zero-touch deployment: Policy change propagates automatically — no change windows

The 3AM Core Components

See the 3AM Technical Architecture page for full details. Summary:

1. Protocol Endpoints (AWS Lambda + API Gateway)

• ACME: https://3am.example.com/acme/directory — RFC 8555, works with certbot/lego/any standard client
• SCEP: https://3am.example.com/scep — RFC 8894, network devices, IoT, legacy systems
• EST: https://3am.example.com/.well-known/est — RFC 7030, high-security environments (DoD, financial services)

Key insight: Applications never know which CA backend is used. They only know "request certificate via standard protocol." That's the decoupling that makes PQC migration a policy update.

2. Policy Engine (DynamoDB + Lambda)

Routing decisions based on:

• Certificate type (TLS, code signing, S/MIME)
• Environment (production, staging, development)
• Algorithm requirement (hybrid, classical, PQC-only)
• Compliance tags (PCI-DSS, HIPAA, SOC2)
• Application criticality (high, medium, low)

Policy changes take effect in seconds. Rollback is trivial. This is infrastructure intelligence, not operational efficiency — a live data source for security posture, compliance evidence, and infrastructure risk.

3. Backend CA Integrations (Pluggable)

The 3AM supports multiple backend CAs simultaneously:

• Public CAs: Let's Encrypt, DigiCert, Sectigo
• Private CAs: AWS Private CA, Microsoft AD CS, Google CAS
• Specialised: Code signing CAs, S/MIME CAs

PQC migration timeline via backend additions:

• 2025: Classical CAs only (existing infrastructure)
• 2027: Add hybrid CA backend (RSA + ML-DSA)
• 2029: Add PQC-only CA backend (ML-DSA only)
• 2030: Deprecate classical backends

Vendor independence: If DigiCert raises prices 50%, switch to Sectigo backend via policy change. No application work. No migration project. No vendor negotiation from a position of lock-in.

4. CMDB Integration (Event-Driven)

Certificate lifecycle events published to your asset management:

• Issuance, renewal, revocation, algorithm migration tracking
• Certificate ID, algorithm (e.g. "ML-DSA-65-RSA-PSS-2048"), issuer, validity, owner, environment

Continuous inventory reconciliation:

1. The 3AM scans network for active certificates with ACME clients as its agents
2. Compares with issued certificate database
3. Identifies discrepancies (shadow IT, deployment failures, expired certs still in use)
4. Alerts generated for investigation
5. CMDB updated with accurate state

Compliance reporting: Automated reports show PQC migration progress, algorithm distribution, and compliance with federal timelines. Evidence auto-generated — no manual audit preparation.

Common PQC Migration Challenges — Solved Operationally

Challenge 1: "We don't know what certificates we have"

Traditional approach: Spend 6–12 months on manual inventory, likely miss 20–30% of certificates. Then restart the project.

Infrastructure-first approach:

• Deploy the 3AM with continuous discovery
• Network scanning finds active certificates automatically
• Inventory improves over time as discovery runs continuously
• Migration proceeds even with incomplete initial inventory

Real example — major internet company:

• Estimated: 8,000 certificates
• Discovery found: 23,000 certificates (3× estimate)
• Traditional approach: restart project, re-scope, re-budget
• 3AM: discovery continued during migration, no timeline impact

Challenge 2: "Legacy applications can't support PQC certificates"

Symptoms:

• Application fails to parse certificates >8KB (PQC signatures are ~3.3KB)
• Cryptographic library doesn't recognise ML-DSA algorithm
• Performance issues on slow mobile networks

Solutions — choose per application:

Option A: Proxy/Gateway — Deploy TLS proxy in front of legacy app. PQC certificate to internet, classical certificate to legacy app. Minimal cost, low complexity.

Option B: Isolated Network — Move legacy app to isolated segment. Allow classical-only certificates. Document as exception for compliance. Medium cost.

Option C: Decommission — If limited business value, decommission instead of migrate. Removes technical debt. High cost but eliminates ongoing tax.

The 3AM flexibility: Policy routes different certificates to different backend CAs. Legacy apps get classical, modern apps get PQC, all from the same infrastructure. No split environments. No parallel systems.

Challenge 3: "Our change management is too slow"

Symptom: Certificate changes require 14–30 day approval cycles, making rapid iteration impossible.

Solution: Decouple certificate issuance from application deployment, categorise by risk:

• Low Risk (no approval): Automated renewals, same algorithm/CA — 3AM handles automatically
• Medium Risk (24–48 hours): Algorithm changes within established policy — policy change, not app deployment
• High Risk (5–7 days): New CA vendor additions, significant policy changes
• Emergency (<4 hours): Certificate-related outages, CA compromise — switch immediately

Impact: Most PQC migration work happens as "medium risk" policy changes, not "high risk" application deployments. Change management becomes an enabler, not a blocker.

Challenge 4: "We're locked into our current vendor"

Traditional options:

• Pay contract termination fees ($500K–$2M typical)
• Wait 2 years, miss PQC deadlines
• Run parallel infrastructure (double costs)

The 3AM approach: Keep existing vendor. Add PQC-capable vendor as additional backend.

• Year 1: Deploy the 3AM, keep existing vendor as primary backend
• Year 1–2: Migrate applications to protocol-based enrolment
• Year 2: Add PQC-capable vendor as secondary backend
• Year 2+: Route new certificates to PQC vendor, existing contract winds down naturally

No termination fees. No big-bang migration. Can evaluate PQC vendors based on actual performance (route 10% of traffic to test) instead of RFP promises.

Challenge 5: "PQC performance concerns"

Reality check — PQC signatures are faster to verify than RSA, but larger:

• Verification speed: ML-DSA-65 is 5× faster than RSA-2048 (0.1ms vs 0.5ms)
• Signature size: ML-DSA-65 is 13× larger than RSA-2048 (3,309 bytes vs 256 bytes)
• TLS handshake on 100 Mbps: +0.84ms added latency (negligible)
• TLS handshake on 4G mobile: +4.2ms added latency (noticeable but acceptable)

Where it matters: High-latency networks (satellite), high-volume TLS handshakes (>10K/sec), low-power IoT devices.

3AM testing approach: Route 10% of traffic to PQC, measure latency/throughput. Gradually increase if acceptable. Roll back if not. Maintain classical for performance-sensitive apps, PQC for everything else. This is what incremental testing via policy looks like — impossible with algorithm-first approaches.

Why We Built This — And Why We Know It Works

Axelspire exists because the certificate management industry has misdiagnosed the problem for twenty years. The tools are not the issue. The operations are.

Dan Cvrcek — Cambridge PhD, Black Hat and DEF CON speaker — built 3AM after managing tens of thousands of certificates across:

• Barclays — enterprise certificate lifecycle automation
• Deutsche Bank — PKI infrastructure transformation
• TSB — Windows Certification Services modernisation
• Sky UK — HashiCorp Vault namespace management and certificate automation
• Comcast — xPKI technology integration and lifecycle management

These are not case studies from a marketing deck. They are the empirical foundation for every claim on this page. The 3× certificate undercount? Real data from a real client. The 80% failure rate for algorithm-first? Observed across 7 failed migrations we were brought in to rescue.

What makes Axelspire different:

• Not a managed service provider. We don't take over your PKI. We transform it and hand it back.
• Not a reseller. We're not compensated by CA vendors for recommendations.
• Serverless by design. 3AM deploys into your AWS account. You own the infrastructure, the data, and the control.
• Operational transformation is the product. Technology is the enabler. The deliverable is a repeatable, governed, auditable certificate lifecycle that runs without heroics.

Stop Paying the Invisible Infrastructure Tax

Your PQC migration deadline is approaching. The question isn't which algorithm to choose — it's whether your operational PKI can survive the transition.

Start with a free crypto-agility assessment. We'll quantify your invisible infrastructure tax, map your certificate estate against PQC migration requirements, and tell you honestly whether the 3AM fits your situation — or if a different approach makes more sense.

→ Free PQC Crypto-Agility Assessment

Or contact us directly — we'd rather have an honest conversation than a sales pitch.

Related Resources

References

1. National Institute of Standards and Technology. (2024). Post-Quantum Cryptography Standards (FIPS 203, 204, 205).
2. Internet Engineering Task Force. (2019). RFC 8555: Automatic Certificate Management Environment (ACME).
3. Internet Engineering Task Force. (2024). RFC 8894: Simple Certificate Enrollment Protocol (SCEP).
4. Internet Engineering Task Force. (2013). RFC 7030: Enrollment over Secure Transport (EST).
5. Forrester Consulting. (2024). The Total Economic Impact of Certificate Automation.
6. National Security Agency. (2022). CNSA Suite 2.0: Cybersecurity Algorithm Requirements.