Security Level (NIST)
A NIST security level, formally a NIST security category, is one of five strength tiers NIST defined during its post-quantum standardization process to rate how much computational work it takes to break a cryptographic algorithm. Rather than invent a brand-new unit, NIST pegged each category to the difficulty of attacking a primitive the world already trusts: Category 1 is at least as hard to break as a key search on AES-128, Category 2 as hard as a collision search on SHA-256, Category 3 as hard as AES-192, Category 4 as hard as SHA-384, and Category 5 as hard as AES-256. When a standard like FIPS 203 offers ML-KEM-512, ML-KEM-768, and ML-KEM-1024, those parameter sets are its way of hitting Category 1, 3, and 5, and choosing a parameter set is really choosing a security category.
The short version:
- A NIST security category is a strength rating from 1 (lowest) to 5 (highest), defined by comparison to a well-understood primitive, not by a raw bit count.
- The odd-numbered categories are anchored to block-cipher key search (1 is AES-128, 3 is AES-192, 5 is AES-256); the even-numbered ones to hash collision search (2 is SHA-256, 4 is SHA-384).
- Every post-quantum parameter set targets a category. ML-KEM-512/768/1024 hit Categories 1/3/5; ML-DSA-44/65/87 hit Categories 2/3/5.
- Higher category means a bigger security margin and usually bigger keys, ciphertexts, and signatures, so the choice is a strength-versus-size tradeoff.
- NIST recommends Category 3 as a sensible general-purpose default (ML-KEM-768), while CNSA 2.0 requires the top level, Category 5, everywhere (ML-KEM-1024 and ML-DSA-87).
Think of it like grading a new building material by saying it has to be at least as strong as a steel grade we already build bridges from, instead of inventing a fresh strength unit nobody has intuition for. NIST did the same thing for cryptography. It took the strengths of algorithms everyone already relies on, AES and SHA, and turned them into five tick marks. A “Category 5” post-quantum algorithm has to be at least as hard to break as AES-256, a lock the world already bets on, so you inherit decades of confidence in what that mark means.
What is a NIST security level (category)?
A NIST security category is a rating, on a scale of 1 to 5, of how much computational effort any successful attack against an algorithm must cost, expressed as “at least as hard as” attacking a specific reference primitive. NIST introduced the scale in its call for proposals for the post-quantum standardization process, and it now appears in every finalized PQC standard as the way each parameter set advertises its strength.
The point of anchoring to reference primitives rather than to a plain bit count is calibration. Post-quantum algorithms rest on unfamiliar math (lattices, codes, hashes), and a raw “256-bit” label would mean something different in each family and wouldn’t say how a quantum attacker changes the picture. By requiring that breaking a Category 5 scheme cost at least as much as a key search on AES-256, NIST expresses strength in terms whose difficulty, classically and against quantum search, is already well understood. The categories are the common ruler that lets a lattice KEM and a hash-based signature be compared on the same scale.
The terms “security level,” “security category,” and “security strength” are used interchangeably in practice, and this note treats them as the same thing. NIST’s own documents settled on “security category” as the precise term.
Source: NIST, “Submission Requirements and Evaluation Criteria for the Post-Quantum Cryptography Standardization Process,” December 2016, Call for Proposals.
How does NIST define the five categories?
NIST defines each category by a single requirement: any attack that breaks the scheme must require computational resources comparable to or greater than those needed to break a named reference primitive. The five, in order of increasing strength, are pegged to the strengths of the existing NIST symmetric standards, which NIST expects to resist quantum cryptanalysis well:
| Category | An attack must cost at least as much as | Reference primitive |
|---|---|---|
| 1 | Key search on a block cipher with a 128-bit key | AES-128 |
| 2 | Collision search on a 256-bit hash function | SHA-256 / SHA3-256 |
| 3 | Key search on a block cipher with a 192-bit key | AES-192 |
| 4 | Collision search on a 384-bit hash function | SHA-384 / SHA3-384 |
| 5 | Key search on a block cipher with a 256-bit key | AES-256 |
The odd categories (1, 3, 5) are the key-search tiers pegged to AES; the even categories (2, 4) are the collision-search tiers pegged to SHA-2 and SHA-3. NIST also stated the ordering assumption plainly: it expects a brute-force collision attack on SHA-256 to become feasible before a brute-force key search on AES-192, which is why Category 2 sits below Category 3 rather than beside it. The one nuance to keep is that “resources” isn’t a single number. NIST measures against several metrics at once (classical operations, quantum circuit size, and circuit depth under a bound it calls MAXDEPTH), and a scheme has to clear the threshold under all of them to claim a category.
Source: NIST, “Submission Requirements and Evaluation Criteria for the Post-Quantum Cryptography Standardization Process,” December 2016, Call for Proposals.
How do the ML-KEM and ML-DSA parameter sets map to the categories?
Each post-quantum standard offers a few parameter sets, and each set is engineered to land on a specific NIST category. This is the practical translation table that connects a parameter-set name to a strength tier, drawn straight from the finalized standards:
| Category | ML-KEM | ML-DSA | SLH-DSA |
|---|---|---|---|
| 1 | ML-KEM-512 | (none) | SLH-DSA-128s / 128f |
| 2 | (none) | ML-DSA-44 | (none) |
| 3 | ML-KEM-768 | ML-DSA-65 | SLH-DSA-192s / 192f |
| 4 | (none) | (none) | (none) |
| 5 | ML-KEM-1024 | ML-DSA-87 | SLH-DSA-256s / 256f |
A few things fall out of this table. The KEM (ML-KEM) targets only the odd, AES-anchored categories, so it has no Category 2 or 4 set. The general-purpose signature (ML-DSA) starts one tier lower at Category 2, because its smallest set, ML-DSA-44, is calibrated to SHA-256 collision strength. No standardized parameter set targets Category 4; it exists on the scale but no finalized PQC algorithm advertises it. The numbers in the parameter-set names (512, 768, 1024 for ML-KEM; 44, 65, 87 for ML-DSA) are internal design parameters, not the security category and not a bit count, which is exactly why the mapping table is worth keeping handy.
Sources: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, FIPS 203.
NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, FIPS 204.
NIST, “Stateless Hash-Based Digital Signature Standard,” FIPS 205, August 2024, FIPS 205.
Which security level do I need?
For most deployments Category 3 is the right default, and the two anchors worth knowing are NIST’s general-purpose guidance and the stricter national-security bar. NIST recommends ML-KEM-768 (Category 3) as the sensible default for general use, on the reasoning that it gives a large security margin at reasonable cost, and it advises picking the strongest practical set when you first deploy so you don’t pay to upgrade later. The decision usually comes down to three considerations:
- How long the protection has to hold. For long-lived secrets or roots of trust that must stay secure for decades, the higher categories buy margin against future cryptanalysis, and the extra size is worth it. For ordinary session traffic, Category 3 is ample.
- What the artifact sizes cost you. A higher category means larger keys, ciphertexts, and signatures. Where bandwidth or storage is tight, that size is a real constraint, so you weigh it against the marginal strength gain.
- What a mandate requires. CNSA 2.0 settles the question for U.S. national-security systems by requiring Category 5 (Level V) everywhere: ML-KEM-1024 for key establishment and ML-DSA-87 for signatures, at every classification level with no lower tier. If you build for or sell into that market, the choice is made for you.
The gap between the two anchors is instructive. NIST’s civilian default is Category 3; the national-security requirement is Category 5. That’s a deliberate step up, not a contradiction, and it means “which level” often depends less on the math than on who your buyer is.
Sources: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, FIPS 203.
NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” CSA U/OO/194427-22, September 2022, CNSA 2.0.
Why are the categories anchored to AES and SHA instead of a bit count?
NIST anchored the scale to real primitives because a bare bit count is ambiguous once quantum attacks enter the picture, and because it wanted a strength unit the whole field already had intuition for. Two problems make a plain “128-bit” or “256-bit” label misleading for post-quantum work:
- Quantum attacks scale differently for different primitives. Grover’s algorithm roughly halves the effective strength of a symmetric key search, so AES-128 offers about 64 bits of quantum security while AES-256 still offers about 128. Collision search on a hash scales differently again. A single bit-count label can’t capture those differences, but “as hard as AES-128 under the best known attacks” does.
- Post-quantum families don’t share a native unit. The internal parameters of a lattice scheme, a code-based scheme, and a hash-based scheme aren’t comparable to each other or to a symmetric key length. Pinning every one of them to the same set of reference primitives is what makes a lattice KEM and a hash-based signature commensurable on one scale.
The result is a rating an engineer or a regulator can reason about without redoing the cryptanalysis: Category 5 means “breaking this should cost at least what breaking AES-256 costs,” and AES-256 is a quantity the industry has decades of confidence in. The scale borrows that confidence rather than asking you to trust a fresh number.
Source: NIST, “Submission Requirements and Evaluation Criteria for the Post-Quantum Cryptography Standardization Process,” December 2016, Call for Proposals.
Common misconceptions
- “The number in ML-KEM-768 is the security category.” It isn’t. 512, 768, and 1024 are internal design parameters; the categories they hit are 1, 3, and 5. The same goes for ML-DSA-44/65/87, which map to Categories 2, 3, and 5.
- “A higher category is always better, so use Category 5 everywhere.” Higher categories cost bandwidth and storage through larger artifacts. NIST’s own default for general use is Category 3, and a higher level is reserved for long-lived keys or a mandate that requires it, not chosen reflexively.
- “A NIST security category is a bit count.” It’s a comparison to a reference primitive under all metrics NIST considers relevant, including quantum circuit size and depth. Category 1 corresponds to AES-128’s difficulty, which is not the same as a flat “128 bits” of security once quantum search is in scope.
- “Categories 1 through 5 are evenly spaced.” They aren’t a linear ladder. The odd tiers track block-cipher key search and the even tiers track hash collision search, and NIST orders them by expected practical difficulty (Category 2, pegged to SHA-256, sits below Category 3, pegged to AES-192).
- “Every category has a standardized algorithm.” No finalized PQC parameter set targets Category 4, and ML-KEM skips Categories 2 and 4 entirely. The scale has five rungs, but the standards only populate some of them.
Questions people ask
What’s the difference between a security level and a security category? Nothing meaningful; people use “security level,” “security category,” and “security strength” interchangeably. NIST’s precise term in the standards is “security category,” rated 1 through 5.
Which NIST security level should I use by default? Category 3 is the general-purpose default, which for key establishment means ML-KEM-768. Move to Category 5 for long-lived, high-assurance keys or when a mandate like CNSA 2.0 requires it.
What does Category 5 require? Category 5 means any attack must cost at least as much as a key search on AES-256. In the finalized standards it corresponds to ML-KEM-1024 and ML-DSA-87, which is exactly the pairing CNSA 2.0 mandates for national-security systems.
Why does ML-KEM have no Category 2 or 4 option? ML-KEM targets only the odd, AES-anchored categories (1, 3, 5), so it offers three parameter sets and no even-numbered tier. ML-DSA starts at Category 2 because its smallest set, ML-DSA-44, is calibrated to SHA-256 collision strength.
Is a higher category slower? Usually the cost shows up as size rather than speed. Higher categories mean larger keys, ciphertexts, and signatures while the compute stays fast, so bandwidth and storage are what you plan around and CPU rarely is.
Does the category account for quantum computers? Yes. NIST evaluates the resource thresholds under quantum metrics too (circuit size and a depth bound called MAXDEPTH), so the reference points already fold in the effect of quantum attacks like Grover’s on the underlying primitives.
How do I compare a signature’s category to a KEM’s category? Directly, which is the whole point of the scale. A Category 3 signature and a Category 3 KEM are both calibrated to roughly AES-192 difficulty, so the category lets you match strengths across different algorithm families without redoing the analysis.
Everything here is the map, given freely. When your team needs the right security categories chosen and sequenced across your own systems and mandates, that’s the work I do. Request an alignment briefing.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.