Post-Quantum Readiness: Why Protecting the Network Is Not Enough

I recently published an article on LinkedIn as part of my ongoing writing on post-quantum readiness. The article, “Quantum Cryptography Requires Ongoing Management,” explored why cryptographic discovery and crypto-agility should be treated as continuing management responsibilities rather than one-time technology exercises.

In the discussions that followed, one question kept coming up, particularly in conversations with senior government colleagues:

Why do we need to go through all this work identifying applications, certificates and cryptographic dependencies? Why not simply put a quantum-safe protective layer around the enterprise network and leave the applications alone?

It is a reasonable question.

For a large government organization with hundreds or even thousands of applications, the idea is attractive. If the network can be protected end to end using post-quantum cryptography, perhaps the organization could avoid the cost and complexity of examining every application individually.

Unfortunately, that would solve only part of the problem.

The reason is relatively simple:

Post-quantum readiness is not just a network-encryption problem. It is an enterprise cryptographic dependency problem.

A quantum-safe network can protect data while it moves between systems. But applications, platforms and services may still rely independently on vulnerable cryptography for authentication, digital signatures, certificates, APIs, database connections, software signing, identity services and the protection of data at rest.

In other words, the network may be quantum-safe while important parts of the enterprise are not.

That distinction is at the heart of the post-quantum migration challenge.

The Network Protects Only One Layer

Network encryption is essential.

Secure tunnels, VPNs, encrypted network links, gateways and transport-level protections will all have an important role in the transition to post-quantum cryptography.

But cryptography exists throughout the technology environment.

Applications may independently use cryptographic mechanisms for:

• User and system authentication

• Digital signatures

• Application and server certificates

• API authentication

• Database connections

• Encryption of stored information

• Document signing

• Software and firmware signing

• Identity and access-management services

• Machine-to-machine communications

• Key exchange

• Cloud services

• Third-party integrations

A quantum-resistant network tunnel does not automatically replace the cryptography being used inside those applications and services.

Consider a relatively simple example.

An application communicates with another system through a quantum-safe network connection. The traffic travelling between the two systems may therefore be well protected.

But the application may still authenticate the receiving system using a certificate based on a quantum-vulnerable public-key algorithm.

A transaction may still be digitally signed using vulnerable cryptography.

A database connection may rely on an older key-exchange mechanism.

An application update may still depend on a vulnerable software-signing certificate.

The network connection may be protected while significant cryptographic dependencies inside the environment remain exposed.

Encryption Is Only One Use of Cryptography

One of the risks in discussing post-quantum migration is treating the words encryption and cryptography as though they mean the same thing.

They do not.

Encryption is one important use of cryptography, but modern digital environments depend on cryptography for much more than keeping information confidential.

Public-key cryptography is also fundamental to establishing trust.

It helps organizations answer questions such as:

Who are you?

Can I trust this system?

Did this message actually come from the claimed sender?

Was this document altered?

Is this transaction authentic?

Did this software really come from the organization that claims to have produced it?

Those functions may depend on digital certificates, public-key infrastructure, digital signatures, cryptographic libraries and identity systems operating at the application, platform and infrastructure levels.

Protecting the network does not remove those dependencies.

This becomes particularly important in government environments, where systems may be required to preserve the confidentiality, authenticity and integrity of information for many years.

The Real Challenge Is Knowing Where Cryptography Exists

This is why cryptographic discovery should be one of the earliest activities in a post-quantum readiness program.

NIST and other standards organizations have emphasized the need for organizations to understand where quantum-vulnerable public-key cryptography is being used across hardware, software and services.

This discovery process is sometimes described as creating a cryptographic inventory, or in more mature implementations, a Cryptographic Bill of Materials (CBOM).

But the purpose should not simply be to create another technology inventory.

The real objective is to understand the organization's cryptographic dependencies well enough to make informed risk, investment and migration decisions.

That requires answering questions such as:

Where is public-key cryptography being used?

Which applications and business services depend on it?

