Compliance Packs

A compliance pack is a definition: a named, versioned statement of what one regulatory regime or governance framework says about cryptography, with the primary sources it is taken from, the controls it expresses, and a dated calendar for the algorithms it names. The platform defines six of them. This page describes what a pack contains, how its calendar is to be read, how the platform evaluates each tenant's keys against a pack, what a pack does not claim, and how the licence decides which packs are evaluated.

The six packs

The identifier in the first column is the value a licence carries and the value the API serves.

Every regime pack names NIST_CSWP_39 as its companion: governance is where a transition is planned, whatever the regime. The companion relation is catalogue content only. A licence states exactly the packs it was issued with; nothing adds a companion to it.

What a pack contains

A pack is declared in code in the platform's algorithm library, beside the algorithm catalogue. It has no database table, no write endpoint and no tenant override, and it changes only with a release.

Identity. A stable identifier, a title, a one- or two-sentence summary, a kind (REGIME or GOVERNANCE) and a packVersion. The version changes whenever any source, control, calendar entry, context statement or not-offered entry of the pack changes. It is the day of the change, YYYY-MM-DD, and a second or later change on the same day adds a sequence suffix .N with N of 2 or more (2026-09-29, then 2026-09-29.2); versions of one pack order by day, then by sequence, a version without a suffix being the first of its day. A licence carries the identifier, never the version: a licence names a regime, and the definition follows the release.

Normative sources. Each source has an identifier, a title, the edition as the source prints it, a publicationStatus of FINAL or DRAFT, and the URL of the primary document. A DRAFT source is never presented without that status. The publication date is kept at the precision the source prints: a day, a month, or, where the source carries no date, UNDATED with the source's own wording.

Controls. Each control has a type (ALGORITHM_ADMISSIBILITY, MIN_SECURITY_LEVEL, HYBRID_USE, ALGORITHM_CALENDAR, CRYPTOPERIOD, KEY_CUSTODY, GOVERNANCE, EVIDENCE_INTEGRITY or KEK_CRYPTOPERIOD), a reference to the source section it transcribes, an obligation in the source's own force (SHALL, SHOULD, MAY, SHOULD_NOT or SHALL_NOT), a verification mode and a severity. Severity follows the obligation (SHALL and SHALL_NOT are HIGH, SHOULD and SHOULD_NOT are MEDIUM, MAY is LOW) unless the control states a reason to differ. A control names algorithms by their catalogue identifiers and templates by their seeded names; it never restates a list the catalogue already produces.

Calendar. Dated milestones per algorithm and per use category, described in the next section.

Context statements. Regime statements that are not controls on keys: a milestone that binds an organisation and names no algorithm (product qualification, procurement, the phase-out of equipment, a phase of a national roadmap, the EU member-state milestones), a recorded mismatch between the source and the catalogue, or a statement no catalogue profile is exposed to, such as NIST's statement about 112-bit symmetric primitives. A milestone whose source names the algorithms it applies to is a calendar entry even when it binds an organisation: CNSA 2.0 "all new acquisitions for NSS will be required to be CNSA 2.0 compliant" names the CNSA 2.0 suite, so it is one. A context statement either names a milestone, read by the calendar's rules below (an UNDATED milestone included), or names no date at all (a mismatch, an absence, a position with no time in it), and then it carries neither a date nor a precision; it may still quote the source.

Not offered. What the regime requires or recommends that the platform does not offer, recorded rather than dropped. An IDENTIFIER entry is one parameter set, spelled in the catalogue's naming convention with the source's own spelling beside it; a CLASS entry is a group, such as the SP 800-208 parameter sets beyond the catalogue's rows, with its rationale.

Unverified points. Where the platform's research could not settle a fact in the primary source, the pack asserts it neither way and marks the entry unverified with the open question. Three such points exist today: whether NSA admits HMAC-SHA-384 and HMAC-SHA-512 under CNSA 2.0, whether NSA admits CMAC-AES-256 under CNSA 2.0, and whether ANSSI treats the platform's HKDF path (HKDF-SHA256, HKDF-SHA384 or HKDF-SHA512 used as an SP 800-227 KeyCombine combiner) as its "CatKDF".

Automated and customer-attested controls

Each control declares how it is evaluated.

• AUTOMATED: the platform's own state is enough to evaluate the control, for example a key's algorithm, security level, hybrid form, expiry date or custody backend. The platform evaluates it (see How a pack is evaluated).
• CUSTOMER_ATTESTED: the evidence lies outside the platform, for example an organisation-wide cryptographic inventory, procurement decisions, product qualification, or the risk class of a use case. The platform reports such a control as not evaluated, never as passed or failed.

Every pack carries the same notice: a satisfied AUTOMATED control does not mean the regime is satisfied. A regime is met by an organisation, not by one of its tools.

Reading the calendar

Each calendar entry names the algorithms it applies to, the use category in the source's own words (the categories are not harmonised across regimes), the key purposes it applies to, a milestone, a date with its precision, an obligation, an optional risk class and the source reference.

Purpose scope. purposes lists the key purposes an entry applies to: ENCRYPT_DECRYPT, SIGN_VERIFY, or both, in that order. An empty list means any purpose, because the use category names no single operation family. The NIST "Digital signature" and BSI "Signatures" entries declare SIGN_VERIFY; the NIST "Key establishment" and both BSI "Key agreement" entries declare ENCRYPT_DECRYPT. So the RSA-2048 key-establishment entry of NIST does not apply to an RSA-2048 signing key.

What date means depends on the milestone.

The table is the reading for a date of precision DAY or YEAR_END. A YEAR_START date is read differently, whatever the milestone: it is the first day the new state holds, so the earlier state ends the day before.

Precision states what the source printed, and every calendar entry carries one.

A year-only date is rendered as the year: it is never presented as a day the source did not print. A dated entry may quote the source too, so the presence of wording says nothing about the precision; only UNDATED requires it. ANSSI's phase 3, "probably not earlier than 2030", is an UNDATED context statement.

Absence is not an undated milestone. When a source gives no milestone of a kind, the pack has no entry of that kind. CNSA 2.0 gives custom applications and legacy equipment only an "exclusively by 2033" deadline, so that category has no support-and-prefer entry at all.

A family is a declared selector. An entry about "every classical asymmetric profile" or "RSA" carries the selector it was declared with, and the served entry also lists the concrete catalogue identifiers the selector expands to in this release.

The definition makes no comparison with today. Dates are civil calendar dates with no time zone. Nothing in the definition, the definition endpoints or the console's definition view compares them with the current date or marks a milestone as past or pending. The comparison belongs to the evaluation, which reads each entry on a stated reference day (below).

How a pack is evaluated

The platform runs every pack the deployment is entitled to against each tenant's keys and reports, per item of the pack, a result and the reason for it, then a score. The evaluation is read-only: it blocks no operation and changes no policy. A result is a statement about the keys the platform holds on a stated day, not an assessment by the regime's authority. The same evaluation, taken at the moment of a request, is what a signed evidence document carries, and what the report of an evidence package renders.

Which packs, which keys, which day

