On February 19, Australia’s Signals Directorate published a quantum technology primer for organizations. It is worth reading in full. It is also worth noticing what it does not contain: qubit estimates.
No discussion of how many physical qubits are needed to factor RSA-2048. No comparison of surface codes versus QLDPC architectures. No Gidney-Ekerå citations. Instead, ASD focuses on what organizations should be doing now, starting with the assumption that a cryptographically relevant quantum computer will eventually exist and that data captured today may be decrypted when it does.
The wrong question
A significant amount of public discussion about post-quantum cryptography centers on hardware timelines. How many qubits does it take to break RSA-2048? Is the Pinnacle architecture realistic? Are we five years away or fifteen?
These are interesting questions for physicists and hardware engineers. They are not useful questions for security teams, CISOs, or procurement officers.
The threat model that drives PQC migration is not “a quantum computer will appear on a specific date.” The threat model is harvest now, decrypt later: an adversary captures encrypted traffic today and stores it until decryption becomes feasible. The relevant variable is the confidentiality window of the data, not the delivery date of the hardware. If your organization handles data that must remain confidential for ten or more years — financial records, medical data, legal communications, government information, intellectual property — then the migration timeline is already binding, regardless of when a CRQC arrives.
The organizations with the most visibility into actual threat timelines have already acted on this logic. The NSA’s CNSA 2.0 framework requires all new National Security Systems acquisitions to be compliant by January 1, 2027, all non-compliant equipment phased out by December 31, 2030, and full quantum resistance by 2035. Australia’s ASD has recommended against RSA for government systems. France’s ANSSI, Germany’s BSI, the UK’s NCSC, and the G7 Cyber Expert Group have all published guidance. None of these timelines are gated on a qubit milestone. They are driven by the recognition that migration takes years and that starting late means finishing late.
The middleware gap
The deadlines above assume organizations can migrate. In practice, the obstacle is not awareness — it is layered implementation.
Microsoft’s SymCrypt library supports ML-KEM. SQL Server does not negotiate it. A cloud provider may terminate TLS 1.3 with hybrid key exchange at its edge, but internal service-to-service traffic behind that edge still uses classical ECDH. An HSM vendor claims PQC readiness; the certificate chain the HSM protects has no post-quantum component. A browser negotiates X25519MLKEM768 with a CDN, but the origin server behind the CDN speaks RSA-2048.
Each of these is a real pattern observable in production infrastructure today. None of them show up in a qubit estimate.
Transport security, identity verification, code signing, key management, and data-at-rest encryption each have different migration paths, different vendor dependencies, and different timelines. An organization can be post-quantum at one layer and entirely classical at the next. The result is a patchwork that satisfies no compliance framework and protects against no coherent threat model. This is the actual engineering problem of PQC migration, and it is invisible to anyone focused on when the hardware arrives. It is visible to anyone scanning real infrastructure and tracking what changes over time.
What to measure
If the middleware gap is the problem, then the useful metrics are the ones that make it legible:
Cryptographic inventory completeness. Do you know what algorithms are in use across your systems, including embedded and legacy infrastructure?
PQC negotiation rate. What fraction of your external connections successfully negotiate post-quantum key exchange today?
Migration trajectory. Is that fraction increasing, decreasing, or flat? Over what timeframe?
Vendor readiness. Which of your critical suppliers have published PQC timelines? Which have not responded?
Compliance gap. Against CNSA 2.0, BSI TR-02102, or your sector’s applicable framework — where do you stand, and what is the delta?
These are the inputs to a migration plan. A tool that answers these questions is more useful than a tool that estimates qubit counts — which is the premise behind pqprobe.
ASD did not publish a primer on how many qubits it takes to break RSA. They published five risks and a recommendation to act. The qubit question will answer itself. The migration will not.