The quantum clock is ticking
Quantum computing is no longer a theoretical curiosity. It is an approaching reality that will fundamentally reshape how organizations protect their most sensitive data, and the public key infrastructure (PKI) that underpins that protection.
Estimates place the arrival of quantum computers capable of threatening current cryptography at around 2030 or soon after. That timeline might feel distant, but the threat is already active. Adversaries are collecting encrypted data today with the expectation of decrypting it once quantum capabilities mature. This “harvest now, decrypt later” strategy means that data protected by today’s algorithms could be exposed retroactively, and a majority of organizations already recognize this as their top quantum concern, according to recent Thales Data Threat Report findings.
The eventual arrival of quantum computers means that most of the algorithms we currently rely on for PKI will no longer be secure. The question is not whether your organization needs to prepare. The question is whether you are preparing fast enough.
This guide provides a practical, five-step framework for enterprise security teams who need to move beyond awareness and into action. Whether you are a CISO building a strategic roadmap, a PKI administrator planning infrastructure changes, or an IT security leader evaluating vendor readiness, these steps will help you build a clear path to quantum resilience.
Why quantum computing threatens your PKI
To understand the urgency, it helps to understand what quantum computing changes at a fundamental level.
Today’s PKI relies on asymmetric cryptographic algorithms, primarily RSA and elliptic curve cryptography (ECC), to establish trust, authenticate identities, and protect data in transit. These algorithms derive their security from mathematical problems that classical computers cannot solve in any reasonable time frame.
Quantum computing changes that equation. Quantum computers, once they reach sufficient maturity, will have the ability to fundamentally render traditional cryptography extremely vulnerable. In particular, Shor’s algorithm can factor large numbers and solve the discrete logarithm problem exponentially faster than any classical computer, breaking the mathematical foundation that classical schemes such as RSA, ECDH, ECDSA, etc. depend on.
The challenge is compounded by the response timeline. The runway once quantum reaches that maturity is relatively short for any organization to respond. Planning needs to be already underway. Organizations that wait for quantum computers to arrive before taking action will find themselves scrambling to overhaul deeply embedded cryptographic infrastructure under pressure, a scenario that dramatically increases the risk of pernicious errors, disruptive outages, and devastating security incidents.
From a risk perspective, quantum computing is a fundamental game changer. Every device that consumes any kind of cryptography becomes a target, and if the cryptography is not quantum resistant, that device is now vulnerable. The infrastructures organizations are building today will need to last five or more years, which means the design decisions made now will determine whether those systems can withstand the quantum transition.
What NIST has standardized (and what it means for your PKI)
The path forward is not undefined. NIST has led the global effort to standardize post-quantum cryptographic algorithms, aiming to produce systems secure against both quantum and classical adversaries that still interoperate with existing protocols and infrastructure. This gives organizations a vetted set of algorithms they can adopt incrementally, without gambling on which approach would eventually win.
That effort has produced finalized standards covering both halves of what PKI does: key exchange and digital signatures. ML-KEM (FIPS 203) handles key encapsulation. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) provide two structurally different approaches to post-quantum signing, lattice-based and hash-based respectively, giving organizations a fallback if cryptanalytic advances ever weaken confidence in one family of assumptions. Two independent signature standards built on different hard problems is a hedge NIST built into the process itself. Further standards are on the way to provide further diversity for security personnel.
For private PKI deployments, this is a concrete set of engineering obligations across the certificate lifecycle, not an abstract milestone. CAs need to support new algorithm types end to end: key generation, certificate signing, and chain validation. Certificate profiles need to accommodate larger key and signature sizes than RSA or ECDSA ever required, with downstream effects on TLS handshake overhead, certificate storage, and constrained device support. Issuance, validation, and revocation tooling across the stack, including HSMs, CA software, and client libraries, all need PQC support before any of this is usable in production.
None of this happens in isolation either. Algorithm availability is necessary but not sufficient. It has to land alongside policy mandates that force migration timelines, protocol-level support in TLS, X.509, and enrollment protocols, and vendor readiness across the CA and HSM ecosystem. Organizations waiting for all of these to align at once will be migrating under deadline pressure. Those treating crypto-agility as infrastructure work now, inventorying where RSA and ECC currently live and building the ability to swap algorithms without re-architecting, will have options when mandates tighten. It’s the same shape of migration the industry went through with SHA-1 to SHA-2, just with a longer runway and higher stakes.
Step 1: Build your cryptographic inventory
The first practical step toward quantum readiness is understanding what you have. You cannot plan a migration if you do not know what needs to migrate.
Being cryptographically agile starts with having a complete inventory of keys, certificates, and algorithms in use across your organization. This means identifying every certificate, every key, and every algorithm deployed across your environment, including those issued by internal certificate authorities, public CAs, and cloud-based issuers.
The challenge is that most organizations have far less visibility into their cryptographic landscape than they assume. Different teams spin up their own certificate authorities. Certificates get deployed across cloud environments, on-premises servers, IoT devices, and containerized workloads without centralized tracking. The result is what the industry calls “CA sprawl,” a fragmented cryptographic environment where organizations struggle to know how many digital certificates they have, where they live, who issued them, or when they expire.
You cannot track what you cannot see. Discovery is the most critical step to avoiding unexpected outages and building a viable quantum migration plan. Organizations should deploy discovery tools across segmented networks and clouds, including SSL/TLS scanning, real-time synchronization with CAs, and deep discovery of key and certificate stores that would not surface through network scanning alone.
Action items:
- Deploy automated discovery across all environments (on-premises, cloud, hybrid)
- Catalog every certificate by issuing CA, algorithm type, key length, and expiration date
- Identify certificates protecting long-lived data or critical infrastructure (these are highest priority for PQC migration)
- Establish ongoing monitoring so the inventory stays current as new certificates are issued
Step 2: Achieve cryptographic agility before you need it
Cryptographic agility (also known as simply crypto agility) is the organizational capability to swap cryptographic algorithms without rebuilding your infrastructure. It is not just a quantum readiness strategy. It is an operational necessity that pays dividends today.
Achieving cryptographic agility involves three core pillars:
- A complete cryptographic inventory (covered in Step 1): You need to know what algorithms are in use before you can change them.
- Automation and compartmentalization: The ability to manage cryptographic changes at scale with minimal side effects. Manual certificate management processes, spreadsheets, calendar reminders, and homegrown scripts simply cannot keep pace with the volume and velocity of modern certificate operations.
- Shorter certificate validity periods: Shorter lifespans force organizations to build the automation and processes that make agility possible. When certificates need to be renewed frequently, manual approaches break down quickly, making automation mandatory rather than optional.
This capability is valuable even if quantum computing never becomes a practical threat. Algorithm deprecations, compliance shifts, CA compromises, and vendor changes all require the same underlying ability to rotate cryptographic assets quickly and reliably. Organizations that build crypto agility today will be positioned to handle the quantum transition as one more algorithm rotation, rather than an infrastructure overhaul.
The key is to enable your organization to quickly identify and remediate certificate-related threats, whether it involves a single certificate or thousands. Look for solutions that enable bulk revocation and seamless transition to a new CA without complex, manual processes.
Step 3: Test post-quantum algorithms in your environment
With some NIST standards already finalized, organizations can begin testing PQC algorithm implementations now, even before full production deployment.
It is recommended that organizations try out the new algorithms as final candidate implementations become available. While there may be some differences between early implementations and production-grade versions, the characteristics of the algorithms, including performance impact, key sizes, and signature sizes, are unlikely to change significantly.
Testing matters because PQC algorithms behave differently from their classical counterparts. Key sizes are substantially larger. Signature sizes vary across algorithms. Performance characteristics differ across hardware platforms. Organizations need to understand how these differences affect their specific environments before committing to a production rollout.
The U.S. Government has already indicated that they will expect vendors to adopt these algorithms as standards become available, and other governments and organizations are likely to follow. Preparing now is the only way to avoid unpleasant surprises later.
Where to start testing:
- Keyfactor’s PQC Lab: The PQC Lab provides a fully configured EJBCA Enterprise instance with PQC certificate authorities, profiles, and enrollment protocols ready to use. The environment runs for 30 days at no cost, with no license fees or infrastructure expenses. Teams can test PQC certificate issuance across multiple protocols, including REST API, ACME, and EST, using NIST-approved PQC algorithms.
- Bouncy Castle libraries: Production-ready PQC implementations are available in both Java and C# .NET editions, supporting ML-KEM, ML-DSA, and SLH-DSA.
Key areas to evaluate during testing:
- Certificate issuance and enrollment workflow compatibility
- Key and signature size impact on storage and bandwidth
- Performance benchmarks across your hardware environment
- Interoperability with existing applications and protocols
Step 4: Plan your PQC CA hierarchy
Once you have tested PQC algorithms and confirmed they work in your environment, the next step is planning your CA architecture for the post-quantum era.
The recommended approach for most organizations is to create a separate PQC CA hierarchy, much like how most enterprises already maintain separate hierarchies for RSA and Elliptic Curve Cryptography (ECC). This parallel approach allows organizations to stand up PQC-capable certificate authorities alongside their existing infrastructure without disrupting current operations.
Hybrid certificates (which combine classical and post-quantum algorithms in a single certificate) are an alternative, however, they are not necessary for most use cases. A parallel hierarchy provides cleaner separation, simpler management, and a more straightforward migration path.
Planning considerations:
- Timing: Begin designing your PQC CA hierarchy now, even if full production deployment is still months or years away. The design phase takes time, and early planning prevents rushed decisions later.
- Structure: Mirror the organizational structure of your existing RSA/ECC hierarchies. Use dedicated root and issuing CAs for PQC algorithms.
- Vendor readiness: Ensure your PKI vendor supports NIST-standardized algorithms so you can begin testing in your lab environment now and have a clear path to quantum readiness when you are ready for production use.
- Algorithm selection: ML-DSA (FIPS 204) is the primary candidate for certificate signing. SLH-DSA (FIPS 205) provides a hash-based alternative for environments where signatures with increased security guarantees are preferred.
Step 5: Automate certificate lifecycle management at scale
The transition to PQC will require mass re-issuance and rotation of certificates across your entire environment. Without automated certificate lifecycle management, this process is impractical for most organizations.
The attention in the enterprise has moved to being able to manage certificates in a fully automated manner, removing people from the equation both for the skill shortage (many organizations do not have enough staff dedicated to PKI) and also from the human error aspect of misconfigurations, which remain one of the leading causes of breaches.
Effective automation for quantum readiness requires:
- Centralized visibility: A single console that provides visibility across all CAs, whether public, private, or cloud-based. You cannot automate what you cannot see.
- Automated renewal and provisioning: The ability to automatically renew, provision, and install certificates at scale, eliminating the manual processes that create bottlenecks during large-scale transitions.
- Bulk operations capability: When the time comes to rotate from classical to PQC algorithms, you will need to revoke and re-issue certificates in bulk. Solutions should enable bulk revocation and seamless transition to a new CA without complex, manual processes.
- CA-agnostic management: Your certificate management platform should work across all CAs in your environment, ensuring that the PQC migration does not create new silos or blind spots.
How Keyfactor can help
Keyfactor supports quantum readiness across the full journey, from cryptographic discovery through PQC certificate issuance and lifecycle automation.
Bouncy Castle PQC support: Bouncy Castle, Keyfactor’s open-source cryptographic library, provides production support for all three NIST PQC standards. The C# .NET 2.5.0 release introduced ML-KEM, ML-DSA, and SLH-DSA support, while the Java 1.79 release added the same standards with release 1.82 extending support to include HQC KEM.
EJBCA Enterprise: Keyfactor’s PKI platform supports quantum-ready certificate issuance, with the flexibility to deploy on-premises, in the cloud, as SaaS, or as a fully managed service. EJBCA supports PQC certificate authorities, profiles, and enrollment across standard protocols including ACME, EST, and REST API.
PQC Lab: Keyfactor’s PQC Lab provides a free, fully configured sandbox environment for testing PQC certificate issuance and signing workflows, giving teams hands-on experience with PQC in a production-grade environment.
AgileSec: You can’t migrate cryptography you can’t see. AgileSec discovers cryptographic assets across networks, applications, source code, and cloud workloads, flags quantum-vulnerable algorithms, and builds a prioritized inventory of what to migrate first. It also supports dynamic remediation, updating algorithms in the field as standards evolve, without touching source code.
SignServer: SignServer now lets you sign using both ML-DSA and SLH-DSA algorithms, bringing quantum-safe capabilities to your signing workflows. SignServer complements EJBCA by securing the signing operations that rely on your PKI’s trust chain, ensuring that both certificate issuance and digital signatures are quantum-ready. The PQC Lab also includes SignServer for hands-on PQC signing and timestamping testing.
Keyfactor Command: For certificate lifecycle automation, Keyfactor Command provides centralized visibility, governance, and automation for certificates issued from any CA, public or private. It enables the bulk operations, automated renewal, and crypto agility that the PQC transition will demand.
Got quantum PKI questions? We’ve got answers.
Q: When will quantum computers be able to break current PKI encryption?
A: Estimates place the arrival of quantum computers capable of threatening current cryptography at around 2030 or soon after. However, the “harvest now, decrypt later” threat means adversaries may already be collecting encrypted data to decrypt later, which is why preparation needs to start now.
Q: What are the NIST post-quantum cryptography standards?
A: On August 13, 2024, NIST finalized three PQC standards: FIPS 203 (ML-KEM for key encapsulation), FIPS 204 (ML-DSA for digital signatures), and FIPS 205 (SLH-DSA for hash-based digital signatures). These are designed to be secure against both quantum and classical computers while interoperating with existing networks.
Q: What is crypto agility and why does it matter for quantum readiness?
A: Crypto agility is the organizational capability to swap cryptographic algorithms without rebuilding your infrastructure. It requires a complete cryptographic inventory, automation to manage changes at scale, and shorter certificate validity periods. It is valuable even without the quantum threat because it addresses current operational challenges like algorithm deprecations and compliance shifts.
Q: Should we use hybrid certificates that combine classical and post-quantum algorithms?
A: For most use cases, the recommended approach is to create a separate PQC CA hierarchy rather than using hybrid certificates, similar to how organizations already maintain separate hierarchies for RSA and ECC. This provides cleaner separation and a simpler migration path.
Q: What is the first step we should take to prepare our PKI for quantum computing?
A: Start with a complete cryptographic inventory. You need to know every key, certificate, and algorithm in use across your organization before you can plan a migration to quantum-safe standards.
Q: How will the transition to post-quantum algorithms affect certificate management?
A: The transition will require mass re-issuance and rotation of certificates across your environment. Without automated certificate lifecycle management, this process would be impractical for most organizations. Centralized visibility and bulk operations capabilities are essential.
Q: Can we start testing post-quantum algorithms now?
A: Yes. NIST finalized its PQC standards in August 2024, and production implementations are available through libraries like Bouncy Castle (supporting ML-KEM, ML-DSA, and SLH-DSA). Keyfactor’s PQC Lab provides a free sandbox environment where you can test PQC certificate issuance across multiple enrollment protocols.
Q: What role does Keyfactor play in quantum readiness?
A: Keyfactor supports quantum readiness across the full journey: Bouncy Castle provides PQC algorithm implementations, EJBCA supports quantum-ready certificate issuance, and Keyfactor Command delivers the certificate lifecycle automation needed to execute large-scale algorithm transitions.