• Packs. The packs the deployment licence entitles, in catalogue order: under TRIAL every pack of this release; under LICENSED (a licence in its grace period included) the packs of this release its compliancePacks names; under EXPIRED none (Packs and the licence). Every other pack of this release is listed locked on both planes and is not evaluated. When no pack is evaluated, the tenant plane says so with emptyReason: NO_PACK_ENTITLED; an empty list is never presented as compliant. Every tenant is evaluated against every entitled pack; there is no per-tenant pack selection. An identifier the licence names that is not a pack of this release is listed on the platform plane only, as not evaluated. The licence status and those identifiers are platform facts: the tenant plane's evaluation never carries them, and learns only which packs are evaluated and which are locked. The one exception is the tenant's signed compliance evidence, which states TRIAL or LICENSED and nothing else about the licence.
• Keys. The tenant's live keys, those in ACTIVE, EXPIRED or SUSPENDED state; a revoked key, or one in any other state, is not evaluated. A composite key is evaluated by its own identifier, with its components read alongside it. A key whose algorithm resolves in no catalogue is listed in unresolvableKeys and never counts towards a pass.
• Reference day. The server's current UTC calendar date, returned as referenceDay. No request supplies a day.

The effective day of a calendar entry

Each dated calendar entry has an effective day, the first day its new state holds, derived from the milestone and the precision exactly as Reading the calendar describes:

Results and reasons

Each evaluated item, a control by its controlId or a calendar entry by its position in the pack version's calendar, receives one result:

A result may carry a reason: CUSTOMER_ATTESTED, UNVERIFIED, UNDATED, BEFORE_EFFECTIVE_DAY, RISK_CLASS_NOT_HELD, PERMISSION_OR_RECOMMENDATION, PLATFORM_PROPERTY, UNRESOLVABLE_KEYS, NO_MATCHING_KEY, EVIDENCE_CHAIN_BROKEN, NO_EVIDENCE_HISTORY, KEK_CRYPTOPERIOD_EXCEEDED, KEK_ROTATION_DUE, KEK_PROVIDER_ROTATION_OFF, KEK_CUSTOMER_ROTATION_OFF, KEK_ROTATION_UNOBSERVED, KEK_DEPLOYMENT_CUSTODY or NO_TENANT_KEK. The rules apply in this order:

1. Not decidable here. A CUSTOMER_ATTESTED item is NOT_EVALUATED with reason CUSTOMER_ATTESTED, even when its day has passed: the EU RSA-2048 2025-12-31 entry stays not evaluated, because a national extension may apply. An unverified entry is NOT_EVALUATED / UNVERIFIED; an undated calendar entry is NOT_EVALUATED / UNDATED.
2. Admissibility. A SHALL_NOT or SHOULD_NOT list fails, naming every live key on a listed algorithm, and passes otherwise. An exclusive SHALL set (CNSA 2.0's general admissibility) fails naming every key outside it. A MAY or SHOULD admission is INFORMATIONAL / PERMISSION_OR_RECOMMENDATION. A minimum-level control fails naming the keys of the governed kind outside its list.
3. Hybrid use is decided from the key's type, its components and its recorded KDF: ANSSI's hybridation rule fails a stand-alone ML-KEM or ML-DSA key; CNSA 2.0's prohibition fails a composite; BSI's combiner recommendation fails a composite recorded with CasKDF. Any other SHALL or SHOULD hybrid control that lists algorithms (BSI.HYBRID.KEM, BSI.HYBRID.SIGNATURE, EU.HYBRID.*) fails naming every stand-alone (non-composite) key on a listed algorithm and passes otherwise, scored at the control's severity (MEDIUM for SHOULD); one that lists no algorithm is INFORMATIONAL / PERMISSION_OR_RECOMMENDATION, listing the composite keys. A MAY is INFORMATIONAL.

4. Cryptoperiod (NIST.CRYPTOPERIOD, CSWP39.ALGORITHM-TRANSITIONS) fails naming every live key whose expiry date is absent or beyond its maximum cryptoperiod: later than the creation of the key's primary material plus the maximum of its key class (calendar months, UTC), 24 months for a symmetric key, 36 months for a private signature key, 24 months for a key-establishment key, and no maximum for a verify-only public key (NIST SP 800-57 Part 1 Rev. 5, Table 1; see Maximum cryptoperiod). It passes when every live key is within its maximum; the controls serve the table as maximumCryptoperiods. Key custody of LMS and XMSS fails naming each such key whose operations include sign. CSWP 39's policy-profile control passes when the tenant declared an explicit policy template. A control the platform satisfies by itself (CSWP 39's platform inventory and platform CBOM, ANSSI's platform hybrid mode) is PASS / PLATFORM_PROPERTY. Evidence integrity (CSWP39.EVIDENCE-INTEGRITY.PLATFORM) verifies every stored pack chain of the tenant (Daily history): PASS when all of them verify, FAIL / EVIDENCE_CHAIN_BROKEN when any of them is broken, and NOT_APPLICABLE / NO_EVIDENCE_HISTORY when the tenant has no stored row yet. It does not depend on the keys, so it is decided before rule 6. It is scored, except for a tenant with no live key: there the result is reported and kept outside the score, so that tenant stays NEUTRAL. Another tenant's chain never affects it. Tenant key-encryption key (NIST.CRYPTOPERIOD.KEK) measures the key-encryption key that wraps every data key of the tenant, by who rotates it, and names no key:

   • The platform, for a tenant key-encryption key on a PKCS#11 token (on the deployment's HSM or on an ANKA-managed PKCS#11 tier). Its age is that of its active version, from its activation (from its creation when no activation was recorded), in calendar months, UTC. It is PASS before the rotation period of the carrier it is on, WARNING / KEK_ROTATION_DUE from the end of that period, and FAIL / KEK_CRYPTOPERIOD_EXCEEDED from 24 months, the maximum for a key-wrapping key (SP 800-57 Part 1 Rev. 5, Table 1, row 7), or when neither instant is known. It is NOT_EVALUATED / KEK_ROTATION_UNOBSERVED when the carrier's period cannot be read.
   • The provider, for a key-encryption key on an ANKA-managed Cloud KMS tier, from the provider's rotation as the platform last observed it: rotating is PASS, not rotating is FAIL / KEK_PROVIDER_ROTATION_OFF, unknown or never observed is NOT_EVALUATED / KEK_ROTATION_UNOBSERVED.
   • The customer, for a tenant's own key: rotation enabled at the provider with a period of 730 days or less is PASS, a longer period is FAIL / KEK_CRYPTOPERIOD_EXCEEDED, rotation disabled is FAIL / KEK_CUSTOMER_ROTATION_OFF, and an unknown state or an enabled rotation with no stated period is NOT_EVALUATED / KEK_ROTATION_UNOBSERVED.
   • Not evaluated here: the deployment's own key-encryption key and a key-encryption key on a Cloud KMS deployment backend are NOT_APPLICABLE / KEK_DEPLOYMENT_CUSTODY; a tenant that holds no key-encryption key is NOT_APPLICABLE / NO_TENANT_KEK; a carrier the platform cannot classify is NOT_EVALUATED / KEK_ROTATION_UNOBSERVED. A fact the platform cannot establish is never PASS, and a provider or own-key rotation reading older than twice the interval of the pass that refreshes it (OWN_KEY_OBSERVE_INTERVAL, or the managed tier's reconcile interval), or, for an own key, taken before the backend was last declared, is not established.

   The result never depends on whether the key is protected in hardware, the item is decided before rule 6, and it is scored like the evidence-integrity control: for a tenant with no live key it is reported and kept outside the score. An ALGORITHM_CALENDAR control is read from the pack's AUTOMATED calendar entries, never re-evaluated against the keys: it fails when one of them fails, warns when one warns, and passes otherwise. It is never scored, because the entries it restates are, so a failing entry counts once. 5. Calendar entries. An entry matches a key when the key's own catalogue identifier is listed and the key's purpose is in the entry's purposes (an empty list matches any purpose; a key with no recorded purpose matches every scope). A composite never matches the identifier of one of its components. No match is NOT_APPLICABLE / NO_MATCHING_KEY. With a match, an entry scoped by a risk class is WARNING / RISK_CLASS_NOT_HELD naming the class and the effective day, on either side of that day and never FAIL, because which class a use case belongs to is the customer's classification. Any other matching entry is WARNING / BEFORE_EFFECTIVE_DAY before its effective day and FAIL on or after it, at the entry's severity. 6. Empty and unresolvable populations. A key-population control on a tenant with no live key is NOT_APPLICABLE. A result that would be PASS while an unresolvable key is in its population is NOT_EVALUATED / UNRESOLVABLE_KEYS. 7. Pointers. CSWP 39's reference to the NIST calendar is a pointer, not a second evaluation; context statements and not-offered entries are not findings.

