Quantum readiness made practical

What is post-quantum cryptography?

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to be secure against attacks from both classical computers and future quantum computers. Current public key (asymmetric) cryptographic algorithms, such as RSA and ECC, rely on complex math problems that quantum computers will be able to solve efficiently. PQC algorithms are built on different mathematical foundations that remain hard for quantum computers to break. NIST finalized the first PQC standards in 2024.

Why does this matter now if quantum computers aren't a practical threat yet?

Two reasons. First, attackers are already collecting encrypted data today to decrypt later when capable quantum computers exist—an attack known as harvest now, decrypt later (HNDL). Any sensitive data in transit today that must remain confidential for more than five to ten years is at risk. Second, cryptographic migrations are multi-year efforts. NIST calls for vulnerable public key algorithms to begin being deprecated after 2030, meaning they should not be used when possible, and to be generally disallowed after 2035. Organizations that wait until the threat is immediate will not have time to migrate safely. The latter, combined with the expectation of stricter timelines driven by new and updated compliance requirements, may provide more realistic forcing functions for organizations to start executing now.

How will this impact my organization's security posture?

Organizations that have not migrated by the time a cryptographically relevant quantum computer exists will have no reliable way to protect data in transit or authenticate digital identities. The impact extends beyond network communications: code signing, document signatures, device identity, and other PKI-dependent systems are also affected. The organizations most exposed are those protecting long-lived confidential data, operating long-lived or difficult-to-update systems, relying on long-lived trust anchors, or needing signed artifacts to remain verifiable for many years. It is also highly likely that compliance frameworks like HIPAA, PCI DSS, EU DORA, and others will require adoption of PQC.

When will quantum computers be able to break current encryption?

No definitive date exists. Estimates from government agencies and researchers generally range from the early 2030s to beyond 2040. The uncertainty itself is the planning problem: mitigating the threat requires deploying PQC in advance of knowing that the threat exists.

How urgent is this transition?

Urgent enough to start now; not so urgent that it requires an emergency response. For 2026, quantum readiness should be taken as having a plan for your PQC migration and making progress on the plan. Importantly, PQC migration efforts today need to be incremental and practical. Enterprise-wide efforts tend to stall in the inventory and risk assessment phases. Organizations that wait until 2028 or 2029 to start their migration will face compressed timelines, at best.

What is a cryptographic inventory, and how is it different from a CBOM?

A cryptographic inventory is the organization’s view of cryptographic assets, dependencies, ownership, and business context. A cryptographic bill of materials (CBOM) is a standardized, machine-readable way to represent cryptographic assets and dependencies. A CBOM can contribute to the inventory, but it usually does not contain the business context needed for migration planning.

Where do we start building a cryptographic inventory?

Start with your external TLS endpoints, critical business systems, and application environments that are in scope for external audit. Those systems are likely to be well-documented, making it easier to build an inventory for them. From there, work inward, focusing on use cases with long lives like private CAs, connected devices, legal agreements, and embedded software.

Why does TLS 1.3 matter for PQC readiness?

TLS 1.3 is the standards-based path for deploying hybrid PQC key exchange. The IETF is not adding PQC key exchange to TLS 1.2, so organizations still dependent on TLS 1.2 should plan the protocol upgrade as part of their PQC migration. Updating your TLS version across your infrastructure is one of the earliest and most actionable things you can measure.

What is ML-KEM and why does it keep coming up?

ML-KEM is the NIST-standardized algorithm for key encapsulation—the mechanism that protects the key exchange necessary to secure a network session. It is the PQC algorithm relevant to TLS and most widely supported by browsers, content delivery networks (CDNs), and web server software like IIS and Apache. If your organization is prioritizing one algorithm to deploy first, ML-KEM for TLS is the practical starting point. It is already deployed in hybrid mode by major browsers and cloud providers. Deploying ML-KEM has the added benefit of stopping the creation of new traffic vulnerable to harvest now, decrypt later.

What is a hybrid certificate or hybrid key exchange, and should we care?

In general, a hybrid approach combines a classical algorithm (RSA or ECC) with a PQC algorithm. The logic being that if one is compromised, the other still provides protection. Hybrid can refer to multiple objects: key exchange, signatures, and certificates.

Hybrid key exchange applies to the TLS handshake, so that the session key is only compromised if both algorithms fail. Deploy it now for external network connections that use TLS. Deploy in a controlled fashion so you can roll back changes due to any unforeseen issues. It has already been widely deployed by large vendors, so you won’t be a pioneer in doing so.

Hybrid signatures apply to digital signatures used, for example, to execute legal agreements and verify the integrity of software. Don't use hybrid digital signatures unless a specific compliance requirement or partner mandates it.

Hybrid certificates bind both a classical and a PQC public key to an identity within a single certificate. Pick either hybrid or pure certificates and test that approach in production. The choice won’t materially change your learnings.

How do we assess vendor readiness for PQC?

Ask vendors three questions: Do they have a documented PQC roadmap with committed timelines? Which of their products support PQC algorithms today? Will migration paths for deployment technologies require hardware replacement, firmware updates, or software upgrades? Vendors without answers to these questions represent migration dependencies you need to plan around now.

What are the performance impacts of PQC?

PQC algorithms have larger key sizes and different computational characteristics than RSA and ECC. ML-KEM adds modest overhead to TLS handshakes. ML-DSA (the NIST-standardized signature algorithm) has larger signature sizes that can affect certificate chain size and performance in constrained environments, IoT devices, and high-volume low-latency systems. The right answer is to test in your environment. A controlled pilot on a representative application is how you discover capacity and performance issues before you're migrating under pressure.

What can we do without additional budget?

Several meaningful steps require intent rather than budget. Assign a named owner to your PQC migration. Enable TLS 1.3 across your environment; most modern infrastructure supports it so it should be a configuration change or a patch update. Identify which vendors and partners are dependencies. Track down a list of business-critical systems and PKIs that you will need to migrate. These steps cost time, not budget, and they are things you want to do anyway.

How do we prioritize when we can't migrate everything at once?

Start with external TLS connections and then prioritize by exposure and lifespan. If you don’t have a list of business-critical application environments and vendors, create one. Systems in explicit regulatory scope should also make the list. Migrate those first, again focusing on moving TLS to version 1.3 and using ML-KEM. PKI root and intermediate certificate authority keys, which anchor the trust of your entire certificate estate, deserve your attention next. That ordering gives you a migration sequence tied to relevance to the business.

Are there regulatory deadlines we need to meet?

Deadlines vary by sector, and new ones are expected. The U.S. government (via CNSA 2.0) has set explicit adoption timelines for national security systems, with requirements for certain algorithm transitions by 2030 and broader migration by 2033. Other U.S. government agencies are likely in scope for Executive Order 14412. Financial services regulators in multiple jurisdictions are signaling PQC requirements. NIST will formally disallow use of RSA and ECC by 2035. Organizations in regulated industries should treat these as hard deadlines and work backward to establish a migration timeline now. It’s a safe bet that more and stricter compliance requirements are on the way.

How do we demonstrate PQC readiness to auditors or regulators?

The evidence auditors are beginning to ask for includes a documented cryptographic inventory, a migration roadmap with named ownership and milestones, evidence of policy enforcement (what algorithms are approved, how exceptions are handled), and proof of progress over time. The last point is important. In the short term, PQC readiness doesn’t mean you are done; it means you are making progress.