A Guide to Post-Quantum Cryptography (PQC) Readiness

The National Institute of Standards and Technology (NIST) leads the charge on post-quantum cryptography (PQC) readiness in the U.S. At a recent Quantum World Congress event, NIST director Arvind Raman said that the organization’s PQC standards are already being implemented at scale [source], citing examples across tech giants including Google, IBM, and Amazon.

In total, roughly 60 companies are working with NIST’s National Cybersecurity Center of Excellence to boost PQC adoption.

It’s a good start, but 60 companies means we’re only scratching the surface. Security leaders understand the quantum threat is real, but many likely couldn’t tell you which of their systems carry the most exposure risk or how long a full migration would take.

Criminals are already running “harvest now, decrypt later” schemes, where they steal encrypted data now to unlock it once quantum hardware catches up. Meanwhile, NIST’s official PQC roadmap [source] suggests disallowing quantum-vulnerable algorithms such as RSA, ECDSA and ECDH after 2035.

In addition, the National Security Agency (NSA) has laid out cryptographic requirements [source] expecting new national security system acquisitions to support quantum-resistant algorithms starting in 2027.

That’s a tight timeline, considering most organizations need three to five years to fully migrate.

This guide breaks post-quantum cryptography readiness into four stages, so you can reference it as you survey your inventory, brief decision-makers, and revise your roadmap.

1. Build a Complete Cryptographic Inventory

Every PQC readiness assessment should start with the same question: where does our cryptography live? For most organizations just getting started, the answer is typically “everywhere” or “we’re not sure,” but that’s ok.

There are so many places for cryptography to hide: TLS certificates that protect web traffic and APIs, SSH keys for server access, code signing certificates for software releases, and the list goes on.

Further, each of the major cloud providers runs its own key management service, and many enterprises use them alongside legacy hardware security modules (HSMs). Keys are also often hard-coded into source code and container images, and third-party SaaS platforms might use their own undocumented cryptography.

A comprehensive inventory includes each cryptographic asset; you should also identify the algorithm and key length, where the key is stored, who owns it, when it expires or rotates, and which applications depend on it.

This also shouldn’t be a one-time thing. New workloads are created every day, keys rotate, and teams implement new services, so you need to make sure your inventory is continuously updated.

The goal is to keep accurate records even as your environment evolves. Fortanix Key Insight maps each key to the services and resources it protects, enabling teams to easily remediate weaknesses.

Quick checklist:

• Scan cloud, on-premises, container and third-party environments for keys, certificates and cryptographic libraries.
• Record algorithm, key length, rotation schedule and dependencies for each asset.
• Map dependencies between keys and the applications that use them.
• Enable continuous discovery so the inventory updates whenever your environment changes.

2. Conduct a Quantum Risk Assessment

Once your inventory tells you what you have, a quantum risk assessment tells you what you should fix first.

Start with Mosca’s theorem [source] by estimating three numbers: how long your data must stay confidential (X), how long your migration will take (Y), and how long until a cryptographically relevant quantum computer arrives (Z). If X plus Y is larger than Z, that data is already at risk.

For example, a health system that keeps patient records for 25 years and is looking at a five-year migration has a 30-year exposure window.

That’s much longer than most estimates for when quantum computers will be able to break RSA.

You then need to organize your assets by how quantum computing affects them. Public-key algorithms, including RSA, ECC, and Diffie-Hellman, are the primary targets, while symmetric encryption holds up better and will typically rank lower on the priority list.

Each asset should then be weighted against business factors like data shelf life and exposure. Things like trade secrets, health records, financial info and government data need to be protected for decades. Any system tied to revenue, safety or core operations should get earlier attention as well. From a regulatory standpoint, federal contractors, financial institutions and critical infrastructure operators have the tightest timelines.

You’ll move much quicker if your organization already classifies data by sensitivity. Most organizations produce a tiered list of assets that need to move in the next year to 18 months, assets that can follow over the next few years, and those that can wait for routine upgrades.