For example, on 2026-10-05 a tenant whose payments-signing-rsa key is an RSA-2048 signing key receives, for the NIST RSA-2048 signature DEPRECATED_AFTER entry, WARNING / BEFORE_EFFECTIVE_DAY with effective day 2031-01-01, and NOT_APPLICABLE for the RSA-2048 key-establishment entry, which is scoped to ENCRYPT_DECRYPT.

The score

Per pack and tenant, score = scoredPassed / (scoredPassed + scoredFailed), a value from 0 to 1, over the scored items: AUTOMATED controls and AUTOMATED calendar entries whose result is PASS or FAIL, platform property passes, ALGORITHM_CALENDAR controls and every item of a tenant with no live key excluded. WARNING, INFORMATIONAL, NOT_APPLICABLE and NOT_EVALUATED are outside it. Every item weighs the same, and the counts of every result are served beside the score. When nothing is scored there is no score, and the status is NEUTRAL instead of SCORED; a tenant with no live key is NEUTRAL on every pack.

Every response repeats the pack notice: a satisfied AUTOMATED control does not mean the regime is satisfied.

The platform aggregate

On the platform plane each pack is aggregated over every tenant that is not soft-deleted, in any lifecycle status, other than the platform tenant: per item, the number of tenants in each result and the most severe tenant result, in the order FAIL, WARNING, NOT_EVALUATED, PASS, INFORMATIONAL, NOT_APPLICABLE, so an item fails when it fails in any tenant and an item no tenant could decide is never shown as passing; the platform score over those aggregate results, never a mean of tenant scores; and one row per tenant with its status, score and counts. A tenant's item that is outside the score (the evidence-integrity or key-encryption key result of a tenant with no live key) is counted in the tenant counts, and decides the aggregate result only when no tenant's item is inside the score; the item is then outside the platform score too. A tenant whose key population cannot be evaluated (a live key with no key identifier) is omitted and counted in tenantsSkipped, never shown as passing; any other failure fails the whole read. The platform plane carries no key identifier and no list of keys.

The platform plane also reads one tenant in one pack: that tenant's items, each with the number of its keys the result names and, on an item an exclusion rule decides key by key, the number of keys the rule examined and did not name, beside the pack's deployment score and the tenant's score in every entitled pack, all from one platform run. These are counts, never keys: the second count is not a count of compliant keys, because a rule also examines keys it does not govern and names none of them. The key names stay on the tenant plane.

Daily history

The daily posture snapshot cycle also stores, per tenant and evaluated pack, one row of facts: the pack version, the reference day, each item's result and reason, and the counts, never a key identifier. It stores one aggregate row per pack. The rows are append-only and hash-chained, the history reads return the stored facts of each day, and a change of pack version shows on the day it happened. A day on which the licence could not be read stores nothing, and the next cycle retries it.

Licence gaps are marked, never backfilled. With the day's pack rows, in the same transaction, the cycle stores one licence coverage row for the day: the licence status it read, the packs it evaluated and the packs the licence locked (the whole catalogue on EXPIRED, none on TRIAL). On an EXPIRED licence that row is the day's only write. The history reads serve, beside the points, licenceInactiveDays: the days of the window whose coverage row lists the pack as locked, as inclusive ranges of consecutive UTC days. Those days have no point, before or after a renewal; nothing evaluates them afterwards. A day with neither a point nor a range has no data, and the history does not guess why: the cycle did not run that day, the day predates the coverage record, or the pack was not yet in that day's catalogue (a pack in neither list of a day's row is never marked inactive). The coverage is deployment-wide, so on the tenant plane no range starts before the UTC day the tenant was created: a tenant is never shown a licence gap from before it existed, and a tenant identifier with no tenant record has an empty list. The platform plane is not clipped. For example, a pack stored on 1 to 3 October, locked by the licence on 4 to 6 October, evaluated again from 7 October, with no cycle on 8 October, reads over 1 to 9 October as points for 1, 2, 3 and 7 October and licenceInactiveDays: [{"from": "2026-10-04", "to": "2026-10-06"}].

The coverage row holds no tenant data and no key identifier, and it is outside the pack hash chain. A licence gap leaves no pack row, so the first row after it takes the next sequence number and chains to the last row before it: the chain verifies across the gap, and the signed evidence is unchanged.

The platform verifies these chains itself, walking each one from its first row and recomputing every row hash: before the daily cycle appends a day, when CSWP 39's evidence-integrity control is evaluated, and when a signed evidence document is generated, which states the outcome and the chain's head. The chain is keyed by a secret the platform holds, so a third party cannot verify it; what the signed document gives a third party is the platform's attributable statement of the outcome and a head to compare across documents.

When the licence cannot be read

Every read of a pack reads the licence from the License Server, uncached. What a failed read means depends on what the read serves:

• The current evaluation (both lists, the detail on either plane, one tenant in one pack), the remediation plan and its writes, and the evidence exports answer 502 Upstream Service Unavailable naming the licence server, with no partial result; the detail states neither the licence server's status nor its text. The plan is among them because its shape depends on the verdict: derived when the pack is entitled, read-only when it is not.
• The stored records (the history on both planes, the executions and the attestations of a pack) answer 200 with licensing: UNRESOLVED: the records are the audit record, and every write is refused on its own, so an unreadable licence withholds only the verdict, never the records.

No read ever falls back to a default pack set. A licence answer whose status is not TRIAL, LICENSED or EXPIRED is an unreadable licence, so no pack is evaluated on it.

The packs in detail

