PQC Roadmap vs PQC Migration Roadmap: What Enterprises Need to Know

Brian Couzens

Aug 14

9 min read

When Is a PQC Roadmap Not a PQC Roadmap?

Why a cloud provider's PQC roadmap is not the same thing as an enterprise post-quantum migration roadmap

The post-quantum cryptography industry has a terminology problem.

We are increasingly seeing vendor roadmaps presented, discussed and referenced as though they describe how an organisation should migrate to post-quantum cryptography.

They do not.

They may be extremely useful.

They may be technically sophisticated.

They may contain detailed milestones, algorithms, services and target dates.

But a technology provider's PQC roadmap is not automatically an enterprise PQC migration roadmap.

The distinction matters.

And the recently published Google Cloud PQC roadmap is a good example of why.

The Google Cloud PQC roadmap

On 11 August 2026, Google published its updated Google Cloud post-quantum cryptography roadmap, setting out its ambition to achieve full PQC readiness across Google Cloud by 2029.

Google describes the roadmap around three major domains:

Store Now, Decrypt Later mitigation
Integrity and non-repudiation
Foundations and key management

It then maps these domains to customer journeys, Google Cloud products and services, and target completion dates. Google states that most services are expected to meet their respective target dates, while also noting that individual product timelines may change because of engineering requirements and third-party dependencies.

This is useful information.

Very useful information for Google Cloud customers.

It tells them where Google is going, what capabilities are becoming available, and when.

But that is precisely the point.

It is a Google Cloud roadmap.

It is not an enterprise-wide roadmap for becoming quantum safe.

So what is the confusion?

The confusion is subtle.

Nobody seriously argues that a cloud provider should publish a complete migration plan for every customer.

That would be impossible.

The problem occurs when a vendor capability roadmap becomes interpreted as a generic PQC migration framework.

The two answer different questions.

A vendor roadmap asks:

When will this provider's infrastructure, products and services support the required PQC capabilities?

An enterprise migration roadmap asks:

What does this organisation need to change, in what order, based on what risk, and how will it demonstrate that the migration is complete?

Those are not the same question.

A cloud roadmap is therefore an input to a migration programme.

It is not necessarily the migration programme itself.

That distinction is becoming increasingly important as PQC roadmaps are circulated through LinkedIn, technical articles, presentations and academic material without always making the boundary between the two explicit.

This is not a criticism of Google's roadmap

In fact, the opposite is true.

The Google roadmap is considerably more comprehensive than a simple product release calendar.

Google explicitly describes a risk-based approach and identifies three major areas of concern: confidentiality against Store Now, Decrypt Later attacks, integrity and non-repudiation, and the foundations required for cryptographic agility.

It also includes customer actions around:

inventory
software updates
testing
application behaviour
asymmetric key lifecycle management
quantum-safe configuration

Google's roadmap also explicitly distinguishes between:

Google's responsibility: security of the cloud

and

Customer's responsibility: security in the cloud.

That distinction is important.

Because it demonstrates exactly where a vendor roadmap ends and an enterprise migration programme begins.

A roadmap is not the same thing as a migration framework

Consider the structure of the Google roadmap.

Google identifies specific journeys and maps them to representative services.

For example, the roadmap addresses customer workloads, administrative and developer flows, data pipelines, software supply chains, certificates, identity and access, key management, hardware-backed cryptographic services and partner solutions.

That is exactly what a cloud provider should be doing.

But an enterprise still has to determine:

Which of our systems are affected?

Which of our applications depend upon these services?

Which systems sit outside Google Cloud?

Which suppliers introduce additional cryptographic dependencies?

Which trust chains cross organisational boundaries?

Which legacy systems cannot yet migrate?

Which risks are material to the business?

Who owns those risks?

What constitutes completion?

Those questions cannot be answered by a Google Cloud product roadmap because they are not Google Cloud questions.

They are enterprise questions.

The roadmap problem: availability versus readiness

This is perhaps the most important distinction.

A vendor roadmap measures capability availability.

An enterprise migration programme needs to measure organisational readiness.

For example:

2027: PQC capability becomes available for Service X.

That is a legitimate product milestone.

But an enterprise cannot reasonably translate that directly into:

2027: System X is quantum safe.

There is a missing chain of work between those two statements.

The enterprise may need to:

Discover → Assess → Prioritise → Design → Test → Migrate → Validate → Accept

