Why “Wait for the Vendor” Is Not a PQC Strategy

Many organisations assume post-quantum cryptography will be solved by their vendors.

Cloud providers will upgrade their platforms.
SaaS vendors will update their products.

Certificate authorities will change their processes.
Security vendors will release new versions.
Software suppliers will publish migration notes.
Managed service providers will advise when action is required.

Some of that is true.

Vendors will play a major role in post-quantum transition. In many cases, organisations will depend on vendor roadmaps, product updates, firmware upgrades, software libraries, certificates, configuration guidance and support windows.

But “wait for the vendor” is not a strategy.

It is a dependency.

For boards, CEOs, CIOs and risk leaders, the practical question is not:

“Will our vendors eventually support post-quantum cryptography?”

The better question is:

“Do we know which vendors we depend on, what systems they affect, what evidence we need from them, and what we must still control ourselves?”

That is the difference between passive waiting and active readiness.

Vendors matter – but they do not own your risk

Post-quantum cryptography, or PQC, is the transition required because future quantum computers may be able to weaken or break some of today’s widely used public-key cryptography.

NIST finalised its first three post-quantum cryptography standards in August 2024: FIPS 203 for ML-KEM key establishment, FIPS 204 for ML-DSA digital signatures and FIPS 205 for SLH-DSA digital signatures.

The Australian Signals Directorate recommends ceasing the use of traditional asymmetric cryptography by the end of 2030, including RSA, DH, ECDH and ECDSA primitives. ASD also notes that organisations may need to change software libraries according to vendor guidance as part of the transition.

That last point is important.

Vendor guidance matters. But guidance is not the same as organisational readiness.

A vendor may provide an update, but your organisation still needs to know:

• where the product is used;
• what data it protects;
• which business process depends on it;
• whether it integrates with other systems;
• whether changes will break compatibility;
• who owns the configuration;
• whether the update requires testing;
• whether the vendor roadmap aligns with your risk timeline;
• what evidence you need for customers, auditors, insurers or the board.

The vendor may own the product.

You own the business consequence.

The hidden risk is dependency without visibility

Most organisations do not have a complete view of their cryptographic dependencies.

They may know their major platforms: cloud provider, CRM, payroll, payments, document management, identity provider, security tools, website platform and managed IT provider.

But that is not the same as knowing where public-key cryptography is used.

Cryptography may be present in:

• TLS certificates;
• APIs and integrations;
• VPNs and remote access;
• identity federation;
• authentication tokens;
• digital signatures;
• software updates;
• code-signing;
• payment workflows;
• device firmware;
• mobile applications;
• cloud services;
• SaaS platforms;
• vendor support tools;
• bespoke and legacy software.

CISA, NIST and NSA have recommended that organisations prepare for PQC migration by developing a quantum-readiness roadmap, conducting cryptographic inventories, applying risk assessments and engaging technology vendors about their post-quantum roadmaps.

That is the point: vendor engagement is one part of readiness. It is not the substitute for readiness.

If the organisation does not know where cryptography is used, it cannot know which vendors to question first.

“Our cloud (or platform) provider will handle it” is incomplete

For many organisations, the cloud provider will handle some layers of transition.

That may include infrastructure-level cryptographic upgrades, supported libraries, managed certificates, TLS configuration options, key-management services, identity features or product-specific updates.

But cloud does not remove responsibility.

It changes the responsibility model.

The organisation may still need to manage:

• application configuration;
• custom code;
• third-party integrations;
• certificates and domains;
• identity and access-control settings;
• API clients and SDKs;
• mobile and desktop applications;
• data-retention decisions;
• vendor-to-vendor integrations;
• legacy systems connected to cloud services;
• customer assurance evidence.

A cloud provider’s PQC readiness does not automatically make your application, your data flows, your access-control model or your customer-facing service ready.

The question is not whether the provider is moving.

The question is whether your organisation understands what part of the transition remains yours.

SaaS vendors will not all move at the same speed

SaaS platforms are convenient because they externalise product maintenance.

But they also create visibility gaps.

A business may depend on SaaS tools for CRM, HR, payroll, document management, collaboration, marketing, payments, booking, customer service, case management, membership, risk management or operational reporting.

Each vendor may have a different PQC roadmap. Some may move quickly. Some may wait. Some may depend on their own cloud providers. Some may support new standards but require customer configuration changes. Some may not provide clear answers for some time.

ASD recently highlighted vendor readiness as one of the biggest factors influencing an organisation’s ability to transition to PQC within recommended timeframes and released guidance to help organisations assess supplier readiness.