Each fact below is taken from the primary source named beside it and is the content of the pack version named here. The current versions are NIST_PQC_TRANSITION 2026-10-19, NSA_CNSA_2_0 2026-10-03, EU_PQC_ROADMAP 2026-10-02, BSI_TR_02102_1 2026-10-15, ANSSI_PQC 2026-10-10 and NIST_CSWP_39 2026-10-07. The five regime packs changed on 2026-10-02 when the catalogue replaced its single LMS and XMSS profiles with one row per offered parameter set and added SMAUG-T, and the NIST and CNSA 2.0 custody controls gained the restore rule. Four of them changed again on 2026-10-03: the NIST and CNSA 2.0 restore rule now rotates a restored key instead of revoking it, and the BSI and ANSSI packs admit LMS-SHA256-M24-H10-W4, with BSI declaring the SP 800-208 parameter sets beyond the catalogue rows as not offered. Three of them changed on 2026-10-05: the NIST and BSI per-category calendar entries declare their key purposes, and the NIST and CSWP 39 cryptoperiod statements name the key's expiry date as what carries a cryptoperiod. CSWP 39 changed again on 2026-10-06, when its CBOM and evidence-integrity controls were each split into a platform part evaluated from platform state and an organisation part attested by the customer (below); every tenant's CSWP 39 score moves at that version. The NIST and CSWP 39 cryptoperiod controls changed on 2026-10-07, when they gained a maximum cryptoperiod per key class from SP 800-57 Part 1 Rev. 5 Table 1: a key whose expiry lies beyond its maximum now fails, where before only a key with no expiry did. NIST changed again on 2026-10-19, when it gained the tenant key-encryption key cryptoperiod control: from that version, a tenant with live keys whose key-encryption key item passes or fails has one more scored item in its NIST score. ANSSI changed on 2026-10-10, when its symmetric floor began to admit HMAC-SHA256, HMAC-SHA3-256, CMAC-AES-192 and CMAC-AES-256 (PG-083 §2.1.3, RecoPQMAC): an HMAC or CMAC key on one of them now passes that control. BSI changed on 2026-10-15, when it began to cite BSI's TR-02102 page beside the guideline and to follow its advice against Classic McEliece: a CMCE-460896 or CMCE-6688128 key is now judged by a SHOULD_NOT control, as an ML-KEM-512 key is, and the hybrid recommendation no longer names Classic McEliece. Where a source is a draft, the pack says so on every entry taken from it.

The date each source was read is the one recorded in the research that backs the packs, not the date of the pack version:

• Read on 2026-09-28 (the regulatory source register; some of its rows were read from the workspace standards cache built on 2026-09-27 from the same primary URLs, with their publication status re-checked on 2026-09-28): FIPS 203, 204 and 205; SP 800-227; SP 800-131A Rev. 2 and Rev. 3 ipd; NIST IR 8547 ipd; SP 800-57 Part 1 Rev. 5; SP 800-208; NSA advisory PP-22-1338 and the CNSA 2.0 FAQ; the NIS Cooperation Group roadmap and FAQ; ECCG Agreed Cryptographic Mechanisms v2.0; BSI TR-02102-1 Version 2026-01; ANSSI views on the PQC transition, its 2023 follow-up and the ANSSI PQC FAQ; NIST CSWP 39-upd1.
• Read on 2026-09-29 (the attribution audit, which supersedes the register where they differ): ANSSI-PG-083 version 3.00 and SP 800-56A Rev. 3, both first recorded by that audit. SP 800-186 was read by the same audit from the workspace standards cache; no separate retrieval date is recorded for it.

NIST_PQC_TRANSITION

Sources: FIPS 203, FIPS 204 and FIPS 205 (final, 2024-08-13); SP 800-227 (final, September 2025); SP 800-131A Rev. 2 (final, March 2019, the revision in force); SP 800-131A Rev. 3 ipd (draft, 2024-10-21); NIST IR 8547 ipd (draft, 2024-11-12); SP 800-57 Part 1 Rev. 5 (final, 2020-05-04); SP 800-208 (final, October 2020); SP 800-56A Rev. 3 (final, April 2018); SP 800-186 (final, February 2023).

• Admissibility: ML-KEM, ML-DSA and SLH-DSA are approved (FIPS 203, 204, 205); LMS and XMSS, and their multi-tree variants HSS and XMSS^MT, are approved by SP 800-208 and are not suitable for general use because they require careful state management. The control names the five rows the catalogue offers: XMSS-SHA2_10_256, XMSSMT-SHA2_20/2_256, LMS-SHA256-M32-H10-W4, LMS-SHA256-M24-H10-W4 and LMS-HSS-L2-SHA256-M32-H10-W4. FN-DSA is not approved: FIPS 206 is not among the published FIPS, and NIST states only its intent to develop a FIPS derived from FALCON (IR 8547 ipd §2.1.1). Admitting LMS and XMSS is not conformance to SP 800-208; its custody requirement is the separate control below.
• Key custody of LMS and XMSS, SHALL, AUTOMATED (SP 800-208 §1; §8.1): key generation and signature generation are performed in hardware cryptographic modules that do not allow secret keying material to be exported, even in encrypted form, validated to FIPS 140-2 or FIPS 140-3 Level 3 or higher physical security, with a non-modifiable or limited operational environment, operating only in an approved mode and implementing no bypass mode. The platform generates and uses LMS and XMSS keys in software, and keeps the private key encrypted under a data-encryption key wrapped under the key-encryption key, which is export in encrypted form; no PKCS#11 mechanism is used for them. Every LMS or XMSS key whose private part the platform holds is therefore a gap. An imported public-only LMS or XMSS key is verify-only: the platform performs neither key generation nor signature generation with it, so it is outside the requirement. After a database restore, the platform refuses every signature by LMS or XMSS key material created at or before the restore: the restored copy carries the one-time signature indices as they stood when it was taken, and some of them may since have been used (core-api, against the restore marker, 409 stateful-key-exhausted). The restore procedure rotates each restored LMS or XMSS key: its successor signs from index 0, and the restored material becomes RETIRED and keeps VERIFY, so a signature made before the restore still verifies. The key is not revoked with reason SECURITY_COMPROMISE, which would also close VERIFY.
• SHOULD_NOT: X25519 and X448. They are not approved key-agreement schemes: the approved elliptic curves for ECC key agreement list no Montgomery curve (SP 800-56A Rev. 3 Appendix D, Table 24).
• Hybrid key encapsulation, MAY (SP 800-227 §4.6): a composite (PQ/T hybrid) key-encapsulation mechanism is permitted as a transitional measure, and its component shared secrets are combined with an approved key combiner.
• Hybrid signatures, MAY (IR 8547 ipd §3.2.2, draft): dual (composite) signatures are accommodated provided that at least one component signature algorithm is NIST-approved; hybrid use is permitted, not required.
• Cryptoperiod: each key has a cryptoperiod, "the time span during which a specific key is authorized for use" (SP 800-57 Part 1 Rev. 5 §5.3), after which it is replaced. The key's expiry date carries it, so a key with no expiry date has no cryptoperiod. Its originator-usage period, measured from the creation of the key's current material, is at most 24 months for a symmetric key, 36 months for a private signature key and 24 months for a key-establishment key; a public signature-verification key has no fixed maximum (SP 800-57 Part 1 Rev. 5 §5.3.6, Table 1, pp. 45-46, the upper end of each range). The control measures each key's expiry date against that maximum. A key's rotation schedule is bounded by the same maximum: a rotation interval longer than it is refused when it is written, and a schedule's next due instant never falls later than the creation of the key's current material plus that maximum.
• Tenant key-encryption key cryptoperiod, SHOULD, AUTOMATED (SP 800-57 Part 1 Rev. 5 §5.3.6, Table 1, row 7): the tenant key-encryption key, which wraps every data key of the tenant, is a key-wrapping key whose originator-usage period is at most 24 months, measured from the activation of its current version. A key-encryption key the platform rotates is also due at the rotation period of the carrier it is on; one its provider or its owner rotates is held to the rotation the provider is observed to apply (rule 4). The control type is KEK_CRYPTOPERIOD; it never bounds a data key's rotation schedule.
• Migration, SHOULD, customer-attested (IR 8547 ipd §2.2, draft): the protocols, software libraries, hardware modules and infrastructure components that rely on quantum-vulnerable public-key cryptography are identified and revised to support the post-quantum algorithms. The crypto-agility practice for it is the companion pack NIST_CSWP_39.
• Calendar, all from IR 8547 ipd and therefore draft: RSA-2048 is deprecated after 2030 and disallowed after 2035, for digital signature and key establishment, each in its own entry scoped to SIGN_VERIFY or ENCRYPT_DECRYPT. RSA-3072, RSA-4096, RSA-6144, RSA-8192, P-256, P-384, P-521, Ed25519 and Ed448 are disallowed after 2035, with no deprecation stage. X25519 and X448 have no calendar entry, since they are not approved. The Brainpool curves carry the same 2035 entry; NIST allows them for interoperability reasons, outside its recommended curves (SP 800-186 Appendix H.1).
• Recorded mismatch: NIST rates RSA-2048 at 112 bits and places ML-DSA-44 in Category 2, while the catalogue records both at its lowest level. The pack states the mismatch and sets no level threshold over those two profiles. The RSA-2048 statement is dated: signature generation at 112 bits is acceptable through 2030-12-31 (SP 800-131A Rev. 3 ipd §3, draft). The ML-DSA-44 statement names no date.
• Not offered: the six SLH-DSA SHAKE parameter sets; XMSS-SHA2_16_256 (key generation measured at 213.5 s), XMSS-SHA2_20_256 (key generation did not finish in 660 s), XMSSMT-SHA2_40/4_256 (first signature about 21.5 s) and LMS-SHA256-M32-H15-W4 (key generation 24.2 s), each over the synchronous request budget of a third of the SDK's 30 s read timeout; and, as a class, the other SP 800-208 heights, Winternitz parameters and hierarchies and the SHA-256/192 (beyond LMS-SHA256-M24-H10-W4), SHAKE256/256 and SHAKE256/192 sets, which are not modelled.