The vendor controls only part of that chain.

This is why the existence of a PQC-enabled cloud service does not automatically mean that the applications using that service are quantum ready.

Google itself makes this distinction

Google's announcement is particularly useful here because it does not pretend otherwise.

Google states that organisations remain responsible for their own applications, including updating client-side software to negotiate PQC handshakes, managing the lifecycle of asymmetric keys and updating Google Cloud configurations with quantum-safe settings and policies.

Google then recommends three immediate customer actions:

1. Inventory

Identify cryptographic resources such as keys and certificates and map their usage across the organisation.

2. Update

Ensure development and SRE teams use software capable of supporting PQC algorithms and quantum-safe connections.

3. Validate

Test existing application behaviour against quantum-safe APIs and load balancers to identify architectural bottlenecks before production migration.

Those are sensible recommendations.

But notice what they tell us.

The cloud provider's roadmap and the customer's migration activity are complementary.

They are not interchangeable.

The enterprise roadmap sits above the vendor roadmaps

This is where organisations need to change their thinking.

A mature enterprise does not have one PQC roadmap.

It may have many.

There may be:

a Google Cloud roadmap
an AWS roadmap
an Azure roadmap
a browser roadmap
a PKI roadmap
an HSM roadmap
an identity roadmap
a network roadmap
a software supply-chain roadmap
a SaaS supplier roadmap
a hardware replacement roadmap

Each tells the organisation something useful.

But none of them, individually, represents the enterprise migration.

The enterprise roadmap needs to sit above them.

It needs to orchestrate those dependencies.

That is the difference between tracking vendor readiness and managing enterprise readiness.

What should an enterprise PQC roadmap contain?

A genuine enterprise PQC roadmap needs to establish a sequence of outcomes rather than simply a sequence of product releases.

At minimum, it should answer:

1. What do we have?

A cryptographic inventory.

Not just applications.

Not just certificates.

Not just cloud services.

The objective is visibility across the cryptographic estate and its dependencies.

NIST's Migration to PQC work similarly places significant emphasis on discovery and inventory, with its migration project demonstrating how organisations can identify where cryptography protects important data and digital systems and use that information to support prioritisation.

2. What matters most?

Not every cryptographic dependency carries the same risk.

Migration needs prioritisation based on factors such as:

data sensitivity
confidentiality lifetime
business criticality
exposure
dependency concentration
exploitability
migration complexity
supplier dependency

This is particularly important for Store Now, Decrypt Later exposure, where data captured today may remain sensitive long after the underlying cryptographic technology has been replaced.

3. What depends on what?

This is where a simple application inventory starts to become insufficient.

Cryptographic dependencies can cross:

applications → APIs → identity → PKI → certificates → HSMs → suppliers → cloud services → hardware

A migration roadmap needs to understand those relationships.

Otherwise, an organisation can declare one component migrated while leaving the trust chain around it vulnerable.

4. What can actually migrate?

A theoretical migration path is not necessarily an operational migration path.

Organisations need to test:

protocol compatibility
performance
certificate behaviour
key sizes
application dependencies
hardware support
library support
interoperability
operational impact

PQC changes can introduce practical engineering constraints, particularly around certificates, signatures, protocol messages and infrastructure components.

5. When is a system actually ready?

This is where many roadmaps become weak.

A date is not a readiness criterion.

A system should have defined entry and exit criteria for migration.

For example:

Discovery complete

Risk classification complete

PQC architecture approved

Dependencies validated

Migration tested

Production deployment complete

Evidence collected

Residual risk accepted

That creates an auditable migration state rather than a calendar milestone.

The problem with calling a product roadmap the "gold standard"

This is where the terminology becomes dangerous.

Calling a vendor roadmap a gold standard for PQC transformation creates an expectation that the roadmap describes the transformation discipline itself.

It does not.

The Google roadmap is a strong example of a provider mapping its own technology transition.

It is not a generic enterprise transformation methodology.

And that distinction matters because a roadmap can be technically excellent while still being incomplete for another purpose.

A railway timetable is not a railway construction plan.

A software release schedule is not an enterprise transformation strategy.

A cloud provider's PQC roadmap is not an enterprise cryptographic migration framework.

The problem is not the roadmap.

The problem is what we claim the roadmap represents.

Why the dates can also create confusion

Google's roadmap has clear target dates.

