In Brief (TL;DR)

Post-quantum cryptography isn't just a PKI or algorithm problem. As cryptographic standards evolve, the impact will reach the technologies that establish and enforce trust across the network, including TLS, IPsec, VPN, ZTNA, SASE and identity controls. Organizations need to understand these dependencies now, build crypto-agility into their architecture and make sure their enforcement layer is ready for the next cryptographic transition.

Most conversations about post-quantum cryptography (PQC) start with algorithms. But for network and security leaders, the bigger challenge may sit further up the stack: at the enforcement layer.

As cryptography changes, many of the technologies responsible for establishing, inspecting and enforcing trust will need to change with it.

That includes:

• TLS

• VPN

• IPsec

• ZTNA

• SASE

• SD-WAN

• Proxies

• Gateways

• Firewalls

• API gateways

• Remote access

• Service-to-service communication

These are no longer simply network technologies. They are places where trust is established, inspected and enforced. And cryptography sits underneath a large part of that trust.

So preparing for post-quantum cryptography isn't just about choosing new algorithms. It means understanding where cryptography is embedded across the network and how those dependencies will affect security enforcement.

Once TLS, IPsec and other protocols start transitioning to new cryptographic mechanisms, the impact does not stop with the protocol itself.

Think about everything we have built around TLS alone: inspection, proxying, certificates, application delivery, load balancing, ZTNA, SASE, API security, service meshes and microservices.

That creates a significant dependency chain.

The same applies to IPsec, VPNs and other technologies that rely on cryptographic mechanisms to establish secure connections and authenticate users, devices, workloads or services.

Changing the underlying cryptography can therefore have implications for the technologies that depend on it, the vendors that provide them and the policies that govern how they are used.

This is why I don't think PQC can sit with the PKI team by itself.

Network security needs to be involved. Identity needs to be involved. Architecture needs to be involved. Cloud needs to be involved too.

The question is no longer simply:

Which PQC algorithm should we use?

It's:

Where does cryptography sit across our enforcement architecture, and what happens when it changes?

I increasingly think about modern cyber controls in three areas: at the Edge, at the Endpoint and in Context.

At the edge, we control connectivity.

At the endpoint, we understand device and workload posture.

In context, we understand identity, privilege, behavior, application, resource and risk.

But ultimately, something has to make the decision: allow, deny, restrict, segment, inspect, step up authentication or terminate.

That is enforcement.

PQC adds another question into that decision process:

Is the cryptography underlying this interaction resilient against future quantum threats?

This matters because cryptography isn't just something happening in the background. It is part of the mechanisms that allow modern security controls to establish trust and enforce policy.

If that foundation changes, the enforcement layer needs to be ready for it.

Zero Trust assumes that trust can be continuously evaluated.

But that trust evaluation relies on mechanisms such as certificates, credentials, tokens, device identity, digital signatures, encrypted sessions and machine identity.

If the cryptography underpinning those mechanisms becomes vulnerable or deprecated, the trust decision itself becomes weaker.

This means cryptographic posture could ultimately become another signal within a Zero Trust security model.

Security teams may increasingly need to understand not only who or what is requesting access, but also how the connection is being secured and whether the cryptographic mechanisms behind it are ready for a post-quantum future.

PQC therefore adds another dimension to Zero Trust: cryptographic resilience.

The enforcement layer needs to be capable of evaluating and responding to that risk alongside identity, device, application and behavioral signals.

One of the challenges with post-quantum cryptography migration is that cryptographic dependencies aren't always obvious.

An organization might know which certificates it has, for example, but have less visibility of every application, network security platform, proxy, API, workload or service that relies on them.

The same is true for network protocols.

A firewall might support a particular cryptographic mechanism, but what about the SASE platform sitting alongside it? The VPN infrastructure? The identity provider? The application delivery layer? The API gateway? The service-to-service connections running in the cloud?

PQC migration therefore needs to look beyond individual products.

It needs to consider the relationships between technologies and understand where cryptography is being used to establish and enforce trust.

This is where crypto-agility becomes important.

The ability to change cryptographic mechanisms without having to redesign an entire architecture will become increasingly valuable as organizations transition toward quantum-resistant cryptography.

The organizations that understand their cryptographic dependencies now will be in a much stronger position to make those changes when they are needed.

This is an area where Xalient can bring together capabilities that are often treated separately when planning for post-quantum cryptography.

We can help organizations assess:

• Network encryption dependencies across TLS, VPN and IPsec

• TLS and certificate usage across applications and services

• ZTNA and SASE architecture and their cryptographic dependencies

• Identity-aware enforcement across users, devices and workloads

• Machine and workload identity

• PKI and certificate lifecycle management (CLM) maturity

• Vendor support for PQC

• Zero Trust policy architecture

• Crypto-agility requirements and the ability to change cryptographic mechanisms without major architectural disruption

The goal is to move beyond simply asking whether a firewall, SASE platform or VPN supports PQC.

The bigger question is how the entire enforcement architecture behaves when the cryptographic foundation changes.

That is where the real work is.

Post-quantum cryptography is often presented as a future problem. But the decisions organizations make today about architecture, identity, certificates, network security and technology dependencies will shape how difficult that transition becomes.

The organizations that start by mapping where cryptography is being used, understanding their dependencies and building crypto-agility into their architecture will be better placed to respond as standards and technologies evolve.

PQC isn't just an algorithm problem.

It's an architecture problem.

And increasingly, it's an enforcement problem too.