NSA_CNSA_2_0

Sources: advisory PP-22-1338 Ver. 1.0 (September 2022) and the CNSA 2.0 FAQ Ver. 2.1 (December 2024), both final; and SP 800-208 (final, October 2020), by which the FAQ specifies LMS and XMSS, for its custody requirement.

• Admissibility, SHALL: ML-KEM-1024, ML-DSA-87, AES-GCM-256 and AES-CCM-256.
• LMS and XMSS, MAY, customer-attested: allowed in specific applications, for firmware and software signing only; LMS SHA-256/192, offered as LMS-SHA256-M24-H10-W4, is recommended. What a key signs lies outside the platform. The control names the single-tree rows XMSS-SHA2_10_256, LMS-SHA256-M32-H10-W4 and LMS-SHA256-M24-H10-W4. Admitting them is not conformance to SP 800-208.
• Key custody of LMS and XMSS, SHALL, AUTOMATED: the same SP 800-208 requirement (§1; §8.1) as in NIST_PQC_TRANSITION, with the same result: every LMS or XMSS key whose private part the platform holds is a gap, because the platform generates and uses them in software; an imported public-only key is verify-only and outside the requirement. After a database restore, the platform refuses every signature by LMS or XMSS key material created at or before the restore: the restored copy carries the one-time signature indices as they stood when it was taken, and some of them may since have been used (core-api, against the restore marker, 409 stateful-key-exhausted). The restore procedure rotates each restored LMS or XMSS key: its successor signs from index 0, and the restored material becomes RETIRED and keeps VERIFY, so a signature made before the restore still verifies. The key is not revoked with reason SECURITY_COMPROMISE, which would also close VERIFY.
• Exclusions, SHALL_NOT: SLH-DSA, ML-KEM-512, ML-KEM-768, ML-DSA-44, ML-DSA-65, HashML-DSA, HSS and XMSS^MT — the multi-tree prohibition names the rows the catalogue offers, XMSSMT-SHA2_20/2_256 and LMS-HSS-L2-SHA256-M32-H10-W4, which carry no NSA attribution.
• Hybrid use, SHALL_NOT on national security system mission systems, except where NSA names an exception; the pack quotes the one it names (IKEv2) and does not generalise it.
• The pack references the seeded policy template US_NSA_CNSA by name.
• Calendar, as support-and-prefer by / exclusively use by: software and firmware signing 2025 / 2030; web browsers, servers and cloud services 2025 / 2033; traditional networking equipment 2026 / 2030; operating systems 2027 / 2033; niche equipment 2030 / 2033; custom applications and legacy equipment exclusively by 2033 only.
• Dated obligations, all customer-attested: new NSS acquisitions EXCLUSIVELY_BY 2027-01-01 (SHALL, "all new acquisitions for NSS will be required to be CNSA 2.0 compliant"); CNSA 2.0 mandated EXCLUSIVELY_BY 2031-12-31 (SHALL); all national security systems quantum-resistant by the end of 2035 (SHOULD: "NSA expects" the transition to be complete). These three name the CNSA 2.0 suite and are calendar entries. The phase-out of equipment and services that cannot support CNSA 2.0 by 2030-12-31 (SHALL) names no algorithm, so it is a context statement.
• Unverified: whether HMAC-SHA-384/512 and CMAC-AES-256 are admitted. Their SHOULD is the force of the FAQ's advice to consult NSA before using what CNSA 2.0 does not specify, not a recommendation to use the construction.
• Not offered: XMSS-SHA2_16_256, XMSS-SHA2_20_256 and LMS-SHA256-M32-H15-W4, over the synchronous request budget; the other LMS and XMSS heights and Winternitz parameters, which are not modelled; and SHA-384/512 as a first-class hash policy item.

EU_PQC_ROADMAP

Sources, all final: the NIS Cooperation Group roadmap, Part 1 Version 1.1 (11.06.2025); the NIS CG FAQ (15.04.2026); and the ECCG Agreed Cryptographic Mechanisms v2.0 (April 2025, in force; the version 3 draft is not used).

• Calendar, risk-scoped, SHALL: every classical asymmetric profile of the catalogue (RSA, the NIST and Brainpool curves, X25519, X448, Ed25519, Ed448, SM2 and GOST R 34.10-2012) is not to be used stand-alone after the end of 2030 for high-risk use cases and after the end of 2035 for medium-risk use cases; the roadmap prints the years only. The set is derived, not enumerated: one key-type selector per classical asymmetric key type of the catalogue (RSA, EC, OKP, SM2, GOST-EC). A composite or a PQC profile satisfies the control. Low-risk use cases have no stand-alone deadline, and the control says so; their "as much as feasible" 2035 milestone is a customer-attested context statement.
• Risk classification: customer-attested. The roadmap defines the classes; classifying a use case is the customer's act.
• Hybrid use, SHOULD (roadmap §4.1): lattice-based key-encapsulation mechanisms, ML-KEM and FrodoKEM, are combined with a classical mechanism (ECCG ACM Note 60), and so is ML-DSA, with a classically secure signature mechanism (Note 51). Hash-based signatures may stand alone (Note 53).
• Admissibility per ECCG ACM v2.0: ML-KEM-768, ML-KEM-1024, FRODO-976, FRODO-1344, ML-DSA-65, ML-DSA-87, SLH-DSA-SHA2-192S, SLH-DSA-SHA2-192F, SLH-DSA-SHA2-256S, SLH-DSA-SHA2-256F, the single-tree XMSS-SHA2_10_256 and LMS-SHA256-M32-H10-W4 (no multi-tree set), and RSA with a modulus of at least 3000 bits (RSA-3072, RSA-4096, RSA-6144, RSA-8192).
• RSA-2048 carries the ACM Note 30 legacy deadline, disallowed after 2025-12-31, stated as the source prints it together with its second sentence: "A later acceptability deadline for user/data authentication with this particular algorithm may be set on a national level." Because a national extension may apply, the entry is customer-attested, not automated.
• Not in the ACM v2.0 list, SHALL, customer-attested: Classic McEliece, FN-DSA/Falcon, HQC, BIKE, NTRU, NTRU Prime, SABER and SMAUG-T. A construction is agreed only when it uses agreed primitives (ACM §1.2, Note 1). The pack records the absence and sets no deadline for them.
• Member-state milestones (31.12.2026, 31.12.2030, 31.12.2035) are customer-attested context, not controls on keys.
• Not offered: the SLH-DSA SHAKE parameter sets at security levels 3 and 5; the curve FRP256v1 (ACM §4.3); and composite KEMs with FrodoKEM, which is to be combined with a classical mechanism like ML-KEM but has no composite pair in the catalogue.

