The central question in post-quantum cryptography is no longer whether organizations should migrate. It is how they can migrate complex, changing estates without losing control of the systems they are trying to protect.

That question framed Before the Breach: Securing Critical Systems for the Next Cryptographic Era, a special PQC Summit held on 22 September 2026 at The Hotel at the University of Maryland, immediately ahead of Quantum World Congress.

The program brought together speakers from NIST, the U.S. Department of War, IBM, IonQ, HEQA Security, Tychon, Applied Quantum, QuantumGenie and the broader post-quantum ecosystem. Across sessions, several themes repeatedly converged: the standards are usable, discovery must begin now, interoperability matters, authentication cannot be postponed, and automation is essential for scale.

For QuantumGenie, this was more than a high-level discussion. It closely matched the operating model we have been building: discover cryptography continuously, normalize it into a Cryptographic Bill of Materials, map dependencies, prioritize by business impact, orchestrate migration, and monitor the estate so vulnerable cryptography does not return.

NIST has supplied the cryptographic foundation

NIST finalized the first three principal post-quantum standards in 2024:

  • FIPS 203: ML-KEM, for post-quantum key establishment;
  • FIPS 204: ML-DSA, for post-quantum digital signatures; and
  • FIPS 205: SLH-DSA, the stateless hash-based signature standard derived from SPHINCS+.

NIST says these standards form the foundation for most post-quantum deployments and that organizations should begin applying them now. The portfolio is also widening. HQC was selected as a backup key-encapsulation mechanism based on mathematics different from ML-KEM, while Falcon/FN-DSA continues through the signature-standardization process.

That does not make migration easy. It makes migration actionable.

The federal policy environment has also accelerated. Executive Order 14412 directs the migration of federal information systems to NIST-approved PQC standards. OMB Memorandum M-26-15 converts that direction into an operating program built around migration leadership, cryptographic inventory, prioritized planning, crypto-agility, governance and phased execution.

The message is clear: the standards phase and the inventory phase now overlap. Organizations do not need to wait for every protocol, product and vendor to reach its final state before discovering what they have.

Automation is how an enterprise keeps its cryptographic truth current

During the panel The Role of Automation in Facing the Quantum Threat, QuantumGenie founder and CEO Srijan Dhare described automation as “making an engine that performs while you sleep.”

That engine is necessary because an enterprise cryptographic estate never stays still. Certificates expire and rotate. Applications appear and retire. Libraries change. New cloud resources are created. Vendors introduce new dependencies. A spreadsheet created six months ago records a historical sample, not the current cryptographic truth.

The panel distinguished several stages in the migration lifecycle:

  1. Discovery: identify cryptography across source code, certificates, keys, protocols, cloud resources, endpoints, network infrastructure, databases and third parties.
  2. Attribution: map every CBOM record to the application, owner, data path, service and dependency that gives it meaning.
  3. Prioritization: identify crown-jewel systems, harvest-now-decrypt-later exposure, operational constraints and vendor clocks.
  4. Migration: select and implement the target post-quantum approach with testing, approval and rollback controls.
  5. Continuous monitoring: detect drift, expired assets, new vulnerable dependencies and incomplete migration.

Automation is especially well suited to discovery, attribution, normalization and monitoring. These are repetitive, high-volume activities that must run across many data sources and keep running after the first assessment.

Human judgment remains central to policy, business priority, risk acceptance, legacy-system treatment, target architecture, validation and production change. As Srijan noted, AI can write code, but it does not automatically contain the accumulated edge cases and validation knowledge required to migrate a real enterprise safely.

This is not a choice between people and automation. The viable model is automation for scale and human control for consequence.

You cannot migrate what you cannot see

Srijan summarized the first principle in one sentence: “You cannot migrate what you don't see or what you don't know.”

A useful cryptographic inventory must go beyond counting certificates or finding obvious calls to RSA. It must normalize evidence from different tools and environments into a consistent model. That includes:

  • algorithms and parameter sets;
  • keys and key-establishment mechanisms;
  • certificates and trust chains;
  • digital signatures and authentication paths;
  • protocols and cipher suites;
  • implementation libraries and versions;
  • owners, applications and business services;
  • data sensitivity and longevity;
  • infrastructure and vendor dependencies; and
  • evidence lineage, confidence and validation status.

Normalization matters because heterogeneous tools describe the same cryptographic fact differently. Without a standard set of normalized values, teams cannot compare findings, measure progress, enforce policy or determine whether a system is classical, hybrid or fully post-quantum.

A CBOM becomes operational only when it is connected to those relationships. Changing a certificate, library or key-establishment mechanism can affect a chain of applications and services. The inventory identifies the object. Dependency mapping explains the consequence.

Interoperability is a migration requirement

