Your Quantum Deadline May Belong to Someone Else
In a well-prioritized post-quantum migration plan, the hardest deadline to control may not be your own. It may belong to a vendor whose cryptography you don’t own and whose roadmap you can’t set.
In my previous article, I looked at how organizations can decide which cryptographic migrations they should begin with. The specific starting point for an organization depends on what is being protected, how long that information needs to remain secure and how much time the migration itself is likely to take.
But even a well-prioritized migration plan can run into problems. A primary challenge may be that you are not in full control of all the cryptography your organization needs to migrate.
Today, most organizations depend on technology built and operated by others. Applications run on cloud platforms. Networks rely on equipment from multiple manufacturers. Critical systems contain operating systems, firmware, software libraries and hardware components developed outside the organization. SaaS providers, telecommunications companies and specialized technology vendors may all sit somewhere in the chain.
Cryptography is embedded throughout that environment. When it needs to change, an organization may discover that its own readiness depends on someone else’s.
The scale of that problem is already visible in the data. DigiCert’s 2026 survey of more than 1,000 enterprise security leaders found that 87 percent of organizations plan to adopt quantum-safe encryption, but only 7 percent have broadly deployed it, a figure that has barely moved in a year. That gap is not only a question of internal effort. Much of it sits with vendors.
When the Migration Clock extends outside the organization
I have used the Migration Clock throughout this series to describe the time required to discover, prioritize, test, coordinate, replace, validate and deploy cryptographic changes. Much of that work takes place inside the organization, but not all of it.
Consider a critical system protecting information that must remain confidential for many years. The organization has identified the cryptography involved, concluded that migration needs to begin and allocated the necessary resources. During planning, however, the team discovers that an essential component depends on a product that does not yet support the required post-quantum capability.
There may be several ways forward. The organization can ask the vendor for a roadmap, push for earlier support, investigate another product or redesign part of the system. What it cannot do is determine when the vendor will develop, test and release a new capability. Every alternative also takes time.
That external timetable has now become part of the organization’s Migration Clock.
Vendor dependencies are hardly new to cybersecurity. Organizations have always waited for patches, software updates, hardware refreshes and product certifications. PQC migration adds a different kind of timing problem because organizations are preparing for a threat whose exact horizon is uncertain, while protecting information that may need to remain confidential for many years.
Harvest Now, Decrypt Later makes this particularly relevant. Some of the information that needs to survive the future quantum threat is already being created, transmitted and stored today. A supplier’s future migration date can therefore affect the protection of information that already exists. Organizations need to worry not only about the Migration Clock ticking within their own environment, but also about whether their vendors’ clocks are in sync with theirs.
The useful question is not simply whether a vendor intends to become “quantum safe.” It is whether the vendor will be ready when you need it to be.
Finding the dependencies that matter
Most large organizations know who their major technology suppliers are. Knowing your suppliers is not the same thing as knowing which of them control cryptographic dependencies that matter to a PQC migration.
Sometimes the dependency is obvious. A cloud service may control part of the encryption stack, or a hardware platform may need an upgrade before new cryptography can be supported. In other cases, the dependency sits further down in the technology stack: firmware, an identity service, a software library, certificate infrastructure or another component that receives little attention until someone tries to change it.
A cryptographic inventory becomes much more useful when it can answer not only where cryptography exists and what it protects, but also who can change it. If the organization controls the system, it can plan and resource the migration. If someone else controls a critical part of it, the organization needs to understand that party’s roadmap and decide what to do if the two timelines do not align.
That may involve a commitment from the supplier, contractual requirements, an alternative product or a change in architecture. In some cases, replacing the dependency may be the only realistic option. None of those decisions is particularly attractive when made under the pressure of a tight timeline.
The questions to ask vendors are changing
Organizations already question technology suppliers about security, compliance, availability and support. PQC readiness should increasingly become part of those discussions, especially for products that protect long-lived information or are expected to remain in service for many years.
Asking “Are you quantum safe?” is unlikely to get you very far. It is too broad, and different vendors can reasonably interpret it in different ways.
Consider hardware security modules, the devices many organizations rely on to protect their most sensitive keys. By 2026, the major HSM vendors, Thales, Entrust and Utimaco, had added NIST-validated support for the new postquantum algorithms to their firmware. That sounds like readiness. But most of their mainstream commercial platforms were still waiting for the separate, stricter FIPS 140-3 Level 3 certification that many regulated organizations actually require before they can deploy that cryptography in production. A vendor can answer “yes” to quantum safety and still be a year or more away from the certification your compliance team needs.
Instead, the questions need to be specific. Which cryptographic functions in the product are likely to require migration? What is the roadmap for supporting post-quantum cryptography, and against which certification? When will customers be able to test those capabilities? Will the transition require a software update, new hardware or a larger architectural change? How will existing systems continue to operate during the transition? And what will customers themselves need to do?
There will not always be precise answers. Product roadmaps change, standards evolve and implementation dates move. The point is not to force a supplier to predict the future. It is to understand enough about the expected path to know whether it fits your own.
Finding out early that it does not leaves room to respond. Finding out when the migration has already become urgent is a very different situation.
Procurement has a role here too
Some of the decisions that will determine an organization’s future ability to migrate are being made today by people who may not think of themselves as part of a quantum-readiness program.
A multi-year technology contract signed this year may still be in force when critical systems need to migrate. Hardware purchased now may remain deployed for much of the next decade. A platform selected today may become deeply embedded in business operations before anyone has examined how easily its cryptography can change.
This does not mean quantum risk should dominate every technology purchase. But when a product protects sensitive information for many years, performs a critical trust function or remains deployed for a long period, the ability to support cryptographic change needs to be part of the procurement conversation. It is much easier to ask about that before signing a contract than halfway through a migration.
The problem becomes more complicated when several suppliers are involved. A cloud platform may support new algorithms while the application running on it does not. The application may be ready while a hardware component underneath it still requires replacement. Different parts of the same system can therefore move on very different schedules. In practice, the organization’s migration timeline can end up being determined by a dependency several layers away from the team responsible for the migration.
What if a vendor cannot move fast enough?
Finding a dependency is only useful if the organization is prepared to act on what it finds. Once a critical vendor is identified, the first question should be whether its migration timeline fits within the time available to the organization. There is no universal period that every supplier should be given to become PQC-ready. A vendor supporting short-lived, easily replaceable data presents a different problem from one embedded in a system protecting information that must remain confidential for fifteen years.
The relevant deadline should come from the organization’s own clocks. How long must the information remain protected? How long will the internal migration take? How much time would be required to test and deploy the vendor’s solution? And, if that solution does not arrive, how long would it take to move to an alternative? Those answers tell the organization how much time it can realistically give the supplier.
A vendor that cannot meet that timeline does not automatically compromise the security of the entire company. The effect depends on what the dependency does, what it protects and how deeply it is connected to other systems. A critical dependency can, however, leave an important part of the organization exposed or prevent a broader migration from being completed. That is why the issue needs to be treated as a risk decision rather than simply a vendor-management problem.
The response should become progressively more serious as the gap between the two timelines grows. An organization might first seek a documented roadmap and clear milestones from the supplier. If the dependency is important, those commitments can become part of contract renewals and procurement requirements. The organization can test alternatives in parallel rather than waiting for the deadline to arrive. Where the gap cannot be closed, it may need to isolate the dependency, redesign the architecture or replace the product altogether.
The important point is not to wait indefinitely for a vendor to catch up. At some point, the time required to move away from that vendor becomes part of the Migration Clock too. An organization needs to know that point before it reaches it.
Your clocks are connected to theirs
Seen through the Three Clocks, the issue becomes fairly straightforward. The Data Clock belongs to the information that needs protection. The Quantum Clock remains the uncertain external horizon. The Migration Clock is different. Parts of it may run through suppliers, platforms and technology providers outside the organization.
An organization can therefore do much of the internal work correctly and still find itself short of time. It may know which information matters, where the relevant cryptography sits, who owns the problem and which migrations should begin first. None of that guarantees that every critical dependency will be ready when needed.
So there is one more question worth adding to the migration discussion:
Who else has to move before we can finish?
Finding the answer is only the first step. The organization then needs to decide how long it can afford to wait, what evidence it needs from the supplier and at what point waiting becomes more dangerous than changing course.
Sometimes someone else’s roadmap will become part of your deadline. It should never become an excuse for missing it.
Next: Migration Is Not the End State — why quantum readiness should not end with replacing today’s cryptography, but with making the next cryptographic change easier to manage.
