Cryptography Standard: [Organisation name]
Organisation-wide standard for the use of cryptography: approved algorithms and minimum key sizes, protocols
(TLS 1.3 by default), random number generation, password hashing, key management across the key lifecycle,
cryptographic modules, the deprecation schedule for weak and quantum-vulnerable algorithms, crypto agility,
exceptions and compliance checks. Key management follows NIST SP 800-57 Part 1 Rev. 5 (May 2020). Algorithm
transitions follow NIST SP 800-131A Rev. 2 (March 2019; Rev. 3 is an initial public draft from October 2024) and
NIST IR 8547, Transition to Post-Quantum Cryptography Standards (final, October 2026), which deprecates
quantum-vulnerable public-key algorithms after 2030 and disallows them under NIST standards after 2035.
Replace every [bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [SEC-STD-CRY-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@security-architect] |
| Approvers/reviewers | [@ciso], [@chief-architect], [@platform-lead], [@privacy-officer] |
| Policy parent | [Information security policy ID] |
| Applies to | [All entities, products, environments and suppliers handling organisation data] |
| Effective date | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD (at most 12 months after approval) |
| Classification | [Internal] |
| Last updated | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|
| Chief information security officer | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief architect | [@name] | [Decision] | YYYY-MM-DD |
| Platform and infrastructure | [@name] | [Decision] | YYYY-MM-DD |
| Data protection officer (consulted) | [@name] | [Comments] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | Example: Added post-quantum algorithms and the 2030/2035 schedule from NIST IR 8547 (final) |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved; TLS 1.2 minimum, TLS 1.3 default |
Contents
1. Purpose, scope and authority
This standard sets the minimum rules for protecting the confidentiality, integrity and authenticity of organisation data with cryptography. It applies to every system that the organisation builds, buys, operates or has operated on its behalf, in every environment where real data is processed.
| In scope | Out of scope |
|---|
| Example: Data in transit between any two systems, including internal service traffic | Cryptography inside a supplier's service that never handles organisation data |
| Example: Data at rest in databases, object storage, backups, laptops and mobile devices | Personal devices not enrolled in device management (covered by the acceptable use policy) |
| Example: Code, container and firmware signing; document and email signing | National security systems under separate government rules |
| Example: Keys, certificates, HSMs, cloud KMS and secrets platforms | [Item] |
| [Item] | [Item] |
Authority: the standard is issued under [information security policy ID] by the [CISO]. A breach of a MUST rule is a security finding and is tracked in the risk register (compliance/risk-register) until fixed or excepted.
2. Roles and responsibilities
| Role | Responsibility |
|---|
| Standard owner [@security-architect] | Maintains this document, reviews it at least yearly and after any major advisory, chairs the cryptography review |
| CISO | Approves the standard and exceptions above [threshold] risk |
| Key custodians | Generate, activate, rotate and destroy keys for a named system, following section 8 |
| Platform team | Provides approved libraries, KMS, HSM and TLS termination as paved roads |
| System owners | Keep their systems compliant, register cryptographic assets in the inventory (section 11), request exceptions |
| Procurement and supplier management | Include the supplier clauses in section 9.3 in contracts and assessments (compliance/supplier-security-assessment) |
| Internal audit | Tests compliance independently |
3. Principles and requirement language
The keywords MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are used as described in RFC 2119 and RFC 8174 when written in capitals.
| ID | Principle |
|---|
| CRY-P01 | Use vetted, standard algorithms through vetted libraries. Never design or implement a cryptographic algorithm or protocol in house. |
| CRY-P02 | Prefer platform services (managed TLS, KMS, HSM, secrets platform) over application-level key handling. |
| CRY-P03 | Choose strength by the lifetime of the protection needed, not by the lifetime of the system. Data that must stay confidential beyond 2035 needs quantum-resistant key establishment now. |
| CRY-P04 | Keep algorithm choices in configuration, so they can change without a code release (section 11). |
| CRY-P05 | Every key has one owner, one purpose and a defined cryptoperiod. |
| CRY-P06 | Fail closed: a failed verification, decryption or certificate check stops the operation. |
4. Approved algorithms and minimum strengths
4.1 Security strength baseline
New systems MUST provide at least 128 bits of classical security strength. Existing systems at 112 bits MAY continue until the dates in section 5. The comparable strengths below follow NIST SP 800-57 Part 1 Rev. 5 (section 5.6).
| Security strength | Symmetric | RSA modulus | Elliptic curve key size | Finite field (L, N) | Hash for signatures |
|---|
| 112 bits | 3TDEA (disallowed, see section 5) | 2048 | 224 to 255 | 2048, 224 | SHA-224, SHA-512/224, SHA3-224 |
| 128 bits | AES-128 | 3072 | 256 to 383 | 3072, 256 | SHA-256, SHA-512/256, SHA3-256 |
| 192 bits | AES-192 | 7680 | 384 to 511 | 7680, 384 | SHA-384, SHA3-384 |
| 256 bits | AES-256 | 15360 | 512 and above | 15360, 512 | SHA-512, SHA3-512 |
4.2 Approved algorithm list
| ID | Function | Approved algorithm and parameters | Default | Notes |
|---|
| CRY-ALG-001 | Symmetric encryption, authenticated | AES-GCM (128 or 256-bit key, 96-bit nonce, 128-bit tag); ChaCha20-Poly1305 (RFC 8439) | AES-256-GCM | Nonce MUST be unique per key; with random nonces, at most 2^32 encryptions per key (NIST SP 800-38D) |
| CRY-ALG-002 | Symmetric encryption, storage | AES-XTS (SP 800-38E) for full-disk and block storage; AES-GCM-SIV (RFC 8452) where nonce reuse is a risk | Platform default | XTS gives confidentiality only; add integrity where tampering matters |
| CRY-ALG-003 | Lightweight authenticated encryption | Ascon-AEAD128 (NIST SP 800-232) | Constrained devices only | Approved for devices that cannot run AES efficiently |
| CRY-ALG-004 | Hash | SHA-256, SHA-384, SHA-512, SHA-512/256, SHA3-256, SHA3-384, SHA3-512 | SHA-256 | SHA-1 and MD5 prohibited for security purposes (section 5) |
| CRY-ALG-005 | Message authentication | HMAC with an approved hash and a key of at least 128 bits; KMAC; AES-CMAC | HMAC-SHA-256 | Compare tags in constant time |
| CRY-ALG-006 | Key derivation | HKDF (RFC 5869, SP 800-56C); SP 800-108 KDFs | HKDF-SHA-256 | Not for passwords (see section 7.2) |
| CRY-ALG-007 | Key establishment, post-quantum | ML-KEM-768 or ML-KEM-1024 (FIPS 203) | ML-KEM-768 (NIST IR 8547 default) | Use in hybrid mode with a classical scheme during transition (section 6.2) |
| CRY-ALG-008 | Key establishment, classical | ECDH with X25519, P-256 or P-384; RSA-OAEP with at least 3072-bit modulus for new systems | X25519 | Quantum-vulnerable: deprecated after 2030 (section 5) |
| CRY-ALG-009 | Digital signature, post-quantum | ML-DSA-65 or ML-DSA-87 (FIPS 204); SLH-DSA (FIPS 205) for long-lived roots and firmware; LMS or XMSS (SP 800-208) for firmware with state management | ML-DSA-65 | Adopt per the migration plan; check product and HSM support |
| CRY-ALG-010 | Digital signature, classical | ECDSA P-256 or P-384 (FIPS 186-5); Ed25519 (FIPS 186-5); RSA-PSS with at least 3072-bit modulus; RSA PKCS#1 v1.5 for interoperability only | ECDSA P-256 or Ed25519 | Quantum-vulnerable: deprecated after 2030 (section 5) |
| CRY-ALG-011 | Password storage | Argon2id (RFC 9106); scrypt; PBKDF2-HMAC-SHA-256 where FIPS validation is required | Argon2id | Parameters in section 7.2 |
| CRY-ALG-012 | Random bit generation | Operating system CSPRNG or an SP 800-90A DRBG inside a validated module | OS CSPRNG | Section 7.1 |
| [CRY-ALG-NNN] | [Function] | [Algorithm and parameters] | [Default] | [Notes] |
Post-quantum security categories are described in NIST IR 8547 (Table 1). ML-KEM-768 and ML-DSA-65 sit in category 3; ML-KEM-1024 and ML-DSA-87 in category 5. Choose category 5 for data or signatures that must stay protected for decades.
5. Deprecated and prohibited algorithms
| ID | Algorithm or use | Status in this standard | Basis | Organisation deadline |
|---|
| CRY-DEP-001 | MD5, SHA-1 for signatures, certificates or integrity | Prohibited | SP 800-131A Rev. 2; IR 8547 notes SHA-1 is deprecated and disallowed in validated modules after 2030 | Now |
| CRY-DEP-002 | DES, 2-key and 3-key TDEA, RC4, Blowfish | Prohibited for encryption; legacy use for decryption of archives only | SP 800-131A Rev. 2 (3-key TDEA encryption disallowed after 2023) | Now |
| CRY-DEP-003 | AES-ECB for data larger than one block, unauthenticated CBC or CTR | Prohibited for new code | SP 800-131A Rev. 3 draft proposes retiring ECB as a confidentiality mode | Now |
| CRY-DEP-004 | DSA signature generation | Prohibited | FIPS 186-5 (verification only for existing signatures) | Now |
| CRY-DEP-005 | RSA below 2048 bits, ECC below 224 bits, finite field DH below 2048 bits | Prohibited | SP 800-131A Rev. 2 | Now |
| CRY-DEP-006 | Any 112-bit strength algorithm (RSA-2048, P-224, SHA-224 for signatures) | Deprecated; no new use | IR 8547 (112-bit symmetric standards disallowed in 2030); SP 800-131A | [2029-12-31] (Example) |
| CRY-DEP-007 | Quantum-vulnerable key establishment (RSA, finite field and elliptic-curve DH and MQV) | Acceptable now; deprecated after 2030; disallowed after 2035 | NIST IR 8547, Table 4 | Hybrid key establishment for data with a confidentiality need beyond 2035 by [YYYY-MM-DD] |
| CRY-DEP-008 | Quantum-vulnerable signatures (RSA, ECDSA, EdDSA) | Acceptable now; deprecated after 2030; disallowed after 2035 | NIST IR 8547, Table 2 | Per the migration plan (security/pqc-migration-plan) |
| CRY-DEP-009 | SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 | Prohibited | RFC 8996 (March 2021) | Now |
| [CRY-DEP-NNN] | [Item] | [Status] | [Basis] | YYYY-MM-DD |
NIST IR 8547 replaces the earlier SP 800-57 Part 1 plan to disallow 112-bit public-key schemes on 2031-01-01 with the 2030 deprecation and 2035 disallowance shown above. For US federal high value assets and high impact systems, OMB Memorandum M-26-15 (24 June 2026) sets earlier deadlines: post-quantum key establishment by 2030-12-31 and post-quantum signatures by 2031-12-31. Other governments publish their own roadmaps; record the ones that bind you in this table with a link and a date.
6. Protocols
6.1 TLS
| ID | Rule | Level |
|---|
| CRY-TLS-001 | Offer TLS 1.3 (RFC 8446) on every new endpoint, external and internal. | MUST |
| CRY-TLS-002 | Accept TLS 1.2 only where a named client population needs it, with forward-secret ECDHE suites and AEAD ciphers only. | MAY |
| CRY-TLS-003 | Do not offer TLS 1.1 or earlier, SSL, export, NULL, anonymous, RC4, 3DES or CBC-SHA1 suites. | MUST NOT |
| CRY-TLS-004 | Use certificates from the approved CAs and profiles in security/pki-certificate-architecture; validate the full chain and the host name. | MUST |
| CRY-TLS-005 | Send HSTS with at least one year max-age on public web hosts. | SHOULD |
| CRY-TLS-006 | Use mutual TLS for service-to-service traffic that crosses a trust boundary. | SHOULD |
| CRY-TLS-007 | Disable TLS 1.3 0-RTT unless the request is idempotent and replay was assessed. | MUST |
US federal agencies must support TLS 1.3 or a successor no later than 2030-01-02 under Executive Order 14306 and OMB M-26-15. NIST SP 800-52 Rev. 2 (August 2019) is under review as of May 2026; its next revision is expected to cover post-quantum key establishment in TLS (NIST IR 8547, section 4.2).
6.2 Hybrid post-quantum key exchange
Hybrid key exchange combines a classical and a post-quantum shared secret, so the session stays secure if either one holds. RFC 10024 (2026, Proposed Standard) defines the TLS 1.3 groups X25519MLKEM768 (recommended), SecP256r1MLKEM768 and SecP384r1MLKEM1024.
| ID | Rule | Level |
|---|
| CRY-PQ-001 | Enable X25519MLKEM768 on external TLS endpoints and clients as soon as the platform supports it. | SHOULD |
| CRY-PQ-002 | Prioritise hybrid key exchange for traffic carrying data with a confidentiality need beyond [2035]. | MUST |
| CRY-PQ-003 | Do not use the pre-standard Kyber draft groups. | MUST NOT |
| CRY-PQ-004 | Test middleboxes for larger ClientHello messages before enabling hybrid groups broadly. | SHOULD |
6.3 Other protocols
| Protocol | Rule | Notes |
|---|
| SSH | Example: Ed25519 or ECDSA host keys; curve25519 or hybrid post-quantum key exchange; no SSH protocol 1, no DSA keys, no CBC ciphers | Host key inventory in section 11 |
| IPsec and IKEv2 | Example: IKEv2 only; AES-GCM; DH group 19 or 20 or above; post-quantum additional key exchange where supported | Many VPN products lag; track in the migration plan |
| Email | Example: MTA-STS and DANE where supported; S/MIME with approved algorithms | Opportunistic STARTTLS alone does not meet CRY-TLS-001 |
| JOSE and JWT | Example: ES256, EdDSA or PS256; never alg: none; pin the expected algorithm on verification | Tokens are covered in security/secure-coding-standard |
| [Protocol] | [Rule] | [Notes] |
7. Random numbers, passwords and tokens
7.1 Randomness
- CRY-RNG-001: Generate keys, nonces, salts and tokens only from the operating system CSPRNG or a validated DRBG (NIST SP 800-90A). MUST.
- CRY-RNG-002: Session identifiers and reset tokens carry at least 128 bits of entropy. MUST.
- CRY-RNG-003: Virtual machine images and containers do not ship pre-generated keys or seeds. MUST NOT.
7.2 Password hashing
| Algorithm | Minimum parameters (Example: tune to at most [500] ms on production hardware) | Notes |
|---|
| Argon2id | Memory [64] MiB, iterations [3], parallelism [1], 16-byte salt, 32-byte output | Preferred |
| scrypt | N = 2^[17], r = 8, p = 1 | Acceptable |
| PBKDF2-HMAC-SHA-256 | [600,000] iterations | Only where a FIPS 140-3 validated module is required |
Rehash on next login when parameters rise. Store algorithm and parameters with each hash. Never encrypt passwords for storage, and never use a fast hash such as SHA-256 alone.
8. Key management lifecycle
8.1 Lifecycle
| ID | Rule | Level |
|---|
| CRY-KEY-001 | Generate keys inside the HSM, KMS or validated module that will use them; private keys of CAs and code-signing keys never leave an HSM in plaintext. | MUST |
| CRY-KEY-002 | Each key has one purpose (encryption, signing, key wrapping or authentication), recorded in the inventory. | MUST |
| CRY-KEY-003 | Data keys are wrapped by a key-encryption key held in KMS or HSM (envelope encryption). | MUST |
| CRY-KEY-004 | Access to key use and key administration is separate; no one person can both administer and use a production master key. | MUST |
| CRY-KEY-005 | Key operations are logged centrally (see security/security-logging-standard). | MUST |
| CRY-KEY-006 | Rotation is automated and keeps old versions in decrypt-only (legacy use) state until data is re-encrypted or expires. | SHOULD |
| CRY-KEY-007 | On suspected compromise, revoke or disable within [4 hours], rotate dependent keys and open an incident (security/security-incident-report). | MUST |
| CRY-KEY-008 | Key backup and escrow for encryption keys follow dual control; signing keys are not escrowed. | MUST |
| CRY-KEY-009 | Destruction is recorded with date, method and approver. | MUST |
8.2 Cryptoperiods
The values below are organisation choices informed by SP 800-57 Part 1 section 5.3. Shorten them where volume, exposure or the value of the data is high.
| Key type | Originator usage period | Recipient or verification period | Rotation method |
|---|
| Example: KMS key-encryption key | 1 year | Until all wrapped keys are rewrapped | Automatic in KMS |
| Example: Data encryption key (envelope) | Per object or per [30] days | Life of the data | Generated per write |
| Example: TLS server private key | Life of the certificate | Same | Renewed with the certificate |
| Example: Code-signing private key | [2] years | Signatures timestamped; verification until product end of support | HSM ceremony |
| Example: HMAC key for webhooks | [1] year | [7] day overlap | Dual-key validation |
| [Key type] | [Period] | [Period] | [Method] |
9. Cryptographic modules and libraries
9.1 Modules
- CRY-MOD-001: HSMs protecting root CA, code-signing and KMS master keys hold a current FIPS 140-3 validation at [Level 3] or an equivalent certification named here: [scheme]. MUST.
- CRY-MOD-002: Systems in [regulated scope] use modules with a current FIPS 140-3 certificate in their approved mode. MUST.
- CRY-MOD-003: Track module certificates: a historical or revoked certificate triggers a review within [30] days. SHOULD.
9.2 Libraries
| Language or platform | Approved library | Notes |
|---|
| Example: General | Platform TLS terminators and cloud KMS SDKs | First choice |
| Example: C and C++ | OpenSSL 3.x providers, BoringSSL, AWS-LC | OpenSSL 3 providers allow algorithm changes by configuration |
| Example: Java | JCA/JCE with an approved provider | Configure providers centrally |
| Example: Other languages | The standard library or the binding to an approved C library | No pure in-house primitives |
| [Platform] | [Library] | [Notes] |
9.3 Supplier clauses
Contracts and assessments with suppliers that process organisation data ask for: algorithms and protocols in use, conformity with this standard or an equivalent, a roadmap for post-quantum algorithms with dates, key ownership options (provider-managed, customer-managed, customer-held), and notification of cryptographic vulnerabilities.
10. Data protection patterns
| ID | Situation | Approved pattern |
|---|
| CRY-PAT-001 | Data at rest in cloud storage and databases | Platform encryption with KMS keys; customer-managed keys for [Confidential] and above |
| CRY-PAT-002 | Sensitive fields (identity numbers, card data) | Application-level envelope encryption or tokenisation through the platform service |
| CRY-PAT-003 | Laptops and mobiles | Full-disk encryption managed by device management, keys escrowed |
| CRY-PAT-004 | Backups | Encrypted with keys separate from production; restore tested with key access |
| CRY-PAT-005 | Files exchanged with partners | TLS-based transfer; payload encryption with approved algorithms when stored by the partner |
| CRY-PAT-006 | Software releases | Signed artefacts and provenance, see security/supply-chain-security |
| CRY-PAT-007 | Searchable or comparable encrypted data | Keyed hash (HMAC) for equality; any other scheme needs cryptography review |
| [CRY-PAT-NNN] | [Situation] | [Pattern] |
11. Crypto agility and inventory
| ID | Rule | Level |
|---|
| CRY-AGL-001 | Algorithm, key size and parameters come from configuration or a central policy, not from code constants. | MUST for new systems |
| CRY-AGL-002 | Data formats carry an algorithm identifier and key version, so old and new can coexist. | MUST |
| CRY-AGL-003 | Protocols negotiate algorithms and can be restricted to acceptable ones to prevent downgrade. | MUST |
| CRY-AGL-004 | KMS and HSM platforms support post-quantum key types or have a dated vendor roadmap. | SHOULD |
| CRY-AGL-005 | Maintain a cryptographic inventory (a cryptographic bill of materials) fed by automated discovery: certificate scans, TLS scans, code and dependency analysis, KMS and HSM exports. | MUST |
Minimum inventory fields: system, owner, asset type (key, certificate, protocol endpoint, library), algorithm and size, purpose, location, data classification, confidentiality horizon in years, cryptoperiod, expiry, discovery source. CycloneDX 1.6 and later can express this as a CBOM. The inventory feeds compliance/asset-inventory and the migration plan (security/pqc-migration-plan).
12. Compliance checks and metrics
| Check | Rules covered | Method | Frequency | Owner |
|---|
| Example: External TLS scan | CRY-TLS-001 to 007, CRY-PQ-001 | Scanner against all public hosts | Weekly | [@secops] |
| Example: Code scan for weak primitives | CRY-DEP-001 to 005, CRY-RNG-001 | SAST rules in CI, build fails on prohibited calls | Every merge | [@appsec] |
| Example: Dependency check | Section 9.2 | Software composition analysis against the approved library list | Every build | [@appsec] |
| Example: KMS configuration | CRY-KEY-001 to 006 | Cloud posture rules | Daily | [@cloud-security] |
| Example: Inventory completeness | CRY-AGL-005 | Discovered assets with no inventory record | Monthly | [@security-architect] |
| [Check] | [Rules] | [Method] | [Frequency] | [@owner] |
| Metric | Target (Example) |
|---|
| Public endpoints offering TLS 1.3 | 100% |
| Public endpoints offering hybrid post-quantum key exchange | [80]% by [YYYY-MM-DD] |
| Prohibited algorithm findings open past 30 days | 0 |
| Keys with an owner and cryptoperiod in the inventory | 98% |
| Open exceptions past expiry | 0 |
13. Exceptions
A system that cannot meet a MUST rule needs an approved exception before go-live, or within [30] days of the finding for existing systems. Each exception records the rule, the reason, the data affected, compensating controls, the risk owner, the expiry (at most [12] months) and the exit plan. Exceptions for prohibited algorithms need CISO approval.
| ID | Rule | System | Reason | Compensating controls | Approver | Expiry |
|---|
| CRY-EXC-001 (Example) | CRY-TLS-003 | Legacy payment terminal gateway | Terminals support only TLS 1.2 CBC suites | Private network, IP allow-list, terminal replacement funded | [@ciso] | YYYY-MM-DD |
| [CRY-EXC-NNN] | [Rule] | [System] | [Reason] | [Controls] | [@approver] | YYYY-MM-DD |
14. Glossary and references
14.1 Glossary
| Term | Meaning |
|---|
| Security strength | Work needed to break an algorithm, in bits (s bits means about 2^s operations) |
| Acceptable, deprecated, disallowed, legacy use | NIST status words: allowed; allowed with risk accepted by the data owner; not allowed; allowed only to process already protected data |
| Hybrid key exchange | A key exchange combining a classical and a post-quantum scheme so that both must be broken |
| CBOM | Cryptographic bill of materials, an inventory of cryptographic assets |
| Cryptoperiod | The time a key is authorised for use |
| Envelope encryption | Data encrypted with a data key that is itself encrypted by a key-encryption key |
| HSM, KMS | Hardware security module; key management service |
| ML-KEM, ML-DSA, SLH-DSA | NIST post-quantum key encapsulation and signature standards (FIPS 203, 204, 205) |
14.2 References
| Reference | Version or date | Use |
|---|
| NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1, General, https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final | May 2020 | Strength table, lifecycle, cryptoperiods |
| NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths, https://csrc.nist.gov/pubs/sp/800/131/a/r2/final | March 2019 (Rev. 3 initial public draft October 2024) | Transition status words and dates |
| NIST IR 8547, Transition to Post-Quantum Cryptography Standards, https://csrc.nist.gov/pubs/ir/8547/final | Final, October 2026 | 2030 deprecation, 2035 disallowance, post-quantum parameter sets |
| OMB Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography (whitehouse.gov) | 24 June 2026 | US federal deadlines, TLS 1.3 date, agility elements |
| FIPS 203, 204, 205 | August 2024 | ML-KEM, ML-DSA, SLH-DSA |
| FIPS 186-5, FIPS 140-3, SP 800-38D, SP 800-90A, SP 800-208, SP 800-232 | 2023, 2019, 2007, 2015, 2020, 2025 | Signatures, modules, GCM, DRBG, stateful hash signatures, Ascon |
| NIST SP 800-52 Rev. 2, https://csrc.nist.gov/pubs/sp/800/52/r2/final | August 2019, under review since May 2026 | TLS configuration |
| NIST CSWP 39, Considerations for Achieving Cryptographic Agility, https://csrc.nist.gov/pubs/cswp/39/considerations-for-achieving-cryptographic-agility/final | December 2025, updated June 2026 | Agility strategies |
| RFC 8446 (TLS 1.3), RFC 8996 (deprecating TLS 1.0 and 1.1), RFC 10024 (hybrid ML-KEM key agreement for TLS 1.3) | 2018, 2021, 2026 | Protocol rules |
| RFC 9106 (Argon2), RFC 8439 (ChaCha20-Poly1305), RFC 5869 (HKDF) | 2021, 2018, 2010 | Primitives |
Standard and licence note
Based on NIST SP 800-57 Part 1 Rev. 5, NIST SP 800-131A Rev. 2, NIST IR 8547 (final, October 2026), the FIPS and SP publications listed in section 14.2, and OMB Memorandum M-26-15, which are works of the US Government, and on the IETF RFCs listed. The rule wording, tables and examples are original text written for this collection; no publication text is reproduced. Algorithm status and deadlines change: check the current NIST publications at https://csrc.nist.gov and the laws and government roadmaps that bind your organisation before relying on a date. This is a documentation format, not legal advice. Template licence: MIT.