# Key length

Minimum key sizes, post-quantum migration deadlines and cryptographic control requirements, each traced to its source document. Reviewed 2026-09-21.

## Classical security-strength equivalence

Source: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05, Table 2. Security strength is also the equivalent ideal symmetric-key size.

| Security bits | RSA modulus | Finite-field modulus / subgroup | Elliptic-curve key | Collision-resistant hash |
|---|---|---|---|---|
| 80 (legacy) | 1024 | 1024 / 160 | 160-223 | 160 |
| 112 | 2048 | 2048 / 224 | 224-255 | 224 |
| 128 | 3072 | 3072 / 256 | 256-383 | 256 |
| 192 | 7680 | 7680 / 384 | 384-511 | 384 |
| 256 | 15360 | 15360 / 512 | 512+ | 512 |

## Suggested cryptoperiods

Source: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05, Table 1. These are starting points; the application and operating environment may justify shorter or longer periods.

### Signing

- **Private signature key:** 1–3 years
- **Public signature-verification key:** Several years; depends on key size

### Authentication

- **Symmetric authentication key:** Originator use <2 years; recipient use <originator period + 3 years
- **Private authentication key:** 1–2 years
- **Public authentication key:** 1–2 years

### Encryption, wrapping and derivation

- **Symmetric data-encryption key:** Originator use <2 years; recipient use <originator period + 3 years
- **Symmetric key-wrapping key:** Originator use <2 years; recipient use <originator period + 3 years
- **Symmetric random-bit-generator key:** See NIST SP 800-90
- **Symmetric master or key-derivation key:** About 1 year
- **Private key-transport key:** <2 years
- **Public key-transport key:** 1–2 years

### Key agreement

- **Symmetric key-agreement key:** 1–2 years
- **Private static key-agreement key:** 1–2 years
- **Public static key-agreement key:** 1–2 years
- **Private ephemeral key-agreement key:** One key-agreement transaction
- **Public ephemeral key-agreement key:** One key-agreement transaction

### Authorization

- **Symmetric authorization key:** <2 years
- **Private authorization key:** <2 years
- **Public authorization key:** <2 years

## Minimum key sizes by source

All sizes are in bits and are minimums.

### NIST

Source: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05.

| Window | Symmetric | Factoring modulus | Discrete log | Elliptic curve | Hash |
|---|---|---|---|---|---|
| 2019 to 2030 | 112 | 2048 | 2048 / 224 | 224 | 224 |
| 2031 to open | 128 | 3072 | 3072 / 256 | 256 | 256 |

Classical public-key algorithms: Disallowed after 2035 under draft IR 8547.

Post-quantum key establishment: ML-KEM (FIPS 203). Post-quantum signatures: ML-DSA, SLH-DSA.

### BSI

Source: [BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, version 2026-01](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html), BSI, 2026-01-23.

| Window | Symmetric | Factoring modulus | Discrete log | Elliptic curve | Hash |
|---|---|---|---|---|---|
| 2026 to 2032 | 128 | 3000 | 3000 / 250 | 250 | 256 |

Classical public-key algorithms: Classical key agreement alone is recommended only until the end of 2031; classical signatures until the end of 2035.

Post-quantum key establishment: Hybrid with a classical scheme: ML-KEM-768 or -1024, FrodoKEM-976 or -1344, or Classic McEliece. Post-quantum signatures: ML-DSA-65 or -87, SLH-DSA (192 or 256), LMS or XMSS; classical signatures until end of 2035.

### ANSSI

Source: [ANSSI-PG-083, Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques, v3.00](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-mecanismes-crypto-3.00.pdf), ANSSI, 2026-03-20.

| Window | Symmetric | Factoring modulus | Discrete log | Elliptic curve | Hash |
|---|---|---|---|---|---|
| 2026 to 2030 | 128 | 2048 | 2048 / 250 | 250 | 256 |
| 2031 to open | 128 | 3072 | 3072 / 250 | 250 | 256 |

Post-quantum key establishment: Hybrid with a classical scheme: ML-KEM-768 preferred (512 allowed), FrodoKEM-976 preferred; post-quantum recommended for use beyond 2030. Post-quantum signatures: ML-DSA hybrid with a classical signature; SLH-DSA may be used alone.

### NSA CNSA 2.0

Source: [NSA CNSA 2.0 algorithms advisory](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF), NSA, 2025-05-30.

| Window | Symmetric | Factoring modulus | Discrete log | Elliptic curve | Hash |
|---|---|---|---|---|---|
| 2025 to open | 256 | Transition only | Transition only | Transition only | 384 |

Post-quantum key establishment: ML-KEM-1024. Post-quantum signatures: ML-DSA-87; LMS or XMSS for firmware.

### ASD

