Which Cryptography Must Move First? Build a Post-Quantum Migration Evidence Map
Map the business object, cryptographic job, implementation boundary, dependency owner and acceptance proof before scoping a post-quantum migration project.
Signals to watch
- A named product, data set or federal procurement is tied to a post-quantum architecture or inventory decision
- The discussion identifies a key-establishment or signature dependency instead of using “encryption” for every cryptographic function
- A vendor, protocol, library or hardware owner must produce migration evidence before a dated architecture or procurement review
Do not begin a post-quantum migration scope with an algorithm name. Begin with the business object that must remain trustworthy, identify whether the cryptographic job is key establishment or digital signing, trace the protocol, library and hardware that perform it, and attach an owner and acceptance test to every dependency. That produces a migration evidence map; “supports PQC” does not.
This is the useful first move for a cryptographic-agility or security consultancy practice lead reviewing authorised public-key infrastructure (PKI), hardware security module (HSM), security-engineering and regulated-procurement Telegram groups. The commercial Signal is a named product, data set or procurement event with a broken migration dependency. Seeing it a day late can mean missing the architecture workshop where the inventory scope and outside adviser are assigned.
Definition: three NIST standards cover two different cryptographic jobs
On 13 August 2024, the US National Institute of Standards and Technology (NIST) published its first three finalized post-quantum cryptography standards. NIST developed them to resist attacks from both conventional and future quantum computers, but the standards do not all perform the same job.
- FIPS 203 specifies the Module-Lattice-Based Key-Encapsulation Mechanism, or ML-KEM. A key-encapsulation mechanism lets two parties establish a shared secret over a public channel. The surrounding protocol can use that secret with symmetric cryptography to protect data.
- FIPS 204 specifies the Module-Lattice-Based Digital Signature Algorithm, or ML-DSA. Digital signatures support origin authentication and detection of unauthorised modification.
- FIPS 205 specifies the Stateless Hash-Based Digital Signature Algorithm, or SLH-DSA. It is a separate signature standard based on a different mathematical approach from ML-DSA.
Post-quantum cryptography (PQC) therefore means cryptographic algorithms designed to resist attacks enabled by quantum computers. It is not the name of one protocol, one certificate or one product certification.
Why “we use RSA” is still not a project scope
A cryptographic algorithm can appear in many places: a transport handshake, code-signing service, document signature, device identity, firmware update, certificate authority, virtual private network or archived record. Replacing one library call may leave the certificate profile, peer system, HSM, recovery procedure or compliance evidence unchanged.
The protected business object changes the decision. A short-lived browser session and a signed firmware image that must remain verifiable for years have different failure consequences. An encrypted archive with a long confidentiality life raises a different exposure question from a service certificate renewed every few months. NIST’s standards define algorithms; they do not provide one universal order for an organisation’s assets.
That is why “the bank request for proposal (RFP) wants FIPS 203” is only a discovery clue. It might concern transport key establishment, an inventory, vendor roadmaps, an implementation test or a procurement checkbox. Current public information is not sufficient until the affected object and decision are named.
Build one migration evidence map
Use one row per protected object or trust decision. Do not put “the platform” in a single row if its web gateway, signing service and device-update path use different owners or release cycles.
| Evidence layer | Record this | Evidence that can support it | Keep unknown when |
|---|---|---|---|
| Business object | Data set, transaction, service identity, software release or device update that must remain protected | Architecture record, data classification, product support record, procurement requirement | The message says only “PQC” or “quantum-safe” |
| Cryptographic job | Key establishment, digital signature or another function | Protocol trace, certificate profile, signing policy, key-management design | “Encryption” is being used as a label for every function |
| Implementation boundary | Protocol, library, algorithm parameter set, certificate, HSM, endpoint and peer | Configuration export, software bill of materials, cryptographic inventory, interoperability result | A vendor claim has no version or deployment boundary |
| Dependency owner | Internal team, cloud provider, certificate authority, device supplier or external counterparty that controls the change | Contract, roadmap, support statement, issue owner and decision date | Nobody can approve or deliver the dependency |
| Acceptance proof | What will demonstrate the migrated path works and can be operated | Test vector result, handshake or signature verification, rollback test, performance result, approved exception | “Algorithm enabled” is the only completion criterion |
This five-layer map is the article’s original contribution. It lets a consultancy separate an inventory assignment from protocol engineering, vendor coordination, validation support or a broader crypto-agility programme.
Place FIPS 203, 204 and 205 in the job layer
ML-KEM belongs in a key-establishment discussion. ML-DSA and SLH-DSA belong in signature discussions. That distinction prevents a request for document signing from being routed to an encryption specialist, or a transport key-exchange problem from being scoped as a signature migration.
The standard still does not select the implementation. A complete row records the parameter set, library or service version, protocol integration, peer compatibility and operating environment. If a supplier says “FIPS 203 supported,” ask which product version exposes which ML-KEM parameter set through which protocol, and what evidence is available for the actual deployment.
Connect dependencies before estimating delivery
The migration path can stop outside the buyer’s code. A managed gateway may control the transport handshake. An HSM may not expose the required operation. A certificate authority or relying party may not accept the new signature profile. A device already in the field may have memory or update constraints.
The dependency owner must provide a dated statement or testable artifact. “Vendor roadmap” without product, release or committed scope remains an unknown, not evidence that the project will finish in a particular quarter.
Define acceptance without inventing certification
Publishing FIPS 203, 204 and 205 standardizes algorithm requirements. It does not certify every product that mentions ML-KEM, ML-DSA or SLH-DSA. A product-validation programme, procurement authority or regulated organisation may require separate implementation, module, interoperability or operational evidence.
Write the acceptance proof in observable terms: two named endpoints complete the expected key establishment; a known verifier accepts and rejects the correct signed artifacts; key rotation and rollback behave as designed; performance remains within an approved limit; or a responsible authority accepts the evidence package. The applicable programme decides which proof is sufficient.
Example: a procurement clue with three blank layers
Consider this illustrative composite fragment, not a real customer message or migration result:
“PQC came up in the bank RFP. Most TLS goes through the managed gateway. One signing service is still old. Need discovery before architecture review.”
The fragment names a procurement event, a transport boundary and a signing dependency. It does not identify the protected data, gateway product and version, current key-establishment algorithm, certificate path, signing use, data lifetime, vendor commitment, review date or acceptance authority.
The evidence map should open at least two rows rather than force one answer:
- Managed transport row: business service and protected data unknown; key establishment is likely relevant; gateway and peer systems need versions and owners; acceptance requires a defined interoperability test.
- Signing-service row: signed object and verification lifetime unknown; ML-DSA or SLH-DSA may be candidates only after the signature profile and relying parties are known; acceptance requires named signers, verifiers and failure tests.
This can justify discovery, but not a migration date or standard choice. Ask for the architecture owner, RFP clause, cryptographic inventory, service contacts and review date through an authorised channel.
Across Telegram sources the user deliberately selects and is authorised to access, Top Prospect can preserve and group fragments such as an RFP reference, an HSM limitation and a later architecture date, retain the original source and time, and rank the combined candidate for human review. It cannot inspect source code, discover private keys, validate an implementation, certify compliance, contact the writer or decide the migration priority. Pricing and access options describe the discovery product rather than a cryptographic service.
For governance context, the NIST CSF 2.0 Current Profile assessment shows how an observed state differs from a target outcome. When inventory evidence depends on shipped components, the SBOM and VEX comparison explains why a component list and a vulnerability statement answer different questions. Federal contractors should keep the separate CMMC phased-implementation evidence map tied to their applicable solicitation and assessment route.
Completion standard: every row can survive a handoff
A migration evidence map is ready for scoping when each row names the protected object, cryptographic job, deployed boundary, dependency owner, dated decision and acceptance proof. Rows may still contain unknowns, but each unknown has an owner and a verification route.
Stop short of a delivery estimate when the only evidence is an algorithm name, an undated vendor promise or a policy sentence. Continue to a technical proposal when the map identifies a bounded inventory, engineering change, external dependency and observable test.
Key facts
- NIST finalized FIPS 203, FIPS 204 and FIPS 205 on 13 August 2024.
- FIPS 203 standardizes ML-KEM for key encapsulation; it is not a bulk-data encryption algorithm.
- FIPS 204 standardizes the lattice-based ML-DSA digital-signature algorithm.
- FIPS 205 standardizes the stateless hash-based SLH-DSA digital-signature algorithm.
- Key establishment and digital signing are different cryptographic jobs and need different inventory evidence.
- A standardized algorithm does not by itself certify a product, implementation, protocol or migration outcome.
- Migration priority depends on the protected object, exposure period, implementation dependencies, vendor readiness and the organisation’s decision context.
FAQ
Which post-quantum standards did NIST finalize on 13 August 2024?
NIST finalized FIPS 203 for ML-KEM key encapsulation, FIPS 204 for ML-DSA digital signatures and FIPS 205 for SLH-DSA digital signatures. They cover different cryptographic jobs and are not interchangeable product labels.
Is ML-KEM a bulk-data encryption algorithm?
No. ML-KEM establishes a shared secret over a public channel. A protocol can then use that secret with symmetric cryptography to protect data. The protocol, parameter set and implementation still need review.
Does using a FIPS 203, 204 or 205 algorithm certify a product as quantum-safe?
No. The FIPS documents standardize algorithms and their requirements. Product, module, protocol, deployment and migration acceptance require the evidence specified by the applicable programme or authority.
Which systems should migrate first?
There is no universal business order in the three standards. Inventory the protected data or transaction, cryptographic function, exposure period, implementation dependencies, vendor support and decision deadline before assigning priority.
Frequently asked questions
Which post-quantum standards did NIST finalize on 13 August 2024?
NIST finalized FIPS 203 for ML-KEM key encapsulation, FIPS 204 for ML-DSA digital signatures and FIPS 205 for SLH-DSA digital signatures. They cover different cryptographic jobs and should not be treated as three interchangeable product labels.
Is ML-KEM a bulk-data encryption algorithm?
No. ML-KEM is a key-encapsulation mechanism used to establish a shared secret over a public channel. A protocol can then use that secret with symmetric cryptography to protect data. The surrounding protocol and implementation still need review.
Does using a FIPS 203, 204 or 205 algorithm certify a product as quantum-safe?
No. A FIPS publication standardizes an algorithm and its requirements; it does not by itself certify a product, implementation, protocol, deployment or migration outcome. Validation and acceptance depend on the applicable program and evidence.
Which systems should migrate first?
The NIST standards do not provide one universal business priority order. An organisation must inventory the protected data or transaction, cryptographic function, exposure period, implementation dependencies, vendor support and decision deadline before prioritising work.
Sources and further reading
- NIST: First Three Finalized Post-Quantum Cryptography Standards, published 13 August 2024
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard, final, 13 August 2024
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard, final, 13 August 2024
- NIST FIPS 205: Stateless Hash-Based Digital Signature Standard, final, 13 August 2024
- NIST Post-Quantum Cryptography project, accessed 16 August 2026
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
