Buying Technology That Must Last Beyond 2030? Start Asking Post-Quantum Questions Now

Post-quantum cryptography can sound like a problem for a future security team equipped with technology that does not yet exist.

That framing is increasingly difficult to defend.

NIST finalized its first three post-quantum cryptography standards on August 13, 2024 and encouraged organizations to begin transitioning immediately. Canada’s federal roadmap goes further: departments were expected to develop initial migration plans by April 2026, report progress annually, complete high-priority systems by the end of 2031 and migrate remaining systems by the end of 2035.

Those dates may appear distant. Enterprise migration timelines are not.

Many systems being purchased, renewed or modernized today will still be operating in the 2030s. Contracts signed now may determine whether those systems can adopt new cryptographic standards through configuration and software updates—or require expensive replacement.

The first challenge is finding the cryptography

Most organizations cannot produce a complete list of where public-key cryptography is used.

It may be embedded in:

TLS certificates and application gateways
virtual private networks
identity and access-management platforms
API integrations
email encryption
digital signatures and document workflows
code-signing and software-update processes
hardware security modules and key-management services
database clients, message brokers and integration middleware
mobile applications, operational technology and network appliances
vendor-managed SaaS platforms

A conventional asset inventory may identify the product but not the algorithm, key size, certificate, protocol, library, dependency or supplier responsibility involved.

That is why the Canadian Centre for Cyber Security places cryptographic discovery and inventory near the beginning of its migration roadmap. Its recommended inventory includes system components, products and versions, configurations, dependencies, hosting platforms, contracts, expected refresh dates and accountable contacts.

The useful question is not simply, “Do we use RSA or elliptic-curve cryptography?”

It is: Which business services depend on quantum-vulnerable cryptography, how long must their information remain protected, and what would be required to change them?

Prioritize by information lifetime and operational impact

Not every system needs to move at the same time.

Organizations should first identify information exposed to a “harvest now, decrypt later” threat. An attacker may collect encrypted data today and retain it until future capabilities make decryption possible. Information requiring confidentiality for many years may therefore face risk before a cryptographically relevant quantum computer exists.

Priority should also reflect:

the sensitivity and useful lifetime of protected information
the consequences of forged signatures or identities
exposure to external networks
dependence on unsupported hardware or software
the time required to change suppliers or replace equipment
upcoming renewals, modernization initiatives and capital cycles
the availability of standards-compliant replacements

This produces a risk-based transition plan instead of an indiscriminate technology refresh.

It also creates opportunities to combine work. A certificate-management improvement, identity-platform replacement, API-gateway modernization or network-equipment renewal may be the least disruptive point to introduce post-quantum support.

Put cryptographic agility into procurement now

The Cyber Centre recommends that new procurements include support for post-quantum cryptography aligned with its guidance, validated cryptographic modules and cryptographic agility.

Agility is crucial because migration is not a one-time algorithm swap. Standards, protocols, implementations and threat information will continue to evolve.

On July 28, 2026, NIST reported that a vulnerability had been found in HAWK, a digital-signature candidate still under consideration. Its developers withdrew it, and it will not be standardized. NIST explicitly stated that the finding does not affect finalized standards such as ML-KEM and ML-DSA.

The lesson is not to delay migration. It is to avoid building systems around permanently fixed cryptographic assumptions.

Procurement teams can ask suppliers:

Which finalized post-quantum standards does the product support?
Is support available now, planned, or dependent on another vendor?
Can algorithms and parameters be changed without replacing the product?
How are cryptographic components identified and updated?
Are keys, certificates and signatures exposed through standard interfaces?
What performance or compatibility limitations exist?
Will the supplier provide a dated migration roadmap and evidence of testing?
What happens if an algorithm, library or protocol must be retired?
Are subcontractors, cloud services and embedded components covered?

A roadmap without contractual commitments may provide little protection when priorities change.

Test complete workflows, not isolated algorithms

A library successfully generating a post-quantum key does not prove that a business service is ready.

Post-quantum algorithms can introduce different key, ciphertext and signature sizes. Those changes may affect protocols, certificate chains, network appliances, message limits, databases, hardware, latency and monitoring tools.

A useful pilot should follow a complete operational path. For example:

Establish a protected connection using the proposed configuration.
Authenticate users and services.
Process a representative transaction.
Generate and verify required signatures.
Rotate or revoke keys and certificates.
Capture logs and operational evidence.
Exercise failure, rollback and recovery procedures.
Confirm interoperability with every external dependency.

Performance matters, but so do deployment, observability and supportability. A technically secure implementation that cannot be diagnosed or safely rolled back will be difficult to operate.

Hybrid approaches combining classical and post-quantum methods may be appropriate during transition, but teams should follow current cryptographic-authority and protocol guidance rather than designing custom combinations.

Establish ownership across organizational boundaries

This migration cannot sit entirely with a cryptography specialist.

Security teams can define risk and approved approaches. Infrastructure and application teams know where technologies are deployed. Procurement controls future dependencies. Finance aligns changes with lifecycle budgets. Information-management and privacy teams understand how long data remains sensitive. Program owners determine the consequences of service disruption.

A practical initial work plan should:

Assign an executive sponsor and technical migration lead.
Define the inventory schema and discovery methods.
Identify high-value information and critical services.
Map supplier, contract and technology-refresh dependencies.
Add post-quantum and cryptographic-agility questions to procurements.
Select one representative service for an end-to-end pilot.
Record gaps, costs, decisions and target transition dates.
Reassess the inventory and roadmap regularly.

Discovery will not be perfect on the first pass. The objective is to create a maintained capability for understanding cryptographic dependencies—not a spreadsheet completed once and forgotten.

Webster Apps’ perspective

Post-quantum readiness should be incorporated into normal modernization decisions.

A replacement platform, cloud migration or new digital-service procurement should leave the organization more adaptable than before. That includes the ability to identify cryptographic dependencies and change them without redesigning the entire service.

The strongest near-term deliverable is therefore not a claim that an organization is “quantum-safe.” It is a defensible inventory, a prioritized roadmap, procurement requirements and evidence that representative workflows can transition.

Conclusion

Organizations do not need to predict the date of a cryptographically relevant quantum computer to act responsibly.

Standards are available. Canadian milestones are defined. Systems purchased today may remain in service beyond the migration deadlines.

Start by locating cryptography, connecting it to business risk and using planned renewals to reduce future disruption. The organizations that begin now can treat post-quantum migration as managed lifecycle work. Those that wait may face simultaneous replacements, constrained supplier choices and compressed procurement timelines.