Source: [ASD, Planning for post-quantum cryptography](https://www.cyber.gov.au/business-government/secure-design/quantum/planning-for-post-quantum-cryptography), ASD, 2025-09-22.

Classical key sizes are not yet imported.

Classical public-key algorithms: RSA, DH, ECDH and ECDSA not approved after 2030.

Post-quantum key establishment: ASD-approved PQC (ISM). Post-quantum signatures: ASD-approved PQC (ISM).

## Post-quantum migration deadlines

Status follows the Hong Kong Monetary Authority's classification into mandatory, guidance and stated target.

### US federal civilian

Status: Mandatory. Sector: Government. Source: [Executive Order 14412](https://www.federalregister.gov/documents/2026/06/25/2026-12909/securing-the-nation-against-advanced-cryptographic-attacks), The White House, 2026-06-22, secondary reporting.

- late October 2026: Agency migration plans to OMB (Plan, inventory or report)
- 31 Dec 2030: PQC key establishment for high value assets (Priority systems migrated)
- 31 Dec 2031: PQC signatures for high value assets (Priority systems migrated)
- 2035: Remaining systems (Migration complete)

### US federal contractors

Status: Mandatory. Sector: Government. Source: [Executive Order 14412](https://www.federalregister.gov/documents/2026/06/25/2026-12909/securing-the-nation-against-advanced-cryptographic-attacks), The White House, 2026-06-22, secondary reporting.

- 31 Dec 2030: FIPS compliance including PQC, via a FAR rule not yet final (Procurement requirement)

### US defense (DoW)

Status: Mandatory. Sector: Defence. Source: [Department of War PQC Strategy](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), DoW, 2026-06-23, secondary reporting.

- end of 2030: Every system supports PQC or is phased out (Priority systems migrated)
- end of 2031: Every system uses PQC (Migration complete)

### US national security systems

Status: Mandatory. Sector: Defence. Source: [NSA CNSA 2.0 algorithms advisory](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF), NSA, 2025-05-30.

- 1 Jan 2027: New acquisitions must support CNSA 2.0 (Procurement requirement)
- 2030: Networking gear and firmware signing exclusive (Priority systems migrated)
- 2033: Most categories exclusive (Priority systems migrated)
- 2035: All NSS quantum-resistant (Migration complete)

### NIST algorithm lifecycle

Status: Guidance. Sector: Government. Source: [NIST IR 8547 initial public draft](https://csrc.nist.gov/pubs/ir/8547/ipd), NIST, 2024-11-12, draft.

- after 2030: 112-bit quantum-vulnerable algorithms deprecated (Deprecated)
- after 2035: Quantum-vulnerable algorithms disallowed (Disallowed or ceased)

### European Union

Status: Guidance. Sector: Government. Source: [NIS Cooperation Group coordinated implementation roadmap](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), European Commission and member states, 2025-06-23, secondary reporting.

- end of 2026: National roadmaps and first steps (Plan, inventory or report)
- end of 2030: High-risk use cases migrated (Priority systems migrated)
- end of 2035: Migration complete as far as feasible (Migration complete)

### Germany, France and partners

Status: Guidance. Sector: Government. Source: [Securing Tomorrow, Today (joint statement)](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), BSI, ANSSI and partner agencies, 2024-11, secondary reporting.

- end of 2030: Latest date for prioritized transitions (Priority systems migrated)

### Germany (BSI)

Status: Guidance. Sector: Government. Source: [BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, version 2026-01](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html), BSI, 2026-01-23.

- end of 2030: Applications with very high protection requirements move to quantum-safe key agreement (Priority systems migrated)
- end of 2031: Classical key agreement alone no longer recommended; hybrid with a post-quantum KEM only (Disallowed or ceased)
- end of 2035: Classical signatures no longer recommended (Disallowed or ceased)

### Switzerland (FINMA, finance)

Status: Guidance. Sector: Finance. Source: [FINMA Guidance 05/2026, as reported](https://postquantum.com/security-pqc/mas-quantum-resilience-supervisory-expectations/), FINMA (Switzerland), 2026-07, secondary reporting.

- mid-2027: Supervised institutions have PQC roadmaps (Plan, inventory or report)

### United Kingdom

Status: Guidance. Sector: Government. Source: [Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines), NCSC (UK), 2025-03-20.

- by 2028: Discovery, assessment and initial migration plan (Plan, inventory or report)
- 2028 to 2031: Highest-priority migration activities (Priority systems migrated)
- 2031 to 2035: Migration complete for all systems, services and products (Migration complete)

### Canada (federal)

Status: Mandatory. Sector: Government. Source: [ITSM.40.001](https://cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-canada-itsm40001), Canadian Centre for Cyber Security, 2025-06-23.

- April 2026: Departmental migration plans, then annual reports (Plan, inventory or report)
- end of 2031: High-priority systems migrated (Priority systems migrated)
- end of 2035: Remaining systems migrated (Migration complete)

### Australia

Status: Guidance. Sector: Government. Source: [ASD, Planning for post-quantum cryptography](https://www.cyber.gov.au/business-government/secure-design/quantum/planning-for-post-quantum-cryptography), ASD, 2025-09-22.

- end of 2026: Refined transition plan (Plan, inventory or report)
- end of 2028: Begin with the most critical systems (Priority systems migrated)
- end of 2030: Traditional asymmetric cryptography ceased (Disallowed or ceased)

### Japan (government)

Status: Stated target. Sector: Government. Source: [Interim report on the government PQC transition](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), National Cyber Command Office (Japan), 2025-11, secondary reporting.

- 2027: National migration roadmap expected (Plan, inventory or report)
- 2035: Government agencies complete transition (Migration complete)

### South Korea

Status: Stated target. Sector: Government. Source: [PQC Transition Master Plan](http://www.boannews.com/media/view.asp?idx=120080), NIS and MSIT (Korea), 2023-07, secondary reporting.

- 2026: Public-sector rollout of KpqC algorithms begins (Procurement requirement)
- 2035: National transition (Migration complete)

### India

Status: Stated target. Sector: Government. Source: [Implementation of Quantum Safe Ecosystem in India (task force report)](https://dst.gov.in/sites/default/files/Report_TaskForce_PQMigration_4Feb26%20%28v1%29.pdf), DST India, National Quantum Mission, 2026-02-04, secondary reporting.

- 2027: Critical information infrastructure completes inventory, governance and pilots (Plan, inventory or report)
- 2028: CII begins full migration; other enterprises complete foundations (Plan, inventory or report)
- 2030: High-priority CII systems migrated (Priority systems migrated)
- 2033: PQC the default across communication systems (Migration complete)

### Singapore (MAS, finance)

Status: Guidance. Sector: Finance. Source: [MAS supervisory expectations on quantum resilience, as reported](https://postquantum.com/security-pqc/mas-quantum-resilience-supervisory-expectations/), Monetary Authority of Singapore, 2026-08, secondary reporting.

- end of the decade: Financial institutions quantum-resilient (Priority systems migrated)

### Hong Kong (HKMA, banks)

Status: Stated target. Sector: Finance. Source: [HKMA Quantum Preparedness Index, first results](https://postquantum.com/security-pqc/hkma-banks-quantum-readiness-2-3/), Hong Kong Monetary Authority, 2026-07, secondary reporting.

- 2030: Banks reach full marks on the Quantum Preparedness Index (2.3 of 10 in 2026) (Priority systems migrated)

### Israel (Bank of Israel)

Status: Mandatory. Sector: Finance. Source: [Bank of Israel quantum preparedness requirement, as reported](https://www.mdpi.com/2674-1032/5/1/16), Bank of Israel, 2025, secondary reporting.

- early 2026: Banks and payment providers submit quantum preparedness plans (Plan, inventory or report)

### United Arab Emirates

Status: Mandatory. Sector: Government. Source: [National Encryption Policy and Post-Quantum Migration Program, as reported](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), UAE Cyber Security Council, 2025, secondary reporting.

- 2026: Compliance-critical government entities formalize migration plans (Plan, inventory or report)

### China (NGCC standardisation)

Status: No date set. Sector: Government. Source: [NGCC round 1 candidates, public-key and hash tracks](https://www.niccs.org.cn/niccs/Proposal/pc/list.html), Institute of Commercial Cryptography Standards, China, 2026-09.

Own algorithm programme, round 1 candidates published Sept 2026; no migration deadline.

- 30 June 2026: NGCC submission deadline for public-key algorithms (Plan, inventory or report)
- September 2026: Round 1 candidates published, 84 public-key and 35 hash algorithms (Plan, inventory or report)

### New Zealand

Status: No date set. Sector: Government. Source: [NZISM position on PQC, as reported](https://cybermillennial.com/cybersecurity-insights/post-quantum-cryptography-how-global-guidance-is-taking-shape/), GCSB (New Zealand), 2025, secondary reporting.

No migration deadline set; follows NIST publication.

### G7 financial sector

Status: Stated target. Sector: Finance. Source: [G7 CEG statement on a PQC roadmap for the financial sector](https://www.gov.uk/government/publications/advancing-a-coordinated-roadmap-for-the-transition-to-post-quantum-cryptography-in-the-financial-sector/g7-cyber-expert-group-statement-on-advancing-a-coordinated-roadmap-for-the-transition-to-post-quantum-cryptography-in-the-financial-sector-january-20), G7 Cyber Expert Group, 2026-01-13, secondary reporting.

- 2030 to 2032: Critical systems may transition (Priority systems migrated)
- 2035: Sector-wide migration target (Migration complete)

## Cryptographic requirements by framework

### Approved algorithms and strengths

- **PCI DSS v4.0.1** (Explicit requirement, Strong cryptography definition, glossary): PCI defines strong cryptography as industry-tested algorithms with a minimum of 112 bits of effective key strength, with proper key management. In practice that means 2048-bit RSA or P-256 and above.
- **NIS2 and EU 2024/2690** (Explicit requirement, Regulation (EU) 2024/2690, Annex, point 9): The implementing regulation requires a cryptographic policy that specifies which protocols, families of protocols and algorithms are approved, set against asset classification and risk. It names no specific algorithm.
- **DORA RTS** (Explicit requirement, RTS Article 6(3)): The policy must include criteria for selecting cryptographic techniques and use practices, taking into account leading practices and standards and the classification of the ICT assets concerned. Entities that cannot meet those practices must adopt mitigation and monitoring measures.
- **CA/B Forum TLS BRs** (Explicit requirement, S/MIME BR ballot, via the Baseline Requirements page): A ballot raises the minimum RSA key size for root and subordinate CA certificates in the S/MIME requirements from 2048 to 4096 bits for keys created after 15 September 2026, keeping 2048 bits for subscriber certificates. From 15 September 2027 CAs may not issue subscriber certificates from any sub-CA whose RSA modulus is below 3072 bits.
- **US federal (NIST, FISMA)** (Explicit requirement, EO 14412): Federal systems use NIST-approved, FIPS-validated cryptography. EO 14412 directs agencies to the post-quantum FIPS on a fixed schedule and requires NIST to revise the module validation process to accelerate validations.
- **FedRAMP** (Explicit requirement, SC-13; FedRAMP cryptographic module policy v1.1.0): FedRAMP inherits NIST SP 800-53 control SC-13, which requires cryptography from a FIPS 140-validated module or an NSA-approved one. Using an approved algorithm is not enough; the module itself must hold a CMVP certificate. The FedRAMP cryptographic module policy v1.1.0, approved in January 2025, is the operative document and adds two ways to handle security fixes in validated modules.
- **CMMC and NIST SP 800-171** (Explicit requirement, NIST SP 800-171 Rev 2, 3.13.11): Requirement 3.13.11 requires FIPS-validated cryptography wherever cryptography protects the confidentiality of controlled unclassified information. A NIST-recommended algorithm such as AES is not sufficient unless the implementation itself has been validated.
- **ISO/IEC 27001** (Explicit requirement, Annex A 8.24): Annex A 8.24 requires that rules for the effective use of cryptography, including key management, be defined and implemented. It does not name algorithms or key sizes. The organization chooses them, which is where the figures on the key length page come in.

### Protocol versions

- **PCI DSS v4.0.1** (Explicit requirement, Requirement 4.2.1): Account data crossing open, public networks must be protected with strong cryptography and secure protocols, accepting only trusted keys and certificates and confirming certificates are neither expired nor revoked. In practice TLS 1.2 or 1.3, with TLS 1.0 and 1.1 disabled.
- **NIS2 and EU 2024/2690** (Explicit requirement, Regulation (EU) 2024/2690, Annex, point 9): The cryptographic policy must state which protocols are approved, with TLS 1.3 given as the example for communications, and crypto agility is recommended so newer standards can be adopted quickly.
- **DORA RTS** (Explicit requirement, RTS Article 6(2)): The policy must cover encryption of data at rest and in transit, of data in use where necessary, and of internal network connections and traffic with external parties. Where data in use cannot be encrypted, it must be processed in a separated and protected environment or equivalent measures taken.
- **CA/B Forum TLS BRs** (Not covered): The Baseline Requirements govern certificate issuance, not the TLS versions a server negotiates.
- **US federal (NIST, FISMA)** (Explicit requirement, EO 14144 as reported): Federal policy requires TLS 1.3 or its successor across federal systems by the start of 2030, alongside the PQC transition.
- **FedRAMP** (Implied or indirect, SC-8, SC-13): Protection in transit falls under SC-8, and the cryptography used for it must come from validated modules under SC-13.
- **CMMC and NIST SP 800-171** (Explicit requirement, NIST SP 800-171 Rev 2, 3.13.8 and 3.13.16): Cryptographic mechanisms must prevent unauthorized disclosure of CUI during transmission, and CUI must be protected at rest, in both cases with FIPS-validated cryptography.
- **ISO/IEC 27001** (Implied or indirect, Annex A 8.24): Protocol choices fall under the cryptography rules the organization defines, applied to data in transit, at rest and in use according to its classification.

### Cryptographic inventory

- **PCI DSS v4.0.1** (Explicit requirement, Requirements 4.2.1.1 and 12.3.3): Requirement 4.2.1.1 requires an inventory of the trusted keys and certificates used to protect card data in transit. Requirement 12.3.3 requires an up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used, documented and reviewed at least every 12 months. Both became mandatory on 31 March 2025.
- **NIS2 and EU 2024/2690** (Implied or indirect, Regulation (EU) 2024/2690, Annex): The implementing regulation has no separate cryptographic inventory requirement, but a policy that names approved algorithms against classified assets cannot be evidenced without one.
- **DORA RTS** (Implied or indirect, RTS Articles 4 to 6): Cryptographic controls are tied to an approved data classification and ICT risk assessment, and ICT asset management is covered separately in Articles 4 and 5.
- **CA/B Forum TLS BRs** (Not covered): Subscriber inventories are not a Baseline Requirements matter, though shorter lifetimes make them necessary in practice.
- **US federal (NIST, FISMA)** (Explicit requirement, OMB M-23-02 and EO 14412): Federal agencies maintain inventories of cryptographic systems vulnerable to quantum attack, and EO 14412 adds minimum elements for a cryptographic bill of materials to be published by CISA and NIST.
- **FedRAMP** (Implied or indirect, System Security Plan): The System Security Plan has to identify the cryptographic modules in use and their CMVP certificates, which in practice requires an inventory of where cryptography is used.
- **CMMC and NIST SP 800-171** (Implied or indirect, System Security Plan): Assessors expect the System Security Plan to name the cryptographic products protecting CUI and their CMVP certificate numbers. A general statement that AES is used does not meet the requirement.
- **ISO/IEC 27001** (Implied or indirect, Annex A 8.24): Rules for where cryptography is required can't be shown to be applied without knowing where it is used.

### Monitoring and ability to change algorithms

- **PCI DSS v4.0.1** (Explicit requirement, Requirement 12.3.3): Requirement 12.3.3 requires active monitoring of industry trends regarding the continued viability of the cipher suites and protocols in use, and documentation of a plan to respond to anticipated changes in cryptographic vulnerabilities. This is the clause that already reaches post-quantum work.
- **NIS2 and EU 2024/2690** (Explicit requirement, Regulation (EU) 2024/2690, Annex, point 9; NIS2 Article 21(1)): The regulation expects a cryptographic policy based on state-of-the-art practice with mechanisms for replacing algorithms quickly, and NIS2 itself requires measures that take the state of the art into account.
- **DORA RTS** (Explicit requirement, RTS Article 6(4) and (5), Recital 9): The policy must include provisions for updating or changing cryptographic technology on the basis of developments in cryptanalysis, so that it remains resilient. Entities unable to update must adopt mitigation and monitoring measures and record a reasoned explanation. Recital 9 names quantum advancements among those developments.
- **CA/B Forum TLS BRs** (Implied or indirect, Ballot SC-081v3 rationale): Reducing certificate validity is how the web PKI keeps the ability to change algorithms and correct mistakes quickly.
- **US federal (NIST, FISMA)** (Explicit requirement, EO 14412): EO 14412 sets post-quantum key establishment for high value assets by the end of 2030 and signatures by the end of 2031, with contractors following through a FAR rule.
- **FedRAMP** (Explicit requirement, FedRAMP guidance on the FIPS 140-2 sunset): All FIPS 140-2 certificates moved to historical status on 21 September 2026. FedRAMP's guidance for providers whose FIPS 140-3 module is still in the validation backlog is to move to it early and track that as a risk, or keep the historical module and track that as a risk instead.
- **CMMC and NIST SP 800-171** (Implied or indirect, 32 CFR 170.4(b)): When validated cryptography is temporarily unavailable, for example during a module transition, CMMC allows it to be recorded as a temporary deficiency in a plan of action rather than treated as a failure.
- **ISO/IEC 27001** (Implied or indirect, Annex A 8.24): The rules are expected to be reviewed as algorithms weaken and requirements change, but the standard sets no mechanism or schedule for replacing algorithms.

### Key management

- **PCI DSS v4.0.1** (Explicit requirement, Requirements 3.6 and 3.7): PCI has long required protection of the cryptographic keys used to protect stored account data, covering generation, distribution, storage, rotation and retirement.
- **NIS2 and EU 2024/2690** (Explicit requirement, Regulation (EU) 2024/2690, Annex, point 9): The policy must set procedures across the key lifecycle, including setting expiration dates to limit key lifespan.
- **DORA RTS** (Explicit requirement, RTS Articles 6(2)(d) and 7): The encryption policy must address cryptographic key management with rules on the correct use, protection and lifecycle of keys, which Article 7 then sets out in full.
- **CA/B Forum TLS BRs** (Explicit requirement, Baseline Requirements): CA key generation, protection and compromise handling are governed by the Baseline Requirements and the network and certificate system security requirements.
- **US federal (NIST, FISMA)** (Explicit requirement, SP 800-57 Part 1): Federal key management follows SP 800-57, with validated modules for key storage.
- **FedRAMP** (Explicit requirement, SC-12): SC-12 requires cryptographic keys to be established and managed according to defined requirements, with the moderate and high baselines adding availability of keys and approved key management technology.
- **CMMC and NIST SP 800-171** (Explicit requirement, NIST SP 800-171 Rev 2, 3.13.10): Requirement 3.13.10 requires organizations to establish and manage cryptographic keys for the cryptography used in their systems.
- **ISO/IEC 27001** (Explicit requirement, Annex A 8.24; ISO/IEC 27002 8.24): Annex A 8.24 covers key management explicitly, and the ISO/IEC 27002 guidance expands it to generation, storage, distribution, rotation, revocation, recovery and destruction.

### Certificate lifetime and validation

- **PCI DSS v4.0.1** (Implied or indirect, Requirement 4.2.1): PCI requires confirmation that certificates protecting card data in transit are valid, but sets no maximum lifetime.
- **NIS2 and EU 2024/2690** (Implied or indirect, Regulation (EU) 2024/2690, Annex, point 9): Expiry dates are required to limit key lifespan, without a fixed certificate validity period.
- **DORA RTS** (Implied or indirect, RTS Article 7): Certificate validity falls under the key lifecycle rules rather than a stated maximum.
- **CA/B Forum TLS BRs** (Explicit requirement, Ballot SC-081v3): Ballot SC-081v3 phases maximum public TLS certificate validity from 398 days down to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Domain validation reuse falls from 398 days to 10 days over the same schedule. Private PKI is out of scope.
- **US federal (NIST, FISMA)** (Not covered): Federal systems follow agency policy and the root programs for public certificates.
- **FedRAMP** (Implied or indirect, SC-17): Public key infrastructure certificates are issued under an appropriate certificate policy or obtained from an approved provider, without a general maximum lifetime.
- **CMMC and NIST SP 800-171** (Not covered): NIST SP 800-171 Rev 2 sets no requirement on certificate lifetimes.
- **ISO/IEC 27001** (Implied or indirect, Annex A 8.24): Certificate validity is handled under the key lifecycle rules rather than a stated maximum.

### Governance and review

- **PCI DSS v4.0.1** (Explicit requirement, Requirement 12.3.3): Cipher suites and protocols in use must be documented and reviewed at least once every 12 months, which makes the inventory a standing obligation rather than an assessment artefact.
- **NIS2 and EU 2024/2690** (Explicit requirement, NIS2 Article 21(2)(h)): NIS2 requires policies and procedures on the use of cryptography and, where appropriate, encryption, with management bodies accountable for the risk measures.
- **DORA RTS** (Explicit requirement, RTS Article 6(1) and (5)): The encryption and cryptographic controls policy must be developed, documented and implemented as part of the ICT security framework, and every exception recorded with a reasoned explanation.
- **CA/B Forum TLS BRs** (Explicit requirement, Baseline Requirements): Publicly trusted CAs are audited annually against the Baseline Requirements and root program policies.
- **US federal (NIST, FISMA)** (Explicit requirement, OMB M-26-15): Agencies must name a migration lead and report progress against the federal plan.
- **FedRAMP** (Explicit requirement, Continuous monitoring): Cryptographic weaknesses are tracked through the plan of action and milestones and reported through continuous monitoring, which is how the FIPS 140-2 transition is being handled in practice.
- **CMMC and NIST SP 800-171** (Explicit requirement, DoW CIO memorandum, 13 July 2026): CMMC Phase 1 self-assessments against NIST SP 800-171 remain mandatory. On 13 July 2026 the Department of War suspended Phase 2, which would have required third-party certification from 10 November 2026, froze later phases and began a 60-day review. The DFARS safeguarding obligations and False Claims Act exposure are unchanged.
- **ISO/IEC 27001** (Explicit requirement, Annex A 8.24, Annex A 5.1): The rules must be documented as a topic-specific policy with defined roles and responsibilities, and are examined in certification and surveillance audits.

### Post-quantum obligation

- **PCI DSS v4.0.1** (Implied or indirect, Requirement 12.3.3): PCI names no post-quantum requirement. The monitoring and response-plan parts of 12.3.3 are where quantum-vulnerable algorithms land, since they are the clearest anticipated change in cryptographic viability.
- **NIS2 and EU 2024/2690** (Implied or indirect, NIS2 Article 21(1); ENISA guidance): NIS2 does not name quantum. Its state-of-the-art test plus ENISA guidance following the 2024 FIPS publications point covered entities toward quantum-resistant algorithms for data exposed to harvest-now-decrypt-later collection.
- **DORA RTS** (Explicit requirement, RTS Article 6(4), Recital 9): The cryptanalysis-driven update requirement is the operative clause, and Recital 9 names threats from quantum advancements among the developments entities must stay abreast of.
- **CA/B Forum TLS BRs** (Not covered): There is no post-quantum certificate profile in the Baseline Requirements, and Chrome's stated path is Merkle Tree Certificates rather than post-quantum X.509.
- **US federal (NIST, FISMA)** (Explicit requirement, EO 14412): Key establishment for high value assets by the end of 2030 and signatures by the end of 2031, with contractors required to meet the post-quantum FIPS by the end of 2030.
- **FedRAMP** (Implied or indirect, SC-13; EO 14412): FedRAMP names no post-quantum requirement of its own. Federal customers bring the EO 14412 dates with them, and post-quantum algorithms become usable under SC-13 as validated modules implementing them receive CMVP certificates.
- **CMMC and NIST SP 800-171** (Implied or indirect, DoW PQC strategy): The Department of War's June 2026 post-quantum strategy commits to extending its requirements across the defence industrial base, including through CMMC, although the mechanism is not yet published.
- **ISO/IEC 27001** (Not covered): The standard does not mention quantum computing. Post-quantum work reaches ISO programmes through the organization's own risk assessment and the legal requirements it must consider.

## Questions and background

### The basics

#### Why does key length matter at all?

Every cryptographic key can in principle be recovered by an attacker with enough computing time. Key length sets how much time that is. For a well-designed algorithm, each extra bit of security doubles the work an attacker has to do, so the difference between 112-bit and 128-bit security is a factor of about 65,000 in attack cost.

The difficulty is that attack cost keeps falling. Computers get faster and cheaper, and researchers find better attacks on the underlying mathematics. A key that was comfortably out of reach when it was generated can drift within reach while the data it protects still matters. Choosing a key length is choosing how far ahead of that curve you want to stay.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05.

#### What does “acceptable through 2030” actually mean?

It is a statement about probability under stated assumptions, not a guarantee. When an authority says a key size is acceptable through a given year, it means that under its current assumptions about attacker computing power, the growth of that power and progress in cryptanalysis, the expected cost of breaking the key stays above an acceptable threshold until then.

If the assumptions change, the date changes. That is why the figures are revised, why different authorities publish different numbers, and why this site records the edition and date of every figure it shows.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05; [BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, version 2026-01](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html), BSI, 2026-01-23.

#### What is a cryptoperiod?

A cryptoperiod is the span of time during which a specific key is authorized for use. NIST divides it into the originator-usage period, during which a key may be used to encrypt or sign, and the recipient-usage period, during which data protected with it may still be decrypted or verified. The second is usually longer, because data encrypted on the last day of use still has to be readable afterwards.

A cryptoperiod limits the damage if the assumptions behind a key turn out to be wrong. It caps how much data a single compromised key exposes, how long an attacker has to work on a key while it is still in use, and how long the key sits in systems and backups where it can leak for reasons that have nothing to do with mathematics.

The right cryptoperiod depends on the setting as much as the algorithm. Sensitive or high-volume data, keys held in software rather than hardware, and keys handled by many people or systems all argue for shorter periods. Shorter periods only help if the organization can actually rotate keys that often without outages, which is why automation matters.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05.

#### Which year should I enter on the key length page?

Enter the last year the data must stay secure, not the year the key stops being used. For confidentiality, that is the end of the recipient-usage period plus the time the data must remain secret. A key used for one year to encrypt records that must stay confidential for twenty years needs to be sized for twenty-one years.

For signatures, it is the last year anyone needs to rely on the signature being genuine. Signatures can often be renewed by re-signing or timestamping while the old algorithm is still trusted, so the horizon is usually shorter than for encryption.

#### Why do different authorities give different numbers?

They start from different assumptions and different missions. NIST sets minimums for US federal systems and moves in fixed steps of security strength. BSI and ANSSI build in more margin and set their own horizons. NSA's CNSA 2.0 protects national security systems and asks for the largest parameter sets.

None of them is wrong. The practical question is which of them applies to you, which is why the key length page puts your chosen rules first and shows the strictest figure among them.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05; [BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, version 2026-01](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html), BSI, 2026-01-23; [ANSSI-PG-083, Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques, v3.00](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-mecanismes-crypto-3.00.pdf), ANSSI, 2026-03-20; [NSA CNSA 2.0 algorithms advisory](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF), NSA, 2025-05-30.

### Concepts

#### What does “bits of security” mean?

Security strength is a way of comparing very different algorithms on one scale. An algorithm offers n bits of security when the best known attack takes about 2 to the power n operations, the same as trying every key of an ideal n-bit cipher.

This is why a 128-bit AES key, a 3072-bit RSA key and a 256-bit elliptic-curve key are treated as roughly equivalent. They have very different sizes, but NIST rates all three at about 128 bits of security because the best attacks against each take about the same effort.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05.

#### What is the difference between symmetric and public-key cryptography?

Symmetric cryptography, such as AES, uses the same secret key to encrypt and decrypt. It is fast and its key size maps directly onto its security, so a 128-bit key gives about 128 bits of security. The limitation is that both sides need the key before they can talk.

Public-key cryptography, such as RSA and elliptic curves, uses a key pair. The public half can be shared openly and the private half stays secret. It solves the problem of agreeing on keys with someone you have never met, and it makes digital signatures possible. Its keys are much larger for the same security because it rests on mathematical problems that have faster attacks than trying every key. Almost every secure connection uses public-key cryptography to agree on a symmetric key and then symmetric cryptography for the data itself.

#### What is the factoring modulus?

RSA's security rests on factoring. The public key contains a large number, the modulus, made by multiplying two secret prime numbers together. Multiplying them is easy, but recovering the two primes from the product is extremely hard for large numbers, and anyone who can do it can derive the private key.

The modulus size, 2048 or 3072 bits, is what the key length tables mean by RSA key size. Factoring algorithms improve steadily, which is why RSA keys have to be much larger than symmetric keys for the same security. A 2048-bit modulus gives about 112 bits of security and a 3072-bit modulus about 128.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05.

#### What are the two numbers for discrete logarithm keys?

Classic Diffie-Hellman and DSA work in a group of numbers modulo a large prime, and their security rests on the discrete logarithm problem, which is recovering an exponent from the result of repeated multiplication. Two sizes matter. The first is the size of the prime that defines the group, written first in the tables. The second is the size of the subgroup the computations actually use.

Each size defends against a different kind of attack. The best attacks on the whole group scale like factoring, so the group prime needs to be about as large as an RSA modulus. Generic attacks on the subgroup take roughly the square root of its size, so the subgroup needs about twice as many bits as the security target. That is why the tables show pairs such as 3072 and 256.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05; [ANSSI-PG-083, Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques, v3.00](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-mecanismes-crypto-3.00.pdf), ANSSI, 2026-03-20.

#### Why are elliptic-curve keys so much shorter than RSA keys?

Elliptic-curve cryptography uses the discrete logarithm problem on the points of a curve instead of on numbers modulo a prime. No attack is known that exploits the structure of well-chosen curves the way factoring algorithms exploit RSA, so the best classical attacks are generic and take about the square root of the group size.

That means a curve needs about twice as many bits as the security target, so a 256-bit curve gives about 128 bits of security, compared with 3072 bits for RSA. The smaller keys and signatures are why elliptic curves took over most of the web. They are just as vulnerable to a quantum computer as RSA, however, because Shor's algorithm solves the elliptic-curve discrete logarithm too.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05.

#### Why do hash functions need twice the output size?

A hash function turns any input into a fixed-size fingerprint. The most demanding property is collision resistance, meaning nobody can find two different inputs with the same fingerprint. Because of the birthday effect, finding some collision takes only about the square root of the number of possible outputs, so a 256-bit hash gives about 128 bits of collision resistance.

Finding an input that matches a particular given fingerprint is much harder and takes about the full output size. Signatures and certificates depend on collision resistance, which is why the tables pair a 256-bit hash with 128-bit security.

Sources: [BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, version 2026-01](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html), BSI, 2026-01-23.

#### What is a KEM, and how is it different from Diffie-Hellman?

A key encapsulation mechanism, or KEM, is how the new post-quantum algorithms establish a shared secret. One side publishes a public key. The other side uses it to generate a random secret together with a ciphertext that only the holder of the private key can open, and sends the ciphertext back. Both sides end up with the same secret, which then keys the symmetric encryption.

Diffie-Hellman reaches the same result differently, with both sides contributing a public value and combining it with their own private value. Protocols such as TLS 1.3 can carry either, which is why ML-KEM could be added to TLS as a new key exchange option without redesigning the protocol.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05.

#### What are lattice, hash-based and code-based algorithms?

They are families of post-quantum algorithms named after the mathematical problem their security rests on. None of these problems has a known efficient quantum attack.

Lattice-based algorithms rest on problems about finding short vectors in high-dimensional grids. ML-KEM for key establishment and ML-DSA for signatures are both lattice-based, fast and compact, which is why they are the main standards. FrodoKEM uses a less structured lattice, which is slower and larger but considered more conservative, and BSI and ANSSI both recommend it.

Hash-based signatures, such as SLH-DSA, LMS and XMSS, rest only on the security of hash functions, which is very well understood. Their signatures are large, so they suit uses such as firmware signing where size matters less than confidence.

Code-based algorithms rest on the difficulty of decoding error-correcting codes. Classic McEliece has decades of analysis behind it but public keys of hundreds of kilobytes or more. HQC was selected by NIST in 2025 as a backup key establishment standard based on a different problem from ML-KEM.

Sources: [BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, version 2026-01](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html), BSI, 2026-01-23; [ANSSI-PG-083, Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques, v3.00](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-mecanismes-crypto-3.00.pdf), ANSSI, 2026-03-20.

#### What does stateful mean for LMS and XMSS?

LMS and XMSS build a signature key out of a large number of one-time keys, and each one may only ever be used once. The signer has to keep track of which have been used, which is the state. If the state is lost or copied, for example by restoring a backup or cloning a virtual machine, a one-time key can be reused and security fails.

That makes them unsuitable for general use but a good fit for tightly controlled signing, such as software and firmware updates signed from a hardware module. CNSA 2.0 requires them for exactly that. SLH-DSA is the stateless alternative, at the cost of larger signatures.

Sources: [NSA CNSA 2.0 algorithms advisory](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF), NSA, 2025-05-30.

#### What are NIST's post-quantum security categories?

NIST rates post-quantum parameter sets against the effort to break AES or SHA of a given size, rather than in bits. Category 1 is at least as hard to break as finding an AES-128 key, category 3 matches AES-192 and category 5 matches AES-256. Categories 2 and 4 are defined by collision search on SHA-256 and SHA-384.

The number in a parameter set name usually indicates its category. ML-KEM-512, 768 and 1024 are categories 1, 3 and 5, and ML-DSA-44, 65 and 87 are categories 2, 3 and 5. Authorities that want more margin, such as CNSA 2.0, require the category 5 sets.

Sources: [NSA CNSA 2.0 algorithms advisory](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF), NSA, 2025-05-30; [ANSSI-PG-083, Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques, v3.00](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-mecanismes-crypto-3.00.pdf), ANSSI, 2026-03-20.

#### What are Shor's and Grover's algorithms?

They are the two quantum algorithms that matter for cryptography. Shor's algorithm solves factoring and discrete logarithms efficiently, which breaks RSA, Diffie-Hellman and elliptic curves completely rather than weakening them. No increase in key size fixes that, which is why those algorithms have to be replaced.

Grover's algorithm speeds up brute-force search, in theory halving the effective size of a symmetric key. In practice the attack has to run as one very long sequential computation and parallelises poorly, so the real reduction is much smaller. That is why symmetric keys and hash functions need little or no change.

#### What is the difference between physical and logical qubits?

Physical qubits are the actual hardware elements, and they make errors far too often to run a long computation directly. Error correction combines many physical qubits into one logical qubit that behaves reliably. The more physical qubits per logical qubit, measured by the code distance, the lower the error rate.

A cryptographically relevant attack needs on the order of a thousand or more logical qubits running reliably for hours or days. The estimates on this site count physical qubits, which is why they run from hundreds of thousands to millions, and why a device announced with a few dozen logical qubits at a small code distance is still a long way from that.

#### What is a CRQC?

A cryptographically relevant quantum computer is one able to run Shor's algorithm at the scale needed to break keys in real use, such as RSA-2048 or a 256-bit elliptic curve. No such machine is known to exist.

Estimates of when one might exist vary widely, and for planning purposes the date matters less than two other numbers, which are how long your data must stay secret and how long your migration will take. If those two add up to more than the time until a CRQC exists, the data is at risk.

### Post-quantum

#### No one has a quantum computer that can break RSA. Why act now?

Because data can be recorded today and decrypted later. An attacker who captures encrypted traffic now and stores it only needs a capable quantum computer at some point before the data stops mattering. If records must stay confidential for ten years and a capable machine arrives in eight, they are already exposed, even though nothing can break them today.

Migration also takes years. Inventories, protocol changes, hardware refresh cycles and supplier updates mean that organizations starting when a machine is announced will be too late. The published estimates of what such a machine needs have fallen sharply, from about 20 million qubits in 2019 to under a million in 2025 on the same hardware assumptions, and further on other architectures.

Sources: [How to factor 2048 bit RSA integers with less than a million noisy qubits](https://arxiv.org/abs/2505.15917), Google Quantum AI, 2025-05-21; [How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits](https://arxiv.org/abs/1905.09749), Gidney and Ekerå, 2019-05.

#### Why does key establishment come before signatures?

Encrypted data can't be protected retroactively. If the key exchange behind a recorded session is broken later, the session is exposed, and nothing done afterwards changes that. A signature is different. It only needs to hold until it is replaced, and a forged signature is only useful while the old algorithm is still trusted.

That asymmetry is why US federal policy requires post-quantum key establishment for high value assets by the end of 2030 and signatures a year later, and why most national timelines follow the same order.

Sources: [Executive Order 14412](https://www.federalregister.gov/documents/2026/06/25/2026-12909/securing-the-nation-against-advanced-cryptographic-attacks), The White House, 2026-06-22, secondary reporting.

#### What is hybrid cryptography, and why do BSI and ANSSI require it?

A hybrid scheme combines a classical algorithm such as ECDH with a post-quantum one such as ML-KEM, so that an attacker has to break both. The post-quantum algorithms are much newer and have had far less scrutiny. Hybrid protects against the possibility that one of them turns out to be weaker than expected, while still protecting against a quantum computer.

The most widely deployed example is X25519MLKEM768 in TLS 1.3, which runs an elliptic-curve Diffie-Hellman exchange and an ML-KEM encapsulation in the same handshake and combines both results into the session key. It is already the default in current browsers and major TLS libraries, and it accounts for most of the post-quantum traffic measured on the web.

BSI and ANSSI both require post-quantum key establishment to be used in hybrid form. ANSSI allows hash-based signatures such as SLH-DSA to be used alone, because their security rests on well-understood hash functions. NSA takes a different view and requires CNSA 2.0 algorithms on their own once the transition dates pass.

Sources: [BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, version 2026-01](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html), BSI, 2026-01-23; [ANSSI-PG-083, Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques, v3.00](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-mecanismes-crypto-3.00.pdf), ANSSI, 2026-03-20; [NSA CNSA 2.0 algorithms advisory](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF), NSA, 2025-05-30; [OpenSSL 3.5 LTS release](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), OpenSSL, 2025-04, secondary reporting.

#### Do symmetric keys and hashes also need to change?

Much less. The quantum algorithm that breaks RSA and elliptic curves, Shor's algorithm, has no counterpart against symmetric ciphers and hash functions. The best known quantum attack on them, Grover's algorithm, gives a much smaller speed-up that is also hard to run in practice.

NIST continues to treat AES-128 as acceptable, while CNSA 2.0 requires AES-256 and SHA-384 or SHA-512 for national security systems. The large changes are all on the public-key side.

Sources: [NIST SP 800-57 Pt 1 Rev 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final), NIST, 2020-05; [NSA CNSA 2.0 algorithms advisory](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF), NSA, 2025-05-30.

#### Why do the quantum estimates keep falling?

Two things improve at once. Better algorithms reduce how many logical qubits and operations an attack needs, and better error correction reduces how many physical qubits each logical qubit costs. The 2019 to 2025 drop for RSA-2048 came entirely from those improvements on unchanged hardware assumptions.

The 2026 estimates go further by assuming different hardware, such as neutral atoms or error-correcting codes that need richer connectivity. They are not directly comparable with the earlier series, which is why the chart only joins estimates made under the same hardware model, and why the runtime matters as much as the qubit count.

Sources: [How to factor 2048 bit RSA integers with less than a million noisy qubits](https://arxiv.org/abs/2505.15917), Google Quantum AI, 2025-05-21; [How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits](https://arxiv.org/abs/1905.09749), Gidney and Ekerå, 2019-05.

### Deadlines and rules

#### Which deadline applies to me?

Usually more than one. A company can be bound by its national government, its sector regulator, the jurisdictions of its customers and the requirements of the standards it certifies against. The practical answer is to plan against the earliest deadline among those that actually apply to your systems, which the transition page shows once you select your jurisdictions.

Read the scope carefully. Many dates apply only to government systems, high-value assets or critical infrastructure, and a date that does not bind you directly may still reach you through procurement requirements.

#### What is the difference between mandatory, guidance and a stated target?

A mandatory requirement binds its scope through law, regulation or procurement, and failing it has consequences. Guidance is advice from an authority without direct enforcement, although regulators and auditors often treat it as the expected standard. A stated target is a goal a government has announced without a mechanism to enforce it.

The classification follows the one the Hong Kong Monetary Authority used in its comparison of national programmes, and it is shown next to every jurisdiction on the timeline.

Sources: [HKMA Quantum Preparedness Index, first results](https://postquantum.com/security-pqc/hkma-banks-quantum-readiness-2-3/), Hong Kong Monetary Authority, 2026-07, secondary reporting.

#### Why is China treated differently?

China is standardising its own post-quantum algorithms rather than adopting the NIST set, as it did with SM2, SM3 and SM4. Its programme published round 1 candidates in September 2026, with 84 public-key and 35 hash algorithms, and no migration deadline yet.

For organizations operating in China, that means a second set of algorithms on a different schedule, and parameter choices that will not map directly onto ML-KEM and ML-DSA.

Sources: [NGCC round 1 candidates, public-key and hash tracks](https://www.niccs.org.cn/niccs/Proposal/pc/list.html), Institute of Commercial Cryptography Standards, China, 2026-09; [Call for proposals for the next-generation public-key cryptographic algorithms](https://www.niccs.org.cn/niccs/Notice/pc/content/content_1975896137741635584.html), Institute of Commercial Cryptography Standards, China, 2025-10-09.

### Operations

#### What is crypto agility, and why do regulators ask for it?

Crypto agility is the ability to change algorithms, key sizes or protocols without redesigning the systems that use them. It matters because every recommendation on this site will change again. A system that can swap algorithms by configuration can follow the next revision. A system with algorithms fixed in hardware, firmware or data formats has to be rebuilt.

Regulators have started to require it directly. DORA requires financial entities to have provisions for updating cryptographic technology as cryptanalysis develops, NIS2's implementing regulation expects it in the cryptographic policy, and PCI DSS requires a documented plan to respond to anticipated changes in cryptographic vulnerabilities.

#### Why is everyone asking for a cryptographic inventory?

Because you can't migrate what you can't find. Cryptography is embedded in applications, libraries, devices, certificates and third-party services, and most organizations don't know where all of it is. An inventory records which algorithms, key sizes, protocols and certificates are used where, and for what.

PCI DSS has required an inventory of cipher suites and protocols since March 2025, US federal agencies have maintained inventories of quantum-vulnerable systems since 2022, and most national migration plans make an inventory the first milestone.

#### Why are TLS certificates getting shorter?

Shorter validity limits how long a mis-issued or compromised certificate stays useful, and it forces automation. Once renewal is automatic, changing key types or algorithms becomes a configuration change that propagates within one certificate lifetime, which is the web PKI's form of crypto agility.

Maximum validity for publicly trusted TLS certificates fell to 200 days in March 2026 and will fall to 100 days in March 2027 and 47 days in March 2029.

#### What is FIPS 140 validation, and why isn't using AES enough?

FIPS 140 is the US standard for cryptographic modules, the hardware or software that actually implements the algorithms. NIST's Cryptographic Module Validation Program tests modules against it and publishes certificates. FedRAMP, CMMC and federal systems require validated modules, not just approved algorithms, because a correct algorithm can still be implemented badly.

The standard is in transition. All FIPS 140-2 certificates moved to historical status on 21 September 2026, so new federal procurements depend on FIPS 140-3 certificates, and many modules are still waiting in the validation queue. Post-quantum algorithms follow the same path, since they can only be used in these regimes once validated modules implementing them exist.

Sources: [Will FedRAMP provide guidance on the sunsetting of FIPS 140-2?](https://help.fedramp.gov/hc/en-us/articles/53386638354843-Q-Will-FedRAMP-provide-guidance-on-the-sunsetting-of-FIPS-140-2-What-do-I-do-if-our-planned-140-3-Module-is-not-yet-approved), FedRAMP, 2026-07.

### About the data

#### Where does the data come from, and how do I know it's right?

Every figure links to the document it comes from, and every source is marked by how it was checked. Primary means the cited section of the document itself was read. Secondary means the entry rests on reporting about the document and still needs checking.

The distinction matters. Checking against primary documents has already corrected errors that were repeated across widely cited summaries, including the number of the US executive order and what BSI actually requires for hybrid key establishment. Surveys and trackers from firms that sell post-quantum products are treated as leads, not evidence.

#### How is the site kept current?

New findings and rules go into the developments log first, with their source, and are folded into the tables and charts once they have been checked. Every section shows the date it was last reviewed. The data is published as open JSON under CC BY 4.0 so that anyone can check it, build on it or send corrections.

#### What happened to the old Lenstra and RFC key-size calculators?

The original keylength.com included equation-based estimators from Lenstra and Verheul and RFC 3766. They are useful historical models: a reader can change assumptions about attacker budgets, hardware prices, computing growth and cryptanalytic progress, then estimate an equivalent public-key size or protection year.

This site does not mix those outputs into the current-requirements table. They are models built from explicit assumptions, not current policy, and their defaults predate today's hardware and the post-quantum transition. The current table instead shows dated figures from active authorities and links each one to its source. A future archival calculator could reproduce the historical equations with their assumptions and publication dates clearly exposed.

Sources: [Selecting Cryptographic Key Sizes](https://research.tue.nl/en/publications/selecting-cryptographic-key-sizes), Journal of Cryptology, 2001; [RFC 3766: Determining Strengths For Public Keys Used For Exchanging Symmetric Keys](https://datatracker.ietf.org/doc/html/rfc3766), IETF, 2004-04.

## Developments log

- 2026-09-21, Standard: FIPS 140-2 certificates move to the historical list. Every remaining FIPS 140-2 validation became historical, leaving FIPS 140-3 as the only active standard for new federal procurements, with a large backlog of modules still awaiting validation. Source: [Will FedRAMP provide guidance on the sunsetting of FIPS 140-2?](https://help.fedramp.gov/hc/en-us/articles/53386638354843-Q-Will-FedRAMP-provide-guidance-on-the-sunsetting-of-FIPS-140-2-What-do-I-do-if-our-planned-140-3-Module-is-not-yet-approved), FedRAMP, 2026-07.
- 2026-09, Standard: China publishes NGCC round 1 candidates. 84 public-key algorithms and 35 hash algorithms enter first-round evaluation, with the block cipher track still to follow. China is standardising its own post-quantum algorithms rather than adopting the NIST set. Source: [NGCC round 1 candidates, public-key and hash tracks](https://www.niccs.org.cn/niccs/Proposal/pc/list.html), Institute of Commercial Cryptography Standards, China, 2026-09.
- 2026-08, Policy: MAS sets an end-of-decade quantum resilience expectation for financial institutions. Supervisory expectations with milestones rather than a statutory deadline. Source: [MAS supervisory expectations on quantum resilience, as reported](https://postquantum.com/security-pqc/mas-quantum-resilience-supervisory-expectations/), Monetary Authority of Singapore, 2026-08, secondary reporting.
- 2026-07-13, Policy: Department of War suspends CMMC Phase 2. Third-party certification, due from 10 November 2026, is paused pending a 60-day review; Phase 1 self-assessments against NIST SP 800-171 remain mandatory. Source: [Department of War suspends CMMC Phase II requirements](https://business.defense.gov/Engage/News/Article/4542563/forging-the-arsenal-of-freedom-department-of-war-suspends-cmmc-phase-ii-require/), US Department of War, 2026-07-13.
- 2026-07, Policy: HKMA publishes first Quantum Preparedness Index results. Hong Kong banks score 2.3 of 10 against a target of 10 by 2030. Source: [HKMA Quantum Preparedness Index, first results](https://postquantum.com/security-pqc/hkma-banks-quantum-readiness-2-3/), Hong Kong Monetary Authority, 2026-07, secondary reporting.
- 2026-07, Policy: FINMA Guidance 05/2026 asks Swiss institutions for PQC roadmaps. Roadmaps recommended by mid-2027. Source: [FINMA Guidance 05/2026, as reported](https://postquantum.com/security-pqc/mas-quantum-resilience-supervisory-expectations/), FINMA (Switzerland), 2026-07, secondary reporting.
- 2026-07, Operator: Oratomic raises a $300M Series A to build a fault-tolerant neutral-atom machine. Reported alongside Google and Cloudflare 2029 targets and Microsoft's 2029 and 2033 plan. Source: [Neutral-atom quantum computing, Oratomic's $300M bet](https://www.supercomputing.news/quantum/oratomic-neutral-atom-qubits-rsa-2048), Supercomputing News, 2026-07, secondary reporting.
- 2026-06-24, Policy: OMB M-26-15 sets agency plan, inventory and migration phases. Plans due late October 2026, key establishment by 2030, signatures in 2031, the rest by 2035. Source: [OMB M-26-15](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), OMB, 2026-06-24, secondary reporting.
- 2026-06-23, Policy: Department of War PQC strategy. Every system supports PQC or is phased out by end of 2030, and uses it by end of 2031. Source: [Department of War PQC Strategy](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), DoW, 2026-06-23, secondary reporting.
- 2026-06-22, Policy: Executive Order 14412 pulls US federal dates forward. High value assets on PQC key establishment by end of 2030 and signatures by end of 2031; contractors through the FAR. Source: [Executive Order 14412](https://www.federalregister.gov/documents/2026/06/25/2026-12909/securing-the-nation-against-advanced-cryptographic-attacks), The White House, 2026-06-22, secondary reporting.
- 2026-05, Resource estimate: RSA-2048 on a half-million-qubit modular atomic processor. Distributing Shor's algorithm across modules costs only 16% more time than one large module. Source: [Factoring 2048 bit RSA integers with a half-million-qubit modular atomic processor](https://arxiv.org/abs/2605.03951), Xue and Covey, 2026-05.
- 2026-04, Standard: CRYPTREC clears ML-KEM for Japanese government use. Removes the main procurement barrier; a national roadmap is expected in 2027. Source: [PQC migration deadlines by country, 2026 guide](https://www.encryptionconsulting.com/pqc-migration-deadlines-by-country/), Encryption Consulting, 2026-06, secondary reporting.
- 2026-03-31, Resource estimate: Elliptic curve keys under 500,000 qubits, minutes of runtime. Google withheld the circuits and published a zero-knowledge proof of the resource counts. Source: [Securing elliptic curve cryptocurrencies against quantum vulnerabilities (arXiv 2603.28846)](https://thequantuminsider.com/2026/03/31/q-day-just-got-closer-three-papers-in-three-months-are-rewriting-the-quantum-threat-timeline/), Babbush et al., Google Quantum AI, 2026-03-31, secondary reporting.
- 2026-03-31, Resource estimate: Shor's algorithm with about 10,000 neutral atoms. Space-efficient layouts trade qubits for runtimes of days to weeks. Source: [Shor's algorithm is possible with approximately 10,000 reconfigurable atomic qubits](https://postquantum.com/security-pqc/10000-qubits-shors/), Cain et al., Oratomic and Caltech, 2026-03-31, secondary reporting.
- 2026-03-20, Standard: ANSSI publishes version 3.00 of its cryptographic mechanisms guide. RSA and finite-field groups at 2048 bits through 2030 and 3072 from 2031; post-quantum mechanisms must be hybridised, except hash-based signatures. Source: [ANSSI-PG-083, Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques, v3.00](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-mecanismes-crypto-3.00.pdf), ANSSI, 2026-03-20.
- 2026-02-27, Standard: Chrome sets out its Merkle Tree Certificates path. No immediate plan to add PQC X.509 certificates to the Chrome Root Store. Source: [Cultivating a robust and efficient quantum-safe HTTPS](https://security.googleblog.com/2026/02/cultivating-robust-and-efficient.html), Google Chrome, 2026-02-27.
- 2026-02-04, Policy: India's task force report sets milestones from 2027 to 2033. Critical infrastructure first, with PQC the default across communication systems by 2033. Source: [Implementation of Quantum Safe Ecosystem in India (task force report)](https://dst.gov.in/sites/default/files/Report_TaskForce_PQMigration_4Feb26%20%28v1%29.pdf), DST India, National Quantum Mission, 2026-02-04, secondary reporting.
- 2026-02, Resource estimate: Pinnacle architecture puts RSA-2048 under 100,000 qubits. Uses quantum LDPC codes; needs richer connectivity than a planar grid. Source: [The Pinnacle architecture (arXiv 2602.11457)](https://thequantuminsider.com/2026/03/31/q-day-just-got-closer-three-papers-in-three-months-are-rewriting-the-quantum-threat-timeline/), Webster et al., Iceberg Quantum, 2026-02, secondary reporting.
- 2026-01-23, Standard: BSI TR-02102-1 2026-01 ends the sole use of classical asymmetric mechanisms. Classical key agreement alone until end of 2031 (2030 for very high protection), classical signatures until end of 2035, post-quantum KEMs in hybrid form. Source: [BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, version 2026-01](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html), BSI, 2026-01-23.
- 2026-01-23, Policy: CISA lists product categories where only PQC-capable products should be bought. Includes browsers, servers and cloud services. Source: [Product categories for technologies that use PQC standards](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), CISA, 2026-01-23, secondary reporting.
- 2026-01-13, Policy: G7 Cyber Expert Group points the financial sector at 2035. Critical systems between 2030 and 2032; explicitly non-binding. Source: [G7 CEG statement on a PQC roadmap for the financial sector](https://www.gov.uk/government/publications/advancing-a-coordinated-roadmap-for-the-transition-to-post-quantum-cryptography-in-the-financial-sector/g7-cyber-expert-group-statement-on-advancing-a-coordinated-roadmap-for-the-transition-to-post-quantum-cryptography-in-the-financial-sector-january-20), G7 Cyber Expert Group, 2026-01-13, secondary reporting.
- 2026-01, Policy: European Commission proposes making the PQC transition binding under NIS2. COM(2026) 13; adoption expected late 2026 or early 2027. Source: [PQC migration deadlines by country, 2026 guide](https://www.encryptionconsulting.com/pqc-migration-deadlines-by-country/), Encryption Consulting, 2026-06, secondary reporting.
- 2026-01, Hardware: QuEra runs 96 logical qubits on 448 atoms. A distance-4 code, well short of the distance Shor's algorithm needs at length. Source: [Qubit tracker, QuEra 96 logical qubits and code distance](https://qrlhub.com/en/qubits), QRL Hub, 2026-05, secondary reporting.
- 2025-12-05, Standard: NIST SP 800-57 Part 1 Rev 6 draft. Adds ML-KEM, ML-DSA and SLH-DSA and drops dated approval tables. Source: [NIST SP 800-57 Pt 1 Rev 6 initial public draft](https://csrc.nist.gov/pubs/sp/800/57/pt1/r6/ipd), NIST, 2025-12-05, draft.
- 2025-11, Hardware: Quantinuum Helios reaches 48 logical qubits from 98 ions. The best encoding ratio so far, using a distance-2 code. Source: [Quantum logical qubit leaderboard](https://quantumzeitgeist.com/quantum-logical-qubit-leaderboard/), Quantum Zeitgeist, 2026-06, secondary reporting.
- 2025-10-09, Standard: ICCS opens submissions for next-generation public-key algorithms. Final submission requirements and evaluation criteria published, with a submission deadline of 30 June 2026. Source: [Call for proposals for the next-generation public-key cryptographic algorithms](https://www.niccs.org.cn/niccs/Notice/pc/content/content_1975896137741635584.html), Institute of Commercial Cryptography Standards, China, 2025-10-09.
- 2025-10, Policy: Singapore's CSA publishes a Quantum-Safe Handbook and readiness index. Pressure applied through procurement and the Cyber Trust Mark rather than a date. Source: [Quantum-Safe Handbook and Quantum Readiness Index, as reported](https://quantumgate.ae/post-quantum-cryptography-how-governments-worldwide-are-shaping-the-transition-ahead), Cyber Security Agency of Singapore, 2025-10, secondary reporting.
- 2025-09, Hardware: Caltech builds a 6,100-atom neutral-atom array. The largest qubit array so far, not yet used for computation. Source: [New findings shorten the road to CRQCs (6,100-atom array)](https://physicsworld.com/a/new-findings-shorten-the-road-to-cryptographically-relevant-quantum-computers/), Physics World, 2026-06, secondary reporting.
- 2025-06-23, Policy: EU coordinated roadmap and Canada's ITSM.40.001. Both set high-priority migration around 2030 to 2031 and completion by 2035. Source: [NIS Cooperation Group coordinated implementation roadmap](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html), European Commission and member states, 2025-06-23, secondary reporting.
- 2025-05-30, Standard: NSA updates the CNSA 2.0 algorithms advisory. ML-KEM-1024 and ML-DSA-87, with LMS or XMSS for firmware. Source: [NSA CNSA 2.0 algorithms advisory](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF), NSA, 2025-05-30.
- 2025-05-21, Resource estimate: RSA-2048 under one million qubits on the 2019 hardware model. A twentyfold drop from the 2019 estimate from algorithms and error correction alone. Source: [How to factor 2048 bit RSA integers with less than a million noisy qubits](https://arxiv.org/abs/2505.15917), Google Quantum AI, 2025-05-21.
- 2025-03-20, Policy: UK NCSC publishes 2028, 2031 and 2035 milestones. Discovery and planning, priority migration, then completion. Source: [Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines), NCSC (UK), 2025-03-20.
- 2025-02-05, Standard: China launches the NGCC programme. A global call for public-key, hash and block cipher algorithms, run by ICCS under the Chinese Cryptography Standardization Technical Committee. Source: [Announcement on launching the Next-generation Commercial Cryptographic Algorithms Program (NGCC)](https://www.niccs.org.cn/niccs/Notice/pc/content/content_1937428197396713472.html), Institute of Commercial Cryptography Standards, China, 2025-02-05.
- 2024-12, Hardware: Google's Willow chip shows error correction below the surface code threshold. First experimental evidence that the noise assumptions behind these estimates are achievable. Source: [Three papers in three months are rewriting the quantum threat timeline](https://thequantuminsider.com/2026/03/31/q-day-just-got-closer-three-papers-in-three-months-are-rewriting-the-quantum-threat-timeline/), The Quantum Insider, 2026-03-31, secondary reporting.
- 2024-11-12, Standard: NIST IR 8547 draft proposes 2030 deprecation and 2035 disallowance. Still a draft; widely used as the planning baseline. Source: [NIST IR 8547 initial public draft](https://csrc.nist.gov/pubs/ir/8547/ipd), NIST, 2024-11-12, draft.
- 2023-12, Hardware: IBM Condor passes 1,000 qubits. 1,121 superconducting qubits; IBM then shifted focus from count to quality. Source: [IBM Condor 1,121-qubit processor, and Sycamore context](https://postquantum.com/industry-news/ibm-condor/), PostQuantum, 2023-12, secondary reporting.
- 2023-08, Resource estimate: Regev proposes the first fundamental change to Shor's factoring algorithm in decades. Fewer gates per run at the cost of more qubits; later refined by Ragavan and Vaikuntanathan. Source: [Three papers in three months are rewriting the quantum threat timeline](https://thequantuminsider.com/2026/03/31/q-day-just-got-closer-three-papers-in-three-months-are-rewriting-the-quantum-threat-timeline/), The Quantum Insider, 2026-03-31, secondary reporting.
- 2019-05, Resource estimate: RSA-2048 in 8 hours with 20 million noisy qubits. The reference estimate for six years. Source: [How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits](https://arxiv.org/abs/1905.09749), Gidney and Ekerå, 2019-05.
- 2012, Resource estimate: Surface code estimate of around a billion qubits. Fowler et al.; the starting point most comparisons use. Source: [Estimating the energy requirements to operate a CRQC (RAND), table of earlier estimates](https://arxiv.org/abs/2304.14344), Parker and Vermeer, 2023-04.

Data: https://keylength.goodkey.co/data/ (CC BY 4.0).