Vendors deliver the cryptographic capabilities. Enterprises must connect those capabilities to deployed services, coordinate dependencies and verify the intended protection. Track what is committed, available, enabled and verified for each cryptographic function, with a clear record of what remains unassessed.
A CISO asked me recently why their organization needed to own the migration to post-quantum cryptography. Vendors supplied the upgrades that moved the world from SSL to TLS. Wouldn't they supply these too?
They will supply most of them. Vendors and open-source maintainers will implement the new algorithms. Cloud providers will update the services they operate. No enterprise should write its own ML-KEM, and every enterprise should use supported capabilities wherever they meet its requirements.
What a vendor cannot do is know which of your applications bundles its own copy of a library, which business partner can accept a new signature format, or which configuration is actually running in production. For an enterprise, migration means applying the right protection to a defined business service and demonstrating that the service still works. That is coordination across suppliers, application teams, infrastructure, security and the business, and its size depends as much on how the organization has assembled its technology as on how many servers it runs.
This article sets out how I think about that work and where it usually goes wrong.
Four states, not one readiness label
The most useful discipline I know is to stop asking whether a system is "PQC-ready" and instead track four states for each cryptographic function a business service depends on.
- Committed. The supplier has the capability on its roadmap.
- Available. A supported release provides it for the deployment model you use.
- Enabled. Your deployed version and configuration turn it on.
- Verified. The intended protection has been confirmed for the function and path you care about.
These states answer different questions, and different people own the move between them. Vendor roadmaps live in state one. Most "supports PQC" claims describe state two. Internal upgrade programs deliver state three. Only state four tells a CISO the service is protected, and only for the client, route and configuration that was actually tested. A failed or unattempted check stays an identified gap rather than becoming an assumption.
The rest of this article is about getting a service from state one to state four.
What actually changes
The transition concerns public-key cryptography. RSA and elliptic-curve algorithms rest on mathematical problems a sufficiently capable quantum computer could solve, and their replacements have to be integrated into the protocols, products and applications that use them.[1] Three functions need to be kept apart.
Key establishment produces shared secrets for protecting communications. ML-KEM is the post-quantum mechanism most deployments will use, typically in a hybrid construction alongside a classical exchange.
Digital signatures underpin certificate-based identity, software updates and signed messages. A new signature algorithm helps only when every verifier of those signatures supports it. NIST's initial standards cover both functions.[2]
Symmetric encryption, including AES, is not exposed to the same attack, and NIST continues to permit existing key sizes. An AES-256 database does not need a new data-encryption algorithm because of PQC. It does need an assessment of how its keys are protected and distributed and how applications connect to it.[3]
Keeping these apart prevents the most common scoping mistake: treating every reference to "encryption" as the same migration task.
Where the SSL to TLS comparison stops working
The analogy is right about delivery. Enterprises adopt cryptographic improvements through supported software, hardware and managed services, and PQC should ride the same mechanisms.
It understates the customer's share. SSL retirement and the later TLS upgrades also required customer decisions, because removing an old protocol could disconnect an application or partner that still depended on it. RFC 8996, which deprecated TLS 1.0 and 1.1, discusses that interoperability problem directly.[4]
PQC carries the same coordination problem into more places. A transport upgrade does not change the signing code inside an application or the trust relationships used to validate software. And within TLS 1.3 itself, key establishment, authentication and the symmetric cipher are negotiated separately, so a protocol version or a cipher-suite name is not evidence that a connection uses post-quantum protection.[5]
Cloudflare's documentation shows the distance between states two and four. Its post-quantum key agreement protects a connection only when the other endpoint supports it; the browser-to-edge and edge-to-origin hops have to be considered separately; and key agreement is distinct from post-quantum authentication, which is at an earlier stage of deployment.[6]
Scale sets the scope; architecture sets the difficulty
Consider a SaaS company on managed cloud networking, current application frameworks and a small number of identity and infrastructure providers. Where a provider controls the full service and can update its cryptography transparently, the customer's work concentrates on confirming coverage, updating dependent clients and validating integrations.
The scope changes the moment that company runs custom authentication, signs software for customers or ships an application that runs outside its own environment. Cloud hosting gives the provider no control over those cryptographic decisions.
Now consider a bank with hybrid infrastructure, thousands of endpoints and hundreds of vendor dependencies: several generations of applications, private certificate authorities, hardware security modules and counterparties that upgrade on their own schedules. Some of that estate will be straightforward. Other parts wait on an application modernization project, a hardware support decision or a counterparty's test window.
These are illustrations, not industry verdicts. Endpoint count is a sound measure of the estate that has to be discovered and covered. It is a weaker measure of difficulty, which comes from the variety of implementations, how easily each can be changed and how many parties have to move together. A large, consistently managed fleet can be simpler to migrate than a small collection of bespoke integrations.
Follow one service through its dependencies
Picture a banking service that receives requests through a cloud load balancer, calls an on-premises application over mutual TLS, and sends signed messages to an external partner. Its application certificate comes from a private certificate authority, with the key held in an HSM.
The load balancer's PQC upgrade moves one hop to state three. The internal connection needs compatible capability at both ends. The signed messages need the sender and the partner's verifier to agree on an algorithm and format. And the application may depend on a runtime or library version that differs from what the operating system supplies; updating a system library does not establish that the application uses it, because it may bundle its own copy or need changes to how it calls cryptographic functions.
Michael Osborne and his IBM co-authors describe why this dependency context matters: an application's cryptography spans frameworks, runtime components, databases, operating systems and hardware, and change is often required at more than one level.[7]
The service owner has to decide which changes can proceed independently, which must wait for another component, and how the service operates in the meantime. A temporary compatibility arrangement can preserve availability while leaving a specific cryptographic risk open. That is a legitimate decision, provided it is recorded as one.
Allocate the work around the deployed service
Responsibilities follow the contract and service model. A fully managed service absorbs far more execution than software the customer deploys and configures. Even then, the customer must understand what is covered and how the service connects to everything else. The following is a starting split.
Migration activity | Typical supplier contribution | Enterprise responsibility |
|---|---|---|
Implement cryptography | Provide supported algorithms and product integrations | Select capabilities appropriate to the use case |
Plan deployment | State supported versions, prerequisites and limitations | Map those to deployed systems and owners |
Establish interoperability | Test the product and document supported combinations | Validate the business service across its actual dependencies |
Sequence the rollout | Provide release plans and upgrade guidance | Coordinate teams, counterparties, change windows and exceptions |
Verify ongoing protection | Supply configuration guidance and evidence | Confirm coverage, review gaps and track changes over time |
A roadmap is useful when it can be translated into this table. Marin Ivezic has made the case for demanding concrete evidence from vendors rather than statements of intent: named documents with revision dates, a bill of materials, proof of a past algorithm change, and disclosure of their own supplier dependencies.[8] I would add one discipline. Capture each answer against the business service that depends on the product, not in a vendor-management folder. That is what makes a slipped release or an unsupported version visible to the people who must respond to it.
Build an inventory that can guide a change
An inventory earns its keep when it helps a team decide what to do next. A list of algorithms or certificates needs enough context to connect each finding to a system, an owner and a business purpose.
For a selected service, record the cryptographic function, the algorithms and configuration in use, the supporting software or hardware, and the evidence source. Add dependencies, the sensitivity of the protected information and any gaps in the assessment. NIST's discovery guidance frames inventory across applications, devices, protocols, keys, certificates and data flows.[9]
Different methods answer different questions. Network observation shows what a connection offers or negotiates. Code and dependency analysis finds cryptography that never appears on the wire. Platform configuration and supplier information explain the managed services and components that no scan can see inside. A cryptographic bill of materials (CBOM) organizes this information and gives suppliers a structured way to state what their software contains; the enterprise still has to tie it to the versions and configurations it actually runs.[10]
Above all, document the coverage boundary. Evidence from one network segment, one repository or one configuration must not silently become a claim about the enterprise.
Prioritize by risk and by time to change
Two clocks matter. The first is the confidentiality lifetime of the data. Traffic protected by quantum-vulnerable key establishment can be captured now and decrypted later, and upgrading the connection afterwards does nothing for what was already recorded. The joint CISA, NIST and NSA guidance makes long-lived secrecy the first prioritization criterion.[11] NIST's initial public draft IR 8547 adds a planning timeline: it proposes deprecating quantum-vulnerable public-key schemes at the 112-bit security level, such as RSA-2048, after 2030 and disallowing them after 2035. Schemes at 128 bits or above, including P-256, are proposed for disallowance after 2035. This is draft transition guidance, not a universal regulatory deadline.[12]
The second clock is how long a system takes to change. Signature migration deserves its own assessment even where no secrets are involved, because software and firmware updates depend on telling an authorized release from a forgery. Systems with long replacement cycles or few upgrade options need planning now even if no PQC deployment is available for them yet, while other services can take a supported improvement today. A program can run both without forcing them onto one schedule.
Test on the path the service actually uses
Compatibility has to be demonstrated with representative clients, intermediary devices and downstream connections, under expected load and failure conditions. Handshake size is a concrete example. Cloudflare documents that adding ML-KEM can push the initial TLS message across additional packets, which exposes faults in some implementations and middleboxes. That is a reason to test the network path rather than assume a uniform effect.[13]
Define acceptance criteria before the pilot: which algorithms were actually negotiated, whether intended clients connect, the performance effect, and how the service behaves when a peer cannot support the preferred configuration. Fallback deserves an explicit decision. A connection that succeeds on classical cryptography meets an availability objective while failing the protection objective. Record the distinction and agree how long the exception may stand.
The evidence differs by function. A negotiated key-exchange group supports a claim about that connection. Signature migration needs evidence that issuer, signer and verifier work together under the intended trust policy. Neither result alone establishes enterprise-wide readiness.
Start with a defined service and expand from evidence
Select a small number of important services and the teams that can change them. Map their cryptographic dependencies, obtain specific supplier information, and identify one supported migration that can be tested safely. There is no need to hold every improvement until discovery across the whole organization is complete. Osborne's discussion of migration delays makes the same connection between discovery, critical business assets, dependencies and actionable vendor roadmaps.[14] The scope has to be clear enough to decide and the unresolved areas visible enough to prevent overstated progress.
As services change, update the inventory and keep the evidence needed to reassess them. That is crypto-agility in practice: the ability to replace cryptographic mechanisms across applications, protocols, software, hardware and infrastructure while preserving security and operations.[15]
The CISO's question remains the right test of any plan. Which work can a supplier absorb, and which decisions require the enterprise's knowledge of its own business? Answered at the service level, the migration becomes something you can fund, sequence and verify.
How Qinsight approaches this
Atlas, our cryptographic posture management platform, helps teams build cryptographic visibility through discovery and inventory across supported environments. The four states above provide a planning model for evaluating supplier commitments, deployed capabilities and verification evidence. The coverage and evidence available depend on the discovery methods, integrations and scope used. Our white paper, Cryptographic Posture Management: The evidence standard for the quantum transition, describes the approach in detail.
Sources and further reading
- NIST. What Is Post-Quantum Cryptography.
- NIST. Post-Quantum Cryptography FIPS Approved. August 13, 2024.
- NIST CSRC. Post-Quantum Cryptography FAQs, Transition and Migration.
- IETF. Deprecating TLS 1.0 and TLS 1.1. RFC 8996.
- IETF. The Transport Layer Security Protocol Version 1.3. RFC 8446.
- Cloudflare. Post-quantum cryptography.
- Ray Harishankar, Michael Osborne, Jai S. Arun, John Buselli and Jennifer Janechek. Crypto-agility and quantum-safe readiness. IBM, June 19, 2024.
- Marin Ivezic. Getting Vendors to Answer the Right Questions. Quantum Academy, June 9, 2026.
- NIST NCCoE. Frequently Asked Questions about Post-Quantum Cryptography, Discovery and Inventory.
- Alessandro Curioni and Michael Osborne. Cryptographic Bill of Materials Speeds Quantum Safe Adoption. IBM Research, December 8, 2022.
- CISA, NIST and NSA. Quantum-Readiness: Migration to Post-Quantum Cryptography. August 21, 2023.
- NIST. Transition to Post-Quantum Cryptography Standards. NIST IR 8547 (initial public draft), November 12, 2024.
- Cloudflare. Post-quantum between Cloudflare and origin servers.
- Michael Osborne. Denial of PQC Migration attacks. February 25, 2026.
- NIST. Considerations for Achieving Crypto Agility: Strategies and Practices. CSWP 39upd1, June 29, 2026.
Next step: Start with one critical business service and define the cryptographic dependencies, owners, and evidence needed for a scoped discovery pilot. Discuss a discovery pilot.
Build the evidence behind the argument.
Start with one accredited boundary or one delivered system and produce evidence a reviewer will accept.
