S/MIME Baseline Requirements: Profiles and Deadlines

Publicly trusted S/MIME certificates have been governed by the CA/Browser Forum S/MIME Baseline Requirements since 1 September 2023, and the rules keep tightening: Legacy profiles ended for new issuance on 15 July 2025, SHA-1 had to be gone by 15 September 2026, and extended key usage is restricted from 1 July 2027. Organisations that sign or encrypt email with public certificates see these changes as renewals that come back with a different subject, fewer key usages or a different validity period, and as integrations that stop working because a certificate no longer allows client authentication or document signing. This guide covers the certificate types and generations, the dated compliance timeline from the Requirements themselves, who is affected, how to find certificates that will not survive renewal, the migration options and the risks of waiting. It is for PKI owners, messaging teams and anyone running an Enterprise RA. How to use S/MIME and OpenPGP day to day is in the OpenPGP and S/MIME Email Encryption Guide; this page does not repeat it.

Key takeaways

Four types, three generations. Certificates are Mailbox-, Organization-, Sponsor- or Individual-validated, each in Legacy, Multipurpose or Strict generation, identified by policy OIDs under 2.23.140.1.5.
Legacy is closed for new issuance. From 15 July 2025, subscriber certificates "SHALL NOT be issued using the Legacy Generation profiles"; existing ones run to expiry.
Validity is capped by generation. 825 days for Strict and Multipurpose, 1185 days for Legacy, so renewed certificates are often shorter.
Multipurpose is narrowing. From 1 July 2027 only id-kp-emailProtection SHALL be present and id-kp-clientAuth MAY be present in S/MIME subscriber and subordinate CA certificates, ending other usages such as document signing.
Internal PKI is out of scope, mail clients are not. The Requirements do not cover enterprise CAs whose roots are not distributed by software suppliers, but recipients' clients judge your publicly trusted certificates.

What is changing and why

Before 2023, S/MIME issuance varied widely between CAs, with inconsistent identity checks and certificate contents. The CA/Browser Forum S/MIME Certificate Working Group adopted version 1.0 of the Baseline Requirements (ballot SMC01), with an initial implementation date of 1 September 2023. The document defines an S/MIME certificate as one with the id-kp-emailProtection extended key usage (OID 1.3.6.1.5.5.7.3.4) and an rfc822Name or SmtpUTF8Mailbox in the subject alternative name. It applies to every CA in a publicly trusted chain and flows down from the root to subordinate CAs.

The Requirements set out three generations so that existing practice could become auditable and then converge:

Generation	Purpose as stated in the Requirements	Extended key usage	Maximum validity	Status (checked 8 Nov 2026)
Legacy	Flexibility for existing S/MIME practices to become auditable, with options for subject attributes, EKU and extensions	emailProtection required; clientAuth and others allowed (others only before 1 July 2027)	1185 days	New issuance prohibited from 15 July 2025
Multipurpose	Aligned with Strict but with extra EKU options for crossover between document signing and secure email	emailProtection required; clientAuth allowed; others only in certificates issued before 1 July 2027	825 days	Current; narrowing on 1 July 2027 (SMC018)
Strict	The long-term target profile	emailProtection only	825 days	Current

Certificate type	Subject content	Validation	Typical use
Mailbox-validated	Optional emailAddress, commonName and serialNumber only	Mailbox control only	Encryption and signing where no identity claim is needed
Organization-validated	Legal Entity attributes only	Mailbox control plus organisation identity	Shared or role mailboxes such as invoices@
Sponsor-validated	Natural Person attributes with an organisationName	Mailbox, organisation and individual; may be done by an Enterprise RA	Employees signing for their employer
Individual-validated	Natural Person attributes only	Mailbox control plus individual identity	Professionals signing as themselves