The summit emphasized that post-quantum cryptography enters environments where cryptography already exists almost everywhere. This is fundamentally different from adding a new standalone technology to a greenfield system.

Large organizations operate custom protocols, government-developed systems, commercial platforms, legacy applications, operational technology and cloud services. No single implementation will replace all of that at once. Migration tools therefore need to preserve interoperability while making the state of each system unambiguous.

This creates a demanding classification problem. A discovery platform must recognize classical, hybrid and pure post-quantum implementations. It must identify the algorithm, protocol and dependency context well enough to distinguish a completed migration from an intermediate state.

Interoperability also extends to the evidence layer. A normalized CBOM can provide a common language across engineering, security, architecture, procurement, auditors and vendors. Those groups do not need identical tools, but they do need consistent values and traceable decisions.

Authentication should move with key establishment

One of the strongest operational themes concerned authenticity.

Organizations often frame PQC migration first as a confidentiality problem: replace vulnerable key establishment so captured traffic cannot be decrypted later. That is necessary, but it is incomplete. Digital signatures and cryptographic identities are also vulnerable to a future quantum adversary.

For a small product, it may be possible to update key establishment now and authentication later. For an enterprise with hundreds of thousands or millions of endpoints, two migrations mean two rounds of planning, testing, approvals, downtime risk and cost. Critical infrastructure and long-lived operational systems cannot be updated at cloud cadence.

The target architecture should therefore consider ML-KEM for key establishment and ML-DSA or another approved post-quantum signature profile for authentication in the same migration program. PKI, MFA, identity lifecycle, certificate ownership and signature evidence belong in the migration model from the beginning.

This closes a common loophole: protecting the confidentiality of a connection while leaving the identity of the communicating parties dependent on quantum-vulnerable signatures.

Crypto-agility is a control system, not a product checkbox

The PQC portfolio will continue to evolve. ML-KEM, ML-DSA and SLH-DSA are standardized. HQC provides future diversity for key establishment. Falcon/FN-DSA expands the signature portfolio. Protocol profiles, library implementations, validation status and agency requirements will continue to change.

Crypto-agility means an organization can absorb those changes deliberately. It requires:

  • a current cryptographic inventory;
  • normalized algorithm and protocol identities;
  • dependency and ownership mapping;
  • policy-controlled target profiles;
  • version and configuration evidence;
  • explicit approval rather than silent downgrade;
  • interoperability testing;
  • migration and rollback workflows; and
  • continuous monitoring after deployment.

Without these controls, “agility” can become uncontrolled negotiation or automatic fallback. With them, it becomes an evidence-backed ability to change cryptography without losing governance.

The immediate action is discovery

The final question to the panel asked each participant for one action the audience should take tomorrow.

Srijan's answer was direct: “Discovery can be started as of yesterday and, if not yesterday, tomorrow.”

An organization can begin by listing the applications, load balancers, network devices, endpoints, cloud environments, code repositories, databases, certificate stores and vendors it already knows. It can then define what it expects from each CBOM record and deploy read-only discovery across a bounded pilot.

The first inventory will not be perfect. It does not need to be. Its purpose is to expose blind spots, validate access, establish normalized evidence, and create a repeatable process that becomes more complete over time.

Post-quantum migration is a multi-year program. The organizations that begin discovery now gain time to understand their dependencies, work with vendors, test interoperability, protect authentication, and make risk-based decisions before deadlines turn planning into emergency change.

The algorithms are ready enough to begin. The mandate is real. The estate is already changing.

The next step is to see it.

Frequently asked questions

Which post-quantum algorithms are standardized today?

NIST has finalized ML-KEM in FIPS 203, ML-DSA in FIPS 204 and SLH-DSA in FIPS 205. HQC has been selected as a future backup KEM, while Falcon/FN-DSA remains in the signature-standardization pipeline.

Why is a CBOM necessary for PQC migration?

A Cryptographic Bill of Materials records algorithms, keys, certificates, protocols, libraries and related evidence. It gives an organization a measurable inventory from which to prioritize migration and demonstrate progress.

Can PQC discovery be automated?

Much of discovery, normalization, attribution and continuous monitoring can be automated through source-code analysis, APIs, agents, agentless inspection and integrations. Human validation remains important for ambiguous findings, business context and migration decisions.

Why migrate authentication with encryption?

Quantum-vulnerable signatures can undermine identity and authenticity even when data confidentiality has been upgraded. Combining key-establishment and authentication planning reduces duplicated work and avoids an incomplete security boundary.

What should an enterprise do first?

Define a bounded scope, identify known assets and evidence sources, decide which normalized fields the CBOM must contain, and run an initial read-only discovery pilot. Expand after owners validate the findings and operating process.

Sources