S/MIME EKU change from 1 July 2027: only two EKUs allowed, plus your email PKI checklist

Summary. From 1 July 2027, a publicly trusted S/MIME certificate may carry only two extended key usages (EKUs): emailProtection, which is mandatory, and clientAuth, which is optional. The rule comes from CA/Browser Forum ballot SMC018, which passed on 25 August 2026 with all 15 certificate issuers and all 3 certificate consumers voting yes, and took effect as S/MIME Baseline Requirements (BRs) version 1.0.16 on 28 September 2026. It applies to subscriber certificates issued, and subordinate CA certificates signed, on or after 1 July 2027. Existing certificates are not revoked. The change ends the Multipurpose profile's freedom to add other EKUs, which some CAs used to combine email with document signing or Windows smart card logon. Strict-profile certificates are unaffected. Apple's root programme policy 2.0 uses the same date and adds an earlier one: from 1 February 2027, every new emailProtection certificate must carry an email address. On 15 September 2027, CAs must stop issuing from RSA intermediates under 3,072 bits. Counting from 7 November 2026, 236 days remain before the EKU rule applies. Certificates from your own internal CA are outside the BRs.

About this article. For IT, security and PKI teams that buy or run S/MIME certificates. We checked the ballot, votes, dates and EKU rules against CA/Browser Forum ballot pages, working group minutes and the S/MIME BRs version 1.0.16 dated 28 September 2026, the current version on 7 November 2026, and checked Apple, CCADB, Microsoft, Google and IETF documents on the same date. This is not legal advice, CA products and root programme rules change, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

Public web certificates have a separate rulebook, covered in our 100-day TLS certificate checklist.

What changes on 1 July 2027

SMC018 edits the extKeyUsage rules for subordinate CA certificates (section 7.1.2.2) and subscriber certificates (section 7.1.2.3). For subscriber certificates:

For subordinate CAs that issue S/MIME certificates, emailProtection stays mandatory, clientAuth becomes the only other permitted EKU and the same four stay banned, but intermediates signed before 1 July 2027 may keep extra EKUs. So an existing intermediate can keep issuing, yet every leaf it issues from that date must contain only the two permitted EKUs. Apple is already stricter: intermediates signed on or after 1 August 2026 may contain only the EKUs of their trust purpose.

A third change took effect on 28 September 2026. When a CA cross-certifies an S/MIME-dedicated hierarchy from a multipurpose root, the cross certificate may contain only emailProtection, or emailProtection with clientAuth, matching section 6.3 of the CCADB Policy. The ballot also records that Legacy Generation issuance was deprecated from 15 July 2025.

Who voted, and why the forum made this change

Stephen Davidson of DigiCert proposed SMC018, with endorsements from Apple and GlobalSign. Discussion ran from 11 to 18 August 2026 and voting from 18 to 25 August 2026.

The intellectual property review ran from 25 August to 24 September 2026, the ballot was adopted on 28 September, and the GitHub release followed on 29 September. Microsoft and Google are not among the consumer votes.

The working group's 1 July 2026 minutes give the background. Prompted by CCADB Policy section 6.3 and a proposed Apple policy limiting Multipurpose certificates to emailProtection, or emailProtection with clientAuth, members noted that signing software accepts a mix of emailProtection, the IETF document-signing EKU and proprietary Adobe and Microsoft EKUs, and that some CAs still mixed them. Apple's representative said email was the use case most browser root stores support. On 29 July, Stephen Davidson said the 1 July 2027 date matched Apple's version 2 policy.

The security case is older. RFC 9336 defined id-kp-documentSigning (OID 1.3.6.1.5.5.7.3.36) in December 2022, explaining that reusing emailProtection for document signing lets a change in one ecosystem harm the other, and that a separate EKU reduces cross-protocol attack risk.

Apple's policy: the same date, plus one earlier rule

Apple's Root Program Policy 2.0, effective 1 August 2026, recognises two email trust purposes: Secure Email (emailProtection) and Legacy S/MIME (emailProtection with clientAuth). Subscriber certificates signed before 1 July 2027 may still carry other EKU combinations if they otherwise meet the BRs.

Apple also sets a date the BRs lack. From 1 February 2027, every newly signed subscriber certificate with emailProtection must contain at least one email address (rfc822Name). The BRs define an S/MIME certificate as one with emailProtection and a mailbox address, so a signing certificate with emailProtection but no address has sat outside them. The working group is drafting ballot language to bring every emailProtection certificate into scope. Do not plan around dropping the email address to keep a combined certificate.

A profile refresher: validation types, generations and policy OIDs

The S/MIME BRs define four validation types and three generations, each with its own certificate policy OID, the quickest way to tell which rules apply.

