¶ºÒõ¹Ý

The CA/B Forum’s S/MIME Baseline Requirements (BRs) promised to bring order to a long-fragmented ecosystem. At last, certificate authorities would follow a common standard. Email clients would know what to expect, and organizations could deploy signing and encryption with confidence.

That was the idea. And the stakes are high: Email remains the foundation of how organizations communicate—internally, with clients, and across regulated industries like finance and healthcare, where weak or noncompliant certificates can lead to compliance violations, audit failures, and reputational damage.

But two years in, the reality looks different. Compliance isn’t widespread. Interoperability remains spotty. And many organizations—even those with well-managed PKI programs—are still relying on certificates that wouldn’t pass a basic lint check under the BRs.

The assumptions haven’t caught up to the facts. Organizations believe they’re using trusted certificates, that their email security is standards-based, that their clients and partners are seeing green checkmarks. But in practice, many environments are quietly failing to meet the requirements. And as more clients begin to enforce stricter validation, the gap between perception and reality is becoming a liability.

What the BRs were supposed to solve

Before the BRs, S/MIME was a patchwork. Certificate authorities (CAs) issued certificates in inconsistent ways. Email clients handled them differently. There were no shared rules for identity verification, certificate structure, or cryptographic strength. That inconsistency made S/MIME hard to deploy, hard to trust, and easy to misuse.

The BRs were designed to fix that. They introduced clear, enforceable standards for how S/MIME certificates should be issued, validated, and interpreted, bringing email encryption and signing into line with modern PKI expectations.

For organizations, the promise was simple: cleaner interoperability, stronger identity assurance, and less guesswork. With every CA and client playing by the same rules, the risk of broken encryption, confusing errors, or spoofed messages would finally start to shrink.

What’s happening instead

When the BRs went into effect in 2023, many security teams assumed the shift toward stronger email security was underway. They expected the S/MIME certificates in use—especially in regulated environments—would now meet consistent standards. That new deployments would be safe by default. That legacy certificates would be cleaned up. That clients would start enforcing the rules.

That’s not what happened.

In September 2025, researchers presented the first broad, data-driven look at the state of S/MIME certificate deployment, analyzing over 38 million certificates collected from public LDAP directories across the globe. The found that:

• The vast majority of certificates still don’t meet baseline requirements.

• More than 90% of recent certificates lack the policy identifiers that signal BR compliance.

• A significant portion fail basic linting checks—with missing or malformed fields, weak cryptography, or broken trust chains.

• And critically, many of these certificates are still being accepted by popular email clients and used in real-world deployments.

Why the baseline requirements haven’t taken hold

If the S/MIME BRs were clear, well-scoped, and backed by the major players—why hasn’t adoption followed?

The problem isn’t the standard. It’s the ecosystem.

Unlike TLS, where compliance is driven by browsers, HSTS policies, and certificate transparency logs, S/MIME lives in a far less coordinated environment. There’s no central enforcement mechanism. There’s no public logging system, no automatic revocation or update pipeline. And without ecosystem pressure, change is slow.

Many certificate authorities haven’t fully transitioned their issuance workflows. Some still offer legacy profiles by default, while others haven’t updated how they validate identities or enforce field presence. Meanwhile, email clients are only beginning to warn or block noncompliant S/MIME certificates—a²Ôd some still accept certificates that clearly violate the BRs.

Inside organizations, the story is much the same. S/MIME is often deployed once, then left to run in the background. Few teams have tools to audit what certificates are actually in use, where they came from, or whether they meet the BRs. And because failures are often silent—a broken chain here, a missing revocation URI there—the issues stay hidden until something breaks.

The risks of staying out of alignment

At first glance, a noncompliant S/MIME certificate might not seem urgent. It still signs messages. It still encrypts. 

But that sense of normalcy is deceptive. As email clients grow stricter and enforcement catches up, the certificates that quietly worked yesterday can suddenly start to fail, breaking encryption, invalidating signatures, or eroding trust in critical communications.

The real risk is that most organizations don’t see it coming. They don’t have visibility into which certificates are outdated, misconfigured, or vulnerable. They can’t easily audit what’s in circulation or explain why a signature failed. And they may not realize they’re using weak cryptography or expired trust chains until a message goes undelivered or unreadable.

In regulated industries, these failures aren’t just technical—they’re operational and reputational. A missed message, a spoofed sender, or a broken chain can carry real consequences. And in most environments, they’re nearly impossible to detect without the right tools in place.

The first step isn’t replacement—it’s awareness

Most organizations don’t have a clear view of the S/MIME certificates circulating across their infrastructure. Without that visibility, it’s nearly impossible to know whether the certificates in use are compliant, trustworthy, or even secure.

That’s where certificate linting becomes essential. Tools like —a²Ô open-source certificate linter developed by ¶ºÒõ¹Ý—are designed to identify exactly these issues. pkilint scans certificates for BR violations, cryptographic weaknesses, structural errors, and other red flags that most systems never surface.

In fact, the USENIX study used pkilint to analyze nearly 10 million certificates. The findings were striking: Millions of certificates failed basic checks, including missing policy identifiers, misconfigured key usages, and invalid AIA fields. These aren’t edge cases. They’re widespread problems that often go undetected.

By integrating linting into issuance workflows, directory audits, or even partner assessments, organizations can start replacing guesswork with actionable insight—a²Ôd take control of their S/MIME posture before enforcement catches up.

Build a future-proof S/MIME strategy with ¶ºÒõ¹Ý

Email signing and encryption protect your most sensitive communications, your reputation, and in many cases, your regulatory standing. Relying on certificates that don’t meet the standard—or not knowing which ones do—is a risk you shouldn’t have to take.

That’s where ¶ºÒõ¹Ý can help.

With tools like pkilint, you can start by gaining visibility, scanning your certificate inventory for compliance issues before they become failures. From there, ¶ºÒõ¹Ý’s solutions support full lifecycle S/MIME management, trusted issuance aligned with the BRs, and integrations that simplify deployment across large, distributed environments.

Whether you're modernizing an in-house PKI, securing communications across regulated teams, or cleaning up legacy infrastructure, ¶ºÒõ¹Ý gives you the insight and control you need to close the compliance gap. 

Because email trust shouldn't depend on luck. It should depend on your standards—a²Ôd on the tools built to uphold them.