What information is being protected?

How long does that information need to remain protected?

Which certificates and cryptographic libraries are involved?

Which components can be upgraded internally?

Which systems depend on vendors for remediation?

Which applications are scheduled for retirement?

Which systems will still be operating ten or fifteen years from now?

Where would a cryptographic failure create the greatest operational, financial or security impact?

Without this level of visibility, an organization risks attempting a major cryptographic transition without knowing the size or shape of the problem.

This Does Not Mean Remediating Every Application Immediately

There is an important distinction here.

The requirement to discover cryptographic dependencies does not mean that every application must immediately be rebuilt, replaced or modified.

That would be unnecessarily expensive and, in many organizations, operationally impossible.

The objective should be risk-based prioritization.

A public information website does not have the same risk profile as a system storing sensitive personal information, classified information, financial transactions, health records or long-lived government data.

Similarly, an application scheduled to be retired within two years may warrant a very different migration strategy from a platform expected to remain operational for another fifteen years.

Some systems may be remediated.

Others may be replaced.

Some may be isolated or protected through compensating controls.

Others may simply be retired before post-quantum migration becomes necessary.

But those decisions can only be made intelligently if the organization first understands the cryptographic dependencies involved.

This is where cybersecurity, enterprise architecture, asset management, procurement and program governance need to converge.

The organization needs to understand not simply what technology it owns, but which business outcomes, services and information assets depend on vulnerable cryptography.

Applications Are Part of a Larger Trust Chain

There is another reason the application layer cannot simply be ignored.

Modern government services rarely operate as isolated systems.

An application may depend on:

• An identity provider

• An API gateway

• A cloud platform

• Another government department

• A commercial software product

• An external payment service

• A managed security service

• A certificate authority

• Open-source software libraries

• Third-party data services

• Software-as-a-Service providers

This creates chains of cryptographic dependency.

An organization could successfully transition its internal network infrastructure while remaining dependent on a vendor whose product still relies on quantum-vulnerable cryptography.

Similarly, a government application could be quantum-ready internally while depending on an external identity provider, cloud service or API that is not.

Post-quantum readiness therefore becomes not only a cybersecurity issue, but also a supply-chain and procurement issue.

Government organizations will increasingly need to ask suppliers questions such as:

What cryptographic algorithms does your product use?

Where are they used?

What is your post-quantum migration roadmap?

Can cryptographic algorithms be changed without replacing the entire product?

How will future post-quantum upgrades be delivered?

What dependencies exist on third-party cryptographic libraries?

These questions will eventually need to become part of architecture reviews, security assessments and procurement requirements.

The "Harvest Now, Decrypt Later" Issue Makes Prioritization More Urgent

There is also a time dimension to the problem.

An adversary does not necessarily need a cryptographically relevant quantum computer today to create future risk.

Sensitive encrypted information can potentially be captured now and retained for later decryption once sufficiently capable quantum computing becomes available.

This is commonly referred to as harvest now, decrypt later.

That does not mean every government system is equally exposed.

It does mean that organizations should identify information whose sensitivity persists over long periods.

If information must remain confidential for ten, twenty or more years, the migration decision may need to occur considerably earlier than it would for information with a very short useful life.

Once again, this cannot be understood simply by examining the network.

The organization needs to know what information exists, where it resides, which applications process it and what cryptography protects it.

Crypto-Agility May Ultimately Be More Important Than the First Migration

There is another lesson emerging from the post-quantum discussion.

Organizations should resist treating PQC as a one-time technology replacement project.

The objective should not simply be:

Replace today's vulnerable algorithm with today's post-quantum algorithm and declare the problem solved.

Cryptographic standards will continue to evolve.

Algorithms may eventually be replaced.

Implementation weaknesses may be discovered.

Regulatory requirements may change.

New threat models will emerge.

Technology environments will continue to change.

For this reason, one of the most important capabilities an organization can develop is cryptographic agility, the ability to change cryptographic algorithms, certificates, keys and related mechanisms without having to redesign entire systems.

