Why Continuous Cryptographic Inventory is Essential for PQC Readiness

Most organizations can't answer one deceptively simple question: Which of our systems are actually using post-quantum cryptography (PQC) today?

If you can't answer that with evidence, you don't have a migration plan. You cannot manage your PQC migration if you don't know what cryptography you're actually using. This is a governance problem, a board problem, and a risk management problem.

Nation-states, organized crime, and well-resourced intelligence services are already intercepting and stockpiling your encrypted TLS, SSH, and QUIC traffic. They don't need to break it today. They only need to break it before your sensitive data stops being sensitive. This is the "harvest now, decrypt later" problem.

Most experts still place Q-Day, the moment a quantum computer can break RSA and elliptic-curve cryptography, around 2030 if not sooner. That sounds comfortably distant. But every day you delay migration is a day of exposure you can't undo.

A bank's cardholder data, a healthcare record, a law firm's case files, a government’s top secrets — anything “harvested” today will be a live liability when cryptographically relevant quantum computers (CRQCs) arrive.

The clock is no longer hypothetical

This is no longer a distant hypothetical for boards and regulators. The timeline is compressing fast.

• August 2023 - CISA, NSA, and NIST jointly urged organizations to start cryptographic inventories now
• August 2024 - NIST finalized its first post-quantum cryptography standards: FIPS 203, 204, 205
• November 2024 - NIST IR 8547 set a phased deprecation timeline, with NIST removing quantum-vulnerable algorithms from its standards beginning 2030, and full disallowance by 2035. High-risk systems should transition earlier.
• June 2026 - The White House issued Executive Order 14412 mandating that all federal agencies transition all high value assets and high impact systems to use PQC for key establishment by December 31, 2030, and for digital signatures by December 31, 2031.

FS-ISAC — the organization representing the global financial ecosystem to address systemic threats and fortify the resilience of the entire financial services sector — published the risks of “crypto-procrastination”. Despite increasing awareness, many organizations have yet to define or apply resources adequately supporting quantum-resistant projects, which compresses the real migration work into an unrealistically short window.

FS-ISAC's framing of cryptographic agility is the useful mental model here. FS-ISAC states that by becoming crypto agile, practitioners can quickly replace cryptographic algorithms using a repeatable process with minimal impact or downtime and provide sufficient confidentiality, integrity, and/or non-repudiation guarantees. Firms that build this muscle avoid getting stuck on broken algorithms and keep business continuity intact if (when) current cryptography is weakened.

source: Building Cryptographic Agility in the Financial Sector, FS-ISAC, October 2024

You can't migrate what you can't see

Every FS-ISAC PQC paper converges on the same crucial step: inventory. Inventory should not be based on a spreadsheet someone filled out a year ago. You need a live, evidence-based answer to the question: which of our systems are actually negotiating post-quantum key exchanges today, and which ones aren't?

That's a harder question than it sounds. Modern protocols bury the quantum-safe part of the conversation deep inside the handshake. TLS 1.3 doesn't put key agreement in the cipher suite anymore, it's negotiated separately via the key_share extension, which means most traditional TLS inventories miss it entirely.

If you can't see it, you can't measure it; and if you can't measure it, you have no idea if your data is actually safe from a future quantum attack.

The value of continuous inventory and analysis

In a modern enterprise, software updates constantly, cloud infrastructure autoscales, and third-party APIs change daily. If a developer spins up a new microservice that defaults to an old, non-quantum-safe key exchange, your static spreadsheet won't show it. The only way to know you are safe is to actively inspect the live network traffic to see what keys are actually being exchanged in real-time.

Hybrid key exchanges use a belt-and-suspenders approach to ensure the communication remains safe in the event that either key is broken

ExtraHop spots quantum-resistant algorithms and hybrid key exchanges by drilling into the TLS handshake itself. And because ExtraHop captures metrics and metadata continuously, this isn't a one-time audit. It's the foundation for the “revisit and revise” discipline that FS-ISAC and NIST both stress. Quantum-resistant cryptography is going to arrive in waves, not one clean cutover. You will need to re-run this kind of assessment repeatedly, against a moving target, for years. Build the muscle now while the stakes are inventory gaps, not compliance failures.

ExtraHop’s protocol analysis engine decodes these handshake details in real-time, and sees if a client and server successfully negotiated a hybrid post-quantum algorithm. Here’s one view of what that looks like within the ExtraHop console.

Hybrid key exchanges visible in ExtraHop

But wait, there’s more: JA4+

Handshake-level visibility is useful for more than PQC. The same underlying capability that allows ExtraHop to surface PQC negotiation also lets it fingerprint clients, servers, and behavior at this depth.

ExtraHop was the first network detection and response (NDR) provider to implement the full NDR-addressable JA4+ suite. Without ExtraHop’s decryption capabilities, several of these fingerprints (JA4H, JA4S, and JA4X509) would normally be out of reach.

The handshake tells you a lot. ExtraHop is built to read all of it.

New AI skill to generate a PQC readiness report

ExtraHop now has an AI skill that runs on RevealX network metrics and automatically inventories every internal TLS server or client active in a given window and answers, with evidence, not guesswork:

• Which internal systems are acting as TLS servers or clients?
• Did each one negotiate at least one post-quantum key exchange?
• How many unique clients per server (or destinations per client) support PQC vs. don't?
• What does the trend look like? Is PQC adoption inconsistent across identical machines, concentrated in specific device roles, or effectively zero?

The skill queries ExtraHop's ssl_server/ssl_client and detail metrics and produces a CSV plus a narrative summary report flagging which systems need remediation first. The report clearly surfaces the specific list of machines your team can go fix this week.

What this doesn't solve

To be clear about scope: this skill tells you where you stand, not how to fix it. It won't rotate your keys, patch your TLS libraries, or negotiate a PQC roadmap with your vendors. Those are real, separate workstreams and ones the FS-ISAC papers referenced above cover in depth, from vendor questionnaires to crypto-as-a-service architectures to certificate-based hybrid rollouts. What this skill gives you is the evidence every one of those workstreams needs, and a repeatable way to measure whether they're working.

Get the PQC readiness skill

This skill, along with other skills and several tool call interfaces (MCP server, CLI) for querying ExtraHop RevealX metrics directly and running the report outside of a chat interface, are available in our GitHub repository.

Download the PQC Readiness Skill on GitHub →

If your board is asking, “are we quantum-ready,” the honest first answer is almost never yes or no. It's “here's our inventory, and here's what it shows.” This is how you get clear, defensible evidence instead of a guess.