S/MIME for Teams: Key Custody and Offboarding

One certificate, two jobs, one of them recoverable

An S/MIME certificate is used for two operations that fail in completely different ways. Signing proves a message came from that mailbox and reached the recipient unaltered; if the signing key is lost, you request a new certificate and carry on. Encryption is the other job: mail arriving at that address was encrypted to that specific public key, and only the matching private key opens it. Lose that one and the archive is closed.

This asymmetry is the thing that makes a team deployment different from a personal one. One person losing their own key loses their own mail, which is unpleasant and self-correcting. Fifty people using company mailboxes are holding keys to correspondence the company is legally and commercially responsible for, and the person holding the key is not the person who owns the data.

There is a design consequence hiding in that split. Escrowing an encryption key protects company data. Escrowing a signing key means somebody other than the named sender can produce that person's signature, which quietly drains the meaning out of the signature. Deployments that want both properties issue two certificates per user: an escrowed encryption key, and a signing key that never leaves the device. Issue one certificate for both jobs and you have chosen one property at the expense of the other, whether or not anyone wrote that down.

Worth being precise about what encryption here actually covers. S/MIME protects the message body and attachments end to end under RFC 8551. Headers travel in the clear, so subject lines, sender and recipient are visible to anything that handles the message. Teams that assume a subject line is protected have been surprised more than once.

Who should hold the private keys?

There are two models and no third. Either the key pair is generated on the user's device and no copy exists anywhere else, or the organisation keeps a recoverable copy, which is what key escrow means. For business mail, most teams need the second, because the correspondence belongs to the company and outlasts the employment. For signing-only deployments and for contractors, the first is usually right.

The mechanics of escrow are more careful than "IT keeps a copy somewhere". In Active Directory Certificate Services, key archival encrypts the user's private key with a symmetric key, which is itself encrypted to the public key of a nominated Key Recovery Agent, and the result is stored in the CA database. Getting a key back needs a certificate manager to pull the record and a key recovery agent to decrypt it. Two roles, deliberately, so that one administrator acting alone cannot read anybody's mail.

Whatever the mechanism, the same three questions decide whether an escrow arrangement is real or decorative. Who can start a recovery, and who has to approve it? How is the recovered key delivered to whoever needs it, given that emailing it defeats the point? And is the recovery logged somewhere the person whose key it is could later see? A scheme without answers to those is a copy of everyone's keys with a nice name.

That last row is the one people read too fast. Escrow captures the key at the moment it is created. Deciding six months into a rollout that recovery matters protects everything issued from that day forward and does nothing at all for the certificates already in the field.

Google and Microsoft answer this differently

The two dominant mail platforms make opposite assumptions about where a private key belongs. Google Workspace hosted S/MIME requires the private key to be uploaded to Google: the certificate and key go up together as a PKCS#12 bundle through the Gmail API, because Gmail decrypts on the server rather than in the client. Microsoft 365 never holds the key at all. It sits in the user's certificate store, and any recoverable copy has to come from infrastructure you run.

On the Google side, an administrator enables S/MIME for the domain first, then each user's certificate and key are loaded through the Gmail API's smimeInfo.insert() method, with the PKCS#12 bundle carrying the key and the signing certificate chain. Because the platform can decrypt, encrypted mail stays searchable and a recovery path exists without you building one. The cost is stated plainly in the design: Google is inside the trust boundary. Whether that is acceptable is a policy question, and it is a much better question to answer deliberately than to discover. The Google Workspace S/MIME setup walkthrough covers the click path.

On the Microsoft side, the key stays with the user and the platform stays out of it, which is a stronger confidentiality story and a weaker recovery one. Two operational details catch teams out. Outlook on the web needs the Microsoft S/MIME browser extension force-installed through the ExtensionInstallForcelist policy in Edge or Chrome, so a user who reads mail in a browser on an unmanaged machine simply cannot open encrypted messages. And support in the new Outlook for Windows has been arriving in stages: as of August 2026, signing and encryption work, storing recipients' S/MIME certificates in Contacts rolled out during May 2026, and coverage for shared and delegate mailboxes has been landing through the same period. If your rollout plan was written against classic Outlook, check the current state before you promise anyone a date. The Outlook S/MIME installation guide covers the per-user side.

Neither platform is imposing a limit here, only a default. You can run user-held keys on Google Workspace by skipping hosted S/MIME and doing client-side S/MIME instead, and you can build escrow on Microsoft 365 with your own certificate service. Both overrides cost real effort, which is why the default usually wins and why it is worth knowing which default you inherited.

What about info@ and billing@?

A shared mailbox has no individual to validate, so it needs a certificate issued against the mailbox rather than a person. Under the CA/Browser Forum's S/MIME Baseline Requirements that is a mailbox-validated or organization-validated certificate, and its private key then has to reach everyone who reads that address. Shared keys are escrow by another name, so treat them that way from the start.

Two practical rules follow. Keep the key in a controlled place rather than in four people's downloads folders, because a PKCS#12 file passed around on chat is the most common way a business key ends up somewhere nobody can account for. And accept that rotating the key when someone leaves the team protects future mail only. Everything encrypted to the old key is still encrypted to the old key, and the departing person kept whatever copy they had. If that matters for a given mailbox, shared S/MIME is the wrong tool for it.