BSI_TR_02102_1

Sources: BSI TR-02102-1 Version 2026-01 (23 January 2026), final; and BSI's TR-02102 page (source BSI-TR-02102-PAGE, final, undated: the page prints no publication date), whose notes on recent developments concerning Classic McEliece carry BSI's later advice on it. The guideline is a technical guideline, so its force is "recommends" and "should", never SHALL, and its prediction period ends in 2032.

• Recommended post-quantum mechanisms: FRODO-976, FRODO-1344, ML-KEM-768, ML-KEM-1024, ML-DSA-65, ML-DSA-87 (hedged), SLH-DSA-SHA2-192S, SLH-DSA-SHA2-192F, SLH-DSA-SHA2-256S, SLH-DSA-SHA2-256F, and LMS and XMSS with their multi-tree variants HSS and XMSS^MT, with every parameter set of SP 800-208 (§5.3.4.3, Table 5.8), where the state can be managed. The control names every row the catalogue offers: XMSS-SHA2_10_256, XMSSMT-SHA2_20/2_256, LMS-SHA256-M32-H10-W4, the SHA-256/192 set LMS-SHA256-M24-H10-W4 and LMS-HSS-L2-SHA256-M32-H10-W4; the hash-based exemption from the hybrid recommendation names the same rows.
• SHOULD_NOT: ML-KEM-512, ML-DSA-44, the SLH-DSA Category 1 sets and RSA-2048. HQC is not yet recommended.
• Classic McEliece, SHOULD_NOT, AUTOMATED (BSI.NOT-RECOMMENDED.CLASSIC-MCELIECE, source BSI-TR-02102-PAGE): Classic McEliece should no longer be used for new developments or in the planning of new cryptographic applications. The control names CMCE-460896 and CMCE-6688128. BSI states that results so far allow no practical attack on the parameter sets TR-02102-1 recommends, and sets no migration requirement for existing use: an existing Classic McEliece key keeps every operation, and the evaluation reports it under this control as it reports an ML-KEM-512 key under BSI.NOT-RECOMMENDED.ML-KEM-512. TR-02102-1 Version 2026-01 still prints Classic McEliece in its Table 2.6; the pack follows the later advice.
• Hybrid use, SHOULD (BSI.HYBRID.KEM, BSI.HYBRID.SIGNATURE): for every recommended KEM — ML-KEM-768, ML-KEM-1024, FRODO-976 and FRODO-1344 — and for ML-DSA. Hash-based signatures may stand alone.
• Minimum classical lengths: RSA and DH 3000 bits, elliptic curves 250 bits; RSA-2048 falls below them, which is its SHOULD_NOT control (§1.1, Table 1.2).
• Combiners, SHOULD, AUTOMATED (§2.2, Table 2.1): a hybrid key agreement combines its shared secrets with CatKDF (with KMAC or HKDF) or the SP 800-227 KeyCombine construction. The platform records one KDF per composite key-encapsulation key: CatKDF or CasKDF of ETSI TS 103 744 (§8.2.3, §8.3.3), or HKDF-SHA256, HKDF-SHA384 or HKDF-SHA512, the SP 800-56C Rev. 2 two-step derivation used as an SP 800-227 §4.6.2 combiner, which is the KeyCombine route. CasKDF is not in Table 2.1, so a key recorded with it does not follow this recommendation. The BSI_HYBRID_ENFORCED template follows the same table: its allowedKdfs is HKDF-SHA256 and CatKDF, so a key that template admits never fails this control.
• Calendar, NOT_STANDALONE_AFTER: what the dates end is the sole use of a classical mechanism; after them it stays recommended in combination with a quantum-safe one. Classical key agreement is not recommended stand-alone after the end of 2031 (2030 for very high protection requirements, customer-attested); classical signatures not after the end of 2035, which the guideline states together with "In future versions, signature methods that are not quantum-safe will therefore only be recommended for hybrid use" (§2.1). The two use categories are kept apart, and the calendar names only the profiles the guideline recommends: RSA of at least 3000 bits and the Brainpool curves of Table B.3.
• Not offered: the SLH-DSA SHAKE sets at levels 3 and 5; the curve brainpoolP320r1 (Table B.3); and composite KEMs with FrodoKEM, since no composite pair in the catalogue has a FrodoKEM component. HSS and XMSS^MT are offered and named in the recommendation above. As a class, the SP 800-208 parameter sets beyond the catalogue rows: the guideline recommends every one of them, and the catalogue offers one row per set whose key creation fits the synchronous request budget, a third of the SDK's 30 s read timeout. XMSS-SHA2_16_256, XMSS-SHA2_20_256, XMSSMT-SHA2_40/4_256 and LMS-SHA256-M32-H15-W4 exceed that budget; the other heights, Winternitz parameters, hierarchies and hash functions are not modelled.

ANSSI_PQC

Sources: ANSSI-PG-083 version 3.00, Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques (final, 20 March 2026), ANSSI's current rulebook, to which every fact it restates or supersedes is cited; ANSSI views on the PQC transition (30 March 2022); its 2023 follow-up (21 December 2023); and the ANSSI PQC FAQ, which carries no date (it is at least as recent as December 2025).

