Algorithm Risk Primer
FIPS 203, 204, 205 Explained: What Each One Actually Means for a Vendor's Algorithm Risk Score
July 28, 2026 · PQCClear · 8 minute read
Most explainers of NIST's post-quantum cryptography standards are written for the person implementing them. This one is written for the person who has to evaluate whether a vendor implemented them, and how much that should move a risk score.
Written for the Evaluator, Not the Implementer
In August 2024, NIST finalized three standards, FIPS 203, FIPS 204, and FIPS 205, that define how quantum-resistant cryptography actually works. Every good technical guide since then covers the same ground: lattice math, key sizes, performance benchmarks, which library supports what.
That is the right level of detail for an engineer choosing an implementation. It is the wrong level of detail for a TPRM analyst trying to answer a narrower question: given what this vendor told us, or what our scanner found in their artifact, how much cryptographic risk does this vendor actually carry?
Algorithm Risk is the single heaviest-weighted factor in a Quantum Readiness Score, carrying more weight than data sensitivity, longevity, exposure, and jurisdiction combined. Getting a working intuition for what “good” looks like in each standard, not the math behind it but the risk signal it carries, is worth ten minutes.
The Three Standards, Read as Risk Signals
Each standard replaces a specific category of classical algorithm. Knowing what a vendor uses today tells you almost immediately what to ask next.
FIPS 203
ML-KEM
Replaces RSA and ECDH for key exchange. Governs how a vendor's systems establish a shared secret before data ever moves, which makes it the front door for harvest-now-decrypt-later exposure: traffic encrypted with a classical key exchange today can be recorded and broken later.
Ask the vendor
Does key exchange on customer-facing and internal service-to-service traffic use ML-KEM, a hybrid mode, or is it still pure RSA and ECDH?
FIPS 204
ML-DSA
Replaces RSA and ECDSA for signatures. The primary recommended signature algorithm: smaller signatures, faster verification, the default choice for most systems. If a vendor has migrated signatures at all, this is almost always what they migrated to.
Ask the vendor
Which systems still sign with RSA or ECDSA, and is there a dated plan to move them to ML-DSA?
FIPS 205
SLH-DSA
An alternative, hash-based signature scheme built on different math than ML-DSA, for cryptographic diversity. Rare to see as a vendor's primary signature algorithm; its presence usually signals a more deliberate, risk-aware crypto program rather than a gap.
Ask the vendor
If SLH-DSA appears anywhere, is it a documented diversity decision, or an inconsistency worth a follow-up question?
How Algorithm Choice Feeds a Risk Tier
Regardless of the specific scoring model, the same rough tiering shows up across most quantum readiness frameworks, including PQCClear’s Algorithm Risk factor. What differs between vendors is not whether they know the standards exist; it is where each system actually lands.
| Pattern | What the evidence shows | Typical tier, and why |
|---|---|---|
| Pure classical | RSA, ECDSA, and ECDH or DH only, with no PQC or hybrid mode disclosed anywhere in the artifact or the questionnaire. | Higher risk. No quantum resistance today and no evidence of a migration in progress. Compounds fast with long data retention. |
| Hybrid, partial | Some systems running hybrid classical plus PQC (for example X25519 plus ML-KEM-768), with a migration roadmap disclosed but not yet complete. | Moderate. Quantum-resistant today on covered systems; risk concentrates in whatever has not migrated yet. Roadmap credibility matters here. |
| NIST-approved | ML-KEM, ML-DSA, and SLH-DSA (or hybrid) applied consistently across the systems in scope, documented and scanner-confirmed. | Lower risk. This is the evidence a bank's examiner will actually want to see attached to the assessment. |
The gap between “vendor says they’re migrated” and “scanner confirms they’re migrated” is exactly why questionnaire-only assessment tops out at Attested rather than Verified for higher-tier vendors. Self-reported algorithm choice and scanner-detected algorithm choice do not always agree, and when they do not, that disagreement is itself a signal worth surfacing.
What Your Assessment Should Be Able to Answer
Tap each question to see what strong evidence looks like versus a generic assurance, and why it moves the score.
01Does the vendor use NIST-approved algorithms for key exchange?
What it reveals
Whether the vendor's front-door key exchange is exposed to harvest-now-decrypt-later collection today.
Strong answer
ML-KEM or a documented hybrid (for example X25519 plus ML-KEM-768) on internet-facing and internal service traffic, confirmed by scan.
Weak answer
“We use industry-standard TLS” with no algorithm named, the same non-answer examiners already flag internally.
Why it matters for scoring
Key exchange is the most common place classical algorithms linger, and it is the direct input to Algorithm Risk.
02Does the vendor support a hybrid classical plus PQC mode?
What it reveals
Whether the vendor is following the transition-period approach NIST and most national bodies recommend, rather than betting on a single algorithm family too early.
Strong answer
Hybrid mode enabled by default on migrated systems, with a stated plan for when pure PQC becomes the default.
Weak answer
No hybrid support and no PQC support, or PQC support with no fallback, which trades one single point of failure for another.
Why it matters for scoring
Hybrid support is a light but real input to Algorithm Risk; it is evidence the vendor is managing transition risk deliberately.
03Which signature algorithm does the vendor use, and is it consistent?
What it reveals
Whether a vendor's migration is a genuine program or a single showcase system with the rest of the estate untouched.
Strong answer
ML-DSA applied consistently across systems in scope, with SLH-DSA used deliberately where cryptographic diversity is warranted.
Weak answer
ML-DSA on the system the vendor chose to showcase, RSA or ECDSA everywhere else in the artifact, with no explanation for the gap.
Why it matters for scoring
Consistency across systems is what separates a real migration from a marketing claim, and it is exactly the kind of thing a CBOM surfaces that a questionnaire alone will not.
04Is there a documented deprecation timeline for classical algorithms?
What it reveals
Whether the vendor is treating the 2030, 2031, and 2035 milestones as a real deadline or a distant abstraction.
Strong answer
A phased roadmap naming specific systems, target dates, and ownership, not just “we're aware of NIST's timeline.”
Weak answer
No roadmap, or one with no dates attached to it.
Why it matters for scoring
This is where Algorithm Risk and Data Longevity interact. A missing roadmap matters far more for a vendor holding data that outlives the deprecation window.
05Can the vendor swap algorithms without a system rebuild?
What it reveals
Crypto-agility: whether cryptographic choices are abstracted behind configuration, or hardcoded into the application layer.
Strong answer
Algorithm selection is externalized to policy or configuration, so a future algorithm change is an operational task rather than an engineering project.
Weak answer
Algorithm choices are hardcoded per system, meaning every future NIST update requires a rebuild.
Why it matters for scoring
This is what a vendor's migration will cost the next time an algorithm is deprecated. Today's compliant vendor with no agility is tomorrow's re-assessment risk.
The Dates That Actually Move a Score
Aug 2024
FIPS 203, 204, 205 finalized
The baseline every algorithm-risk assessment is measured against.
Mar 2025
NIST selects HQC as backup key-establishment algorithm
Standard still in development, so not yet a scoring input, but worth tracking.
Jun 2026
Federal executive order sets civilian deadlines
2030 for key establishment, 2031 for signatures, the dates Data Longevity scoring is anchored to.
TodayYou are here
Preparation window
Vendors assessed now still have runway to close gaps before deprecation pressure builds.
2030
Key establishment deprecation target
Pure-classical key exchange becomes a hard finding, not a soft one.
2031
Digital signature deprecation target
The same shift applies to RSA and ECDSA signing.
2035
Full migration horizon
The outer edge of what “migration in progress” can still mean as a mitigating factor.
What Good Evidence Looks Like
Before an examiner, or a bank’s own TPRM team, accepts a vendor’s algorithm claims, this is the minimum an assessment should be able to point to:
- 01
CBOM entries naming the specific algorithm per system, not a generic “encryption in use” statement.
- 02
Hybrid mode status disclosed per system, with a stated timeline for moving to pure PQC where relevant.
- 03
A deprecation roadmap for any remaining classical algorithms, with dates and ownership, not just awareness of NIST's timeline.
- 04
Consistency across systems, scanner-confirmed, not limited to whichever system the vendor chose to showcase.
- 05
Crypto-agility documentation showing algorithm selection is configurable, not hardcoded per system.
Turn algorithm claims into a scored, evidence-backed assessment
PQCClear scores every fintech vendor’s Algorithm Risk against NIST-approved standards, combining questionnaire responses with scanner-confirmed CBOM data, so “we use industry-standard encryption” is never the final answer.
Request accessThis post represents the editorial analysis of PQCClear as of July 28, 2026. It should not be construed as legal or engineering advice. Financial institutions and vendors should consult their own security and compliance teams regarding specific migration decisions.
Key sources: NIST FIPS 203/204/205 (csrc.nist.gov, August 2024); NIST HQC selection announcement (csrc.nist.gov, March 2025); Executive Order 14412 (whitehouse.gov, June 2026); OMB M-26-15 (whitehouse.gov, June 2026); CISA PQC Product Categories List (cisa.gov, January 2026).