Which validation type each mailbox needs is a decision worth making per address rather than once for the whole company; the breakdown of mailbox, organization, sponsor and individual validation sets out what each one asserts and what it costs in paperwork.

What happens when someone leaves?

Three things have to happen and only one of them is obvious. Preserve the encryption key so the mailbox archive stays readable. Decide between revoking the certificate and letting it expire. Remove the key from the departing person's devices. The order matters, because standard IT offboarding wipes the laptop early, and on a machine holding the only copy of a key that step is the one that cannot be undone.

The revoke-or-expire question is less obvious than it looks. Revocation is the right answer whenever the key may have been copied, or the departure was not amicable, and it should happen immediately in those cases. For an ordinary leaver it is worth knowing that mail clients differ in how they present a signature made before the revocation date: some show it as valid, some flag the whole message. Where policy allows, letting a certificate run to its expiry avoids re-litigating years of signed correspondence in whatever client the recipient happens to use.

A short runbook that survives contact with a real leaving date:

1. Export the key pair to your escrow store, or confirm it is already there, and verify the export actually opens a test message before trusting it.
2. Decide revoke or expire, and write down why, because the next person to handle a leaver will want the precedent.
3. Remove the certificate and key from every device and browser profile the person used, including any personal machine you allowed.
4. Record where the retained key now lives, whose approval is needed to recover it, and when it is safe to destroy it.
5. Stop new encrypted mail arriving at a mailbox nobody can read: either forward the address to a successor who has their own certificate, or close it.

Step one belongs in the HR offboarding checklist rather than in a document only the security team reads. The people who wipe laptops are rarely the people who know what an S/MIME key is, and that gap is where the archives go missing.

Renewal stops being one calendar entry

As of August 2026, publicly trusted S/MIME certificates run for a maximum of 825 days under the Multipurpose and Strict profiles of the S/MIME Baseline Requirements. The older Legacy profile allowed 1,185 days and could no longer be issued after 15 July 2025. Buy for a whole team on one day and they all come due on one day, which turns a routine renewal into an event.

Staggering deliberately is cheap at the start and impossible later. Issue in a few batches, or accept a single renewal weekend and staff it. What you cannot do is spread the work afterwards, because certificate validity runs from issuance and nothing shortens it retroactively except reissuing early and paying twice.

Two details bite at renewal specifically. Identity vetting can be reused for up to 825 days, so returning customers rarely resubmit documents, while proof of mailbox control expires after 30 days, which is why the paperwork feels remembered and the confirmation click never is. And a renewed certificate carries a new key pair that cannot read anything encrypted to the old one, so the old key has to be kept rather than replaced. The S/MIME renewal walkthrough covers that export step in detail, and at team scale it is the step most worth automating or at least templating.

When a team should not use S/MIME

S/MIME is the wrong tool when the requirement is that people outside the company read protected mail without setting anything up. Microsoft Purview Message Encryption is policy-based, runs on Azure Rights Management, needs no certificates on either end, and lets a recipient on Gmail, Yahoo or Outlook.com open a protected message directly. S/MIME earns its place when you need certificate-based sender identity, a signature that stands on its own, or encryption the mail platform itself cannot read.

The honest version of the comparison is that they solve different problems and plenty of organisations run both. Ad-hoc confidential mail to a customer who has never heard of a certificate is a Purview job. Recurring correspondence with a partner who also runs S/MIME, signed statements that need to verify years later, and any requirement written as "end-to-end" point the other way. A third pattern exists too: gateway encryption, where an appliance signs and encrypts on the way out, which keeps keys off endpoints entirely and gives up genuine end-to-end protection in exchange.

If the driver is a compliance clause rather than a threat model, read the clause closely before choosing. Requirements that name digital signatures or non-repudiation generally mean S/MIME or something like it. Requirements that say confidential mail must be protected in transit are usually satisfied more cheaply. Teams also weighing PGP will find the S/MIME and PGP comparison covers the trust-model difference that decides most of it.

A rollout order that avoids the costly mistakes

Most failed S/MIME rollouts are correctly executed in the wrong order. Certificates get bought first because that is the step with a price on it, and the custody model gets settled later, after it can no longer be applied to what was issued. Running the decisions ahead of the purchase costs nothing and removes the two failure modes that are expensive.

1. Settle custody. Escrow or user-held, and whether signing and encryption keys are separated. Everything else follows from this.
2. Inventory mailboxes, not people. Individual addresses, shared addresses, and anything automated that sends mail. Each shared address counts once and needs its own handling.
3. Pick a validation type per class of mailbox rather than one for the whole company.
4. Pilot with three mailboxes, including one shared one and one person who reads mail on a phone. Phones and browsers are where rollouts stall.
5. Write the recovery procedure down and test it by actually recovering a pilot key. An untested escrow is a belief, not a control.
6. Add the key-preservation step to HR offboarding, ahead of the device wipe.
7. Then buy the rest, in staggered batches, with renewal dates already in a calendar someone owns.

Step seven is where the S/MIME certificate options for individuals and businesses become relevant, and by then you know exactly how many of each shape you need. If you are still deciding between personal and business certificates in the first place, the S/MIME buying guide is the better starting point and this article is the sequel.

FAQ