• Scope: binding only in ANSSI's regulated scope: defence-classified information and information marked Diffusion Restreinte, vital information systems (the SAIV scheme), and product certification and qualification (ANSSI security visas). Outside that scope its post-quantum recommendations, hybridation included, have no regulatory force. The pack states this scope.
• Hybrid use, SHALL, AUTOMATED in the regulated scope, for every post-quantum mechanism except hash-based signatures: a mechanism relying only on lattice problems does not satisfy the classical-security rule, so ML-KEM and ML-DSA without hybridation do not conform, whatever the parameter set (PG-083 §2.2, RègleSécuAsym). The control names all 28 post-quantum parameter sets of the catalogue that are not hash-based, ML-KEM-512 and ML-DSA-44 included: ML-KEM, ML-DSA and FrodoKEM, which PG-083 names; FN-DSA, which the 2023 follow-up §2 lists; and BIKE, Classic McEliece, HQC, NTRU, NTRU Prime, SABER and SMAUG-T, which that list does not name. The same rule covers them: the FAQ exempts from systematic hybridation only the signature algorithms based on hashing, and the 2023 follow-up §4 requires hybridation "except if the quantum mitigation only relies on hash-based signatures". The exception is SLH-DSA, XMSS and LMS, for which hybridation is conformant but optional. Phase 2 lasts "until at least 2030", with no end date (2022 position paper).
• Platform products: a platform product must implement a hybrid mode, and its user guidance must recommend using post-quantum algorithms only in hybrid. The mode is AUTOMATED — a policy with requireComposite refuses a stand-alone key of every one of the 28 sets above and admits the hash-based signatures; the guidance is customer-attested.
• Admissibility, non-exhaustive, every post-quantum mechanism in hybrid form except hash-based signatures:
  • ML-KEM-512 is conformant, but the higher level, ML-KEM-768, is preferable (PG-083 §2.2.2). FrodoKEM likewise: FrodoKEM-640 is conformant and FrodoKEM-976 preferable; the catalogue offers FRODO-976 and FRODO-1344.
  • ML-DSA preferably at level 5 or 3, FN-DSA preferably at level 5, and XMSS and LMS where the state can be managed (2023 follow-up §2) — the single-tree rows XMSS-SHA2_10_256, LMS-SHA256-M32-H10-W4 and LMS-SHA256-M24-H10-W4, which carry the ANSSI attribution; no multi-tree set is admitted. Each uses a hash output of at least 192 bits — 256 bits, and 192 bits for LMS-SHA256-M24-H10-W4 — the size PG-083 §2.1.4 recommends for the hash function inside a hash-based signature when post-quantum security is targeted.
  • SLH-DSA with a hash output of at least 192 bits (SLH-DSA-SHA2-192S, SLH-DSA-SHA2-192F, SLH-DSA-SHA2-256S, SLH-DSA-SHA2-256F) may be used as it is (PG-083 §2.2.3). SLH-DSA-SHA2-128S and SLH-DSA-SHA2-128F, the category-1 sets, are SHOULD_NOT: when post-quantum security is targeted, the hash output should be at least 192 bits (PG-083 §2.1.4).
  • RSA with a modulus of at least 3072 bits (RSA-3072 to RSA-8192), recommended even for use that does not go beyond 2030 (PG-083 §2.2.1.1, RègleFactorisation). RSA-2048 is SHOULD_NOT (RecoFactorisation.1) and carries a DISALLOWED_AFTER calendar entry for the end of 2030, a year the guide prints without a day: a 2048-bit modulus is the minimum only for use that does not go beyond the end of 2030 (RègleFactorisation.1, RègleFactorisation.2).
  • The curves P-256, P-384, P-521, brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1 (PG-083 §2.2.1.2). The guide names no Edwards or Montgomery curve and its list is not closed, so the pack neither admits nor excludes X25519, X448, Ed25519 and Ed448.
• Symmetric floor, SHOULD: when post-quantum security is targeted, symmetric keys of at least 192 bits (PG-083 §2.1.1, RecoPQTailleCléSym). A message-authentication mechanism rests on a primitive that meets the post-quantum recommendations (§2.1.3, RecoPQMAC): CMAC over AES-192 or AES-256, and HMAC, which needs no collision resistance from its hash, so a 256-bit hash output is enough and HMAC with SHA-256 conforms. The 384-bit hash output of §2.1.4 (RecoPQHachage) governs a bare hash function, which no key of the catalogue is. The catalogue profiles meeting the floor are AES-GCM-192, AES-GCM-256, AES-CCM-192, AES-CCM-256, CMAC-AES-192, CMAC-AES-256, HMAC-SHA256, HMAC-SHA384, HMAC-SHA512, HMAC-SHA3-256, HMAC-SHA3-384 and HMAC-SHA3-512. KMAC, which the guide does not name, is not among them.
• Combiners, SHOULD, customer-attested: ANSSI recommends CatKDF and CasKDF. The platform records one KDF per composite key-encapsulation key: CatKDF or CasKDF of ETSI TS 103 744 (§8.2.3, §8.3.3), or HKDF-SHA256, HKDF-SHA384 or HKDF-SHA512 as an SP 800-227 KeyCombine combiner. Whether ANSSI accepts that HKDF path as its CatKDF is unverified, and the pack asserts neither acceptance nor refusal. The ANSSI_HYBRID_ENFORCED template admits HKDF-SHA256, CatKDF and CasKDF (2023 follow-up §3.1).
• Calendar: only RSA-2048, disallowed after 2030 as above (AUTOMATED). The calendar holds only milestones on the algorithm of a key.
• Context, customer-attested, the milestones on organisations:
  • PQC obligations for entry into product qualification from 2027 (YEAR_START, MAY): ANSSI states an aim, "vise la mise en place", not yet an obligation or a recommendation.
  • Products that do not integrate PQC are no longer bought from 2030 (YEAR_START, SHOULD). The FAQ words it twice, "pas raisonnable d'acheter […] après 2030" and, as a best practice, "Ne plus acheter […] à partir de 2030"; the pack quotes both and dates it by the stricter one.
  • Phase 3 makes stand-alone PQC optional, "probably not earlier than 2030": UNDATED, MAY. Hybridation stays mandatory until then.
  • The hybrid recommendation has no end date; the statement names no date and quotes the FAQ.
• Not offered: the curve FRP256v1 (PG-083 §2.2.1.2), and composite KEMs with FrodoKEM, which is conformant only in hybrid form but has no composite pair in the catalogue.

NIST_CSWP_39

Source: NIST CSWP 39-upd1 ("December 19, 2025, includes updates as of 06-29-2026"). The December 2025 final is withdrawn and is not cited.

• AUTOMATED: §5 inventory, for the keys the platform manages; §5.2 machine-consumable policy profiles (the seeded policy templates); §3.2 algorithm transitions, a cryptoperiod control: key expiration and revocation are tools for an algorithm transition because a key is bound to one algorithm, and each key's expiry date carries its expiration, no later than the SP 800-57 maximum cryptoperiod of its key class; §5.3 the CBOM for the keys the platform manages (CSWP39.CBOM.PLATFORM, PASS / PLATFORM_PROPERTY, not scored), which the platform produces in every signed evidence document; §5 evidence integrity of the platform's own daily evaluation history (CSWP39.EVIDENCE-INTEGRITY.PLATFORM, scored, except for a tenant with no live key, which stays NEUTRAL).
• CUSTOMER_ATTESTED: §5 organisation-wide inventory; §5.1 the standards, regulations and mandates that set transition requirements; §5.3 technology supply chains, and the rest of the CBOM — protocols, libraries, applications and certificates the platform does not see (CSWP39.CBOM.ORGANISATION); §5.4 cryptographic architecture; §5 evidence integrity of what the organisation measures and reports outside the platform (CSWP39.EVIDENCE-INTEGRITY.ORGANISATION); §6.5 maturity assessment.
• Calendar: none of its own. CSWP 39 §2.3 defers to IR 8547 and SP 800-131A Rev. 3, so the pack references the NIST_PQC_TRANSITION calendar rather than copying it.

What a pack does not claim

A pack states what a regime says and which of its points the platform supports. A deployment aligns with a regime through the controls the platform provides; a pack is not an assessment of a deployment by the regime's authority, and holding one does not mean the regime is met. Its evaluation score measures the platform's own state against the AUTOMATED items only; it is not a certification. A signed evidence document attributes the evaluation to the deployment; it does not turn it into one.

• No pack is a validation programme. FIPS 140-3 is a module-validation programme, not a regime a cryptographic platform can claim through a pack, and it is not a pack.
• A procurement guide is not a regime. The GSA PQC Buyer's Guide lists considerations for agencies and sets no product requirements; the separate GSA PQC Buyer's Guide Alignment page of the partner documentation maps the platform to it.
• A standards body is not a regime, and an IETF draft is a capability. Neither is a pack.

The seeded algorithm availability templates keep their names. A template whose name resembles a former pack label is a template, not a pack, and is unchanged.

Packs and the licence

A deployment licence lists the identifiers of the packs it was issued with, in its compliancePacks member. With the licence status, the list decides which packs are evaluated and which compliance operations a pack admits. Nothing else reads it: no key, policy or crypto operation is allowed or refused because of it.

