S/MIME Certificate Key Sizes: What Changed on September 15, 2026

What key size does your certificate need?

2048 bits. Section 6.1.5 of the S/MIME Baseline Requirements sets a 2048-bit minimum modulus for Subscriber Certificates, and the September 2026 revision left that line exactly where it was. The same section adds one small mechanical rule — the modulus, in bits, has to divide evenly by 8 — which every key generator worth using already satisfies without being told.

If you generate the key yourself, 2048 is the floor rather than a recommendation, and nothing stops you going higher. A 4096-bit subscriber key is perfectly legal and some corporate policies ask for it. The trade is speed: signing and decrypting with a 4096-bit key costs noticeably more CPU than with 2048, which most desktop mail clients will never notice and a busy gateway signing thousands of messages an hour certainly will.

Where the key lives usually decides this for you. Certificates delivered to a smart card or a hardware token take whatever size the device supports, and plenty of older cards top out at 2048. Certificates generated in the browser during enrolment take whatever the CA’s enrolment page offers. In both cases the decision has already been made by the time you see it.

What actually changed on September 15, 2026

Ballot SMC017 rewrote the RSA paragraph of section 6.1.5 so that CA certificates have their own, higher floor. The operative text reads: “For Keys corresponding to CA Certificates (including Root, Subordinate and Cross Certificates) signed on or after September 15, 2026 ensure that the modulus size, when encoded, is at least 4096 bits.” The result was version 1.0.15 of the S/MIME Baseline Requirements, dated July 30, 2026.

Three details in that sentence do more work than they look like they do. The first is Cross Certificates. A cross certificate is how a CA gets a second, independent path to trust — typically an older root signing a newer one so that devices which have not been updated in years can still build a chain. Naming them explicitly closes the obvious route around the rule, which would otherwise have been to cross-sign a 2048-bit root and carry on.

The second is that the jump goes straight from 2048 to 4096 with nothing in between. The TLS world spent years at 2048 with 3072 as the polite next step; the S/MIME Baseline Requirements skipped that rung entirely for new CA certificates. Given that a root signed today may still be in trust stores in the late 2040s, the Forum picked the size that does not need revisiting.

The third is the word signed, which turns out to be the part most summaries have quietly changed.

Why “signed on or after” is not “created after”

The rule keys off the date a CA certificate is signed, not the date its key pair was generated. Those two readings behave differently in exactly the case that matters: a 2048-bit key generated years ago and still sitting in a CA’s HSM. Under the text as written, that key cannot go into a Subordinate CA certificate signed today. Under the “keys created after” paraphrase that has spread through secondary coverage, it could.

This is not a pedantic distinction. CAs keep key material for a long time, and a hierarchy refresh normally means signing new intermediate certificates, often over keys that already exist and are already protected by audited procedures. Generating fresh key material is the expensive part of that exercise. A rule pinned to key-generation dates would have let an operator issue new intermediates from the existing 2048-bit inventory indefinitely, which is plainly not what a ballot titled “Increase Minimum RSA CA Key Size” was trying to achieve.

It cuts the other way too, and this is the reassuring half. Certificates signed before September 15, 2026 are judged by the rule that applied when they were signed. A 2048-bit intermediate issued in 2023 did not become non-compliant overnight, does not have to be revoked, and — subject to the 2027 rule below — keeps issuing. If you are reading a chain in a mail client and seeing 2048-bit CA certificates, that is expected rather than alarming.

The other deadline that landed the same day

September 15, 2026 carried a second, unrelated obligation from a different ballot. SMC016 produced version 1.0.14 of the S/MIME Baseline Requirements in May 2026 and set two SHA-1 deadlines on that date: from September 15, 2026 a CA may not sign a certificate using a signature algorithm that incorporates SHA-1, and before that date it had to revoke any unexpired Subordinate CA certificate carrying a SHA-1 signature.

Coverage of the two ballots has tended to blur them together and credit the SHA-1 sunset to SMC017. They are separate changes with separate version numbers that happen to share a compliance date. That is a common pattern at the Forum. Working groups cluster deadlines so CAs can plan one migration window instead of three.

The revocation half is the sharper of the two. Most obligations of this kind are phrased as “stop doing X from date Y”; this one required affirmative cleanup, by a deadline, of certificates that already existed. And its reach goes past certificates: section 7.1.3.2 applies the same permitted-algorithm list to the signature on a CRL and on an OCSP response, so a CA could not leave SHA-1 running quietly in its revocation infrastructure while modernising the certificates themselves.

For anyone holding a certificate, the practical question is narrow and worth two minutes: is your certificate itself signed with SHA-1? If it was issued by a publicly trusted CA in the last decade it will not be, because SHA-1 issuance for S/MIME had already been shut down well before this ballot formalised it. The command in the last section prints the answer.

