Post-quantum cryptography: where ML-KEM, ML-DSA, SLH-DSA, and HQC fit.

FIPS 203 standardizes ML-KEM for key establishment. That makes it the default starting point for many migration plans because protocols such as TLS, VPN, service-to-service encryption, and secure device onboarding depend on key exchange or encapsulation patterns.

FIPS 204 standardizes ML-DSA and FIPS 205 standardizes SLH-DSA for digital signatures. Those signatures affect a different set of surfaces: code signing, firmware updates, certificate issuance, document signing, audit records, and long-term verification.

NIST's additional selection of HQC as a backup encryption algorithm is a reminder that a migration plan should avoid monoculture. The point is not to chase every candidate at once. The point is to keep an architecture that can rotate when standards and validation states evolve.

Security teams can name the algorithms and still miss the risk. Cryptography hides in load balancers, browsers, service meshes, embedded firmware, mobile apps, SDKs, database drivers, certificate authorities, build systems, partner portals, and backup tools.

The first artifact should therefore be a cryptographic bill of materials. It should identify library, protocol, algorithm, key length, certificate path, owner, data sensitivity, vendor dependency, validation state, and expected migration path.

PQC implementation is workflow-heavy. It needs asset owners, security architects, infrastructure teams, application teams, procurement, legal, and vendor managers to work from the same evidence base.

NowFlow can model the migration as a governed operating process: discover asset, assign owner, collect vendor response, choose algorithm path, test hybrid mode, approve cutover, monitor errors, and archive evidence. QFlow can keep standards references, experiment records, and decision evidence attached to the same migration object.

A useful pilot should cover a complete trust boundary: one internet-facing endpoint, one service-to-service channel, one device or firmware signing path, one internal PKI dependency, and one vendor-managed surface. That gives the team a realistic view of performance, support, monitoring, and rollback.

The pilot should also produce reusable artifacts: test plan, CBOM schema, vendor questionnaire, exception process, risk scorecard, and executive reporting template.

The most common failure is treating the algorithm decision as the finish line. FIPS 203, 204, and 205 name the destinations, but production risk lives in the surfaces the standards do not see: load balancers that terminate TLS with their own libraries, embedded firmware whose signature scheme cannot change in the field, backup tools that re-encrypt with defaults nobody reviewed. A plan that only tracks algorithm names will report success while these surfaces stay classical.

Silent fallback is the second failure. A hybrid endpoint that quietly negotiates down to a classical-only exchange looks identical to a working deployment unless negotiated parameters are recorded per session. Performance and fallback tests during the pilot exist to surface exactly this behavior before it reaches a customer-facing service.

Validation lag is the third. An algorithm can be standardized while a specific implementation's module validation state trails behind, and a CBOM that does not track validation state per module will not catch the gap. HQC exists as a backup selection for the same reason: the standards process itself assumes rotation, so an architecture that cannot rotate is already out of alignment.

Instrument the negotiation layer before any cutover. For every internet-facing endpoint and service-to-service channel in the pilot, record which key-establishment algorithm was actually negotiated per session, not which one was configured. Fallback events, handshake failures, and latency deltas are the earliest signals that a hybrid mode is not yet production-ready on a given surface.

Instrument the signature surfaces next. Code signing, firmware update, and certificate issuance paths need error monitoring through and after cutover, because verification failures on long-lived artifacts surface late and are expensive to unwind. The rollback and revocation plan is only credible if these paths report failures fast enough to trigger it.

Instrument the evidence layer last but design it first. Every test result, vendor response, and approval should attach to the migration object it concerns rather than scatter across inboxes. In the Neura Parse pattern, NowFlow carries the owners and approval gates while QFlow Studio holds the standards references and test evidence, so the audit trail forms as a side effect of doing the work.

The vendor questionnaire produced by the pilot is the main instrument. It should ask which FIPS 203, 204, and 205 algorithms each product supports, what the module validation state is, whether hybrid modes are available, and what the stated migration path is for the surfaces the vendor controls. Answers should land as CBOM entries with owners and dates, not as attachments in a shared drive.

CISA's product categories for post-quantum cryptography adoption give programs a shared vocabulary for that conversation. Grouping vendor-managed surfaces by product category makes gaps comparable across suppliers and keeps the assessment anchored to public guidance rather than to vendor positioning.

Treat rotation capability as a first-class criterion. A supplier that supports ML-KEM today but has no path to HQC or a future selection binds the program to the monoculture the standards process explicitly hedged against. The evidence to request is attestation of current state plus a stated path for the next transition, tied to the same migration object as everything else.