The last digit is the generation: 1 for Legacy, 2 for Multipurpose, 3 for Strict. Section 6.3.2 caps Multipurpose and Strict certificates at 825 days and Legacy at 1,185 days, and section 4.2.1 lets a CA reuse organisation or individual identity validation for up to 825 days.

SMC018 matters mainly for certificates whose policy OID ends in .2. If your estate is already Strict, your leaf certificates are untouched.

The other S/MIME dates to plan around

The BRs' table of additional compliance dates gives the sequence, and Apple's policy adds two dates. The BRs label the key-size ballot SMC017; the version adopted was SMC017v2.

Version 1.0.10 (July 2025) added ACME for S/MIME under RFC 8823, and version 1.0.11 (August 2025) allowed post-quantum ML-DSA and ML-KEM keys. After Apple said it will accept composite ML-DSA certificates, the working group began drafting a composite ballot. Our CNSA 2.0 post-quantum procurement guide covers the wider timetable. Ballot SMC020, whose review ends on 19 November 2026, comes with a redline labelled version 1.0.17 and a 15 March 2027 logging date; it does not touch EKUs.

The 15 September 2027 date is the one IT teams overlook. A CA still issuing from a 2,048-bit RSA intermediate must move to a new one, so renewed certificates may chain differently, and any gateway, archive or data loss prevention (DLP) tool that pins intermediates needs the new chain.

Which certificates break, and which do not

The rule is narrow. Organisations that buy certificates only to sign and encrypt email will see no change.

Smart card logon. Microsoft's documentation says a smart card certificate with an EKU extension must include the smart card sign-in EKU. The domain controller checks for it by default, Group Policy can relax that check, and it is not needed for account mappings based on the public key. A public S/MIME certificate issued from 1 July 2027 cannot carry that EKU, so badges that hold one public certificate for email and Windows logon need two certificates at the next renewal, with the logon certificate on your own CA.

Document signing. RFC 9336 lets document-signing applications require id-kp-documentSigning, and signing software also accepts emailProtection or vendor EKUs. Check what your PDF, e-invoicing and contract tools accept before you split.

Network access. Apple's policy says clientAuth in an email certificate must serve only S/MIME-related client authentication. Ask your CA how it reads that before relying on a public email certificate for Wi-Fi or VPN. An internal CA is the cleaner home for network access.

Client and relying-party compatibility

Recipients, gateways and signing tools must accept the new certificates and chains. Google's Gmail profile, last updated 26 October 2026, sets the rules summarised in the first row below, including a 27-month leaf cap and RSA 2,048, 3,072 or 4,096-bit or ECDSA P-256 or P-384 keys.

Two points apply to every client. Users who encrypt email need their old private keys after renewal to open messages encrypted to the previous certificate, so keep key archival or escrow working. And publish new intermediate certificates wherever your mail clients and gateways pick them up, so recipients can build the chain.

The email PKI checklist for IT teams

Work through this before your first renewal after 1 July 2027.

1. Inventory every publicly trusted S/MIME certificate. Pull certificates from your CA's portal, user certificate stores and smart card management systems. Record holder, CA, dates, policy OID and EKUs.

            # OpenSSL 3.x: print the EKU and policy OIDs of one PEM certificate
openssl x509 -in user.pem -noout -ext extendedKeyUsage,certificatePolicies

# List any EKU other than E-mail Protection and TLS Web Client Authentication
openssl x509 -in user.pem -noout -ext extendedKeyUsage | tail -n +2 | tr ',' '\n' \
  | sed 's/^ *//' | grep -v -E '^(E-mail Protection|TLS Web Client Authentication)$'
          

            # Windows: personal certificates with the Secure Email EKU (1.3.6.1.5.5.7.3.4) and all their EKUs
Get-ChildItem Cert:\CurrentUser\My | ForEach-Object {
  $eku = ($_.Extensions | Where-Object { $_ -is [Security.Cryptography.X509Certificates.X509EnhancedKeyUsageExtension] }).EnhancedKeyUsages.Value
  if ($eku -contains '1.3.6.1.5.5.7.3.4') {
    [pscustomobject]@{ Subject = $_.Subject; NotAfter = $_.NotAfter; EKUs = $eku -join ', ' }
  }
}
          

2. Classify each certificate against the table above. Any EKU other than emailProtection or clientAuth goes on the change list.

3. Ask your CA five questions:

• Which generation and policy OID will renewals use after 1 July 2027?

• Will you keep a Multipurpose product with clientAuth, and at what price?

• Which document-signing product replaces the combined certificate, and which EKU does it carry?

• When will your new SMC017v2 intermediates be published?

