S/MIME baseline requirements expose a certificate governance gap

At a glance

What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: S/MIME baseline requirements have not meaningfully closed the gap between certificate issuance and certificate governance, because many deployments still rely on certificates that fail basic compliance and linting expectations.

Why it matters: IAM and PKI teams need visibility into S/MIME certificate inventory, structural compliance, and lifecycle control because email trust now depends on enforcement, not assumptions.

Context

S/MIME baseline requirements were meant to standardise email certificate issuance, validation, and interpretation so organisations could rely on consistent trust signals. Instead, many environments still operate with certificates that do not meet the requirements, which turns email trust into a governance problem rather than a one-time PKI deployment task.

For identity and access teams, the issue is not just whether a certificate exists. It is whether the certificate is structured correctly, accepted consistently by clients, and governed across its full lifecycle. In regulated environments, that affects signing, encryption, auditability, and the reliability of partner communications.

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: When should organisations prioritise S/MIME certificate cleanup over new issuance?

A: They should prioritise cleanup when existing certificates are already in use for regulated or externally trusted communications, because new issuance does not fix the trust gap in circulation. If baseline identifiers, linting results, or client acceptance are uncertain, the operational risk sits in the live estate, not in future certificates.

Q: What are the signs that S/MIME is not being used effectively across an organisation?

A: Common signs include sensitive email sent in plain text, inconsistent certificate use across clients, failed signature verification, and users relying on manual workarounds to exchange confidential information. Another warning is when certificates expire or are not revoked promptly, which creates trust gaps. If email security depends on individual discipline instead of managed controls, the programme is fragile.

Q: How should teams respond when email clients accept noncompliant certificates?

A: Treat acceptance as a warning, not a validation of correctness. If clients still accept certificates that violate baseline requirements, the organisation needs stronger linting, clearer issuance controls, and better inventory before enforcement tightens. The goal is to remove uncertainty before client behaviour changes and exposes the problem abruptly.

Technical breakdown

Why S/MIME baseline requirements did not self-enforce

The CA/B Forum’s S/MIME Baseline Requirements were intended to reduce fragmentation by standardising how certificates are issued and interpreted. In practice, standards only change behaviour when the ecosystem enforces them. S/MIME lacks the strong browser-driven enforcement loop that pushed TLS toward consistency, so certificate authorities, email clients, and enterprises have moved unevenly. That leaves legacy profiles, inconsistent validation, and weak structural checks in circulation even after the standard exists.

Practical implication: Treat S/MIME compliance as an enforcement and inventory problem, not a standards-awareness exercise.

How malformed certificates survive in production email flows

A certificate can still sign or encrypt mail even when it fails linting checks, which makes structural defects hard to spot. Missing policy identifiers, malformed fields, weak cryptography, and broken trust chains may not surface until a stricter client, partner system, or audit process encounters them. This is why silent failure is the central operational risk: the certificate appears functional until a downstream control begins to reject it.

Practical implication: Scan certificates before client-side rejection exposes the issue in production.

Why linting is now a governance control, not a quality check

Certificate linting is the practical bridge between baseline policy and operational reality. It exposes whether certificates meet structural requirements, use the expected cryptographic properties, and carry the metadata clients rely on for trust decisions. Without routine linting and directory visibility, organisations cannot explain which certificates are compliant, which are legacy, or which will break first as enforcement tightens.

Practical implication: Embed linting into issuance, directory audits, and partner validation workflows.

Threat narrative

Attacker objective: The practical objective is to exploit weak certificate governance so malformed or legacy S/MIME credentials keep functioning until they create trust failure or communication disruption.

1. Entry occurs when an organisation issues or continues to use S/MIME certificates that lack the baseline policy identifiers or structural checks expected under the BRs.
2. Credential or trust abuse follows when email clients and partner systems continue to accept those noncompliant certificates as if they were valid trust anchors.
3. Impact appears when stricter validation, failed linting, or broken trust chains cause signatures to fail, encryption to break, or communications to lose credibility.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate governance has become the real control plane for S/MIME trust: the standard itself is not the problem, the absence of coordinated enforcement is. S/MIME only becomes reliable when issuance, validation, client behaviour, and lifecycle oversight move together. Practitioners should stop treating certificate standards as static policy and start treating them as continuously governed trust infrastructure.

Structural compliance is now more important than nominal issuance: a certificate that can still sign mail is not necessarily a certificate that should be trusted. Missing policy identifiers, malformed fields, and weak cryptography create a quiet divergence between perceived and actual assurance. That gap is exactly where email trust programmes lose credibility.

Visibility, not issuance volume, is the missing control: many organisations can issue certificates, but cannot say which ones meet baseline requirements today. That is a lifecycle governance failure, not a tooling gap. The practitioner takeaway is that inventory, linting, and client acceptance monitoring now belong together.

Baseline requirements expose a certificate governance gap: the industry assumed that a published standard would translate into immediate behavioural change. It did not, because the ecosystem around S/MIME lacks the enforcement machinery that makes a standard operational. The implication is that email trust programmes must be run as governance systems, not as one-time PKI projects.

Regulated communication depends on certificate integrity becoming observable: in finance, healthcare, and other controlled environments, silent certificate drift can become an audit and reputational issue before it becomes a security incident. That means certificate health has to be reportable, not merely assumed, if organisations want dependable signed and encrypted email.

From our research library:

• 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.

What this signals

Certificate drift is now an email governance issue: when standards exist but do not materially change what is deployed, the control gap moves from policy design to lifecycle visibility. Teams should expect baseline compliance to be judged by actual certificate structure and acceptance, not by whether a standard was published.

The practical question is whether organisations can prove which certificates are current, lint-clean, and still accepted by the clients that matter. If that answer is unclear, email trust is already depending on assumption rather than governance.

For practitioners

• Inventory all active S/MIME certificates Build a current inventory of certificates used for signing and encryption across internal directories, partner workflows, and regulated business units. Include issuer, validity period, policy identifiers, key usage, and client acceptance status.
• Run baseline linting across the certificate estate Check for missing policy identifiers, malformed fields, invalid authority information access values, and weak cryptography before stricter clients surface the defects for you.
• Prioritise certificates in regulated communications Focus first on teams handling finance, healthcare, legal, and executive mail flows where broken signatures or failed encryption create immediate compliance and trust consequences.
• Integrate certificate checks into issuance workflows Require linting and policy verification before new certificates enter production so legacy profiles do not continue by default.
• Monitor client acceptance behaviour Track where popular mail clients still accept certificates that do not meet the baseline requirements so you can identify the gap between nominal compliance and real enforcement.

Key takeaways

• S/MIME baseline requirements have not by themselves eliminated inconsistent certificate deployment or silent trust drift.
• The main evidence of the gap is structural, not theoretical, with many certificates failing linting or lacking policy identifiers.
• The right response is continuous certificate governance, including inventory, linting, and lifecycle checks before enforcement exposes failures.

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.
• Trust Chain: The trust chain is the set of delegated relationships that lets one system, token, or integration act on behalf of another. In NHI security, it is often the real attack surface because compromise travels through legitimate permissions instead of obvious malware.
• Certificate Governance: The operational and policy discipline that covers certificate issuance, validation, revocation, renewal, and exposure. It is a lifecycle control, not just a cryptographic one, because trust can fail when ownership, failure paths, and revocation checks are not actively managed.

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 building or maturing an IAM programme, it is worth exploring.