NIST finalised its first post-quantum cryptography standards in 2024. For most organisations, that shifted the question from *should we prepare?* to *where do we start?* The honest answer for many security teams is: we're not sure — because we don't have a live picture of which cryptographic algorithms are actually in use across our network.
Certificate scanners show what's configured. They don't show what's negotiated. A server that looks quantum-safe on paper may be completing TLS handshakes using RSA key exchange with a legacy client. An SSH connection to critical infrastructure may be using key exchange mechanisms that are squarely in the crosshairs of "store now, decrypt later" attacks — where adversaries capture encrypted traffic today to decrypt it once quantum computing matures. Without runtime visibility, cryptographic inventory is incomplete by definition.
What we are building
We are in the discovery phase of developing an IBM QRadar Quantum Risk Insights App — and we are looking for customer input before we finalise the design.
The concept: a native QRadar app that uses QRadar Network Insights (QNI) to inspect cryptographic metadata in live TLS, SSH, and RDP traffic — without decrypting payloads. When a quantum-vulnerable algorithm is detected during protocol negotiation, QRadar would generate a dedicated PQC Vulnerability offenses with full context: asset, protocol, algorithm, and connection details. The result would be a continuous, operational inventory of cryptographic exposure rather than a point-in-time scan.
The capability is designed for two audiences:
Security analysts — triage-ready views of the most exposed assets and protocols, with drill-down to underlying flow data
CISOs — trend dashboards and a readiness scorecard to track migration progress and report to the board
Why this belongs in QRadar
PQC tooling exists in certificate managers and cryptographic inventory platforms. What QRadar adds is runtime negotiation visibility — seeing what is actually agreed between client and server, not just what is configured — combined with the operational context of a SIEM that security teams already work in every day. Cryptographic risk as a native signal in your existing security operations workflow, rather than a separate programme that runs in parallel and rarely connects.
Help us shape it
We are at the stage where customer input has the most influence on what gets built. If your organisation is working through PQC planning and has a view on where cryptographic visibility in your network would be most valuable, we want to hear from you.
Sign up for early access here. The design is informed but not fixed, and conversations at this stage are what make the difference between a capability that is useful and one that is essential.