That should change how leaders view vendor risk.

A vendor inventory is not enough.

Organisations need a vendor readiness view:

• Which suppliers process or protect sensitive data?
• Which vendors support critical workflows?
• Which products rely on public-key cryptography?
• Which vendors have published a PQC roadmap?
• Which vendors can provide assurance evidence?
• Which vendors have unclear timelines?
• Which contracts or renewals should include PQC questions?
• Which vendors may become blockers?

This is procurement, risk and continuity work – not just IT administration.

Vendor updates can create internal work

Even when vendors do the right thing, their updates may create work for customers.

A SaaS provider may change certificate requirements.
An API vendor may change supported algorithms.
A payment platform may require SDK updates.
An identity provider may introduce new token-signing or certificate options.
A device vendor may require firmware upgrades.
A software supplier may require clients to update libraries.
A managed service provider may need change windows, testing and approval.

The organisation must then ask:

• Which systems will be affected?
• Who will test the changes?
• What happens if an integration breaks?
• Which customers or staff will be disrupted?
• Can legacy applications support the change?
• Do we need rollback plans?
• Who approves production changes?
• What evidence do we keep after completion?

This is why PQC transition belongs in business continuity planning.

A vendor may provide the patch. The organisation still has to absorb the change.

Bespoke and legacy systems are rarely solved by vendors

Access control is not only a security function. It is an operational function.

If access control fails, business stops.

• Customers cannot log in.
• Staff cannot access records.
• Payments cannot be approved.
• Vendors cannot support systems.
• Administrators cannot make changes safely.
• APIs cannot exchange data.
• Documents cannot be trusted.
• Audit evidence becomes unreliable.

That is why PQC transition should be viewed through the lens of business continuity.

The goal is not simply to replace vulnerable cryptographic algorithms. The goal is to preserve trusted operation while cryptographic foundations change.

A practical transition plan should ask:

• Which access-control systems are business-critical?
• Which systems control access to long-life sensitive data?
• Which identity providers and authentication flows are involved?
• Which workflows depend on digital signatures or signed approvals?
• Which APIs rely on certificate-based trust or signed requests?
• Which vendor-access pathways are poorly documented?
• Which administrative systems would create high impact if disrupted?
• Which bespoke or legacy applications are least able to adapt?

These questions turn PQC from an abstract cryptography problem into a practical continuity program.

Internal planning belongs to you

Vendor engagement should feed into an internal plan.

The organisation still needs to decide:

• who owns PQC readiness;
• which systems are in scope;
• which data categories matter most;
• which vendors are priority;
• which systems require deeper analysis;
• which contracts need review;
• which legacy applications need modernisation;
• which implementation work should be budgeted;
• which evidence should be preserved;
• how progress will be reported to leadership.

This is the difference between a vendor survey and a transition strategy.

A survey collects answers.

A strategy turns answers into decisions.

The Ariadne View

Ariadne’s view is simple:

Vendors are essential to PQC transition, but they cannot be the organisation’s entire strategy.

For many organisations, the real work is not choosing algorithms. It is understanding dependencies, asking better questions, managing evidence, planning change and modernising the systems that vendors do not control.

Ariadne helps organisations with:

• PQC readiness snapshots;
• governance and discovery;
• vendor dependency review;
• cryptographic touchpoint mapping;
• sensitive-data and confidentiality-life analysis;
• access-control and identity workflow review;
• transition strategy and planning;
• secure software modernisation for bespoke and legacy systems;
• private AI knowledge systems to manage vendor responses, evidence and transition documentation.

The goal is not to replace vendor expertise.

The goal is to make vendor dependency visible, manageable and aligned with your organisation’s risk.

The Practical Conclusion

“Wait for the vendor” sounds safe because it feels sensible to rely on product owners.

But it is incomplete.

Vendors will provide important updates, guidance and assurance. Some will move quickly. Some will not. Some will require customer action. Some dependencies will sit outside vendor control altogether.

The organisations that handle PQC transition well will not be those that simply wait.

They will be those that know which vendors matter, which systems are affected, what evidence is needed, which internal responsibilities remain, and which systems require their own planning or modernisation.

Vendor roadmaps matter.

But your organisation still needs its own roadmap.

Ariadne Thread Solutions helps organisations review vendor dependencies, map PQC exposure and develop practical transition plans before vendor uncertainty becomes operational risk.

CTA: Request a Vendor Dependency Review