Which teams are accountable for S/MIME governance when certificates span HR, PKI, and domain ownership?

Why This Matters for Security Teams

S/MIME governance becomes difficult when certificate issuance depends on evidence from HR, trust decisions from PKI, and proof of domain control from messaging or DNS owners. That split can be harmless on paper, but in practice it creates gaps in accountability for renewal, revocation, and exception handling. NIST Cybersecurity Framework 2.0 encourages clear ownership across governance and protection activities, which is exactly where S/MIME programs often fail when no single team is answerable for the full certificate lifecycle.

The security risk is not limited to expired certificates. Weak governance can lead to certificates being issued against outdated employment records, stale mailbox identities, or domains that have changed hands without a formal review. Once trust is established, users and mail gateways tend to assume messages are authentic until a failure becomes visible. The real issue is that S/MIME is often treated as a technical deployment, when it is actually an identity assurance and authority problem. In practice, many security teams encounter S/MIME failures only after a certificate has already expired, been misissued, or continued to validate after the underlying identity evidence was no longer current.

How It Works in Practice

A workable model assigns one control owner for policy and separate operational owners for evidence, issuance, and transport. HR typically owns employee status signals, such as joiner, mover, and leaver events. PKI or certificate management teams own issuance, renewal, revocation, key protection, and certificate policy enforcement. Domain or messaging owners verify that the relevant email domain is under organisational control before trust is extended. Those responsibilities should be documented in a control matrix, not left implicit.

In mature environments, the process usually depends on three checks:

• Identity evidence is current, meaning the person or service account is still authorised to use the mailbox.
• Certificate authority rules are enforced, meaning issuance matches policy and approval requirements.
• Domain ownership is verified, meaning the organisation still controls the namespace tied to the certificate.

Good governance also requires event-based revocation. When someone leaves, changes role, or loses mailbox authority, the certificate should be reviewed immediately rather than waiting for expiry. That expectation aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially the controls that support access enforcement, auditability, and cryptographic key management. Organisations should also maintain evidence of certificate purpose, issuer, validity period, and approval path so auditors can trace who authorised trust and why.

Operationally, the most effective handoff is a formal ticket or workflow that links HR status, PKI issuance records, and domain validation evidence to a named control owner. That owner does not need to perform every task, but must be able to prove who did what, when, and under which policy. These controls tend to break down when directory data, certificate records, and domain administration are managed in separate systems with no shared revocation trigger because stale identity evidence and delayed change propagation leave valid-looking certificates in circulation.

Common Variations and Edge Cases

Tighter certificate governance often increases administrative overhead, requiring organisations to balance assurance against operational speed. That tradeoff becomes more visible in large enterprises, subsidiaries, and outsourced messaging environments where ownership is split across multiple legal entities or IT providers.

One common edge case is contractor or partner accounts. Current guidance suggests they should not inherit the same lifecycle assumptions as employees, because HR events may not reflect real mailbox authority or business sponsorship. Another is shared mailboxes or functional addresses, where the “user” is really a role or team. In those cases, governance should be tied to a documented business owner, but there is no universal standard for this yet, so organisations should define it explicitly in policy.

Domain ownership also creates exceptions. A certificate can be technically valid while the domain is no longer strategically controlled by the same team, especially after mergers, divestitures, or DNS delegation changes. For that reason, certificate review should not stop at issuance logs. It should include periodic validation that the issuing authority, mailbox ownership, and domain control still align. Where S/MIME is used for regulated communications, mapping that process to NIST Cybersecurity Framework 2.0 helps separate governance responsibilities from operational tasks and makes ownership disputes easier to resolve before trust breaks down.

Related resources from NHI Mgmt Group

• Why do Kubernetes certificates create a governance issue for IAM teams?
• How should security teams use IAST and RASP in NHI governance?
• Who is accountable for quantum migration when certificates and identities span multiple teams?
• How should security teams prioritise NHI remediation in cloud environments?