The CA side has tightened in parallel, and this affects how quickly issuance requests are approved. CAs must now lint every S/MIME certificate before issuance, corroborate domain validation from multiple network perspectives, validate CAA with DNSSEC and pass WebTrust for Network Security as part of their audits. For subscribers the visible effect is that malformed requests, unverifiable organisation details or misconfigured DNS are rejected rather than issued, so renewal problems now surface as failed orders rather than as non-compliant certificates in circulation.

For Multipurpose and Strict individual certificates, the subject must include givenName and/or surname or a pseudonym; Legacy allowed a commonName alone. That is one reason renewals can change the visible name on a certificate.

Official timeline and current status

All dates below are taken from section 1.2.1 of the S/MIME Baseline Requirements, version 1.0.16 (ballot SMC018, published 28 September 2026), checked on 8 November 2026. Future ballots may add or move dates.

Compliance date	Ballot	Requirement
1 September 2023	SMC01	Initial implementation date
15 September 2024	SMC03, SMC05, SMC06	Transition end for extant S/MIME CAs; CAA for S/MIME recommended; CAs must check the active status of Legal Entity applicants
15 March 2025	SMC05	CAA for S/MIME becomes mandatory
1 April 2025	SMC09	WebTrust audits must include WebTrust for Network Security
15 May 2025	SMC010	Multi-Perspective Issuance Corroboration mandatory
15 July 2025	SMC08	No subscriber certificates issued using Legacy Generation profiles
15 September 2025	SMC09	Pre-issuance linting of S/MIME certificates mandatory
15 March 2026	SMC014	DNSSEC validation for CAA mandatory
15 September 2026	SMC016, SMC017	Remaining SHA-1 use in certificates and CRLs sunset; new root or subordinate CA RSA keys at least 4096 bits
1 July 2027	SMC018	Only id-kp-emailProtection SHALL be and id-kp-clientAuth MAY be present in EKU of S/MIME subordinate CA and subscriber certificates
15 September 2027	SMC017	CAs cease subscriber issuance from subordinate CAs with RSA keys below 3072 bits

Other changes without a separate compliance date are in force from publication of their version, including ACME for S/MIME (SMC012, published 2 July 2025, using RFC 8823) and post-quantum algorithms (SMC013, published 22 August 2025).

Who and what is affected

Holders of Legacy certificates: they keep working until expiry, but the renewal will be Multipurpose or Strict, with a shorter maximum validity and possibly different subject fields.
Dual-use certificates: certificates that also carry document signing or other EKUs for PDF or workflow signing lose those usages for issuance from 1 July 2027. Systems that rely on one certificate for both email and document signing need a separate signing certificate.
Client authentication: id-kp-clientAuth remains allowed in Multipurpose and Legacy, but not in Strict. Teams using S/MIME certificates for VPN or Wi-Fi authentication must request Multipurpose or move to a dedicated client certificate.
Enterprise RAs: organisations that issue Sponsor-validated certificates through a CA's portal are bound by contract to the Requirements. The CA must confirm the Enterprise RA controls the email domains and that organisationName matches the enterprise or an affiliate.
DNS owners: CAA processing now applies to S/MIME issuance through the issuemail property defined in RFC 9495, so an issuemail record that omits your S/MIME CA blocks it from issuing.
Key escrow users: where escrow is supported under section 4.12, the CA may retain subscriber private keys past the maximum validity period, which matters for decrypting archived mail.

Finding affected systems and identities

Export issued certificates: from each CA account or certificate management platform, export all S/MIME certificates with their policy OIDs. Policy OIDs ending in .1 (for example 2.23.140.1.5.1.1) are Legacy, .2 Multipurpose and .3 Strict.
Check EKUs: list certificates with any EKU other than emailProtection and clientAuth. These are the ones whose renewals change after 1 July 2027. Find the applications using those extra usages.
Check expiry against the rules: flag Legacy certificates expiring in the next 12 months and certificates longer than 825 days, so owners expect a different renewal.
Check CAA: query CAA records for every mail domain and confirm any issuemail records authorise your S/MIME CA (RFC 9495).
Map to identities: link each certificate to a person, role mailbox or system. Role mailboxes and automated senders (invoicing, notification systems) are non-human identities with private keys on servers: record where each key lives and who can use it. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Check private CAs separately: internally issued email certificates are outside the Requirements, but external recipients will not trust them. Confirm none are used for external mail that must validate.

