{"slug": "nist-ir-8547-rsa-ecdsa-disallowed-after-2035-2026", "title": "NIST IR 8547: RSA, ECDSA Disallowed After 2035 [2026]", "summary": "NIST published final transition report NIST IR 8547 on October 27, 2026, setting dates that deprecate quantum-vulnerable public-key cryptography after 2030 and disallow RSA, ECDSA, EdDSA and all Diffie-Hellman variants under NIST standards after 2035. The report, authored by Dustin Moody, Ray Perlner, Angela Robinson, Andrew Regenscheid and David Cooper, names ML-KEM, ML-DSA and SLH-DSA — final since August 13, 2024 — as the replacements, and ties the schedule to National Security Memorandum 10's 2035 federal migration target plus Executive Order 14412 and OMB Memorandum M-26-15, which require high value assets and high impact systems to adopt post-quantum key establishment by December 31, 2030 and post-quantum digital signatures by December 31, 2031. IR 8547 discards SP 800-57 Part 1's earlier projection that 112-bit public-key schemes would be disallowed on January 1, 2031, placing all quantum-vulnerable schemes on one track regardless of key length.", "body_md": "NIST published its final transition report, NIST IR 8547, on October 27, 2026, and it puts calendar dates on the end of RSA, ECDSA, EdDSA and every Diffie-Hellman variant. Quantum-vulnerable public-key cryptography becomes deprecated after 2030 and disallowed under NIST standards after 2035, according to [NIST’s announcement of the report](https://www.nist.gov/news-events/news/2026/10/nist-report-provides-guidelines-transition-post-quantum-cryptography). The three replacements, ML-KEM, ML-DSA and SLH-DSA, have been final since August 13, 2024.\n\nThat changes the question teams ask about post-quantum cryptography. Picking a winner among the new algorithms matters less than knowing which classical algorithm each one retires, on what date, and how many extra bytes the swap puts on the wire. The answers differ sharply between key establishment, where harvest-now-decrypt-later attacks force early action, and signatures, where the pressure arrives later.\n\nEvery number below comes from NIST’s own documents: the IR 8547 text, FIPS 203, FIPS 204 and FIPS 205. Where a vendor or standards-body claim sits on a single source, the text says so. The byte cost of [swapping RSA for ML-KEM](https://shattered.io/rsa-vs-ml-kem-post-quantum-encryption-2026/) is the first thing most engineering teams hit, so the size tables come early.\n\nDon't miss new tech stories on Google\n\nAdd Shattered once in the Google app and our stories show up in your news suggestions.\n\n[Add now](https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F)\n\n## What NIST IR 8547 Changed on October 27, 2026\n\nThe report, titled Transition to Post-Quantum Cryptography Standards, appeared on October 27, 2026, and NIST’s publication page shows an update on October 28. It replaces the initial public draft that circulated from November 12, 2024. The listed authors are Dustin Moody, Ray Perlner, Angela Robinson, Andrew Regenscheid and David Cooper. Cooper left NIST before publication, and the report states that all of his work was done while he was at the agency.\n\nThe document does three jobs. It lists the quantum-vulnerable algorithms inside NIST’s existing standards. It names the quantum-resistant standards that replace them. And it attaches dates, which the earlier guidance never did for post-quantum work. The report carries both the schedule and the per-algorithm verdicts.\n\nFour federal instruments sit behind those dates. National Security Memorandum 10 set 2035 as the target for finishing the federal migration, and that goal stands. Executive Order 14412 and OMB Memorandum M-26-15 pull the most sensitive systems forward: high value assets and high impact systems must adopt post-quantum key establishment by December 31, 2030 and post-quantum digital signatures by December 31, 2031. OpenSSL Corporation summarized [the new deadlines](https://openssl-corporation.org/blog/post-quantum-cryptography-now-has-deadlines.html) for implementers earlier this year. A fourth instrument, Executive Order 14306, requires agencies to support TLS 1.3 by January 2, 2030, which matters because TLS 1.3 is the practical vehicle for hybrid ML-KEM key exchange.\n\nOne detail shows how fast the plan moved. NIST’s older key-management guidance, SP 800-57 Part 1, had projected that public-key schemes with 112 bits of security would be disallowed on January 1, 2031. IR 8547 discards that projection. All quantum-vulnerable signature and key-establishment schemes now follow a single track: deprecated after 2030, disallowed after 2035, regardless of key length.\n\nDustin Moody, who heads NIST’s post-quantum standardization project, framed the report as a planning aid rather than a single prescription. He said the document describes different use cases and explains why one migration may take longer than another, and that no single strategy fits every system. He also pointed to the practical consequence of the phase-out: an algorithm may be disallowed in federal systems after a set date, or it may stay allowed at the user’s own risk until then. His remarks appear in the NIST announcement linked above.\n\nThe report also repeats a warning that previous cryptographic transitions took 10 to 20 years from standardization to full integration. Measured against that history, the 2030 and 2031 federal deadlines leave little slack, and NIST tells organizations to treat migration as a current operational priority that starts with a cryptographic inventory.\n\n## Deprecated vs Disallowed: NIST’s Status Labels\n\nThe headline dates use words with precise meanings in NIST’s transition framework, defined in SP 800-131A and restated in IR 8547. Misreading them leads to bad planning in both directions: some teams assume RSA stops working in 2031, others assume nothing happens until 2035.\n\n| Status | What NIST means | What it means for your system | \n|---|---|---|\n| Acceptable | Approved for use under the associated guidance | No action required | \n| Deprecated | May still be used, but carries some security risk | The data owner must assess the risk and decide whether to keep using it | \n| Disallowed | No longer permitted for the stated purpose | Use is prohibited for that purpose under NIST standards and guidelines | \n| Legacy use | Only for processing already protected information | Decrypt old ciphertext or verify old signatures, never create new protection | \n\n[Help Net Security’s summary of the roadmap](https://www.helpnetsecurity.com/2026/10/28/nist-post-quantum-cryptography-migration-roadmap/) makes the same distinction in plain terms: deprecation means the methods may still be used but data owners must weigh the risk, while disallowance means use is prohibited for the specified purpose. The 2030 to 2035 stretch is a deprecation window, and NIST says it exists for lower-risk systems and applications with legacy constraints while full migration finishes.\n\nThe window does not shelter everyone. NIST states that it leaves the earlier federal deadlines untouched for high value assets, high impact systems and other prioritized sensitive systems. A hospital network, a bank or a defense contractor handling data that must stay secret past 2030 cannot read “deprecated after 2030” as permission to wait. Application-specific guidance can also pull dates forward. NIST expects to prioritize quantum-resistant key establishment in updates covering interactive protocols such as TLS and IKE, because those protocols are the easiest place for an adversary to collect traffic today.\n\nSystems that cannot support post-quantum cryptography at all get blunt treatment. The report says they should be identified and prioritized for replacement or decommissioning. For embedded fleets, industrial controllers and anything with a fifteen-year hardware life, that sentence is the real deadline, because the replacement purchase has to happen years before the algorithm date does.\n\n## Signatures Compared: ECDSA, EdDSA and RSA vs ML-DSA and SLH-DSA\n\nDigital signatures prove who issued a message, a document or a software update, and that nobody altered it afterward. NIST historically specified approved signature algorithms in FIPS 186, which covers ECDSA, EdDSA and RSA. All three fall to Shor’s algorithm on a cryptanalytically relevant quantum computer, so IR 8547 gives them an identical sunset.\n\n| Quantum-vulnerable signature | Parameters covered | Transition under IR 8547 | \n|---|---|---|\n| ECDSA (FIPS 186) | At least 112 bits of classical security strength | Deprecated after 2030, disallowed after 2035 | \n| EdDSA (FIPS 186) | At least 128 bits of classical security strength | Deprecated after 2030, disallowed after 2035 | \n| RSA signatures (FIPS 186) | At least 112 bits of classical security strength | Deprecated after 2030, disallowed after 2035 | \n\nThe replacements split into three families. ML-DSA, specified in FIPS 204 and derived from the CRYSTALS-Dilithium submission, is the general-purpose lattice signature. SLH-DSA, specified in FIPS 205 and derived from SPHINCS+, relies only on hash functions, which gives it a different and more conservative security assumption at the price of much larger signatures. The third family is stateful hash-based signatures, LMS and XMSS with their multi-tree variants HSS and XMSS<sup>MT</sup>, specified in SP 800-208.\n\n| Post-quantum signature | Parameter sets | Classical strength | Security category | \n|---|---|---|---|\n| ML-DSA (FIPS 204) | ML-DSA-44 | 128 bits | 2 (drops to 1 if an approved random bit generator with under 192 bits of strength is used) | \n| ML-DSA (FIPS 204) | ML-DSA-65 | 192 bits | 3 | \n| ML-DSA (FIPS 204) | ML-DSA-87 | 256 bits | 5 | \n| SLH-DSA (FIPS 205) | SHA2 and SHAKE 128s and 128f | 128 bits | 1 | \n| SLH-DSA (FIPS 205) | SHA2 and SHAKE 192s and 192f | 192 bits | 3 | \n| SLH-DSA (FIPS 205) | SHA2 and SHAKE 256s and 256f | 256 bits | 5 | \n| LMS, HSS, XMSS, XMSS <sup>MT</sup> (SP 800-208) | SHA-256/192 or SHAKE256/192 variants | 192 bits | 3 | \n| LMS, HSS, XMSS, XMSS <sup>MT</sup> (SP 800-208) | SHA-256 or SHAKE256 variants | 256 bits | 5 | \n\nThe stateful schemes deserve a caution. Their private keys consist of many one-time signature keys, and the signer must never reuse one. NIST says that need for strict operational state tracking makes them unsuitable for general use, though they may suit software and firmware signing where a single controlled signing system exists. A reused one-time key breaks the scheme, which is why the stateless SLH-DSA exists at all.\n\nTwo more signature standards are coming. NIST is developing a FIPS for a signature algorithm derived from FALCON, as an additional alternative to ML-DSA and SLH-DSA, and the [FN-DSA versus ML-DSA trade-off](https://shattered.io/fn-dsa-vs-ml-dsa-falcon-dilithium-2026/) matters for anyone who needs compact signatures. NIST is also still evaluating further candidates through its additional digital signature process. IR 8547 states that NIST does not expect to standardize any new signature algorithm that is not quantum-resistant, and that any later selection would add to FIPS 204 and FIPS 205 rather than replace them.\n\nFor a side-by-side of all three NIST algorithms on one page, the existing [three-way ML-KEM, ML-DSA and SLH-DSA comparison](https://shattered.io/ml-kem-ml-dsa-slh-dsa-compared-2026/) covers the algorithm internals. The angle here is different: which classical signature each option retires, and when the retirement bites.\n\nOne timing point surprises many readers. IR 8547 notes that signatures are not vulnerable to harvest-now-decrypt-later attacks, since an adversary cannot retroactively forge a signature that was checked years ago. Authentication systems can keep using quantum-vulnerable algorithms until a capable quantum computer appears, and at that moment they must switch immediately. The catch is long-lived trust: a device that verifies code signatures and cannot be updated in the field should require quantum-resistant signatures now if it will still run after such a computer exists. That is why NIST still calls the signature migration urgent, because the transition involves more parties and takes longer than a key exchange swap.\n\n## Key Establishment Compared: RSA, DH and ECDH vs ML-KEM\n\nKey establishment is how two parties end up with the same secret key over a public channel. The quantum-vulnerable schemes include Diffie-Hellman, ECDH and RSA key establishment under SP 800-56B. Shor’s algorithm threatens every one of them.\n\n| Quantum-vulnerable key establishment | Source standard | Parameters covered | Transition under IR 8547 | \n|---|---|---|---|\n| Finite-field DH and MQV | SP 800-56A | At least 112 bits of classical strength | Deprecated after 2030, disallowed after 2035 | \n| Elliptic-curve DH and MQV (ECDH) | SP 800-56A | At least 112 bits of classical strength | Deprecated after 2030, disallowed after 2035 | \n| RSA key establishment | SP 800-56B | At least 112 bits of classical strength | Deprecated after 2030, disallowed after 2035 | \n\nThe replacement is ML-KEM, a key-encapsulation mechanism from FIPS 203 derived from CRYSTALS-Kyber. A KEM lets one party generate a shared secret key and send an encapsulation that only the key holder can open. The output is a 32-byte shared secret that needs no further derivation step. NIST recommends ML-KEM-768 as the default parameter set because it provides a large security margin at a reasonable performance cost, and it keeps ML-KEM-512 and ML-KEM-1024 for constrained or high-assurance cases.\n\n| ML-KEM parameter set | Classical strength | Security category | Role | \n|---|---|---|---|\n| ML-KEM-512 | 128 bits | 1 | Constrained devices where bytes are scarce | \n| ML-KEM-768 | 192 bits | 3 | NIST’s recommended default | \n| ML-KEM-1024 | 256 bits | 5 | Highest-assurance and long-lived data | \n\nToday ML-KEM is the only approved post-quantum scheme for key establishment based on public-key cryptography. NIST selected HQC as an alternative, and a FIPS for HQC-KEM is under development, but until it publishes, ML-KEM carries the whole load. NIST has no current plans to pick any additional KEMs, though it left that door open. The [ML-KEM versus HQC comparison](https://shattered.io/ml-kem-vs-hqc-2026/) goes through why a code-based backup is worth having.\n\nKey establishment is where the calendar compresses. Session keys protect confidentiality, and encrypted traffic that an adversary records today can be opened later. IR 8547 therefore says organizations should consider moving to FIPS 203 first for data that is particularly sensitive or must stay secret for a long time. TLS 1.3 already keeps Diffie-Hellman for key exchange, as the [RSA versus Diffie-Hellman key exchange](https://shattered.io/rsa-vs-diffie-hellman-key-exchange-2026/) breakdown explains, so the practical work is adding ML-KEM beside it rather than ripping anything out on day one.\n\nForward secrecy complicates the picture in a useful way. Modern protocols use separate asymmetric keys for authentication and for key establishment, and key-establishment keys live for one transaction. IR 8547 points out that this separation lets teams migrate the two halves on different schedules: key exchange first because of collection risk, authentication later because forgery cannot be done in hindsight.\n\n## Specs Table: Key, Ciphertext and Signature Sizes by Parameter Set\n\nSizes decide whether a post-quantum swap is a configuration change or a protocol redesign. The figures below come straight from the size tables in FIPS 203 (Table 3), FIPS 204 (Table 2) and FIPS 205 (Table 2), and the security categories come from IR 8547.\n\n| Algorithm | Parameter set | Public or encapsulation key (bytes) | Ciphertext or signature (bytes) | Security category | \n|---|---|---|---|---|\n| ML-KEM (FIPS 203) | ML-KEM-512 | 800 | 768 (ciphertext) | 1 | \n| ML-KEM (FIPS 203) | ML-KEM-768 | 1,184 | 1,088 (ciphertext) | 3 | \n| ML-KEM (FIPS 203) | ML-KEM-1024 | 1,568 | 1,568 (ciphertext) | 5 | \n| ML-DSA (FIPS 204) | ML-DSA-44 | 1,312 | 2,420 (signature) | 2 | \n| ML-DSA (FIPS 204) | ML-DSA-65 | 1,952 | 3,309 (signature) | 3 | \n| ML-DSA (FIPS 204) | ML-DSA-87 | 2,592 | 4,627 (signature) | 5 | \n| SLH-DSA (FIPS 205) | SLH-DSA-128s | 32 | 7,856 (signature) | 1 | \n| SLH-DSA (FIPS 205) | SLH-DSA-128f | 32 | 17,088 (signature) | 1 | \n| SLH-DSA (FIPS 205) | SLH-DSA-192s | 48 | 16,224 (signature) | 3 | \n| SLH-DSA (FIPS 205) | SLH-DSA-192f | 48 | 35,664 (signature) | 3 | \n| SLH-DSA (FIPS 205) | SLH-DSA-256s | 64 | 29,792 (signature) | 5 | \n| SLH-DSA (FIPS 205) | SLH-DSA-256f | 64 | 49,856 (signature) | 5 | \n\nFIPS 205 defines 12 parameter sets in all, because each size row exists in a SHA-2 and a SHAKE flavor. The size figures are identical across the two. The letter suffix matters more: the s sets give the smaller signatures and the f sets trade bytes for faster signing. Even the smallest SLH-DSA signature, at 7,856 bytes, is roughly 3.2 times the 2,420 bytes of ML-DSA-44. The largest, at 49,856 bytes, is many times the biggest ML-DSA signature of 4,627 bytes.\n\nThe public keys tell the opposite story. SLH-DSA public keys run from 32 to 64 bytes, while ML-DSA public keys run from 1,312 to 2,592 bytes. Whenever a certificate chain carries many public keys and signatures at once, the sum matters more than any single field, and the two algorithm families land closer together than the signature column suggests.\n\n### How to Read the Security Categories\n\nNIST stopped describing post-quantum strength as a single number of bits because nobody can yet predict the cost, speed and memory of future quantum machines. Each category instead pins a floor to a reference primitive whose security is easy to analyze. Classical strength in bits still appears for conventional attacks.\n\n| Category | Reference attack | Example | \n|---|---|---|\n| 1 | Key search on a block cipher with a 128-bit key | AES-128 | \n| 2 | Collision search on a 256-bit hash function | SHA-256 | \n| 3 | Key search on a block cipher with a 192-bit key | AES-192 | \n| 4 | Collision search on a 384-bit hash function | SHA3-384 | \n| 5 | Key search on a block cipher with a 256-bit key | AES-256 | \n\nThe practical reading: ML-KEM-768 and ML-DSA-65 both sit at category 3, so they pair naturally in a system that wants one consistent security level. ML-DSA-44 lands at category 2, with a footnote that it drops to category 1 if the random bit generator supplies less than 192 bits of strength. Teams that pick ML-DSA-44 for its small signatures should check their entropy source.\n\n### Byte Math for a Single Exchange\n\nAdding the encapsulation key and the ciphertext gives the ML-KEM cost of one key exchange, and the cost grows with each step from ML-KEM-512 to ML-KEM-768 to ML-KEM-1024. For signatures, a public key plus one signature gives the same kind of total for each ML-DSA set. SLH-DSA needs far more bytes for that pair than ML-DSA does, and the f sets need more than the s sets. The [ML-KEM versus ML-DSA size comparison](https://shattered.io/ml-kem-vs-ml-dsa/) works through the same arithmetic for protocol designers.\n\n## What Survives: AES, SHA-2, SHA-3 and Ascon\n\nThe transition targets public-key cryptography. NIST’s symmetric standards, including hash functions, extendable-output functions, block ciphers, key derivation functions, authenticated encryption and deterministic random bit generators, are significantly less exposed to known quantum attacks. IR 8547 says NIST does not expect to move away from them as part of the post-quantum migration, and that every NIST-approved symmetric primitive with at least 128 bits of classical security is believed to meet at least category 1.\n\n| Primitive | Classical collision or key strength | Security category | Status in IR 8547 | \n|---|---|---|---|\n| AES-128 | 128 bits | 1 | Remains approved | \n| AES-192 | 192 bits | 3 | Remains approved | \n| AES-256 | 256 bits | 5 | Remains approved | \n| SHA-256 and SHA-512/256 | 128 bits (collision) | 2 | Remains approved | \n| SHA-384 | 192 bits (collision) | 4 | Remains approved | \n| SHA-512 | 256 bits (collision) | 5 | Remains approved | \n| SHA3-256 | 128 bits (collision) | 2 | Remains approved | \n| SHA3-512 | 256 bits (collision) | 5 | Remains approved | \n| SHA-224 and SHA3-224 | 112 bits (collision) | Below 1 | 112-bit symmetric standards disallowed in 2030 | \n| SHA-1 | Under 80 bits (collision) | Below 1 | Deprecated, disallowed in FIPS-validated modules after 2030 | \n\nTwo lines in that table need attention. NIST has a few symmetric standards at the 112-bit level, and it tells applications to move off them during the post-quantum transition, with disallowance in 2030. SHA-1 is already deprecated for all remaining technical applications. Teams doing a cryptographic inventory should log these weak symmetric uses alongside the RSA and ECDSA findings, since the 2030 date hits both.\n\nThe upshot for planning is simple. AES-256-GCM sessions, SHA-256 digests and HMAC constructions do not need replacement because of quantum computers. What changes is how the AES key arrives, and how the certificate that vouches for the server was signed. Anything that wraps a symmetric key with RSA is on the clock, while the symmetric layer under it is not.\n\n## Federal Deadline Calendar: 2030, 2031 and 2035\n\nThe dates come from different instruments with different reach. Mixing them up is the most common error in vendor slides, so the table separates what binds whom.\n\n| Date | Milestone | Source instrument | Who it binds | \n|---|---|---|---|\n| January 2, 2030 | Agencies must support TLS 1.3 | EO 14306 and OMB M-26-15 | Federal agencies | \n| December 31, 2030 | Post-quantum key establishment in place | EO 14412 and OMB M-26-15 | High value assets, high impact systems and other prioritized sensitive systems | \n| End of 2030 | Quantum-vulnerable public-key cryptography becomes deprecated | NIST IR 8547 | All users of NIST standards and guidelines | \n| After 2030 | 112-bit symmetric standards disallowed, SHA-1 disallowed in FIPS-validated modules | NIST IR 8547 | All users of NIST standards and guidelines | \n| December 31, 2031 | Post-quantum digital signatures in place | EO 14412 and OMB M-26-15 | High value assets, high impact systems and other prioritized sensitive systems | \n| After 2035 | RSA, ECDSA, EdDSA, DH and ECDH disallowed | NIST IR 8547 | All users of NIST standards and guidelines | \n| 2035 | Target for completing the federal migration | National Security Memorandum 10 | Federal systems overall | \n\nPrivate companies sit outside the federal mandates, but the reach is wider than it looks. NIST notes that many organizations working with the government will feel the effect, and the NIST standards cited in contracts, audit frameworks and procurement checklists tend to follow the same dates. A vendor that sells to agencies will need post-quantum key establishment by the 2030 deadline whether or not its commercial customers ask.\n\nThe report also invokes Mosca’s theorem to explain the urgency. Take X as the number of years the data must stay secret and Y as the years needed to finish the migration. If X plus Y exceeds the time Z before a cryptanalytically relevant quantum computer exists, the data is already exposed. NIST adds that even if such a machine is a decade away, long-lived records such as medical files and government secrets should move now. Wallets and ledgers that publish long-lived public keys are the clearest case of data whose exposure window outlasts the migration.\n\n## Hybrid vs Pure Post-Quantum Modes: What NIST Allows\n\nHybrid designs combine a classical algorithm with a post-quantum one so that the result stays secure if at least one component holds. NIST treats them as an accommodation, not a goal. The report says hybrids add complexity to implementations and architectures, can raise security risks and costs, and are typically expected to be temporary measures that lead to a second transition to pure post-quantum tools. Early implementations of new algorithms carry their own risk of implementation errors and side-channel leaks, which is the argument for the extra padlock.\n\nOn the key-establishment side, NIST already allows a generic composite technique in SP 800-56C. A shared secret Z from an approved scheme is concatenated with a second secret T from another source, and the result runs through an approved key derivation method. The composite is allowed even when T comes from an unapproved source, including a disallowed algorithm. NIST plans to update SP 800-56C so Z can come from FIPS 203, and it allows the order of Z and T to be reversed, with protocols fixing the order to avoid confusion. SP 800-227 gives further guidance on key combiners. Because the FIPS 203 output is already a shared secret key, it drops directly into the Z slot.\n\nValidation matters for regulated buyers. NIST says a hybrid mode can be FIPS 140-validated as long as at least one input to the composite comes from an approved key-establishment scheme, even if other inputs are disallowed. For signatures, dual signatures are accommodated when at least one component algorithm is NIST-approved, and verification requires every component signature to pass.\n\nNIST leaves the decision to each application. The cost side includes implementation effort, performance loss, engineering complexity and the independent security review that composite constructions need. Systems that negotiate algorithms per session, as many network protocols do, are not hybrids in this definition as long as each session uses a single algorithm. The distinction matters for audits: running RSA and ML-KEM side by side across a fleet is coexistence, not a hybrid.\n\nTLS is where the hybrid question gets concrete. IR 8547 calls TLS an early priority because it protects data in transit for nearly every federal system and offers a practical near-term path to quantum-resistant key establishment, including hybrid key exchange that combines ML-KEM with classical algorithms. Guidance will land in the next revision of SP 800-52. The tradeoffs between running a classical curve beside ML-KEM and going pure are laid out in the [ML-KEM versus X25519 in TLS 1.3 analysis](https://shattered.io/ml-kem-vs-x25519-tls-1-3-2026/), and the broader choice between hybrid, pure and composite paths is covered in [the three rollout paths for quantum-resistant encryption](https://shattered.io/quantum-resistant-encryption-hybrid-pure-composite-ml-kem-2026/).\n\nSignature hybrids are earlier in their life. According to the IETF datatracker listing, the draft [draft-ietf-tls-composite-mldsa-00](https://datatracker.ietf.org/doc/html/draft-ietf-tls-composite-mldsa-00) proposes combining ML-DSA with RSA, ECDSA, Ed25519 or Ed448 in TLS authentication, and a companion draft covers plain ML-DSA in TLS 1.3. Both are Internet-Drafts, not published standards, so they belong in test environments and not in production rollout plans.\n\n## Speed and Size Trade-offs: What the Numbers Mean\n\nIR 8547 publishes no speed rankings, and neither do the FIPS documents. Timing depends on the CPU, the library, the compiler and the parameter set, so cross-vendor benchmark tables age quickly. What the standards do fix are sizes, security categories and a few structural facts that predict performance behavior. Teams that need absolute throughput numbers should measure on their own hardware under their own protocol stack.\n\nThree structural facts do carry through. First, ML-DSA signing uses a rejection loop, and FIPS 204 lists the expected number of repetitions per parameter set: 4.25 for ML-DSA-44, 5.1 for ML-DSA-65 and 3.85 for ML-DSA-87. Signing time therefore varies from message to message, which matters for latency-sensitive services and for constant-time review. Second, SLH-DSA key pairs may sign up to 2<sup>64</sup> messages, and FIPS 205 observes that signing 2<sup>64</sup> messages at 10 billion per second would take over 58 years, so the cap never binds in practice. Third, hash-based signatures give up bytes, not security assumptions: their cost lands in bandwidth and storage.\n\n| Dimension | ML-KEM | ML-DSA | SLH-DSA | \n|---|---|---|---|\n| Job | Key establishment | General-purpose signatures | Conservative hash-based signatures | \n| Standard | FIPS 203 | FIPS 204 | FIPS 205 | \n| Derived from | CRYSTALS-Kyber | CRYSTALS-Dilithium | SPHINCS+ | \n| Security basis | Module lattices | Module lattices | Hash functions only | \n| Parameter sets | 3 | 3 | 12 | \n| Smallest public key or encapsulation key | 800 bytes | 1,312 bytes | 32 bytes | \n| Smallest ciphertext or signature | 768 bytes | 2,420 bytes | 7,856 bytes | \n| Largest ciphertext or signature | 1,568 bytes | 4,627 bytes | 49,856 bytes | \n| Replaces | RSA key transport, DH, ECDH | RSA, ECDSA, EdDSA signatures | RSA, ECDSA, EdDSA signatures | \n\nHardware is the slow part. IR 8547 warns that HSMs and TPMs must be upgraded or redesigned because post-quantum algorithms use larger keys and different computational patterns, and it names the long lead time of hardware design and fabrication as the reason vendors should start immediately. Software libraries such as OpenSSL, BoringSSL and Libsodium need the new algorithms plus side-channel hardening. NIST is also revising the Cryptographic Module Validation Program to speed up validation of modules that implement post-quantum algorithms, as Executive Order 14412 directs.\n\nProtocol limits can bite before CPU does. The report notes that some protocols need only a new algorithm identifier, while others need significant changes to handle the larger sizes of post-quantum objects or algorithms with different interfaces. A certificate chain with several signatures and public keys can grow by tens of kilobytes under SLH-DSA, which is why design discussions tend to favor ML-DSA for high-volume signing and keep SLH-DSA for rarely issued roots and firmware.\n\n## Real-World Adoption Examples Since July 2026\n\nStandards matter only when products ship them. Six recent cases show where the three algorithms already run, with the strength of each claim noted.\n\n- **AWS Key Management Service, ML-KEM.** AWS announced on October 26, 2026 that[KMS now supports ML-KEM for post-quantum key encapsulation](https://aws.amazon.com/about-aws/whats-new/2026/10/kms-ml-kem-post-quantum/) . The announcement is the newest cloud-key-service release found for ML-KEM, and no ML-KEM-specific price or separate billing model was reported alongside it. The[Cloudflare versus AWS post-quantum encryption comparison](https://shattered.io/cloudflare-vs-aws-post-quantum-encryption-2026/) tracks how the two providers differ on defaults.\n- **BellSoft Liberica JDK 17.0.21+11, ML-DSA.** The release notes published October 20, 2026 document ML-DSA support through the Java security provider for ML-DSA-44, ML-DSA-65 and ML-DSA-87. Java shops can test post-quantum signatures without a custom provider.\n- **NEAR mainnet, ML-DSA-65.** NEAR’s version 2.13 mainnet upgrade, deployed in July 2026, added ML-DSA-65 alongside existing signing schemes, and Fireblocks published a walkthrough of rotating a live account to the new key type. A blockchain account makes a useful stress test, because every signature is stored and replayed by many nodes.\n- **Codebat, ML-DSA hardware.** Codebat reported that its ML-DSA hardware engine received NIST CAVP validation under certificate A8288, covering ML-DSA-44, ML-DSA-65 and ML-DSA-87, on April 23, 2026. The certificate validates an implementation. It does not change FIPS 204.\n- **Google Cloud KMS, SLH-DSA.** One industry reference, dated October 2026, reports that Google Cloud KMS made SLH-DSA-SHA2-128s generally available, in pure and pre-hash forms beside ML-DSA variants. That is a single-source claim, so confirm it against Google’s own documentation before relying on it.\n- **Federal identity credentials.** IR 8547 uses Personal Identity Verification as its example of slow-moving trust infrastructure. PIV relies on PKI-based credentials whose issuance systems, smart cards, readers, middleware and supporting PKI all need updating, and deployed credentials follow multi-year replacement cycles. The report says standards, modules and infrastructure updates must start early for PIV to meet the federal deadlines.\n\nThe pattern is consistent. Key encapsulation and cloud key services lead, signature support arrives first in libraries, runtimes and blockchains, and hardware and identity systems trail. That order tracks the urgency NIST assigns, with harvest-now-decrypt-later exposure pulling key exchange forward.\n\n## Migration Cost Table: What the Swap Actually Costs\n\nNo official price exists for ML-KEM, ML-DSA, SLH-DSA or IR 8547. They are public standards, not licensed products, and no reviewed source lists a dollar figure for the algorithms or for AWS’s ML-KEM support. The real bill arrives in engineering time, hardware refresh and bandwidth, so the table prices the work in the units NIST’s own report uses.\n\n| Cost line | Where it lands | What IR 8547 says | \n|---|---|---|\n| Standards and specifications | Free to read and implement | FIPS 203, 204 and 205 are final since August 13, 2024 | \n| Cryptographic inventory | Staff time, scanning tools | Start with inventories, migration planning and early deployments | \n| Library and runtime upgrades | Engineering and regression testing | Libraries must add algorithms, optimize them and harden against side channels | \n| HSM and TPM refresh | Capital spend, long lead times | Hardware needs upgrades or redesign, vendors should begin immediately | \n| PKI and certificate authority changes | CA operations, relying-party testing | CAs must issue and sign with post-quantum algorithms, possibly hybrids | \n| Extra bytes on the wire | Bandwidth, handshake size, storage | Larger sizes may force protocol changes, see the sizes table above | \n| Hybrid operation | CPU, complexity, extra security review | More conservative, but demands more computational resources | \n| Module validation | Waiting on CMVP queues | NIST is revising CMVP to speed validation of post-quantum modules | \n| Replacing unmigratable systems | Capital spend, downtime | Identify and prioritize for replacement or decommissioning | \n\nThe costliest rows are the ones with long procurement cycles. A library upgrade ships in a sprint. A smart-card or HSM refresh is a budget year. IR 8547 stresses that the ability to upgrade often depends on when vendors update their products and whether those products interoperate, which makes the vendor questionnaire a first-class migration task.\n\n## Use-Case Recommendations: Which Algorithm for Which Job\n\nThe standards map cleanly onto jobs once the protocol layers are separated. The table gives a default choice per use case, and the paragraphs below explain the reasoning behind the less obvious rows.\n\n| Use case | Default pick | Why | Urgency | \n|---|---|---|---|\n| TLS and web key exchange | ML-KEM-768, hybrid with a classical curve at first | Harvest-now-decrypt-later exposure, TLS 1.3 is the near-term path | Highest | \n| VPN and IKE tunnels | ML-KEM-768 in a hybrid construction | Interactive protocols are prime targets for traffic collection | Highest | \n| Long-lived archives and medical records | ML-KEM-1024 for key wrapping | Data must stay secret longer than the migration takes | Highest | \n| Code and firmware signing | ML-DSA, or LMS and XMSS where state is controlled, or SLH-DSA for roots | Devices that cannot update must demand quantum-resistant signatures | High | \n| Web PKI and certificate chains | ML-DSA, with SLH-DSA kept to rare roots | Signature and key bytes multiply across a chain | Medium | \n| Email and document signing | ML-DSA | Wide use of RSA and ECDSA today, S/MIME and OpenPGP encryption also face collection risk | Medium | \n| Government identity credentials | ML-DSA and ML-KEM per PIV updates | Multi-year card issuance and reader replacement cycles | High | \n\n**Tunnels first.** VPN traffic is the clearest collection target. Teams that run WireGuard or IPsec should look at [how post-quantum WireGuard differs from the classical version](https://shattered.io/post-quantum-wireguard-vs-classical-wireguard-2026/), because the key-size jump is the main operational change and it affects handshake packets directly.\n\n**Code signing is a two-algorithm decision.** ML-DSA is the general choice. Stateful LMS or XMSS suit a firmware pipeline with one tightly controlled signing system, since NIST says they are for applications like software and firmware signing. SLH-DSA fits the root-of-trust slot where signatures are rare and size matters less than the conservative hash-only assumption. Whichever you pick, bake the verifier into the device early. IR 8547 warns that some devices cannot have their verification code updated after manufacture.\n\n**Authentication can wait a little longer than encryption.** Because forged signatures cannot be applied retroactively, a login or machine-authentication flow can keep quantum-vulnerable algorithms until a capable quantum computer is near, though NIST says it will need an immediate switch at that point. That deferral argument is thin for any system with a multi-year hardware refresh, since the switch cannot be immediate if tokens and PKI have to be replaced first.\n\n**Email gets both problems.** S/MIME and OpenPGP signatures behave like the other signature cases, while encrypted messages face the same collection risk as network traffic. A mailbox archive encrypted with RSA today is exactly the kind of record the harvest-now-decrypt-later warning describes.\n\n## Migration Guide: Seven Steps in Priority Order\n\nThe sequence below follows the order NIST implies: inventory, prioritize by data lifetime, move key establishment, then signatures, then the infrastructure underneath. The [cryptography coverage hub](https://shattered.io/category/cryptography/) collects deeper dives on each algorithm family mentioned along the way.\n\n**Step 1: Inventory every use of public-key cryptography.** Find where RSA, ECDSA, EdDSA, DH and ECDH appear in code, configuration, certificates and vendor products. Certificates are the quickest place to start, and a shell loop can pull the algorithms out of a directory of PEM files.\n\n```\nfor f in /etc/ssl/certs/*.pem; do\n  echo \"$f\"\n  openssl x509 -in \"$f\" -noout -text | grep -E \"Signature Algorithm|Public Key Algorithm\" | sort -u\ndone\n\ngrep -RIn -E \"RSA|ECDSA|ECDH|secp256r1|prime256v1|Ed25519\" /etc /opt --include=*.conf --include=*.cnf 2>/dev/null\n```\n\n**Step 2: Rank systems by data lifetime.** Apply Mosca’s inequality per system. Anything where the years the data must stay secret plus the years to migrate exceed your estimate for a capable quantum computer goes to the front. Federal contractors should also tag systems that count as high value assets or high impact systems, since the 2030 and 2031 dates bind them.\n\n**Step 3: Add ML-KEM key establishment first.** Start with TLS and VPN endpoints, using ML-KEM-768 unless a constraint pushes you to 512 or 1024. Keep a classical component beside it while the ecosystem matures, and treat the hybrid as temporary. Plan for the extra exchange data at ML-KEM-768 before you size packet buffers.\n\n**Step 4: Update protocol and library baselines.** Move agency-facing services to TLS 1.3 ahead of the January 2, 2030 requirement, and check that your cryptographic libraries ship FIPS 203, 204 and 205 implementations. Watch for the SP 800-52 revision that will describe post-quantum key establishment in TLS.\n\n**Step 5: Replace signatures by risk tier.** Begin with code signing and firmware verification where devices cannot be patched, then PKI roots, then user-facing certificates and documents. Choose ML-DSA-65 as a balanced default, ML-DSA-44 only after confirming your entropy source, and reserve SLH-DSA for low-volume, high-assurance roots.\n\n**Step 6: Press vendors on hardware and validation.** Ask every HSM, TPM, smart-card and appliance vendor for dated post-quantum support commitments, and ask whether the modules are on a CMVP validation path. NIST says systems that cannot support post-quantum cryptography should be prioritized for replacement or decommissioning.\n\n**Step 7: Build in agility and retire the weak symmetric uses.** Make algorithm identifiers configurable so the next swap, whether to HQC or FN-DSA, is a policy change. Retire SHA-1 and any 112-bit symmetric standard before 2030, since both dates land in the same year as the first deprecations.\n\n## Pros, Cons and Verdict\n\nThe case for moving now rests on what the schedule fixes and what it leaves open. The three standards are final, the dates are written down, and the federal deadlines are earlier than the NIST-wide ones. The case against rushing rests on size costs, immature hardware and algorithms still in the pipeline.\n\n- **Pro:** The standards are final. ML-KEM, ML-DSA and SLH-DSA have been published since August 13, 2024.\n- **Pro:** The dates are explicit. Deprecated after 2030, disallowed after 2035, with federal key establishment due December 31, 2030 and signatures due December 31, 2031.\n- **Pro:** Symmetric cryptography stays. AES, SHA-2, SHA-3 and Ascon need no replacement because of quantum computers, so the migration touches only the public-key layer.\n- **Pro:** NIST allows hybrids and validates them. A composite key exchange can be FIPS 140-validated when one input comes from an approved scheme.\n- **Con:** Bytes grow. One ML-KEM-768 exchange adds extra bytes to every handshake, and the smallest SLH-DSA signature is about 3.2 times the smallest ML-DSA signature.\n- **Con:** ML-KEM has no approved sibling yet. HQC is selected but its FIPS is still in development, so every deployment bets on one lattice family for now.\n- **Con:** Hardware lags. HSMs, TPMs and smart cards need redesign cycles that outlast the software work.\n- **Con:** Hybrids add complexity. NIST itself expects them to be temporary and warns they can increase risk and cost.\n\n### The Verdict\n\nMove key establishment first, signatures second, and treat 2030 as the real deadline instead of 2035. The data supports a clear ranking. ML-KEM-768 is the one algorithm every team should deploy now, because it is NIST’s recommended default, it addresses the only attack that already works against recorded traffic, and its byte penalty is modest next to the signature options. ML-DSA is the default signature, with ML-DSA-65 at category 3 pairing naturally with ML-KEM-768. SLH-DSA earns a place only where its 32 to 64 byte public keys and hash-only security basis justify signatures of 7,856 to 49,856 bytes.\n\nRSA, ECDSA, EdDSA, DH and ECDH are not broken today, and IR 8547 says so by leaving them usable through the deprecation window. But the report also removes the argument for waiting. A system that protects data for more than a few years, runs on hardware with a long refresh cycle, or sells to the federal government should have a funded plan by the end of this year. Teams outside those groups still gain by finishing the inventory in the next quarter, because the inventory is the step every later estimate depends on.\n\n## Frequently Asked Questions\n\n**Is NIST IR 8547 a draft or a final report?**\n\nIt is final. NIST published Transition to Post-Quantum Cryptography Standards on October 27, 2026, and the publication page was updated on October 28. Some secondary articles still call it an initial public draft, which describes the version that circulated from November 12, 2024.\n\n**Does RSA stop working in 2031?**\n\nNo. RSA, ECDSA, EdDSA, DH and ECDH become deprecated after 2030, which means data owners must assess the risk and decide whether to keep using them. Disallowance under NIST standards and guidelines begins after 2035. Federal high value assets and high impact systems face earlier deadlines of December 31, 2030 for key establishment and December 31, 2031 for signatures.\n\n**Which ML-KEM parameter set should I use?**\n\nNIST recommends ML-KEM-768 as the default because it offers a large security margin at a reasonable performance cost. Use ML-KEM-512 only when bytes are tight and ML-KEM-1024 when you need the highest security category for long-lived data.\n\n**When should I choose SLH-DSA over ML-DSA?**\n\nChoose SLH-DSA when you value a security assumption that rests only on hash functions and can tolerate large signatures, such as root-of-trust or firmware signing that happens rarely. Its signatures run from 7,856 to 49,856 bytes, against 2,420 to 4,627 bytes for ML-DSA. For high-volume signing, ML-DSA is the practical default.\n\n**Do AES and SHA-256 need to be replaced?**\n\nNo. IR 8547 says NIST does not expect to transition away from its symmetric standards as part of the post-quantum migration. The exceptions are standards at the 112-bit security level, which are disallowed in 2030, and SHA-1, which is deprecated and will be disallowed in FIPS-validated modules after 2030.\n\n**Do I have to use a hybrid of classical and post-quantum algorithms?**\n\nNo. NIST accommodates hybrids and lets each application decide whether the extra complexity and compute cost is worth it. It expects hybrids to be temporary, with a later move to pure post-quantum algorithms.\n\n**What about HQC and FN-DSA?**\n\nBoth are in development and not yet final standards. NIST selected HQC as an alternative to ML-KEM and is drafting a FIPS for it, and it is developing a FIPS for a FALCON-derived signature algorithm. Until those publish, ML-KEM, ML-DSA and SLH-DSA are the approved post-quantum choices.", "url": "https://wpnews.pro/news/nist-ir-8547-rsa-ecdsa-disallowed-after-2035-2026", "canonical_source": "https://shattered.io/nist-ir-8547-rsa-ecdsa-disallowed-after-2035-pqc-replacements-2026/", "published_at": "2026-10-28 12:31:53+00:00", "updated_at": "2026-10-28 12:43:02.298890+00:00", "lang": "en", "topics": ["ai-policy"], "entities": ["NIST", "NIST IR 8547", "Dustin Moody", "Ray Perlner", "Angela Robinson", "Andrew Regenscheid", "David Cooper", "ML-KEM"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/nist-ir-8547-rsa-ecdsa-disallowed-after-2035-2026", "markdown": "https://wpnews.pro/news/nist-ir-8547-rsa-ecdsa-disallowed-after-2035-2026.md", "text": "https://wpnews.pro/news/nist-ir-8547-rsa-ecdsa-disallowed-after-2035-2026.txt", "jsonld": "https://wpnews.pro/news/nist-ir-8547-rsa-ecdsa-disallowed-after-2035-2026.jsonld"}}