Tools that flag quantum-vulnerable algorithms, provide a risk score across cloud platforms, and identify potential policy gaps will help you make faster decisions and spend less time gathering information.

Quick checklist:

• Apply Mosca’s theorem to each category of your data.
• Flag every asset that relies on RSA, ECC or other quantum-vulnerable algorithms.
• Rank assets by data shelf life, exposure, business criticality and regulatory pressure.
• Create a tiered remediation list with target dates.

3. Plan and Test Your Migration

The next move is preparing for PQC at the algorithm level. NIST finalized its first three post-quantum standards in August 2024: ML-KEM (FIPS 203) for key establishment, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures.

In March of 2025, HQC was selected as a backup key encapsulation mechanism built on a different type of math than ML-KEM. NIST is also continuing work on a signature standard based on the Falcon algorithm.

Your migration roadmap should specify which algorithms apply to which use cases and leave room for additions.

Today, most organizations are running hybrid deployments during a transition period, using a classical algorithm with a post-quantum one so connections stay secure if either one fails. A hybrid approach that includes an approved algorithm will fall outside the 2035 deadline in NIST’s guidance.

Testing is vital. Post-quantum keys and signatures are much larger than classical ones; an ML-DSA signature is typically several kilobytes, compared to fewer than 100 bytes for an ECDSA signature. That discrepancy can slow TLS handshakes, strain networks, and break devices with tight memory limits.

Run pilots in an isolated environment, measure performance compared to your production baselines, and document what breaks before any changes will affeect customers or end users. The Fortanix PQC Lab has sample libraries and test environments that developers can use to experiment.

Make sure you know where your HSM, cloud, PKI and software providers stand on their PQC roadmaps. If they don’t have concrete timelines, they become a dependency you’ll need to work around later.

Finally, connect your roadmap to the systems your teams already use. Work your migration plan into ServiceNow, Jira, or whatever system your teams use to make sure progress keeps moving.

Quick checklist:

• Map NIST-approved algorithms to each use case in your environment.
• Decide where hybrid deployments make sense during the transition.
• Test PQC algorithms in secure environments and measure the impact on performance.
• Collect PQC roadmaps from your critical vendors.
• Push migration tasks into existing IT workflow tools.

4. Build Crypto-Agility for the Long Term

The first wave of PQC standards is just the beginning; NIST continues to evaluate new algorithms and poke for weaknesses in those it has already approved. That’s promising for the industry as a whole, but it also means that organizations that swap RSA for ML-KEM by hard-coding the new algorithm into every app will face the process again the next time a standard changes.

Crypto-agility is the ability to change algorithms, rotate keys and update policies without needing to rewrite applications or replace infrastructure. There are four practices that will help your organization build that agility into its culture:

Centralize key management. Keys spread across cloud KMS platforms and legacy HSMs make every change harder to manage. A single control plane lets teams update algorithms across environments at once.

Separate cryptography from application code. When apps call a key management service through standard APIs instead of embedded crypto logic, security teams can change underlying algorithms without altering the application.

Govern with policies. Define which algorithms your organization approves, set minimum key strengths, determine rotation schedules, and then monitor for drift.

Remove the hardware bottleneck. Many traditional HSMs predate PQC standards and can’t run new algorithms without being replaced. Software-defined key management avoids that completely, or requires an additional license,

Fortanix Data Security Manager (DSM) was built around these principles, combining a FIPS-certified HSM and key management on a single platform. It supports algorithms aligned with NIST and CNSA 2.0 standards and integrates with databases, PKIs, and signing workflows across environments.

And because it’s software-defined and built on Confidential Computing, teams can adopt new algorithms with simple updates rather than a complete hardware overhaul.

Ultimately, teams are most successful when they treat PQC readiness as a cycle: inventory, assess, plan, test, and adapt, then run it again if and when standards evolve. It’s clear that the world’s largest technology companies have already started this journey, and organizations that start now can set their own pace.

Everyone else will be working with deadlines set by regulators or attackers.