That has significant implications for future system architecture and procurement.

Future government systems should not merely be designed to be quantum-safe.

They should be designed so that their cryptographic components can be identified, managed and changed when necessary.

Discovery Cannot Be a One-Time Exercise

This brings us back to another issue I raised in my recent LinkedIn article.

A cryptographic inventory created today will begin becoming obsolete almost immediately.

Applications change.

Certificates expire and are replaced.

Cloud services evolve.

Vendors update products.

New integrations are introduced.

Systems are retired.

New systems enter the environment.

Cryptographic libraries change.

If post-quantum readiness is treated as a one-time discovery and remediation exercise, the organization may eventually find itself with the same visibility problem that it started with.

The more sustainable model is therefore cyclical:

Discover. Assess. Prioritize. Transform. Assure. Monitor. Rediscover.

Cryptographic discovery should eventually become part of normal enterprise technology and cybersecurity management rather than something performed only because quantum computing created a new threat.

This is one of the reasons crypto-agility and cryptographic asset management are likely to become important long-term capabilities.

What Should Public-Sector Leaders Do Now?

For many organizations, the challenge appears overwhelming.

Thousands of applications.

Thousands—or potentially millions—of certificates and keys.

Multiple cloud environments.

Third-party suppliers.

Legacy infrastructure.

Complex identity systems.

Years of accumulated technology.

The solution is not to attempt to remediate everything at once.

A more practical starting point is to ask a relatively small number of executive questions.

1. What are our most important services and information assets?

Start with business importance rather than technology volume.

2. Where do those services depend on public-key cryptography?

Identify the applications, platforms, infrastructure and suppliers supporting them.

3. Which information must remain protected for many years?

Long-lived sensitive information may require earlier action because of harvest-now-decrypt-later risk.

4. Which systems will be difficult to migrate?

Legacy applications, embedded systems, proprietary products and vendor-controlled platforms may require significantly longer transition periods.

5. Where are we dependent on third parties?

Supplier readiness may ultimately determine the organization's own readiness.

6. Do our future architectures and procurements require cryptographic agility?

Avoid creating tomorrow's legacy cryptographic problem while solving today's.

From there, organizations can progressively build a prioritized cryptographic inventory and migration roadmap.

The distinction is important.

The objective is not to find every certificate simply because it exists.

The objective is to understand enough of the cryptographic landscape to make defensible risk, architecture and investment decisions.

The Network Is Part of the Answer it is Not the Whole Answer

So, can government simply place a quantum-safe protective layer around the enterprise network and leave the applications alone?

In some circumstances, network-level protection may provide a useful interim or compensating control.

It may reduce particular risks.

It may buy time while difficult systems are being remediated.

And it will almost certainly be one component of future post-quantum architectures.

But it cannot substitute for understanding the cryptography embedded throughout the enterprise.

Applications establish identities.

Certificates establish trust.

Digital signatures establish authenticity and integrity.

Databases protect stored information.

APIs connect organizations and services.

Software signatures protect the technology supply chain.

Cloud platforms create additional cryptographic dependencies.

Third-party suppliers extend the trust chain beyond the organization's own boundaries.

All of these can contain cryptographic dependencies that exist independently of the network carrying the traffic.

The organizations that manage the post-quantum transition most effectively will therefore be those that treat it not simply as an encryption upgrade, but as an enterprise risk, architecture and governance transformation.

The question is no longer simply:

"Is our network quantum-safe?"

The more useful question is:

"Do we know where our organization depends on cryptography, and can we change it when we need to?"

That is the foundation of genuine post-quantum readiness.

About the Author

Imran Mirza is an executive technology and assurance advisor with extensive experience in public-sector digital transformation, cybersecurity governance, independent verification and validation, and major technology transformation initiatives. His current research and advisory work includes post-quantum readiness, AI governance, cryptographic agility and outcome-focused technology assurance.

Strategic Services Consulting
A Division of 2372617 Ontario Inc.