Board email the IT team can't read
S/MIME end-to-end with board-owned keys — structural privacy, not policy privacy.
The problem with "just use Google Workspace"
When a company runs on Google Workspace or Microsoft 365, the domain admin can read any email. That's not a bug — it's the product. Admins can delegate mailbox access, run eDiscovery queries, and pull any message in the org. Cloud providers also comply with subpoenas, government requests, and their own internal audit processes.
For most email this is fine. For board communications it's a governance problem. Compensation committee discussions, M&A deliberations, whistleblower concerns, and audit committee findings are the precise categories of communication that should not be accessible to the employee being evaluated, the executive whose pay is being set, or the CTO who manages the infrastructure those emails live on.
The threat model
- Admin-level access. Whoever holds super-admin credentials can read any mailbox. In most orgs that's IT leadership — the same people sometimes under board scrutiny.
- Cloud provider legal exposure. A subpoena to Google or Microsoft reaches board communications. A subpoena to your EC2 instance needs to come to you first.
- Data-at-rest breach. Cloud provider compromise exposes plaintext mail. Your isolated instance with encrypted EBS and no internet-facing data path has a much smaller blast radius.
- Insider investigation. If the subject of a board investigation controls the email infrastructure, you have a structural conflict. Architecture should remove that conflict, not rely on the subject's good behaviour.
The architecture
Three components. Each one removes a separate failure mode.
- Isolated EC2 instance. Private VPC subnet. No public IP on the mail data volume. TLS-only SMTP/IMAP ingress through a dedicated security group. CloudTrail on. The instance serves only board-tier addresses — it is not the company's general mail server. EBS volume encrypted at rest. Access to the instance itself is IAM-controlled and logged, with reports going to the board chair — not IT.
- S/MIME enforcement at the MTA. The mail server is configured to reject unencrypted messages between board member addresses. If a message arrives without a valid S/MIME signature and encryption, it bounces. There is no opt-out. This is a policy enforced in software, not in a handbook.
- Board-owned keys. This is the critical part. Each board member generates their own keypair. The private key never leaves their custody. IT receives only the certificate signing request (CSR) — the public portion. IT signs it, returns the cert, and deletes the CSR. The private key was never present. Communications encrypted to that cert are unreadable by IT, structurally, not by promise.
The key ceremony
This step is where most implementations cut corners and break the guarantee. Do it right.
- Board resolution first. Formally document the key policy: no escrow, no IT custody, key loss means cert reissuance, departing members' certs are revoked.
- Generate on the member's device. Each board member generates their keypair locally.
openssl req -newkey rsa:4096 -keyout member.key -out member.csr— or, better, on a hardware token (YubiKey 5 series). Hardware-bound keys are non-exportable by design. - IT receives only the CSR. The signing authority (a private CA running on the same isolated EC2, or AWS Private CA) signs the CSR and returns a cert. The CSR is deleted after signing.
- Member imports the cert + their private key into their mail client. Apple Mail, Outlook, and Thunderbird all support S/MIME natively. Once configured, encryption and signing are automatic.
- IT can verify the cert is valid. IT cannot decrypt messages encrypted to it.
Where this pattern is already used
This isn't a novel idea. It's standard practice in several sectors, often for legal or regulatory reasons:
- BigLaw. Attorney-client privilege requires that privileged communications be demonstrably secured. Large law firms routinely run on-premises or isolated mail infrastructure for client matter communications, separate from their general corporate email.
- Financial services. OCC and FRB governance guidance for bank boards creates pressure to segregate board communications. Deal teams at investment banks use isolated environments for M&A communications specifically to limit who has access while a transaction is live.
- M&A project rooms. When a public company is in deal negotiations, it's common practice to run board and advisor communications on a separate, access-controlled mail domain for the duration of the deal. Leaks from general corporate email have killed deals and triggered insider trading investigations.
- Delaware corporate governance. Audit committee and compensation committee communications carry fiduciary weight. Post-Sarbanes-Oxley, many public company boards formalized communication segregation specifically to reduce the risk of the executive team having visibility into governance discussions.
- Defense contractors. Cleared facilities running government contracts often maintain separate cleared networks for board-level communications with cleared directors. SMIME with CAC card or PIV credentials is the federal standard.
What IT can and cannot see
- Visible to IT: From, To, Date, Subject, message size. S/MIME encrypts the body and attachments, not the headers.
- Not visible to IT: Message body, attachments, any content of the communication.
- If full metadata privacy is required: S/MIME supports opaque signing with an inner encrypted layer. The outer envelope carries only routing; the subject line is moved inside the encryption. Fewer mail clients handle this cleanly, so evaluate the tradeoff.
- Infrastructure access is separately logged. CloudTrail and VPC flow logs give the board chair an independent record of who accessed the server infrastructure and when. IT access to the instance is not invisible — it's just not the same as access to message content.
The governance value of structural limits
The implementor can prove they couldn't read the mail. That matters when the board is conducting a sensitive investigation, setting executive compensation, or deliberating on a matter where the IT function has a conflict. Policy says "we won't look." Architecture says "we can't." The second one is the one that holds up.
It also protects IT. If there's ever an allegation that the CTO monitored board deliberations about their own performance, cryptographic architecture is the cleanest possible defense. You can't be accused of reading mail you were structurally unable to decrypt.
Board-owned keys, server-enforced S/MIME, isolated infrastructure, audit logs to the chair — not the admin. That's the complete pattern.