Entitlement by licence status

A trial evaluates the whole catalogue so that the deployment shows what each pack measures before a licence is chosen. The grace period keeps every named pack entitled: it is the window in which the licence is still honoured. An identifier the licence names that is not a pack of this release is neither evaluated nor locked; the platform plane lists it as not in the catalogue.

Locked packs

A pack of the catalogue the licence does not entitle is locked. Both evaluation lists carry the locked pack identifiers in lockedPacks, in catalogue order, beside the evaluated packs: the tenant plane learns which packs it is not evaluated against, as it learned it before from the refusal, and still never the licence status. A locked pack is never evaluated or scored, so it has no score, no counts and no evidence. The admin console shows each one as a card labelled Not included in your licence, with the pack's name, description and controls read from the pack definitions, and says who can change that: on the tenant plane the platform administrator, on the platform plane the account manager, through the License screen.

A pack that leaves the licence

When a renewed licence no longer names a pack, or the licence expires, the pack turns read-only. Its stored records stay readable without limit: the daily history on both planes, the remediation plan's follow-up (each action's owner, target date, risk acceptance and migration declaration), the executions and the attestations. Every one of those reads carries licensing: NOT_LICENSED; for an entitled pack it is LICENSED. The read-only plan lists each action with a stored follow-up, with the stored status, or RISK_ACCEPTED while an acceptance is in force, and never RESOLVED, which only an evaluation decides. It carries no score, projection, progress, deadline, finding or step, and no attestable item, because nothing is evaluated.

Nine operations are refused for a locked pack with 403 Compliance Pack Not Licensed: the live evaluation of the pack on either plane and of one tenant in it, every remediation write (updating an action, previewing a step, executing it, recording an attestation) and both evidence exports. A refusal writes nothing, emits no audit event, calls no other service and signs nothing. One answer comes before the licence: an execution retried with the Idempotency-Key and request of an execution already recorded answers its stored result even after the pack left the licence, because a replay writes, emits and calls nothing (Retrying safely). The verification keys stay readable on every licence status, EXPIRED included, so a document issued while the pack was licensed still verifies offline. When the pack returns to the licence, it is evaluated again from the next request, and its history resumes on the next daily cycle with the days in between marked as licence gaps.

Deliberate deviation from cloud findings stores. Cloud security posture services let the findings of a standard that is switched off age out. AWS Security Hub archives the existing findings of a disabled standard automatically after approximately three to five days (Disabling a security standard, read 2026-10-09), and, once the service is disabled for the account, permanently deletes archived findings after 30 days (Disabling Security Hub CSPM, read 2026-10-09). The platform keeps them instead, because what it keeps is a different record. The pack history is a hash-chained, tamper-evident record that signed evidence relies on, and the plan holds customer decisions, risk acceptances above all, that an auditor asks for. Deleting them would remove evidence of past posture. A cloud findings store is regenerated when the standard is enabled again; this record is not.

Before the licence ends

On the platform compliance evaluation screens of the admin console, while the deployment licence notice is in its WARNING, CRITICAL or GRACE band, an inline note that cannot be dismissed states that the packs stop being evaluated and turn read-only when the licence ends. The bands are those of the licence notice the console banner reads; no compliance setting is added.

Pack identifiers at issuance and import

• At issuance, the offline signing tool refuses an identifier that is not one of the six packs, before anything is signed.
• At import, the License Server refuses a licence naming an identifier that is not one of the packs of the running release, with 422 License Artifact Invalid. The check runs after the signature is verified and before anything is stored. The problem names the compliancePacks member, never the value, and says to re-issue the licence.

A pack retired by a later release

The six identifiers are the vocabulary of this release. A licence imported under an earlier release may name an identifier this release no longer defines (earlier releases used five different labels). Such a licence keeps verifying and keeps its state: its signature covers the bytes as issued, the licence view returns the identifier as stored, and the console shows it as a chip labelled as not in this release's catalogue, with no link and no alias to a current pack. Only a new import naming that identifier is refused. Admission follows the running release's vocabulary; integrity follows the licence's authenticity.

Replacing a licence that names a retired identifier

No environment is recreated for this, and no stored licence is deleted.

1. Issue a new licence with the current pack identifiers, with a validFrom not earlier than the validFrom of the licence it replaces. The licence in force is the one with the latest validFrom among those whose window covers today, so the new licence takes over on its start date.
2. Import it. On a customer-operated installation the platform administrator imports it in the console's License screen; the import is the operator's act, never the issuer's.
3. Confirm that the License screen lists the new packs as resolved chips.

Reading the definitions

The definitions are served read-only by the Admin API on two planes, with the same body on both:

• on the platform plane, GET /api/v3/admin/platform/compliance-packs and GET /api/v3/admin/platform/compliance-packs/{packId}, under the permission to read the platform algorithm catalogue;
• on the tenant plane, GET /api/v3/admin/tenants/{tenantId}/compliance-packs and GET /api/v3/admin/tenants/{tenantId}/compliance-packs/{packId}, under the permission to read the tenant's algorithm catalogue.

A well-formed identifier that is not a pack of this release answers 404 Compliance Pack Not Found. In the admin console, a resolved chip on the License screen opens the pack's detail, and the tenant's policy screens offer the same detail on the tenant plane.

Reading the evaluation

The evaluation is served read-only by the Admin API on two planes, under the analytics read permission of each plane:

• on the tenant plane, GET /api/v3/admin/tenants/{tenantId}/compliance-evaluations (each entitled pack's score and counts, and the locked pack identifiers), GET /api/v3/admin/tenants/{tenantId}/compliance-evaluations/{packId} (every item with its result, reason and offending keys) and GET /api/v3/admin/tenants/{tenantId}/compliance-evaluations/{packId}/history (the stored daily series);
• on the platform plane, GET /api/v3/admin/platform/compliance-evaluations, GET /api/v3/admin/platform/compliance-evaluations/{packId}, GET /api/v3/admin/platform/compliance-evaluations/{packId}/history and GET /api/v3/admin/platform/compliance-evaluations/{packId}/tenants/{tenantId} (one tenant in one pack: its items with key counts, the pack's deployment score and the tenant's score in every entitled pack), which add the licence status, the per-tenant table and the tenant counts per item, and carry no key identifier.

A catalogued pack the licence does not entitle answers 403 Compliance Pack Not Licensed on the detail read of either plane and on the platform read of one tenant in one pack, while its history answers 200 with licensing: NOT_LICENSED (A pack that leaves the licence). In the admin console the evaluation has its own screen on each plane, with a page per pack; on the platform plane a page per tenant in a pack opens from the overview's tenants × packs grid and from the pack page's tenant table, and offers to open the tenant's own view, through the audited entry into the tenant's context, for the key names and the remediation plan.

The tenant plane also serves the evaluation of one pack as a signed document, with the keys that verify it: GET /api/v3/admin/tenants/{tenantId}/compliance-evidence/{packId} and GET /api/v3/admin/tenants/{tenantId}/compliance-evidence/verification-keys, under the same analytics read permission; the platform plane serves the verification keys alone at GET /api/v3/admin/platform/compliance-evidence/verification-keys. See Compliance Evidence.

The tenant plane turns the evaluation of a pack into a remediation plan at GET /api/v3/admin/tenants/{tenantId}/compliance-remediation/{packId}, under the same analytics read permission; previewing reads too, while executing a step, tracking an action and recording an attestation need admin.tenant.compliance.remediation.write. See Compliance Remediation Plans.