S/MIME baseline requirements expose a certificate governance gap

At a glance

What this is: This is an analysis of why S/MIME certificates are still failing baseline requirements and what that reveals about email identity governance.

Why it matters: It matters because email trust depends on certificate lifecycle control, and weak S/MIME governance can disrupt compliance, signature validation, and secure communications across both human and machine-adjacent workflows.

By the numbers:

• In September 2025, researchers analyzed over 38 million certificates collected from public LDAP directories across the globe.

👉 Read DigiCert's analysis of why most S/MIME certificates still miss baseline requirements

Context

S/MIME certificate governance is the discipline of making sure email signing and encryption certificates are issued, structured, and validated consistently across an organisation. The primary problem in this article is that baseline requirements exist, but many deployments still do not meet them, which leaves email identity assurance weaker than teams assume.

For IAM, PKI, and compliance teams, the gap is not theoretical. Email remains a core business channel, yet certificate inventories are often unmanaged after issuance, so failures stay hidden until clients or auditors surface them. That makes S/MIME posture part of identity lifecycle control, not just cryptographic hygiene.

The article’s central finding is that the ecosystem has not absorbed the CA/B Forum’s S/MIME Baseline Requirements at the same pace as the standard’s intent. In practice, organisations may believe they have compliant, standards-based email trust when they actually have a mixed estate of legacy profiles, malformed fields, and silent acceptance by clients.

Key questions

Q: What breaks when S/MIME certificates do not meet baseline requirements?

A: When S/MIME certificates miss baseline requirements, organisations can lose reliable signing and encryption assurance even though mail appears to work. Messages may fail validation in stricter clients, trust chains can break, and audit evidence becomes harder to defend. The deeper risk is that noncompliance stays hidden until enforcement or a partner dependency forces the failure into view.

Q: Why do S/MIME certificates create compliance risk in regulated environments?

A: S/MIME certificates create compliance risk because they carry identity and trust evidence that regulators, auditors, and partners may expect to be consistent and enforceable. If policy identifiers, cryptographic strength, or revocation data are missing, organisations can no longer prove that protected communications follow the standard they claim to use.

Q: How do security teams know whether S/MIME governance is working?

A: S/MIME governance is working when certificate inventories are current, linting is embedded in issuance and audit workflows, and email clients reject or flag noncompliant material instead of silently accepting it. If teams cannot explain which certificates are active, where they came from, and whether they meet the baseline, governance is not working.

Q: Who is accountable when noncompliant S/MIME certificates remain in production?

A: Accountability usually spans PKI operations, IAM or identity governance, and compliance teams because S/MIME is both an identity control and a communications control. The organisation is responsible for maintaining policy alignment, but operational ownership should be explicit so legacy certificates do not survive outside review cycles.

Technical breakdown

Why S/MIME baseline requirements fail without ecosystem enforcement

The BRs only work when issuers, clients, and administrators all enforce the same rules. S/MIME lacks the equivalent of browser-driven pressure that helped tighten TLS, so certificate authorities can still keep legacy issuance paths alive and clients may continue to accept certificates that should be rejected. That creates a standards gap where compliance exists on paper but not in runtime behaviour.

Practical implication: treat client acceptance, issuance policy, and inventory auditing as one control plane, not separate tasks.

How malformed certificate fields create silent identity failures

A certificate can still appear usable while violating baseline expectations. Missing policy identifiers, broken trust chains, weak cryptography, malformed key usage, and invalid AIA fields all undermine identity assurance without always breaking message flow immediately. That is why S/MIME failures often remain invisible until a stricter client, partner, or auditor finally enforces the rule set.

Practical implication: lint certificates before deployment and continuously scan production inventories for hidden noncompliance.

Why certificate lifecycle management is the real control gap

The issue is not only issuance quality. Many organisations deploy S/MIME once and never revisit the certificate state, which means outdated profiles, weak chains, or noncompliant fields persist long after policy changes. In identity terms, this is lifecycle drift: the certificate outlives the controls that were supposed to govern it.

Practical implication: tie S/MIME governance to lifecycle review, not just initial provisioning.

NHI Mgmt Group analysis

S/MIME baseline requirements have exposed a certificate lifecycle governance gap, not a standards problem. The article shows that the BRs exist, but many environments still operate with certificates that do not meet them. That means the weak point is governance follow-through across issuance, validation, and inventory control. Practitioners should read this as a lifecycle failure in email identity, not a cryptographic debate.