That is useful.

The roadmap identifies 2027 targets for Store Now, Decrypt Later mitigation and 2028 targets for integrity and non-repudiation and foundations and key management, with the broader Google Cloud PQC transition converging on 2029. Google also states that work will continue beyond 2029 as standards and industry requirements evolve.

These dates provide useful planning signals.

But they should not be converted into an enterprise statement such as:

"Our PQC migration is complete in 2029 because our cloud provider is PQC ready in 2029."

That would be a category error.

The enterprise may have cryptographic dependencies that:

sit outside the cloud provider
depend upon third parties
involve legacy hardware
require PKI changes
require application redesign
require supplier remediation
depend upon standards that are still evolving
cannot be migrated at the same pace as cloud infrastructure

The vendor date therefore becomes one dependency in the enterprise roadmap.

It does not become the enterprise roadmap.

The Y2K analogy makes the distinction worse

This is also why the increasingly common Y2K analogy deserves caution.

Y2K was fundamentally a deterministic date-related engineering problem.

PQC is not.

There is no single guaranteed quantum-computing date at which every vulnerable cryptographic system suddenly fails.

Instead, organisations are managing uncertainty across:

quantum computing development
cryptanalytic advances
migration timescales
data confidentiality lifetimes
technology dependencies
implementation risks
standards evolution
supplier readiness

NIST's migration work reflects this reality by focusing on discovery, inventory, interoperability, performance and risk management rather than simply working towards a single date.

The objective should therefore not be:

"Reach the vendor's PQC date."

It should be:

"Reduce and evidence quantum-related cryptographic risk across the enterprise."

Those are fundamentally different objectives.

The roadmap hierarchy

A useful way to think about this is as a hierarchy.

Level 1: Vendor roadmap

What will the technology provider deliver, and when?

Level 2: Technology migration roadmap

Which enterprise systems will consume those capabilities?

Level 3: Enterprise PQC roadmap

Which cryptographic dependencies will be migrated, in what sequence, and based on what risk?

Level 4: Assurance

What evidence demonstrates that the intended migration actually occurred and that residual risk is understood and accepted?

The first level is necessary.

It is not sufficient.

The question every PQC roadmap should answer

There is a simple test.

Take the vendor name off the roadmap.

Remove the product names.

Remove the release dates.

Then ask:

Could an enterprise use what remains to determine how it will reduce its quantum-related cryptographic risk?

If the answer is no, you probably have a vendor roadmap, not an enterprise migration roadmap.

And that is perfectly acceptable.

The roadmap does not need to be something it isn't.

The real value of the Google roadmap

The correct interpretation of Google's announcement is therefore not:

"This is Google's complete model for how enterprises should become quantum safe."

It is:

"This is Google's roadmap for moving Google Cloud towards PQC readiness, together with the capabilities and actions Google expects its customers to engage with."

That is valuable.

It gives customers visibility.

It provides planning signals.

It shows where PQC capability is becoming available.

It identifies important technical domains.

It helps organisations understand where their Google Cloud dependencies may fit into a broader migration programme.

That is exactly what a good vendor roadmap should do.

But organisations should resist the temptation to promote it into something else.

A PQC roadmap is an input, not an outcome

This is ultimately the distinction.

A vendor roadmap tells you:

what is becoming available.

An enterprise roadmap needs to tell you:

what needs to change.

And an assurance framework needs to tell you:

whether the change actually achieved its intended risk outcome.

Those three things are connected.

They are not the same thing.

The industry should therefore stop using PQC roadmap, PQC migration roadmap and PQC transformation framework as though they are interchangeable terms.

They are not.

And as more vendors publish increasingly sophisticated PQC roadmaps, the distinction will become more important, not less.

Because the risk is not that organisations will fail to find a PQC roadmap.

The risk is that they will find one, follow it faithfully, and mistake vendor readiness for enterprise readiness.

That is the confusion we need to eliminate.

The Bottom Line

Google's PQC roadmap is useful.

It is detailed.

It is risk-oriented.

It provides concrete technology milestones.

It gives Google Cloud customers something they can actually plan against.

But it is still a Google Cloud roadmap.

The enterprise PQC roadmap has to sit above it.

It needs to connect vendor capability to cryptographic inventory, business risk, dependencies, migration sequencing, architecture, testing, validation and residual-risk decisions.

The difference can be expressed simply: