The short answer
From July 1, 2027, a publicly trusted S/MIME certificate may carry only two extended key usages: id-kp-emailProtection, which is required, and id-kp-clientAuth, which is optional. Ballot SMC018 removed the clause that let anything else ride along, and the same limit lands on the subordinate CA certificates that issue them. Certificates issued before that date keep whatever they already carry until they expire, so nothing breaks on the day — the change arrives with your next renewal. The thing it ends is the single certificate that signed both email and documents.
The coverage of this ballot so far has been the ballot text itself, reposted. That text is four lines long and answers none of the questions a certificate owner actually has: whether the certificate in their mail client is affected, whether anything gets revoked, and what replaces the thing that stops being allowed. Worse, the short version doing the rounds — that SMC018 bans code signing and TLS in S/MIME certificates — is wrong, and it sends people looking for a problem they never had. Below is the rule as the requirements actually word it, the cases that break, and a command you can run on a certificate today to find out which group you are in.
What exactly did Ballot SMC018 change?
Ballot SMC018, published as S/MIME Baseline Requirements v1.0.16 on September 29, 2026, carries one compliance date: July 1, 2027. From then, id-kp-emailProtection must be present and id-kp-clientAuth may be present in S/MIME subscriber certificates, and no other key purpose is permitted. The identical limit applies to the subordinate CA certificates that issue them.
The mechanism is a deletion rather than a new prohibition. Section 7.1.2.3 of the requirements sets out the extKeyUsage extension per generation. The Strict row has always read that email protection shall be present and other values shall not. The Multipurpose and Legacy row reads that email protection shall be present, client authentication may be present, and other values may be present in certificates issued before July 1, 2027. That date is the whole ballot. Before SMC018 the same sentence ended at “other values may be present,” with no expiry on it.
Section 7.1.2.2 does the same job one level up. For subordinate CA certificates used to issue S/MIME certificates, email protection shall be present and client authentication may be; the requirements then add that for subordinate CA certificates signed before July 1, 2027, other values may be present. The ballot also pulls CCADB Policy section 6.3 on cross-certificates into the requirements, effective on publication rather than in 2027: where a non-dedicated issuer signs a subject dedicated to S/MIME, the cross-certificate may assert only email protection, or email protection together with client authentication.
The ballot was proposed by Stephen Davidson of DigiCert and endorsed by Dustin Hollinback of Apple and Ashish Dhiman of GlobalSign, which is the usual shape of a CA working group change that nobody is fighting over. Its title is “Realignment of Multipurpose use cases,” and the word realignment is doing real work there. Multipurpose is not being retired. It is being brought into line with Strict on the one axis where the two differed most.
Which EKUs were already banned before this?
Four key purposes were out before this ballot and stay out with no date attached: id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping and anyExtendedKeyUsage. The requirements prohibit all four in S/MIME subscriber and subordinate CA certificates, in a sentence that sits outside the generation table and has no effective date because it was in force already.
This is worth being precise about, because it is where most summaries of SMC018 go wrong. A publicly trusted S/MIME certificate has never been allowed to sign code or serve TLS. If someone tells you the July 2027 change stops you from signing software with your mail certificate, they have described a rule from 2023. What SMC018 removes is narrower and, for the handful of people it touches, more awkward: the open-ended permission for key purposes the requirements never named at all.
Two values lived in that open-ended space and mattered in practice. One is the document signing key purpose, id-kp-documentSigning (1.3.6.1.5.5.7.3.36), standardised by RFC 9336 in December 2022. The other is the family of vendor-defined purposes, of which Microsoft’s smart card logon OID, 1.3.6.1.4.1.311.20.2.2, is the one that shows up in enterprise deployments. Neither was ever explicitly permitted. Both were permitted by the absence of a prohibition, which is what the date now supplies.
Which setups actually break on July 1, 2027?
One pattern breaks cleanly: the certificate bought to do two jobs, signing mail and signing documents. The requirements say so in their own definitions. The Multipurpose profile exists, in their wording, to “allow flexibility for crossover use cases between document signing and secure email.” That sentence describes exactly the arrangement the date ends.
How the crossover came about is documented in RFC 9336 itself. Before a general-purpose document signing key purpose existed, the RFC records, implementers reused id-kp-emailProtection or id-kp-codeSigning, or vendor-defined identifiers, and it warns that appropriating a key purpose for use outside the environment it was defined for introduces problems. The S/MIME requirements inherited that history in 2023 and accommodated it through Multipurpose. SMC018 is the accommodation being withdrawn now that a proper document signing EKU has been available for four years.
In support terms this surfaces as a renewal that comes back different. Someone has a certificate that signs their invoices in Acrobat and signs their mail in Outlook, they renew it after the cutover, and the document half stops being accepted. Nothing was revoked. The replacement certificate simply no longer asserts the purpose the PDF reader checks for, and the fix is a second certificate issued for that job. If documents are the use case that matters, a document signing certificate is the product that carries the right key purpose and the Adobe trust path that goes with it, and it is worth sorting out before the renewal rather than during it.
The smart card logon case is messier and has no commercial answer. Microsoft requires a logon certificate to carry its own key purpose alongside client authentication, and that vendor OID cannot be issued in a public S/MIME certificate after the cutover. Anyone who was getting domain logon out of a public mail certificate moves that function to an internal certification authority, where these requirements do not apply and any key purpose is available. That is where logon certificates generally belong anyway: nothing outside the domain needs to validate them.
Everything else is quieter than it sounds. Signing and encrypting mail needs email protection, which is unchanged. Authenticating a user to a service needs client authentication, which survives as the one permitted companion. If the extension on your certificate holds those two values and nothing else, the date passes and you will not notice it.
What is left of the Multipurpose generation?
Less than the name suggests. Legacy closed to new subscriber certificates on July 15, 2025, leaving Multipurpose and Strict. Their maximum validity is the same, 825 days. From July 1, 2027 their permitted key usage sets differ by one optional value: Multipurpose may include client authentication, Strict may not. The requirements call Strict the long-term target profile.
The generation still governs real things — which subject attributes are allowed, whether subjectDirectoryAttributes may appear, which URI schemes a CRL distribution point may use. What it stops doing is predicting capability. Until now, reading “Multipurpose” in a policy OID told you the certificate might do something beyond mail. After the cutover it tells you only that the certificate was issued under a looser set of rules about its own contents.
That matters for anyone who wrote a procurement requirement around the word. We have seen specifications that ask for a Multipurpose certificate when what the author meant was “a certificate that can also sign PDFs.” After July 2027 a CA can satisfy such a requirement to the letter and deliver something that cannot sign a PDF at all. If you maintain a document that names a generation, name the key purposes you need instead.
The policy OID is still the fastest way to read the generation off a certificate. The arc is 2.23.140.1.5, then the validation type — 1 for mailbox, 2 for organization, 3 for sponsor, 4 for individual — then the generation, where 1 is Legacy, 2 is Multipurpose and 3 is Strict. A sponsor-validated Strict certificate reads 2.23.140.1.5.3.3. Our walkthrough of the four S/MIME validation types covers the first half of that number in detail.
Do certificates I already hold stop working?
No. The requirement governs issuance, not certificates already in the field, and the wording is explicit: other values may be present in certificates issued before July 1, 2027. A compliant certificate issued on June 30, 2027 keeps every key purpose it carries until it expires. Nothing is revoked for the date alone, and no mail client changes behaviour that morning.
Run the arithmetic and the tail is long. The Multipurpose maximum is 825 days, so a certificate issued on the final permitted day can stay valid into early October 2029 with a document signing purpose inside it, fully compliant the whole time. For roughly twenty-seven months after the rule changes, certificates that could not be issued today will still be circulating and still be correct.
Intermediates are grandfathered on the same principle. A subordinate CA certificate signed before July 1, 2027 may keep a wider key usage set, and CAs are not obliged to reissue their hierarchies for this. What changes is what those intermediates may mint: a subscriber certificate issued from a wide intermediate after the cutover still has to stay inside email protection plus optional client authentication. The constraint follows the issuance date of the leaf, not the shape of the chain above it.
The practical reading is that your deadline is not July 1, 2027. It is the first renewal you file on or after that date, which for most organizations lands somewhere in the following two years depending on when the current certificate was issued. Work out that date for your own estate and you have the real planning horizon, which is almost always longer than the headline suggests.
How will this be enforced?
Automatically, at the moment of issuance. Since September 15, 2025 the requirements have obliged every CA to run pre-issuance linting against S/MIME certificates. From July 1, 2027 a request carrying a prohibited key purpose fails that check and no certificate comes back. You will not discover the change from a deprecation notice; you will discover it from a rejected order.
If one slips past the linter, the consequence is revocation rather than a warning. Section 4.9.1.1 lists the reasons a CA must revoke a subscriber certificate, and item 11 covers a certificate the CA becomes aware was not issued in accordance with the requirements. The clock on that is five days, with the requirements saying the CA should manage it within twenty-four hours. A non-compliant certificate issued after the cutover is mis-issuance, and mis-issuance has a timetable.
Neither mechanism reaches backwards, which is why the grandfathering above holds. A certificate that was compliant when issued does not become mis-issued because the rules moved afterwards. The pairing is deliberate: a hard stop on new issuance, no disruption to what is already deployed, and the field drains itself over one validity period.
How do I check which EKUs my certificate has?
Read the extendedKeyUsage extension on the certificates you actually deploy. One OpenSSL command prints it. If the output holds nothing beyond E-mail Protection and TLS Web Client Authentication, July 2027 changes nothing for you. Anything else in that list is a dependency your next renewal after the cutover cannot carry.
# A PEM or DER certificate on disk openssl x509 -in cert.pem -noout -ext extendedKeyUsage # Straight out of a PKCS#12 bundle, without unpacking it first openssl pkcs12 -in cert.pfx -nokeys -clcerts -passin pass:YOURPASS \ | openssl x509 -noout -ext extendedKeyUsage # The generation and validation type, read from the policy OID openssl x509 -in cert.pem -noout -ext certificatePolicies # Windows, for a certificate file certutil -dump cert.cer | findstr /C:"Extended Key Usage" /C:"Code Signing" /C:"Document Signing"
A clean S/MIME certificate prints two lines at most. The values worth stopping on are any document signing purpose, any OID starting 1.3.6.1.4.1 — that arc is vendor-private space, and Microsoft’s logon purpose lives there — and anything OpenSSL renders as a bare dotted number because it has no name for it. Each of those is a use case that needs its own certificate after the cutover.
Check the issued certificate rather than the order form. We see plenty of tickets where someone believes they bought a multipurpose certificate and the certificate in their mail client holds email protection alone, because the CA tightened its profile at some point during the three years they have been renewing it. The extension is the only authority on what the certificate can do.
What should you do between now and July 2027?
For most S/MIME deployments, nothing. Inventory the key purposes on the certificates you hold, sort each extra purpose into the branch that fits it, and act only on the branches that need a separate certificate. The one that costs money is document signing; client authentication is free of charge because it stays permitted, and smart card logon moves to an internal CA.
Three things are worth doing while there is no pressure. First, run the command above across your estate and write down the renewal date of anything that comes back with more than two values, because that date is your real deadline. Second, if document signing is in the list, test a dedicated certificate against whatever consumes the signatures — the trust path and the signature properties both look different, and finding that out during a renewal window is worse than finding it out now. Third, if a procurement document or internal standard names the Multipurpose generation, rewrite it to name key purposes.
Worth asking your CA directly when their profile changes rather than when the requirements do. Nothing stops a CA narrowing earlier, and several have form for retiring an option well ahead of the compliance date to avoid running two profiles. If you buy S/MIME certificates through My-SSL, these are issued by Certum, and we will tell you what their current profile allows rather than what the deadline permits in principle.
What else lands on the 2027 calendar?
One more S/MIME date, close enough to plan alongside this one. Ballot SMC017 requires CAs to stop issuing subscriber certificates from any subordinate CA whose RSA key is smaller than 3,072 bits, effective September 15, 2027. That one is the CA’s problem rather than yours, but it can force an intermediate change in the same window as the key usage narrowing.
| Date | Ballot | What happens | Whose job |
|---|---|---|---|
| 15 Jul 2025 | SMC08 | No new subscriber certificates under the Legacy generation | Done |
| 15 Sep 2025 | SMC09 | Pre-issuance linting becomes mandatory for CAs | Done |
| 15 Sep 2026 | SMC016 · SMC017 | SHA-1 sunset completes; new CA RSA keys at least 4,096 bits | Done |
| 1 Jul 2027 | SMC018 | Only emailProtection and optional clientAuth may be issued | Yours |
| 15 Sep 2027 | SMC017 | No issuance from subordinate CAs with RSA keys under 3,072 bits | Your CA |
The direction across all of these is one purpose per certificate. Public TLS server certificates lost client authentication in 2026 for the same reason this ballot narrows S/MIME: a key that can only do one thing is a smaller problem when it leaks. The side effect is that the certificate count in an average organization goes up, which is an automation question more than a procurement one.
Frequently Asked Questions
Answers to common questions about certificates and our services.
What changes for S/MIME certificates on July 1, 2027?
From July 1, 2027, id-kp-emailProtection (1.3.6.1.5.5.7.3.4) is the only mandatory extended key usage and id-kp-clientAuth (1.3.6.1.5.5.7.3.2) the only optional one permitted in publicly trusted S/MIME subscriber certificates and in the subordinate CA certificates that issue them. Ballot SMC018 removed the clause in the Multipurpose and Legacy subscriber profiles that allowed other values, which the S/MIME Baseline Requirements now permit only in certificates issued before that date. Any other key purpose, including the document signing EKU from RFC 9336 and vendor-defined values such as Microsoft smart card logon, cannot be issued in a public S/MIME certificate after the cutover.
Does my existing S/MIME certificate get revoked on July 1, 2027?
No. The requirement applies to issuance, not to certificates already in the field. Section 7.1.2.3 of the S/MIME Baseline Requirements says other extended key usage values may be present in certificates issued before July 1, 2027, so a compliant certificate issued on June 30, 2027 keeps whatever it carries until it expires. With the 825-day maximum validity that applies to the Multipurpose generation, the last such certificates can stay valid into roughly October 2029. The change bites at renewal, not on the date itself.
Can an S/MIME certificate still sign PDFs after July 2027?
Not as a publicly trusted S/MIME certificate carrying a document signing key purpose. The Multipurpose generation existed, in the Baseline Requirements' own words, to allow flexibility for crossover use cases between document signing and secure email, and SMC018 closes that crossover. Document signing moves to a certificate issued for that purpose, which is a separate product with its own profile and its own trust path through the Adobe Approved Trust List. Whether a given PDF reader accepts a mail certificate was always application-specific; after the cutover the certificate cannot assert the document signing purpose at all.
Is id-kp-clientAuth still allowed in S/MIME certificates?
Yes. clientAuth survives SMC018 as the one optional companion to emailProtection, in both subscriber and subordinate CA certificates. That matters because the TLS side went the other way: public TLS server certificates lost clientAuth in 2026. So a public certificate that authenticates a user to a service is now an S/MIME certificate with clientAuth, not a TLS certificate with it. What clientAuth alone does not cover is Windows smart card logon, which Microsoft requires to carry its own key purpose, 1.3.6.1.4.1.311.20.2.2, alongside clientAuth.
Which EKUs were never allowed in S/MIME certificates?
id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping and anyExtendedKeyUsage have been prohibited in S/MIME subscriber and subordinate CA certificates independently of SMC018, and that prohibition carries no date because it was already in force. This is the most common misreading of the ballot: it does not newly ban code signing or TLS server authentication in a mail certificate. It removes the open-ended permission for everything else, which is where the document signing and vendor logon key purposes lived.
Do subordinate CA certificates have to be reissued before July 2027?
No, existing intermediates are grandfathered. Section 7.1.2.2 says that for subordinate CA certificates signed before July 1, 2027, other extended key usage values may be present, so an intermediate signed in 2026 with a wider set keeps it. What changes is what that intermediate may issue: subscriber certificates minted from it after the cutover still have to stay inside emailProtection plus optional clientAuth. A CA that wants a new intermediate after the date is the one that has to narrow the set.
How do I find out whether this affects my certificates?
Read the extended key usage extension of the certificates you currently deploy. With OpenSSL, openssl x509 -in cert.pem -noout -ext extendedKeyUsage prints the list. If the output shows nothing beyond E-mail Protection and TLS Web Client Authentication, the cutover changes nothing for you. If it shows a document signing purpose, Microsoft smart card logon, or any other value, that certificate relies on something your next renewal after July 1, 2027 cannot carry, and the second use case needs its own certificate.
Why did the CA/Browser Forum make this change?
The stated direction of the S/MIME Baseline Requirements has always been single-purpose certificates: the Strict generation is described in the requirements as the long-term target profile, with extended key usage limited to emailProtection. Multipurpose was a transitional accommodation for practices that predated the requirements. SMC018, proposed by DigiCert and endorsed by Apple and GlobalSign, moves Multipurpose onto the same key usage footing as Strict while implementing CCADB cross-certificate rules. Narrow key purposes limit what a compromised key can be used for, which is the same reasoning that removed clientAuth from public TLS certificates.
If the document half is the part you need
The one group this ballot genuinely costs something is anyone whose single certificate was signing both mail and documents. That splits into two certificates, and the document side needs a document signing certificate carrying the right key purpose. Send us the output of the OpenSSL command above before you renew and we will tell you whether you need one or whether your certificate was only ever doing mail — a fair number of the people who ask turn out to need nothing at all.
Related reading
- S/MIME certificate validation types — the other half of the policy OID: what mailbox, organization, sponsor and individual validation each prove, and how to read which one you hold.
- The clientAuth EKU removal — the same single-purpose argument applied to public TLS certificates, and why client authentication ended up on the S/MIME side of the fence.
- What is a document signing certificate? — what the certificate that replaces the crossover actually contains, and how its trust path differs from a mail certificate's.