Post-quantum cryptography (PQC), and the many ways it intersects with IT and cybersecurity, is becoming increasingly important to organizations of every size. While it seemed like an esoteric concept a few years ago, relegated to cryptographers' conference talks, it’s now something that comes up in many of our customer conversations. In this blog, I’ll outline a few of the challenges around PQC and explain how network visibility provides a distinct advantage when it comes to identifying and migrating systems to a post-quantum world.
First, a quick PQC primer for context. Modern cryptography does its work to protect our private data and communications in two parts:
Every TLS session and SSH connection in your environment uses both. The asymmetric half establishes trust and negotiates the keys, then the symmetric half encrypts the traffic.
Symmetric encryption like AES holds up well against quantum attack, and the research on that has grown more confident rather than less. So the encryption protecting your data isn't the problem. The asymmetric half (trust and key agreement) is the part quantum computing currently threatens, so let’s focus on that.
RSA and ECC are secure because they rely on math problems that are expensive but not impossible: factoring very large numbers, and solving discrete logarithms. No classical computer can currently solve those problems in a realistic amount of time. But Shor's algorithm, published in 1994, changes that possibility on a quantum computer. It converts a previously infeasible problem into something that is actually solvable. The machine capable of solving it at scale is what gets called a cryptographically relevant quantum computer, or CRQC. It doesn't exist yet, and estimates for when it might be ready to challenge current encryption range across decades. Post-quantum cryptography is the replacement for that asymmetric layer, built on math problems that no known quantum algorithm can solve efficiently.
One of the first assumptions people make when discussing PQC is that because the cryptographic algorithms protecting most of our online communications aren’t yet compromised by a CRQC, we must be safe and able to defer the problem for a while. Unfortunately, it’s well established that advanced adversaries (think nation states and APT groups) are actually harvesting and storing traffic for the future when those current crypto systems can be broken. That stored traffic could then be decrypted in the future and allow attackers to unearth the private information inside. This is the class of attacks known as Harvest Now, Decrypt Later (HNDL). Harvesting of network traffic at scale is limited to the most sophisticated adversaries with the access and resources to store vast amounts of data, but it’s still a real threat with an indeterminate timeline.
The HNDL threat also gives us a way to prioritize, because the risk only matters where the value of the data outlives the arrival of a CRQC. If your migration takes five years and the data you're protecting has to stay confidential for twenty, you're already exposed and waiting doesn't improve that math. Intelligence, health records, financial details, and long-lived credentials probably fall into the bucket already, but quarterly marketing analytics probably don't. Governments and large corporations are worried about the HNDL threat, and it's one of the primary catalysts for faster migration towards post-quantum safe algorithms.
That leads to the part of this that matters most for network security. Cryptographic posture isn't a fixed part of a system or a protocol. It's negotiated dynamically on every connection between two parties that can have different capabilities, and you don't control both ends of most of the sessions in your environment. So what a system is capable of and what it actually uses are two different facts, and only the latter tells you anything about your exposure. Migration isn't a single day where you cut over to post-quantum algorithms either. It will be a gradual migration where classical, hybrid, and PQC all coexist on your network, sometimes inside the same application, and the state of any given connection depends on whoever is on the other end of it. Understanding the reality means looking at the traffic.
Because of the generalized threat of HNDL, the complicated fabric of dependencies, and the very long timelines for migration, the US federal government has been ratcheting up their mandates and compliance directives related to PQC migration. This includes publications such as NSM-10, OMB M-23-02, CNSA 2.0, CNSS Policy #15, DoW PQC strategy, and others. Some have specific timelines (e.g. NSM-10 lists 2035 as the target for deprecation of classical algorithms) and some are more focused around the components of the process for migration to PQC across vast agencies and organizations.
But it’s not just the Federal Government that is leading the charge towards PQC. Most of the major internet players, including Google, Cloudflare, and Microsoft, are all-in, pushing toward aggressive migration targets in their platforms and communications. All the momentum means a significant portion of all internet traffic (for example, 65% of human-to-Cloudflare traffic) is already utilizing some sort of hybrid or PQC-capable encryption. But that only solves the easiest part of the challenge between browser and CDN, two components that are readily controlled and easily updated. It doesn’t address the problems that all enterprises are struggling with: Unmanaged devices, east-west traffic, vendor appliances, OT, machine-to-machine, and legacy protocols that linger on in a long tail with production dependencies. In fact, most enterprises are starting to come to terms with the fact that they are not yet prepared to even build a PQC migration plan, let alone implement one.
So where to start? Every credible PQC migration plan starts in the same way: You need to understand what cryptographic assets and systems you have in place and map the dependencies to them. You cannot migrate cryptography unless you know about it, and you cannot budget or scope an enterprise-wide transition you cannot quantify appropriately. So a cryptographic inventory is the place to start.
The industry has landed on a useful concept for this: The cryptographic bill of materials, or CBOM. The idea is borrowed directly from the software bill of materials (SBOM) concept that most security teams understand. But rather than cataloging software components and their dependencies, a CBOM catalogs cryptographic assets and their dependencies. (Federal policy describes the same work as automated cryptography discovery and inventory, or ACDI, because the government prefers its own acronym.)
To create a useful CBOM, you need to capture a lot of fine-grained details: The algorithms and key lengths in use, the protocols and protocol versions carrying them, the certificates and keys (along with their issuers and expiration), the libraries and implementations underneath, and the systems, applications, and services that depend on each. The CBOM also needs to tie ownership to the underlying components and, most importantly, to the business processes that they are supporting.
No single source or product can produce all of that. Certificate management systems know your certificates but not what negotiated them. Code and CI/CD scanning knows which libraries you build against but not what runs in production or how it's configured. Endpoint tooling sees managed host details but misses everything unmanaged. Vendor attestations and active scanning may tell you what a product supports, not what it chose during the actual connection with a host on the wire. Each of these sources plays an important role in the process, but none alone is sufficient to complete a CBOM.
One component, however, does have a distinct advantage when creating or auditing a crypto inventory, and that is network data. After all, HNDL is a network-layer attack, so the same place adversaries harvest traffic for future decryption is where you can observe what was protecting it. Because it is out of band and passive, network visibility gives a clear indication of what key exchange and cipher suites are actually being used in production, including those that are PQC-capable, hybrid, or classical-only. And because it observes both sides of the exchange, it can show you the negotiation itself. When a PQC-capable client connects to a server that isn't, the two will quietly settle on classical algorithms, and the connection will work fine. Nothing in your certificate inventory, your CMDB, or your vendor documentation will tell you that the connection has been downgraded, but the traffic will.
This is also where passive observation separates from active scanning. A scanner can tell you what a server will accept when you ask it directly, but it can't tell you what your own clients negotiated, it can't reach the enclaves where scanning isn't permitted, and it's one more active touch on systems that could be critical for operations if disrupted.
All of this cryptographic information is captured natively by Corelight systems using deep packet inspection and the incredibly powerful protocol analysis capabilities of Zeek. It's also all done regardless of port (using dynamic protocol detection) and written into logs that are flexible and customizable for inventory and reporting purposes. The sort of data that's captured is comprehensive, covering protocol versions, full cipher and curve details, and key exchange and signature algorithm attributes. We also generate full x509 certificate metadata and can even extract the certificates themselves for export to file storage, which allows for offline analysis, correlation with cert management tools, or tracking changes over time. For teams that need to go deeper, capability exchange information (what's offered vs. what's used) and binary logging for PQC-capable connections can be added with easy package extensions, making quick work of specific reporting and inventory questions.
Crypto visibility on its own isn't enough, though, because an inventory without attribution is unlikely to be useful. The protocol, service, and application identification already built into Corelight data tie cryptographic detail back to the specific endpoints, servers, applications, and services using it. Those are truly the assets that need to be identified and prioritized for migration, and connecting crypto usage to them is what turns a list of addresses into something a program manager can actually work from.
We’ve had many customers (especially federal agencies) excited that this use case is already available with their existing sensor fleet. And with a few tweaks and configurations, Corelight sensors can send PQC inventory data out a separate exporter path to another division or data silo as needed for compliance or for auditing purposes.
We have built in PQC dashboards for our Investigator SaaS offering, as well as LogScale and Splunk (with others coming soon). We’ve also helped customers create custom logs, reports, and dashboards related to specific PQC compliance regulations, executive orders, and data reporting requirements. Corelight can serve as a foundational PQC data source as you create your CBOM/ACDI and manage a complex migration journey to a post-quantum world.
The quantum computer that challenges classical encryption is still a future problem, and the timeline for when it becomes real is still a guess. But the crypto inventory problem is neither. HNDL is happening now, continually updated mandates already require a cryptographic inventory, and the PQC migration will outlast many budget cycles. All three issues come back to the same question: What cryptography is your organization actually using, on which systems, talking to whom, and can you track this over time? Network data can’t build your entire CBOM, but it's the only source that answers that question from evidence instead of configuration, and you can get it from the Corelight sensors you have already deployed.
Our white paper covers the federal requirements driving automated cryptography discovery and inventory and how network data supports them.