RSA 4096 vs 2048 vs 3072: All Deprecated After 2030 [2026]

NIST's final post-quantum transition report, published October 27, 2026, deprecates RSA at every approved key size after 2030 and disallows it after 2035, according to reporting on the final text. The policy applies equally to RSA-2048, RSA-3072 and RSA-4096, so a larger modulus adds classical factoring margin but does not extend the quantum deadline. An October 20, 2026 comparison on ECDSA.com recommends RSA-3072 as the default for new keys, reserving RSA-4096 for rarely used long-lived keys such as root certificate authority or offline signing keys, while existing 2048-bit keys should get a rotation date.

NIST published its final post-quantum transition report on October 27, 2026, and reporting on the final text https://postquantum.com/security-pqc/nist-ir-8547-final/ says RSA is deprecated after 2030 and disallowed after 2035 at every approved strength. That single detail rewrites the old RSA 4096 vs 2048 argument. A 4,096-bit modulus buys classical safety margin and costs real CPU time, yet it does nothing about the quantum deadline that now applies to all three common sizes. Engineers still choose between RSA-2048, RSA-3072 and RSA-4096 every week, for SSH keys, certificate authorities, code signing and hardware modules. The short version: 3072 is the sensible default for new keys, 4096 earns its price only on rarely used long-lived keys, and 2048 is a legacy size on a countdown. Every one of them eventually gives way to the post-quantum encryption standards that replace RSA https://shattered.io/rsa-vs-ml-kem-post-quantum-encryption-2026/ , which NIST finalized in August 2024. A recurring theme runs through every comparison below. Key length is a dial that moves classical security a few notches, while the quantum timeline is a cliff that no setting on that dial can avoid. Don't miss new tech stories on Google Add Shattered once in the Google app and our stories show up in your news suggestions. Add now https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F Short Answer: Which RSA Key Size to Pick in 2026 One technical comparison dated October 20, 2026 on ECDSA.com https://ecdsa.com/compare/rsa-2048-vs-rsa-4096 recommends RSA-3072 as the default for new RSA keys. The reasoning is simple. RSA-3072 reaches the 128-bit security level, and it signs for far less CPU than RSA-4096. The same page reserves RSA-4096 for long-lived keys that rarely sign, such as a root certificate authority key or an offline signing key. That matches how most security teams already operate, and it matches where government guidance has been heading through 2026. RSA-2048 is not broken. Against classical computers it stays acceptable when paired with modern padding and sound key management. It maps to roughly 112 bits of security, though, and that is the level the transition policy treats as the first to leave service. New long-lived deployments should not start on it. Existing 2048-bit deployments should get a rotation date, not an emergency. The decision comes down to four rules: - New general-purpose RSA key: choose 3072 bits. - Root CA, offline signing key, or a key that signs a few times a year: 4096 bits is defensible, because the extra signing cost is paid rarely. - Existing 2048-bit keys that protect short-lived data: keep them, schedule rotation, and avoid issuing new long-lived certificates on them. - Anything that must stay trustworthy beyond 2030: plan a post-quantum or hybrid design instead of a larger RSA modulus. That last rule is the one people resist. A bigger key feels like progress, and for classical attackers it is. For a future quantum attacker running Shor’s algorithm, a 4,096-bit modulus falls to the same method as a 2,048-bit one. Elliptic curves share that fate, which is why the ECC versus RSA https://shattered.io/ecc-vs-rsa-2026/ choice matters less than the choice to start migrating. How RSA Key Size Works: Modulus, Padding and Why Length Matters An RSA key pair is built around a modulus, the product of two large secret primes. The public key contains the modulus and a small exponent. The private key contains what an attacker would need to undo the multiplication. Security rests on the difficulty of factoring the modulus back into its primes, and the number people quote as the key size is the bit length of that modulus. A 3,072-bit key therefore means a 3,072-bit modulus built from two primes of about half that length. The key size controls two things at once. It sets how hard factoring is for an attacker, and it sets how much arithmetic the owner must do on every private-key operation. Both costs grow with length, but they grow at different rates. Attack cost rises quickly at first and then flattens, which is why the mapping from key size to security strength looks uneven. Owner cost keeps climbing, since multiplying bigger numbers takes more work. That mismatch is the entire reason the 3072-bit size exists as a sweet spot. Padding matters as much as length. Raw RSA is never used directly. Encryption uses a padding scheme such as OAEP, and signatures use a scheme such as PSS, both described in the PKCS 1 family of standards that RFC 8017 captures. A weak padding choice can undermine a 4,096-bit key faster than a factoring attack could ever threaten a 2,048-bit key. Teams that spend a week debating key length and ten minutes on padding have their priorities reversed. Randomness matters too. The two primes must come from a trustworthy random source, and a flawed generator can produce keys that share primes with other keys or follow guessable patterns. No key length repairs that. Hardware modules and well-maintained libraries exist partly to remove this class of mistake, and they should handle key generation for any key that protects something valuable. Finally, RSA appears in several different roles that tend to get blurred. It signs data, it authenticates certificates, and in older designs it transports session keys. Policy often treats these separately. In modern TLS, RSA mostly survives as an authentication and certificate-signature technology, and the key agreement step has moved to ephemeral methods. The comparison of RSA key exchange and ECDHE https://shattered.io/rsa-key-exchange-vs-ecdhe-2026/ covers that shift. For the key size debate, the practical point is that most 2026 decisions concern signing keys and certificates. RSA-2048 vs RSA-3072 vs RSA-4096: Specs Compared The table collects the parameters that decide which size fits a given system. Byte sizes follow directly from the bit lengths, because an RSA modulus and a PKCS 1 signature occupy the same number of bytes, so 2,048 bits is 256 bytes. Strength figures use the NIST equivalence mapping as cited in October 2026 reporting. | Attribute | RSA-2048 | RSA-3072 | RSA-4096 | |---|---|---|---| | Modulus length | 2,048 bits | 3,072 bits | 4,096 bits | | Modulus / signature size | 256 bytes | 384 bytes | 512 bytes | | Classical security strength | About 112 bits | About 128 bits | Above 128, below the 192-bit level of RSA-7680 | | Separate NIST strength row | Yes | Yes | No exact row in the cited table | | Quantum resistance | None Shor’s algorithm | None Shor’s algorithm | None Shor’s algorithm | | NIST IR 8547 schedule | Deprecated after 2030, disallowed after 2035 | Deprecated after 2030, disallowed after 2035 | Deprecated after 2030, disallowed after 2035 | | Relative key generation cost | Lowest | Middle | Highest | | Relative signing cost | Baseline | Slower than 2048, faster than 4096 | Roughly six times the 2048 baseline in one comparison | | Relative verification cost | Lowest | Middle | Highest | | Typical role | Legacy and short-lived keys | Default for new keys | Root CA and long-lived offline keys | | Listed as supported size in current documentation | Yes | Yes | Yes | | Standard | PKCS 1 v2.2 / RFC 8017 | PKCS 1 v2.2 / RFC 8017 | PKCS 1 v2.2 / RFC 8017 | | Product or list price | None, an algorithm parameter | None, an algorithm parameter | None, an algorithm parameter | Two rows deserve a second look. First, RSA-4096 has no separate row in the NIST equivalence table, so any article that claims it delivers exactly 152, 160 or 192 bits is extrapolating. One October 2026 source places it near 152 bits and flags that figure as an extrapolation, not a tabulated NIST value. Second, the cost rows reflect how RSA works. Public-key operations use a short exponent and stay cheap, while private-key operations such as signing and decryption scale much faster with modulus length. The last two rows matter more than they look. Because every size is a parameter of one standardized algorithm, none has a vendor, a license fee or a release schedule. Newer is not a property that applies here. What changes over time is policy: which sizes regulators accept, for how long, and for which purpose. Security Strength: What 112, 128 and Beyond Really Mean Security strength expresses how much work the best known classical attack needs, measured as the equivalent of brute-forcing a symmetric key. A 112-bit level means an attacker needs on the order of two to the power of 112 operations. No one has that compute budget, which is why RSA-2048 remains unbroken in practice. The mapping also explains why the size ladder looks odd. Doubling the modulus does not double the strength, because factoring algorithms scale sub-exponentially with modulus size. RSA-3072 corresponds to about 128 bits, which lines up with AES-128. That alignment is the engineering argument for 3072. If a system encrypts bulk data with a 128-bit or 256-bit symmetric cipher, the asymmetric layer protecting the session key should not be the weakest link. The gap is wider than many teams expect, and the AES-256 versus RSA comparison https://shattered.io/aes-256-vs-rsa-2026/ shows how far a 256-bit symmetric key outruns even large RSA moduli. RSA-4096 sits above 128 bits and below the 192-bit level that NIST associates with RSA-7680. That puts it in an awkward middle. It costs a lot more than 3072 to sign with, yet it does not reach the next named tier. For a root key that must outlast a decade of classical advances, the extra margin is cheap insurance. For a busy API signer, it is a recurring tax with no matching compliance benefit. NIST’s key management guidance is the reference behind these mappings. The newest publicly identifiable item in SP 800-57 Part 1 is Revision 6, which is still an initial public draft https://csrc.nist.gov/pubs/sp/800/57/pt1/r6/ipd , and its comment period has closed. The draft proposes coverage of Ascon and of the post-quantum standards in FIPS 203, FIPS 204 and FIPS 205. It also proposes replacing hard algorithm approval time frames with references to SP 800-131A. As of October 31, 2026, no final Revision 6 has been identified, so the draft should not be treated as final guidance. Strength numbers carry one more caveat. They describe resistance to factoring attacks on the modulus, and they assume correct implementation. In practice, most real RSA failures come from bad padding, weak random number generators, poor key storage or protocol misuse. A well-handled 2048-bit key beats a sloppy 4096-bit key on every realistic threat model, and that fact should anchor any discussion about spending effort on key length. Speed Benchmarks: Signing and Verification Compared Speed is where RSA-4096 pays for its extra margin. The table lists the dated speed and strength claims available in October 2026, with each source and its limits. No single lab dataset covers all three sizes on one machine, so the rows are best read together and not ranked against each other. | Source and date | What it reports | Limit | |---|---|---| | Developer benchmark of OpenSSL 4.1.0, October 23, 2026 | RSA-2048 at about 33,782 and 2,111 operations per second across its signing and verification tests | One test machine, RSA-3072 not reported | | ECDSA.com comparison, October 20, 2026 | RSA-4096 costs roughly six times more to sign than RSA-2048 | Hardware and method not stated, so not universal | | MojoAuth guide, September 28, 2026 | RSA-2048 is faster and smaller than 3072 or 4096, and 4096 signs slowest | Qualitative only | | Lamarr Labs field guide | RSA-4096 sits between the 128-bit RSA-3072 level and the 192-bit RSA-7680 level | Strength mapping, not a speed test | The developer write-up on building OpenSSL 4.1.0 and measuring it https://dev.to/frankchu/openssl-410-shipped-today-i-built-it-and-measured-ml-kem-ml-dsa-and-dtls-13-4d24 is the freshest hard number set. Other comparisons agree that RSA-4096 costs more than RSA-2048 in generation, signing and verification, with one putting the signing cost at roughly six times. Those ratios raise a puzzle. RSA verification with a small public exponent normally runs far faster than signing, yet the post’s verification figures are lower than its signing figures. One reading is that the two column labels are reversed. If they are, the signing ratio lands near 6.1, which matches the ECDSA.com claim of roughly six times. That is a hypothesis, not a finding, and the practical lesson is to measure on your own hardware before committing. The command is short: openssl speed rsa2048 rsa3072 rsa4096 Run it on the machine that will do the work, a production-class server or a representative device, and read the sign and verify columns carefully. Compare signs per second for services that issue signatures and verifies per second for services that mostly check them. A certificate authority and a package manager sit on opposite sides of that split. The CA signs few objects, so a heavy signing cost hardly matters. The package manager verifies on every install, so verification speed and certificate size dominate. Why 3072 usually beats 4096 on real workloads Private-key operations dominate the bill, and they scale steeply with modulus length. Moving from 2048 to 3072 increases the cost, and moving on to 4096 increases it again. At a few signatures per second the difference vanishes into the noise. At thousands per second, as on a busy TLS terminator that signs handshakes, it shows up on the CPU graph and the cloud invoice. That is the argument behind 3072 as the default, and it is why a modulus larger than 3072 is a deliberate choice, not a free upgrade. Teams that want a very different speed profile should look outside RSA entirely. The Ed25519 versus RSA comparison https://shattered.io/ed25519-vs-rsa/ covers a signature scheme that signs quickly and keeps keys small, though elliptic-curve signatures are also quantum-vulnerable and need their own migration plan. Key, Signature and Certificate Sizes on the Wire Wire size is the quiet cost of larger keys. Every RSA signature is exactly as long as the modulus, so a handshake that carries one signature adds 256 bytes at 2048 bits, 384 bytes at 3072 bits and 512 bytes at 4096 bits. A certificate also embeds the public key, which means a chain of three certificates carries three public keys and several signatures. Move a whole chain from 2048 to 4096 and the total grows by well over a kilobyte. A kilobyte hardly matters on a fiber link. It matters on constrained paths, such as embedded devices on slow radio links, firmware update channels, protocols with small packet budgets, and mail systems with strict field limits. DKIM public keys published in DNS records illustrate the point, because a longer modulus makes a longer record and strains record-size limits. Larger keys tend to fail in boring, practical ways like that, long before anyone measures cryptographic strength. | Item per handshake or object | RSA-2048 | RSA-3072 | RSA-4096 | |---|---|---|---| | One signature | 256 bytes | 384 bytes | 512 bytes | | Public modulus in a certificate | 256 bytes | 384 bytes | 512 bytes | | Signature plus modulus one certificate | 512 bytes | 768 bytes | 1,024 bytes | | Three-certificate chain, all same size signatures plus moduli | Not listed | Not listed | 3,072 bytes | | Growth versus RSA-2048 | Baseline | 1.5 times | 2 times | The figures in the table are straight arithmetic on the bit lengths and ignore certificate extensions, names and encoding overhead, so real chains run larger. The ratios hold, though. RSA-4096 doubles the cryptographic payload of RSA-2048, and RSA-3072 adds half again. Post-quantum signatures change this picture in a way worth keeping in mind. ML-DSA signatures run considerably larger than even RSA-4096 ones, so the wire-size debate between RSA sizes is small next to the jump coming with the replacements. The RSA versus ML-DSA signature comparison https://shattered.io/rsa-vs-ml-dsa-signatures-2026/ lays out those byte counts in detail. A team that already struggles with a 512-byte signature will feel the migration far more than a team that has headroom today. Hardware, HSM and Protocol Limits Key size choices rarely live in a vacuum. Hardware security modules, smart cards, management controllers and network gear each set their own ceiling and floor. A key that the policy prefers but the device cannot generate is worthless, so the supported range often decides the answer before security analysis begins. Current vendor documentation reflects a stable middle. Public listings of supported RSA sizes name 2048, 3072 and 4096 bits as the common set. HPE’s iLO 7 documentation reportedly accepts keys from 2048 through 4096 bits, and DigiCert’s Private CA documentation reportedly supports certificate keys at all three sizes while blocking anything under 2048 bits. Cloud key-management templates and network products follow the same pattern. The practical reading is that a team can adopt 3072 almost anywhere that already supports 4096, and most places that support 2048. Throughput is the other hardware limit. An HSM has a fixed budget of private-key operations per second. Raising key size lowers that budget, so a module that comfortably handles a given signing load at 2048 bits may need a second unit at 4096 bits. Measure the module itself, since vendor numbers vary by model and firmware, and size the cluster for peak load plus failover. Protocol limits matter in less obvious places. Mail authentication records, embedded bootloaders, smart card applets and legacy appliances often hardcode maximum key lengths. The reverse also happens: some tools reject anything below 3072 bits, which is the direction GitHub reportedly moved for new SSH keys in October 2026. An inventory that records the minimum and maximum each component accepts prevents a rotation from stalling halfway through. Software libraries add a final wrinkle. OpenSSL 4.1.0 arrived in late October 2026 as the latest release, and older branches remain in service in many environments. Defaults, provider behavior and policy settings differ across versions, so a key size that works in a test container may fail in a locked-down production image. Treat compatibility testing as part of the key size decision. The Quantum Problem: Why a Bigger Modulus Does Not Help Shor’s algorithm factors integers in polynomial time on a sufficiently capable quantum computer. The security of RSA rests on factoring being hard, so a machine that runs Shor’s algorithm at scale breaks every RSA key size by the same method. A larger modulus raises the number of qubits and the runtime that the attack needs, yet it never changes the class of the problem. That is why the sources in this period say the same thing in different words: none of RSA-2048, RSA-3072 or RSA-4096 is a post-quantum solution. No practical quantum computer can factor RSA-2048 today. The hardware needed for the attack does not exist. Resource estimates keep moving, though. On October 29, 2026, a report attributed to the company Alice & Bob claimed that breaking RSA-2048 could require about 22,593 physical cat qubits and roughly 3.14 days on a specified fault-tolerant system. That is a company estimate, not a demonstrated break, and it comes from a single report. It still shows the direction of travel, because falling qubit estimates pull the planning horizon closer. Harvest now, decrypt later changes the clock The risk is not only a future attack on future traffic. Adversaries can record encrypted sessions today and decrypt them once a capable machine exists. For confidentiality, that makes the relevant deadline the date the data stops mattering, not the date the quantum computer arrives. A document that must stay secret for twenty years needs post-quantum protection now, no matter which RSA size protected its key. Signatures face a different version of the problem. A forged signature is only useful if the verifier still trusts the key at the time of the forgery. A short-lived TLS certificate expires long before a quantum attack matters. A firmware signing key baked into devices that stay in the field until the late 2030s does not. Long-lived signing roots therefore get the earliest attention in most migration plans. NIST finalized its destination technologies on August 13, 2024 as FIPS 203 for key encapsulation ML-KEM , FIPS 204 for lattice signatures ML-DSA and FIPS 205 for hash-based signatures SLH-DSA . The IR 8547 roadmap points RSA users at those standards. Stepping up from RSA-2048 to RSA-4096 only postpones the same migration, and it makes each remaining operation costlier. The earlier draft-versus-final analysis of IR 8547 https://shattered.io/nist-ir-8547-final-vs-draft-post-quantum-cryptography-2026/ explains how the final text broadened the affected algorithms. NIST IR 8547: The 2030, 2031 and 2035 Deadlines The final report, titled Transition to Post-Quantum Cryptography Standards, appeared on October 27, 2026. Its authors are Dustin Moody, Ray Perlner, Angela Robinson, Andrew Regenscheid and David Cooper. The initial public draft dated from November 12, 2024, and the final version replaced it. According to reporting on the final text, the key change from the draft is breadth. The final report deprecates quantum-vulnerable public-key algorithms at all approved security strengths after 2030, and it disallows them under NIST standards and guidelines after 2035. That puts RSA-3072 and RSA-4096 on the same path as RSA-2048, where the draft had focused on the lower strength. | Date or period | Event | Applies to | |---|---|---| | August 13, 2024 | NIST finalizes FIPS 203, 204 and 205 | ML-KEM, ML-DSA, SLH-DSA | | November 12, 2024 | Initial public draft of IR 8547 | Quantum-vulnerable public-key algorithms | | Not listed | SP 800-57 Part 1 Rev. 6 initial public draft | Key management guidance | | October 27, 2026 | Final IR 8547 published | All approved RSA strengths | | After 2030 | Deprecation of quantum-vulnerable algorithms | RSA-2048, RSA-3072, RSA-4096 | | After 2035 | Disallowed under NIST standards and guidelines | RSA-2048, RSA-3072, RSA-4096 | Federal programs add their own targets. NIST’s accompanying announcement says National Security Memorandum 10 sets 2035 as the main target for completing migration across federal systems. It adds that Executive Order 14412 sets targets of 2030 for key establishment and 2031 for digital signatures on high-value and high-impact systems. Secondary reporting gives the matching calendar dates of December 31, 2030 and December 31, 2031, and it advises readers to confirm both against the full official PDF because the public summaries do not state them. The report also supports implementation of OMB Memorandum M-26-15. A deprecated algorithm is not a banned one. Deprecation signals that new designs should avoid it and that auditors may ask for a plan. Disallowance is the point where compliance regimes built on NIST guidance stop accepting it. Between 2030 and 2035, an RSA-3072 deployment will remain legal and increasingly awkward, and a procurement office will likely ask when it plans to move. The earlier piece on why RSA and ECDSA face disallowance after 2035 https://shattered.io/nist-ir-8547-rsa-ecdsa-disallowed-after-2035-pqc-replacements-2026/ traces the replacement mapping. Practitioners should also read what the report does not do. It does not name a new RSA size, and it does not turn RSA-4096 into a quantum-safe choice. The decisive point for this comparison is that the question of which RSA size is fastest or strongest today now matters less than the question of how long each key needs to live. Pricing and Cost: What Each RSA Key Size Really Costs RSA key sizes carry no list price. They are parameters of an open standard, specified in PKCS 1 v2.2 and RFC 8017, and OpenSSL is open-source software. The real cost shows up in compute, hardware, operations and migration. The table translates each of those into relative terms, because no source supplies dollar figures for the sizes themselves. | Cost dimension | RSA-2048 | RSA-3072 | RSA-4096 | |---|---|---|---| | License or list price | None | None | None | | Key generation compute | Lowest | Middle | Highest | | Signing compute | Baseline | Moderate increase | Roughly six times baseline in one comparison | | Bandwidth per signature | 256 bytes | 384 bytes | 512 bytes | | Hardware security module headroom | Highest throughput | Lower throughput | Lowest throughput | | Compliance exposure | Highest, 112-bit level | Lower today, same 2030 and 2035 dates | Lower today, same 2030 and 2035 dates | | Migration effort to post-quantum | Required | Required | Required | The compute line scales into money at volume. A fleet that signs millions of objects a day pays for the extra CPU in cloud instances or in hardware module capacity. A fleet that signs a handful of root-level objects a year pays nothing noticeable. The correct way to compare costs is to multiply operations per second by the relative cost, then check whether the product changes the instance count. A naming trap deserves its own warning. Searches for RSA pricing often land on pages from RSA, the identity-security company, which is unrelated to the cryptographic algorithm. That company’s current portfolio includes RSA Agent ID, RSA ID Plus, RSA Governance & Lifecycle, SecurID and RSA iShield Key 2. Its official pages say RSA Agent ID Discover and Secure will be generally available on November 16, 2026, and Govern in the first half of 2027. Event material reportedly lists ID Plus tiers from $3 per user per month, but those are subscription prices for an identity product and say nothing about key sizes. No source found for this period confirms an RSA-branded implementation of any key-size feature discussed here. Migration is the cost that dwarfs all the others. Inventory, rotation, testing and reissuing certificates take staff time regardless of the size chosen. Teams that pick 3072 now and plan a post-quantum move pay once for the rotation and once for the migration. Teams that pick 4096 pay the same two migration costs plus a permanent compute surcharge on every operation in between. Real-World Examples: Who Requires Which Key Size Standards documents tell one story and operating policies tell another. Six 2026 cases show where the three sizes sit in practice. Each rests on a vendor page or a secondary report, so the wording below stays hedged where the evidence is a single source. 1. GitHub SSH keys: 3072 becomes the floor On October 14, 2026, GitHub reportedly began requiring newly uploaded RSA SSH keys to be at least 3,072 bits, covering both authentication and signing keys, according to Breachroad’s write-up https://breachroad.com/en/blog/github-ssh-rsa-3072-brownout-2026/ . Existing keys remained valid for the time being. GitHub also enabled the hybrid post-quantum key exchange method mlkem768x25519-sha256 on October 14, which is separate from the RSA floor: RSA still authenticates, while the hybrid method protects the session key exchange. A developer with an old 2048-bit key should generate a new one soon. 2. Australia’s guidelines: 2048 minimum, 3072 preferred, 2030 limit The September 2026 edition of Australia’s Information Security Manual, per reporting dated September 7, recommends RSA moduli of at least 2048 bits and preferably 3072 bits for signatures and key transport. It also says RSA will not be approved beyond 2030 because of projected quantum-computing risk. That is a stricter timeline than the NIST disallowance date, and it shows why multinational teams plan to the earliest deadline among the regimes that apply to them. 3. HPE iLO 7: a 3072-bit minimum in CNSA mode HPE’s iLO 7 documentation reportedly permits RSA keys from 2048 through 4096 bits. It sets 3072 bits as the minimum in CNSA mode and 2048 bits as the minimum in FIPS and Secure Standard modes. A server management controller is a good example of a long-lived embedded device, and the mode-dependent floor shows how compliance profiles, not cryptographers, usually pick the size. 4. DigiCert Private CA: all three sizes supported, sub-2048 blocked DigiCert’s Private CA documentation supports RSA-2048, RSA-3072 and RSA-4096 certificate keys and blocks keys smaller than 2048 bits. Private PKI operators therefore have genuine choice across the whole range, and they face the cost trade-offs described above without a vendor forcing the answer. 5. S/MIME and CA keys: 4096 for the roots A secondary report dated September 15, 2026 says newly created root and subordinate CA RSA keys must be at least 4096 bits under current CA/Browser Forum S/MIME requirements, while subscriber certificates kept a 2048-bit minimum at that point. The report itself advises checking the official requirements text before relying on it. If it holds, it formalizes the split recommended elsewhere: large keys on rarely used roots, smaller keys on busy leaf certificates. 6. IETF composite drafts: RSA-4096 paired with ML-KEM-768 An IETF draft on composite ML-KEM for X.509 infrastructure includes variants that pair RSA-4096 with ML-KEM-768. A draft is not a standard, and the pairing does not make RSA a replacement for post-quantum algorithms. It shows the transition design in action. RSA keeps its place beside a post-quantum algorithm, and the post-quantum half carries the quantum risk. Use-Case Recommendations: Seven Scenarios Each recommendation names a size, gives the reason, and states the condition under which the answer flips. 1. New developer SSH or Git signing keys. Use RSA-3072 at minimum, or pick a non-RSA key type if every tool in the chain supports it. Platform floors, like the reported GitHub rule above, already reject smaller new keys. The answer flips to a different algorithm family when the toolchain allows. 2. TLS leaf certificates on public sites. RSA-2048 remains a common subscriber minimum, but RSA-3072 gives a margin for certificates that renew for years under automation. Short certificate lifetimes limit the risk of either size. Flip to larger sizes only when handshake CPU is measured and affordable. 3. Root and intermediate CA keys. RSA-4096 is defensible and, per the S/MIME report above, may be required. These keys sign rarely, live a decade or more, and justify the highest classical margin. Plan the post-quantum root hierarchy in parallel, because a root created now will outlive the 2030 deprecation. 4. Code and firmware signing in long-lived devices. Use RSA-3072 or RSA-4096 only as a bridge. Devices that stay in service past 2030 should carry a path to a post-quantum signature, such as the lattice or hash-based schemes standardized in FIPS 204 and FIPS 205. The bridge decision is about which classical size to ship in the meantime. 5. High-volume API or handshake signing. Stay at RSA-2048 or RSA-3072 and measure. A sixfold signing cost at 4096 bits can force extra servers. If compliance demands more strength, move to a different algorithm instead of a bigger modulus, and read the RSA encryption in Node.js walkthrough https://shattered.io/rsa-encryption-nodejs/ for a worked example of the parameters that matter. 6. Constrained or embedded devices. Keep RSA-2048 where the hardware only handles that size, document an end date, and avoid issuing new certificates with lifetimes beyond the device’s planned replacement. Larger keys hit memory, flash and radio budgets hard. 7. Government and CNSA-aligned systems. Follow the stricter profile. Where a mode sets a 3072-bit floor, as in the HPE example, treat 3072 as the minimum and watch the 2030 and 2031 targets that the executive order sets for high-value systems. One pattern runs through the list. The smaller the number of signatures per key lifetime, the more sense a large key makes. The larger the number of operations, the more a smaller key pays for itself. Quantum risk, in turn, argues for short key lifetimes under any size. Migration Guide: Moving From RSA-2048 Toward 3072 and Post-Quantum A sensible migration happens in two moves. First, retire sub-3072 keys that need to outlive the deprecation window. Second, add post-quantum or hybrid protection where the data or signature lifetime demands it. The eight steps below cover both, and each step can run on its own schedule. Step 1: Inventory every RSA key and certificate. Count what exists before changing anything. For certificates on disk, the public key length appears in the text dump: openssl x509 -in cert.pem -noout -text | grep "Public-Key" ssh-keygen -l -f ~/.ssh/id rsa.pub openssl rsa -in private.pem -noout -text | head -1 Step 2: Classify each key by lifetime and data sensitivity. Sort keys into three bins. Short-lived keys that protect transient traffic can wait. Keys that must stay trusted past 2030 need a plan now. Keys protecting data that must remain confidential for many years need post-quantum key establishment first, because of harvest-now-decrypt-later collection. Step 3: Generate replacement keys at 3072 bits. The commands below create a new RSA key and a matching SSH key. Store private keys in hardware or a managed key service wherever possible. openssl genrsa -out new-key.pem 3072 ssh-keygen -t rsa -b 3072 -f ~/.ssh/id rsa 3072 Step 4: Benchmark on target hardware. Run the speed command shown earlier on a production-class machine and record signs and verifies per second for all three sizes. Compare the result with the peak load the service handles. If 3072 fits with headroom, no further tuning is needed. If it does not, fix capacity or change algorithm instead of dropping back to a weak size. Step 5: Rotate certificates and keys in stages. Start with internal services, where a rollback is cheap, then move to customer-facing endpoints. Keep the old and new keys valid together for an overlap window, and update trust stores and pinning rules before retiring the old key. Check anything that parses key sizes, such as mail gateways and DNS-based key records, since those often hold hidden limits. Step 6: Switch on hybrid post-quantum key exchange where it exists. GitHub’s October 14, 2026 support for mlkem768x25519-sha256 is a live example for SSH. OpenSSL 4.1.0, released in late October 2026, is the newest release line to test against. Verify support in your exact build before assuming a default. The RSA versus Diffie-Hellman comparison https://shattered.io/rsa-vs-diffie-hellman-key-exchange-2026/ helps map which handshake component each change touches. Step 7: Plan post-quantum signatures for long-lived roots and firmware. Pilot ML-DSA FIPS 204 or SLH-DSA FIPS 205 in a non-production hierarchy. Expect larger signatures and certificates, and test every consumer that parses them. Composite approaches that pair a classical and a post-quantum algorithm offer a bridge while trust stores catch up. Step 8: Record the result in a cryptographic inventory. A software bill of materials lists components, while a cryptographic inventory lists algorithms, key sizes and lifetimes. Keep it current. When the next NIST or national deadline moves, the inventory shows what breaks and who owns it, and the audit becomes a query and not a research project. Common Mistakes When Choosing an RSA Key Size Treating 4096 as quantum-safe. This mistake is the most common and the costliest. A larger modulus changes the number of qubits a future attacker needs, not the fact that the attack works. Every source reviewed for this period says the same: RSA-4096 does not solve the post-quantum problem, and the roadmap directs users to new algorithms. Quoting exact strength for 4096. The NIST mapping has no separate row for it. Writing 152 bits or 160 bits as settled fact repeats an extrapolation as a standard. State that it sits between the 128-bit and 192-bit tiers and leave it there. Paying the signing tax everywhere. Teams sometimes standardize on 4096 across the board because it feels safest, then discover that latency and instance counts climbed. Apply the large key where signing volume is low and key life is long. Use 3072 elsewhere. Ignoring padding and randomness. A secure key size cannot rescue a vulnerable padding mode or a flawed random number generator. Use OAEP for encryption and PSS for signatures through a maintained library. Forgetting the calendar. A certificate issued today with a long lifetime on a 2048-bit key can outlive the policy that approved it. Match lifetimes to the 2030 and 2035 dates, and prefer short lifetimes with automated renewal. Confusing the vendor with the algorithm. Searches for RSA documentation can surface the identity company’s product pages. Verify that a page describes the PKCS 1 algorithm before taking prices, dates or release notes from it. Pros and Cons of Each RSA Key Size | Key size | Pros | Cons | |---|---|---| | RSA-2048 | Fastest of the three, smallest keys and signatures, universal support, acceptable against classical attackers today | Only about 112-bit strength, first to face pressure in policy, poor choice for new long-lived keys | | RSA-3072 | About 128-bit strength, moderate cost, recommended as the default for new keys, good fit for compliance floors | Slower than 2048, 50 percent larger signatures, still not quantum-safe, same 2030 and 2035 dates | | RSA-4096 | Extra classical margin for rare long-lived signing, suited to root CAs, widely supported | Highest compute and bandwidth cost, no exact NIST strength row, no quantum benefit, easy to over-buy | The table hides one asymmetry. RSA-2048’s cons are about policy and time, and RSA-4096’s cons are about cost and false confidence. Policy and time cons can be managed with a rotation calendar. False confidence is harder to manage, because it removes the urgency that a migration project needs to start. An honest reading of the evidence gives RSA-3072 the best overall profile for a general audience. It is the only one of the three that avoids both the weakest strength tier and the heaviest operating cost. RSA-4096 wins in narrow cases where signing volume is tiny and key lifetime is long. RSA-2048 wins on speed and compatibility, and it loses on everything that depends on the calendar. Verdict: RSA-3072 Now, a Post-Quantum Plan Next The takeaway: choose RSA-3072 for new general-purpose keys, reserve RSA-4096 for rarely used long-lived roots, and treat RSA-2048 as a legacy size with a rotation date. All three face the same reported IR 8547 schedule of deprecation after 2030 and disallowance after 2035, so the real decision is when to stop adding RSA to systems that will still run in 2035. The evidence for that call is concrete. RSA-3072 reaches roughly 128 bits of classical strength. RSA-4096 reportedly costs about six times more to sign than RSA-2048 in one comparison, and a fresh OpenSSL 4.1.0 benchmark gives a baseline for RSA-2048 signing and verification rates. GitHub reportedly moved its new-key floor to 3072 bits in October 2026, and stricter government profiles reportedly use the same number as a minimum. No source supports the idea that a bigger modulus rescues RSA from the quantum timeline. Teams that act on this should do three things this quarter. Inventory every RSA key and its lifetime. Replace sub-3072 keys that must outlive 2030. Start a pilot of hybrid or post-quantum protection on the data with the longest confidentiality requirement. Readers who want the wider map of algorithm choices can start from the cryptography coverage hub https://shattered.io/category/cryptography/ . FAQ: RSA 4096 vs 2048 vs 3072 Is RSA-4096 more secure than RSA-2048? Against classical attackers, yes. RSA-2048 maps to about 112 bits of strength, RSA-3072 to about 128 bits, and RSA-4096 sits above 128 bits without a separate NIST row. Against a quantum attacker running Shor’s algorithm, all three fall the same way, so the extra length offers no post-quantum protection. How much slower is RSA-4096 than RSA-2048? One October 2026 comparison says signing costs roughly six times more at 4096 bits. A separate OpenSSL 4.1.0 benchmark reportedly gives a ratio near 3.6 on its signing column and near 6.1 on its verification column. Results vary by hardware and library version, so run the speed test on your own machine. Which RSA key size should I use for new keys in 2026? RSA-3072 is the recommended default for most new keys. It reaches the 128-bit level at much lower signing cost than 4096, and reported platform rules such as GitHub’s new-key floor point the same way. Use RSA-4096 only for long-lived keys that sign rarely, such as roots. Is RSA-2048 still safe to use? It remains unbroken, and it works against classical attackers when implemented with modern padding and sound key management. No practical quantum computer can factor it today. It is still a legacy choice, because policy places the 112-bit level on the earliest part of the transition, so new long-lived systems should skip it. Does NIST IR 8547 ban RSA-4096? Not immediately. According to reporting on the final text, the report deprecates quantum-vulnerable public-key algorithms after 2030 and disallows them under NIST standards and guidelines after 2035, at all approved strengths. No separate RSA-4096 deadline appears in the sources reviewed, and the report is a transition roadmap, not an immediate ban. Will a larger RSA key protect against quantum computers? No. A larger modulus raises the resources a quantum attack needs, but it does not change the underlying vulnerability. NIST’s roadmap directs users toward the post-quantum standards finalized in August 2024, namely ML-KEM, ML-DSA and SLH-DSA, not toward longer RSA keys. What did GitHub change for RSA SSH keys in October 2026? Reports say GitHub began requiring new RSA SSH keys to be at least 3,072 bits on October 14, 2026, and it enabled the hybrid mlkem768x25519-sha256 key exchange the same day. Existing keys stayed valid for the time being, while SHA-1 signature brownouts were scheduled for November 4 and December 9, 2026, with permanent removal on January 13, 2027.