• Do you support ACME for S/MIME or an enrolment API?

4. Split combined certificates. One S/MIME certificate for email, one certificate for the other purpose. Use your internal CA for Windows logon.

5. Update enrolment templates in your CA portal, MDM certificate profiles and scripts that request a fixed EKU list, so requests do not fail or silently drop a purpose.

6. Check email addresses in every request, ahead of Apple's 1 February 2027 rule.

7. Test with real clients. Exchange signed and encrypted mail between Outlook, Gmail with hosted S/MIME, Apple Mail and your mobile clients, and sign a test document in each signing tool.

8. Keep decryption keys in archival or escrow for every renewed encryption certificate.

9. Distribute new intermediates to gateways, archives and DLP allow-lists before the CA rotates.

10. Document exceptions with an owner and an end date, and recheck when version 1.0.17 and any scope ballot are published.

Renewal timing: a worked example

The rule applies at issuance. A Multipurpose certificate with a document-signing EKU issued on 30 June 2027 stays valid for its term: at the 825-day maximum, 30 June 2027 plus 825 days is 2 October 2029. A certificate issued on 1 July 2027 cannot carry that EKU.

Gmail changes the sum. Twenty-seven months from 30 June 2027 is 30 September 2029, so a full 825-day certificate runs about two days past Gmail's cap. Ask for 27 months or less if Gmail recipients matter.

Early renewal is a bridge, not a strategy. Your CA may retire combined products before the deadline, every certificate renewed early is one more to split later, and Apple reserves the right to move multi-purpose roots to single-purpose operation. For most estates, split at the first renewal after you have confirmed replacement products, and finish before 1 July 2027.

India and global notes

India. eMudhra, an Indian CA, voted yes on SMC018, so the rule binds it like every other issuer. Its October 2026 key-generation incident, covered in our TLS checklist, concerned TLS: its statement, updated 5 November 2026, limits the impact to TLS certificates and does not mention S/MIME. Whichever CA you use, ask which root your S/MIME certificates chain to and whether your recipients' mail clients trust it.

Digital Signature Certificates from CAs licensed under India's IT Act 2000 and overseen by the Controller of Certifying Authorities follow that national regime, not the CA/Browser Forum BRs. A separate certificate used for tax, company-filing or e-invoicing signatures is untouched by the July 2027 change. For personal data, S/MIME encryption supports the encryption safeguard in our DPDP Rules compliance checklist.

EU. The BRs have accepted ETSI TS 119 411-6 audits since version 1.0.2, so ETSI-audited European CAs apply the same rule. Qualified signature certificates under eIDAS are a separate regime.

US and UK. There is no regional variation. Organisations using smart cards for Windows logon should start the internal-CA work early, because it touches badge issuance, not only email.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cybersecurity services team can inventory your S/MIME and signing certificates, map each to the July 2027 rule, plan the split between public and internal CAs and test the replacements with your mail clients and signing tools. Talk to us at /contact-us/.

Last updated: 7 November 2026.

References

1. Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates, version 1.0.16, 28 September 2026 — CA/Browser Forum

1. Ballot SMC018: Realignment of Multipurpose use cases (discussion, voting results, IPR review and adoption) — CA/Browser Forum

1. Apple Root Program Policy, version 2.0, effective 1 August 2026 — Apple

1. Ballot SMC017v2: Increase Minimum RSA CA Key Size — CA/Browser Forum

1. S/MIME Baseline Requirements v1.0.16 redline — CA/Browser Forum

1. CCADB Policy, version 2.1, section 6.3 Cross-certification across PKI hierarchies — Common CA Database

1. Release v1.0.16, Ballot SMC018, 29 September 2026 — CA/Browser Forum on GitHub

1. Minutes of the S/MIME Certificate Working Group, 1 July 2026 — CA/Browser Forum

1. Minutes of the S/MIME Certificate Working Group, 29 July 2026 — CA/Browser Forum

1. RFC 9336: X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing, December 2022 — RFC Editor

1. Minutes of the S/MIME Certificate Working Group, 21 October 2026 — CA/Browser Forum

1. Minutes of the S/MIME Certificate Working Group, 7 October 2026 — CA/Browser Forum

1. Ballot SMC020: Remove Requirement to Record BR Version of Validation Method — CA/Browser Forum

1. Certificate Requirements and Enumeration (smart card certificates) — Microsoft Learn

1. S/MIME certificate profiles, last updated 26 October 2026 — Google Workspace Admin Help

1. eMudhra Statement on Recent Certificate Security Incident, updated 5 November 2026 — eMudhra

1. Controller of Certifying Authorities, Ministry of Electronics and Information Technology — Government of India