What happens on September 15, 2027

A year from the first deadline, section 6.1.5 stops CAs issuing S/MIME certificates from undersized intermediates. The rule is conditional and precise: a CA may not issue a certificate if the certificate carries id-kp-emailProtection in its extended key usage, carries a compliant subjectAltName, and the issuing CA certificate’s RSA modulus is below 3072 bits. All three conditions have to hold.

Note what it is not. It is not a revocation order, and it is not a blanket ban on the old intermediate. The Note the Forum attached to the paragraph makes the intent explicit: the point is to stop S/MIME subscriber issuance from sub-3072-bit Subordinate CAs, while the issuance of Delegated OCSP Signing Certificates by those same CAs remains permitted. An undersized intermediate therefore stays in the chain and keeps answering revocation queries for the certificates it already issued, right up to its own expiry. That is the only sensible design: revoking it would break every unexpired certificate beneath it.

The conditions also mean the rule is about S/MIME specifically rather than about the CA in general. An intermediate that issues both S/MIME and other certificate types loses only the S/MIME half of its job on that date. If you run an intermediate that issues publicly trusted S/MIME certificates and it sits below 3072 bits, September 2027 is a hard stop on new issuance, and the replacement intermediate will have to be 4096 bits because it will be signed after the 2026 date. That is a year of notice for a piece of work that involves an HSM ceremony, so it belongs in a plan now rather than next summer.

The gap between 3072 and 4096 bits

Reading the two rules side by side turns up an asymmetry that almost nothing written about this ballot mentions. New CA certificates need 4096 bits. The 2027 issuance ban triggers below 3072. So an intermediate that was signed before September 15, 2026 with a 3072-bit key sits in the gap between them: too small for a CA to sign a certificate like it today, comfortably large enough to keep issuing S/MIME certificates for the rest of its natural life.

Whether that gap was deliberate is a fair question, and the ballot text does not say. The charitable reading is that the two rules answer different questions. 4096 is a forward-looking choice about certificates that will be trusted for decades; 3072 is a backward-looking judgement about which existing keys are still strong enough to be worth keeping in service. NIST has treated 3072-bit RSA as the equivalent of a 128-bit security level for years, so drawing the retirement line there is defensible even while the bar for new material sits higher.

The practical consequence for a buyer is small but real: the chain under your certificate may well contain a 3072-bit intermediate for years yet, and that is compliant. If a scanner or an internal policy check flags it as weak, what you are looking at is a policy stricter than the Baseline Requirements. That is a legitimate position to hold. It is just not one the Forum obliges anyone else to share, so expect to argue it on its own merits rather than by citing the rulebook.

If you would rather not think about RSA

Section 6.1.5 permits four key families, and only RSA has a size rule to argue about. ECDSA keys are allowed on the NIST P-256, P-384 and P-521 curves. EdDSA keys are allowed on Curve25519 and Curve448. And the section now carries post-quantum entries as well: ML-DSA at parameter sets 44, 65 and 87, and ML-KEM at 512, 768 and 1024. Then the section shuts the door on everything else: no other algorithms or key sizes are permitted.

None of the elliptic-curve options has a modulus, so none of them is touched by anything in this article. A P-256 key is a P-256 key in 2026 and will be in 2030. That makes ECDSA an appealing way to opt out of the whole key-size conversation, and it is why the question comes up.

The reason most S/MIME deployments still run on RSA is the other end of the wire. An S/MIME signature is only useful if the recipient’s client can verify it, and a message encrypted to your certificate is only useful if the sender’s client can do the encryption. That pulls the decision towards whatever the oldest mail client in your correspondence can handle, which in practice still means RSA for most organisations. If you are choosing between the two, our S/MIME certificate options for individuals and teams list what each product supports, so you can check before you commit an estate to a curve.

How to read the key size out of a certificate

Export the public certificate and run openssl x509 -in cert.pem -noout -text. The Subject Public Key Info block prints the algorithm and, for RSA, the modulus size as a Public-Key line in bits. On Windows, certutil -dump cert.cer prints the same value. Neither command needs the private key, so both work when the key sits on a token or in a client’s protected store.

To see the CA certificates rather than your own, ask for the chain from the connection or open the certificate in your mail client and walk up the certification path. If you would rather not install anything, the certificate inspection tools on this site decode a pasted certificate and print the same fields.

One trap worth knowing about. Section 6.1.5 measures the modulus when encoded, and some tools report the bit length of the integer instead, which can come out one short. If a scanner tells you a certificate from a public CA has an unusual key size, check what the tool is measuring before you open a ticket.