Measure progress with: count of Legacy certificates remaining; certificates with non-email EKUs; percentage of mail domains with correct CAA for S/MIME; percentage of S/MIME certificates issued through automation; and failed renewals per month.

Migration options

Need	Choose	Trade-off
Email signing and encryption only	Strict generation	Cleanest, aligned with the long-term target; no other usages
Email plus client authentication	Multipurpose generation	Keeps clientAuth after 2027; keep an eye on future ballots
Email plus document signing	Separate document signing certificate plus Strict S/MIME	Two certificates to manage; avoids a 2027 break
Role or shared mailbox	Organization-validated	No personal identity in subject; key custody must be controlled
Large user population	Enterprise RA with automation (ACME for S/MIME where the CA supports it)	Contractual obligations and audits fall on your RA process
Internal-only signing	Private CA	Outside the Requirements; not trusted by external recipients

Small organisations usually buy Strict Mailbox- or Sponsor-validated certificates per user and renew annually. Large organisations should consolidate on one or two CAs, run an Enterprise RA, separate signing from encryption keys where escrow is used, and automate issuance so that shorter validity periods do not add workload.

Testing and rollback

Pilot a renewal: issue a new-generation certificate to a small group and test signing, encryption, decryption of old mail and verification in every client your recipients use (desktop, mobile and webmail).
Test integrations: try the new certificate with VPN, Wi-Fi, document signing and workflow tools that used the old one. Any failure identifies a usage you must split out.
Keep old keys: do not delete old private keys on renewal. Mail encrypted to the old certificate still needs the old key to decrypt, which is where escrow or key archive matters.
Roll back by reissue: you cannot roll back to Legacy issuance. If a new certificate breaks a flow, keep using the existing unexpired certificate while the integration is fixed, and reissue with a different generation if needed.
Update CAA in step: change CAA records before changing CA, test issuance, then remove the old CA from CAA once its last certificate has been replaced.

Risks of doing nothing

Surprise breakages at renewal: certificates renew with different EKUs, subjects or validity and silently stop working for document signing or client authentication.
Blocked issuance: incorrect CAA records stop the CA issuing at all, which surfaces as failed renewals just before expiry.
Lost access to encrypted mail: deleting or failing to archive old private keys at renewal leaves past messages unreadable.
Uncontrolled keys on role mailboxes: shared certificates without owners become credentials anyone with server access can use to sign as the organisation.
Distrust exposure: root programme decisions can cover S/MIME too; Apple's 2024 Entrust decision included S/MIME roots. See CA Distrust Events.

Framework	Reference	Why it applies
NIST SP 800-53 Rev. 5	SC-12, SC-12(3), SC-17, IA-5(2)	Key management; asymmetric keys; PKI certificates; public key-based authentication
NIST CSF 2.0	PR.DS-02, ID.AM-08	Data in transit; life cycle management of assets
ISO/IEC 27001:2022 Annex A	8.24, 5.14	Use of cryptography; information transfer
CIS Controls v8.1	3.10	Encrypt sensitive data in transit

Practitioner checklist

Export all publicly trusted S/MIME certificates with policy OIDs, EKUs, validity and owners.
List remaining Legacy certificates and tell owners what their renewal will look like.
Find certificates with document signing or other non-email EKUs and plan separate certificates before 1 July 2027.
Decide Strict or Multipurpose per use case and record the reason.
Check CAA records on every mail domain authorise your S/MIME CA.
Archive or escrow encryption keys before renewal so old mail stays readable.
Assign owners and key custody rules to every role mailbox certificate.
Review the S/MIME Baseline Requirements revision table at each new version.

S/MIME Baseline Requirements: Profiles, Legacy Sunset and Upcoming Certificate Deadlines