Silent noncompliance is the most dangerous S/MIME failure mode because it preserves the illusion of trust. Certificates can continue to sign and encrypt while still carrying malformed fields, weak cryptography, or missing policy identifiers. When clients keep accepting them, teams lose the feedback loop that would normally force remediation. The implication is that email identity assurance cannot depend on user-visible success alone.

Certificate linting should be treated as an identity control, not a specialist diagnostic. The article’s use of pkilint reinforces a broader programme lesson: compliance checking has to move into normal operational workflow, not sit outside it as an occasional audit exercise. That is especially important in regulated sectors where broken signatures or unreadable encrypted mail can become audit findings. Practitioners should elevate linting to a repeatable control.

Lifecycle drift: S/MIME certificates were designed for an environment where policy updates and enforcement would keep pace with issuance, but that assumption fails when legacy certificates remain accepted for years after the rules change. The implication is that email trust programmes must rethink what “valid” means over time, because acceptance by a client is not the same thing as compliance with the baseline.

S/MIME governance now sits at the intersection of human identity and operational identity assurance. The channel is used by people, but the trust object is a certificate that behaves like an NHI credential with a lifecycle, scope, and validation state. That makes email security a shared problem for IAM, PKI, and compliance teams. Practitioners should govern the certificate, not just the mailbox.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, which is a useful reminder that lifecycle control often fails before the breach does.
• For a broader standards view, see Ultimate Guide to NHIs , Standards for how NIST, OWASP NHI, SPIFFE, and zero trust controls map to identity governance.

What this signals

Certificate inventories will need to be governed like credential inventories. As email clients become less forgiving, the operational question shifts from whether a certificate was issued correctly to whether it remains valid, compliant, and enforced across the full estate. Teams that already manage secrets, workload identities, and service accounts should treat S/MIME as part of the same lifecycle discipline, not a side channel.

The practical signal for IAM and PKI leads is that acceptance cannot be the metric. If a certificate is still being used but would fail linting or baseline checks, the programme has hidden drift. That creates a future enforcement event, whether from a stricter client, a partner audit, or a regulatory review.

Lifecycle drift in S/MIME mirrors the same control gap seen across other non-human credentials. The object changes slowly, but the policy environment changes faster. When that happens, organisations need recurring review, not one-time issuance assurance, and they need it in the same operational cadence they use for other identity-bearing artifacts.

For practitioners

• Inventory every active S/MIME certificate Build a current view of issued certificates, including source CA, policy identifiers, key usage, and trust-chain status. Without a live inventory, noncompliant certificates remain invisible until a client or partner rejects them.
• Run certificate linting before and after issuance Use linting in the issuance workflow and in periodic directory audits to catch missing policy identifiers, malformed fields, weak cryptography, and broken AIA values before they spread through the environment.
• Tie S/MIME review to lifecycle governance Add S/MIME certificates to access review, renewal, and offboarding processes so legacy profiles do not survive policy changes, partner changes, or organisational restructuring.
• Test client enforcement against noncompliant certificates Validate how major email clients behave when certificates lack baseline requirements, because acceptance in production may hide the exact failures that stricter enforcement will expose later.

Key takeaways

• S/MIME problems persist because governance, enforcement, and lifecycle review have not kept pace with the baseline standard.
• The evidence points to silent noncompliance, where certificates still function even though they would fail stricter validation or audit checks.
• The practical response is to inventory, lint, and continuously review certificates as identity assets rather than treating issuance as the end of the control.

Key terms

• S/MIME Baseline Requirements: A shared set of rules for issuing and validating S/MIME certificates used to sign and encrypt email. They aim to reduce inconsistent trust decisions by standardising certificate fields, identity checks, and cryptographic expectations across certificate authorities and clients.
• Certificate Linting: Automated checking of certificate structure, fields, and policy data against expected rules. In practice, linting finds malformed or noncompliant certificates before they fail in production, making it a useful control for lifecycle assurance and trust validation.
• Certificate Lifecycle Governance: The ongoing management of issued certificates from creation through renewal, review, and retirement. It ensures certificates remain compliant and trusted after issuance, which matters because standards, clients, and organisational policies can change long before a certificate expires.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Why Most S/MIME Certificates Are Still Missing the Mark. Read the original.