Council Post: Post-Quantum Security Starts With Visibility

Scott Alldridge is CEO of IP Services, a visionary leader, and author of the bestselling VisibleOps book and series.

getty

​Most organizations are likely to approach post-quantum cryptography (PQC) as an algorithm replacement project. Replace RSA and elliptic-curve cryptography, update certificates, refresh libraries and check the “quantum ready” box.

That view is too narrow. Cryptography is embedded throughout applications, identity platforms, APIs, cloud services, firewalls, load balancers, proxies, certificate authorities, VPNs and software libraries. Sitting in the middle of much of that infrastructure is TLS.

That’s why I believe post-quantum migration is primarily an operational visibility and architecture problem. One recurring idea in my VisibleOps Cybersecurity work is that organizations can’t effectively govern or secure what they can’t see. PQC requires the same discipline.

The Algorithm Is Only The Starting Point

NIST has standardized major post-quantum algorithms, including ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. However, standardizing an algorithm is very different from migrating an enterprise.

Public-key cryptography is embedded across TLS, VPNs, APIs, certificates, identity systems, software signing, cloud workloads and machine-to-machine communications. Many organizations don’t have a complete inventory of those dependencies.

The first question should be whether you know where your existing cryptography is being used. You can’t migrate cryptography you can’t see.

Why TLS Matters

TLS deserves special attention because it connects users, applications, APIs, cloud services and infrastructure. A system may support PQC, but that doesn’t mean a production connection actually used it.

A server and client may both support a post-quantum mechanism, but the connection may pass through a CDN, firewall, WAF, reverse proxy, load balancer or API gateway that terminates TLS and creates a new session. From the user’s perspective, a transaction may look like one secure HTTPS connection. From the infrastructure perspective, it may involve several TLS sessions, each with its own key exchange, certificate and trust chain.

Organizations need to understand where TLS is negotiated, terminated, inspected and reestablished.

Hybrid TLS And The Transition

The industry is moving toward hybrid approaches that combine classical cryptography with post-quantum mechanisms.

Hybrid TLS can combine an existing mechanism such as X25519 with ML-KEM. That’s pragmatic because legacy systems, network appliances, third-party software and cloud services will migrate at different speeds.

However, hybrid deployment introduces an important requirement: Organizations must verify what was actually negotiated. Supporting ML-KEM isn’t the same as using ML-KEM. A product specification showing PQC support doesn’t prove production traffic is receiving that protection.

‘PQC Enabled’ Needs More Precision

Executives will increasingly hear vendors say, “We support post-quantum TLS.” The immediate question should be: Which part?

TLS relies on multiple cryptographic functions. Key establishment is one. Authentication and digital signatures are another. ML-KEM addresses post-quantum key establishment. Certificates and their signatures address authentication. A connection could use post-quantum key establishment while still relying on classical signatures elsewhere in the certificate chain.

Post-quantum key establishment doesn’t automatically mean complete post-quantum TLS.

Capability Is Not Assurance

Cybersecurity has seen this problem before. An organization deploys an endpoint security platform and assumes its devices are protected. Later, it discovers some systems never received the agent, others stopped reporting, and critical servers were excluded. The technology and the control existed, but the evidence didn’t support the assumption.

PQC can create the same gap. A system can be capable of ML-KEM without negotiating it. A browser can support hybrid TLS while a network appliance terminates the connection using classical cryptography.

I would recommend thinking about maturity this way: capability, configuration. negotiation, verification, evidence. For executives and boards, one is being told that a capability exists. The other is having evidence that it’s operating as intended.

Crypto-Agility Is The Bigger Objective

The larger architectural objective should be crypto-agility. If organizations replace today’s cryptography only to hard-code tomorrow’s algorithms into applications, they may solve the immediate problem without solving the underlying one.

The better question is how they can make future cryptographic changes easier and less disruptive. That means designing systems so algorithms, certificates and policies can be changed without major application redesign. Organizations should evaluate not only what cryptography a product supports today but how easily it can be replaced tomorrow.

From Inventory To Evidence

A cryptographic bill of materials (CBOM) can help identify where algorithms, keys, certificates and cryptographic libraries exist. However, a static inventory should only be the beginning. The more mature capability is cryptographic observability.

A traditional inventory may tell us that a server supports TLS 1.3. Operational visibility could tell us what percentage of connections actually used the approved post-quantum or hybrid mechanism and which legacy clients caused fallback to classical cryptography.

That moves an organization from understanding what systems can do to understanding what systems actually did.

Where To Start

Organizations don’t need to predict the exact arrival date of a cryptographically relevant quantum computer before beginning meaningful work. The dependencies, technical debt, legacy infrastructure and long-lived sensitive information already exist.

Start with the information that would still create material risk if it were decrypted years from now. Then, discover the cryptography protecting it, map TLS termination points, understand certificate and PKI dependencies, identify legacy systems, test hybrid mechanisms and measure what’s actually being negotiated. Then, retain the evidence.

The algorithms may be new, but the operating principle isn’t: You can’t migrate what you can’t see. You should also be cautious about claiming security you can’t prove.

The organizations that navigate the post-quantum transition most effectively will be those that understand where their cryptography exists, can change it without disrupting the business and can demonstrate that the controls they intended to deploy are actually operating.

That’s crypto-agility and operational assurance, and that’s where post-quantum readiness really begins.​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?