Post-quantum cryptography (PQC) is designed to protect data and authentication systems against future quantum computers capable of breaking cryptographic methods widely used today. For CIOs, CISOs and CTOs, a cloud provider’s PQC readiness does not establish the readiness of every application, client, key and hardware dependency running on that provider.
Providers control some components. Customers and other suppliers control others, while standards bodies influence the migration path. Enterprise readiness therefore depends on knowing who controls each cryptographic dependency and when it can change.
The practical goal is crypto agility: the ability to change cryptographic methods as standards and provider capabilities evolve without a disruptive migration each time.
Post-quantum cryptography readiness depends on ownership
A cloud provider can update infrastructure under its control, but customer-managed dependencies still require changes. Applications, cryptographic assets, client software, service configurations and key lifecycle practices can all sit on the customer side of that boundary.
An incompatible client, for example, cannot use a new cryptographic option until it is updated. A team must identify a cryptographic dependency before it can determine whether the enterprise, its cloud provider or another supplier controls its migration.
This makes crypto agility an architectural requirement. If a cryptographic dependency is embedded in an incompatible client, a legacy software component or a hardware lifecycle, changing the algorithm also requires changing that dependency.
Post-quantum cryptography has different migration paths
Confidentiality creates one migration path. Store Now, Decrypt Later describes an attack in which encrypted information is captured today for decryption after sufficiently capable quantum systems become available. The risk already matters for information that must remain confidential for many years.
Authenticity creates another path. Forged credentials and software signatures pose a different migration problem from captured encrypted traffic. Certificates, identities and other trust mechanisms also have to change.
Hardware and legacy software introduce further constraints because their replacement can depend on upgrade and refresh cycles. Readiness to migrate and retirement of older cryptography can therefore follow different schedules.
A project in mind?
Schedule a 30-minute meeting with us.
Senior experts helping you move faster across product, engineering, cloud & AI.
Some dependencies sit outside customer control
Enterprises depend on provider infrastructure and external standards for parts of the migration they cannot change directly. Other dependencies remain under enterprise control.
For enterprise planning, this creates three ownership groups: provider-controlled infrastructure, standards-dependent mechanisms and customer-controlled systems. Long-lived confidential data should be examined for Store Now, Decrypt Later exposure. Signature, certificate and identity dependencies require their own migration planning. Hardware and legacy software then need to be mapped to whichever path they constrain.
The practical control is an ownership map. It should identify dependencies the enterprise can change directly, those that require provider capabilities, and those governed by standards or other suppliers. That map gives engineering teams a basis for testing customer-controlled clients and applications as the required external capabilities become available.
Key takeaways for decision-makers
- Map cryptographic ownership: Cloud provider readiness does not make customer applications, clients, keys and hardware quantum-safe. Leaders should identify who controls each dependency and where migration depends on providers, standards or other suppliers.
- Plan for different migration paths: Confidentiality, authentication, hardware and legacy software face different post-quantum risks and timelines. Prioritize long-lived sensitive data while planning separately for certificates, signatures, identities and slower technology refresh cycles.
- Build crypto agility around external dependencies: Some cryptographic changes depend on cloud providers, standards bodies and suppliers. Leaders should build crypto agility and test customer-controlled systems as external capabilities become available.
A project in mind?
Schedule a 30-minute meeting with us.
Senior experts helping you move faster across product, engineering, cloud & AI.
