If your email encryption gateway is compromised: revoke keys, protect archived mail and rebuild

A compromised email encryption gateway can expose every message it was trusted to protect, because it holds the private keys that decrypt inbound mail, the signing keys that vouch for outbound mail and the policy that decides which messages get encrypted at all. This playbook covers the response when that gateway, or the accounts that run it, can no longer be trusted: how the compromise shows up, the first hour of triage, containment in priority order, key and certificate revocation, rebuild, and what to tell partners and regulators. It applies to self-hosted gateways, virtual appliances and cloud policy-based encryption services, including the external recipient portal many of them run. It is written for messaging engineers, PKI teams and incident responders, and it is vendor-neutral, so confirm exact menus and commands in your own product's documentation. Preventive hardening is in Securing the Email Encryption Gateway Itself, and filtering gateways are handled separately in If your email security gateway is compromised; this page does not repeat either.

Key takeaways

• Decide early whether private keys left the gateway. If keys were exportable and an attacker had admin or root access, assume they were copied and revoke them; if keys sat non-exportable in an HSM, the exposure is limited to the period the attacker could use them.
• Revocation protects the future, not the past. A copied decryption key still opens every archived or intercepted message encrypted to it, so scope the past exposure separately from issuing new keys.
• Escrow decides whether you can recover. Retrieve escrowed keys under split custody before rebuilding, or archived mail may become unreadable to you while staying readable to the attacker.
• Policy tampering is as serious as key theft. A bypass rule that sent mail in clear, or a routing change that copied decrypted mail out, exposes content without touching a key.
• Partners must learn your new certificates. Gateway to gateway encryption and S/MIME signing fail or stay exposed until correspondents replace the old public keys you have revoked.

What an attacker gains, by component

An encryption gateway concentrates three kinds of power. The response for each is different, so establish early which of them the attacker reached.

RFC 8551 describes a trusted gateway removing the encryption envelope of a message while leaving its signature intact. That is the normal job of an inbound gateway, and it is why the gateway and every point downstream of it hold plaintext. Relevant ATT&CK techniques are T1114 Email Collection and T1114.002 Remote Email Collection for mail copying, T1649 Steal or Forge Authentication Certificates for key and certificate theft, T1557 Adversary-in-the-Middle for rerouting, T1098 Account Manipulation for new admin roles and T1685 Disable or Modify Tools for switching encryption policy off.

How the compromise shows up

• Key events: a key or certificate export, an escrow recovery, a new key import or a change to key admin roles that no change ticket explains.
• Policy drift: new bypass entries for domains or recipients, encryption rules switched from enforce to optional, or decryption scanning disabled for a group.
• Routing changes: new journaling or blind copy destinations on the gateway, or new transport rules and connectors on the mail platform that send mail around or out of the gateway.
• Portal anomalies: bulk downloads, admin sign-ins from new locations, or a spike in passcode failures against recipient accounts.
• Outside signals: a partner reports signed mail from your domain that you did not send, or a CA reports certificates issued to your email addresses that nobody requested.
• Platform compromise: a vendor security advisory for your version, unexpected processes or outbound connections from a self-hosted appliance, or a vendor notice about its own cloud service.

Triage: the first hour

1. Classify the access. Was it an admin account in the console, root or code execution on the platform, an integration credential, or a vendor-side incident? Root access means every key the platform could read is presumed copied.
2. Establish key storage. For each key, record whether it was non-exportable in an HSM or key service, or held in software on the gateway. See the HSM Deployment and Operations Guide.
3. Fix the window. Find the earliest suspicious event in gateway and mail platform audit logs; this bounds which messages, policies and certificates you review.
4. Locate escrow. Confirm where escrowed encryption keys are held, who the custodians are, and whether the escrow store was reachable from the compromised accounts.
5. List dependants: partner domains using gateway to gateway encryption, users with gateway-held S/MIME certificates, the archive, the CA enrolment profile and the portal.
6. Decide on mail flow. Choose whether sensitive outbound mail is paused, sent through an alternative path, or held, and tell the business which classes of mail are affected.

Containment by priority

1. Freeze and capture. Export gateway policy, bypass lists, routing, admin roles and audit logs before anyone changes them, and forward a copy to storage the gateway admins cannot alter.
2. Lock admin access. Disable every gateway admin account except a named response group, reset the built-in or local administrator, revoke API keys and sessions, and remove admin role mappings from directory groups until reviewed.
3. Cut copy paths. Remove unknown journaling, blind copy and outbound routes on the gateway, and unknown transport rules and connectors on the mail platform. This stops ongoing collection even before keys are replaced.
4. Restore enforcement. Reinstate the last approved encryption policy and remove bypass entries that lack an owner and approval, so outbound mail is not leaving in clear during the response.
5. Disable integration credentials. Suspend the directory bind account, the CA enrolment credential, archive and journaling accounts and automation clients, then issue new ones only to the rebuilt gateway.
6. Isolate a compromised platform. Where code execution occurred, take a self-hosted gateway off the network apart from a forensic path and route mail through a standby or the mail platform's own encryption feature.

Rollback: keep the captured configuration so that a containment step that breaks a legitimate business flow can be reversed deliberately, with a record of who approved it.

Key and certificate revocation

Revocation tells relying parties to stop trusting a key from now on. It does not make previously encrypted mail safe. Work through the keys in this order.

Non-exportable keys: where the HSM or key service logs show the keys never left it, you may decide to keep them after the attacker's access is removed. That is a risk decision: the attacker could still have used the keys to decrypt captured mail during the window. Most organisations re-key anyway, because the cost of new certificates is small compared with the doubt.

Escrow before rebuild: recover escrowed encryption keys under the agreed split custody into a clean key store first. Without them, archived mail encrypted to the old keys cannot be read after the rebuild. The Cryptographic Key Management Guide covers custody models.

Scoping the past exposure

• Keys copied: treat every message encrypted to those keys as potentially readable by the attacker, including archives, backups and anything captured in transit. Identify which mailboxes, partners and data classes that covers.
• Policy or routing tampering: use message trace for the window to list messages that matched altered rules or new routes, and record their recipients and classification. See the Email Gateway and Message Trace Detection Guide.
• Portal: list messages held and downloaded during the window, and which recipient accounts were accessed from unusual locations.
• Plaintext stores: check quarantine, journaling targets and any decryption scanning output, which hold readable copies regardless of key status.
• Signatures: ask partners to report signed mail from your domain received during the window, so forged instructions, such as payment changes, can be caught.

Eradication and rebuild

1. Build a fresh gateway on a current release from vendor media, not from a full configuration backup taken during the window.
2. Create the key store first. Generate new keys non-exportable in an HSM or key service where supported, and import recovered escrow keys only for decrypting archived mail, never for new encryption.
3. Re-create policy from a reviewed baseline, entry by entry, with an owner and expiry on every bypass rule.
4. Split admin roles for platform, key, policy, review and audit before returning access to anyone. NIST SP 800-53 AC-5 is the reference.
5. Reconnect integrations with new credentials: certificate based connectors to the mail platform, a read only directory account and an enrolment profile limited to email protection certificates.
6. Clean the mail platform of rules, connectors and application consents created in the window.

Recovery and partner coordination

1. Pilot outbound encryption with one internal domain and one partner, confirming that messages encrypt with the new keys and decrypt correctly.
2. Distribute new public keys to every gateway to gateway partner, with a contact who confirms the old key has been removed from their configuration.
3. Re-enrol users whose S/MIME certificates were gateway-held, and publish the new certificates to the directory used for recipient lookup.
4. Test archive access by decrypting a sample of archived mail with the recovered escrow keys.
5. Restore the portal with new admin credentials, forced re-verification of recipient accounts and message expiry applied to items held during the window.
6. Widen in rings until all mail flows through the new gateway, then retire the standby path.

Evidence and notification

• Preserve: the isolated gateway or its disk image, HSM and key service logs, gateway and mail platform audit logs, policy and routing exports, portal access logs, CA issuance records and message trace for the window.
• GDPR Article 33: the controller notifies the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk to individuals.
• GDPR Article 34(3)(a): notifying individuals is not required where measures such as encryption made the data unintelligible to unauthorised people. That protection is lost when the attacker holds the decryption key, so do not rely on it for messages encrypted to a copied key.
• Other regimes: sector and national reporting rules may apply. See the Data Breach Notification Checklist and the Cyber Incident Reporting Requirements Map.
• Partners and vendor: tell correspondents which keys were revoked and why, and open a case with the gateway vendor, keeping case numbers and indicators of compromise.

Decision guidance

Detection and measurement

• Time to revoke: hours from declaration to revocation of every key presumed copied.
• Keys in hardware: percentage of gateway private keys held non-exportable; the higher this is, the smaller the next incident.
• Partner re-key coverage: partners confirmed on the new keys, out of all gateway to gateway partners.
• Bypass hygiene: bypass rules with an owner and expiry, out of all bypass rules; target 100%.
• Escrow recovery test: date of the last successful recovery and archive decryption test.

Alert on key export attempts, escrow recovery, bypass and routing changes on both the gateway and the mail platform, and portal bulk downloads, in a SIEM the gateway admins cannot alter. See the SIEM Guide.

Framework mapping

Common failure patterns

• Revoking and calling it contained. Revocation does nothing for archived or captured mail encrypted to a copied key; the exposure assessment still has to happen.
• Rebuilding before recovering escrow. The new gateway cannot read years of archived mail, and legal hold obligations fail.
• Fixing the gateway but not the mail platform. A transport rule that routes around the gateway keeps sending mail in clear after the rebuild.
• Forgetting the enrolment credential. The attacker keeps the ability to obtain trusted email certificates for your addresses from your own CA.
• Not telling partners. Correspondents keep encrypting to the revoked key, so their new mail is readable by the attacker until they update.
• Restoring a backup from the window. The attacker's bypass rules and admin roles return with it.

Practitioner checklist

• Record, for every gateway key, whether it is non-exportable and where it is escrowed.
• Capture policy, routing, roles and logs before changing anything.
• Lock admin access and remove unknown copy paths on gateway and mail platform.
• Revoke presumed-copied keys with a key compromise reason and issue new ones.
• Revoke the CA enrolment credential and any certificates it issued without a request.
• Recover escrowed keys under split custody before rebuilding.
• Scope past exposure for archives, captured mail, portal and plaintext stores.
• Distribute new public keys to partners and confirm the old ones are removed.
• Assess GDPR Article 33 and 34 duties, without relying on encryption for messages under a copied key.
• Test archive decryption and partner encryption before widening the new gateway.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• IETF: RFC 8551, S/MIME Version 4.0 Message Specification
• IETF: RFC 9580, OpenPGP
• IETF: RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation
• MITRE ATT&CK: Remote Email Collection

Related NHI Mgmt Group resources: OpenPGP and S/MIME Email Encryption Guide · Email Encryption · If your certificate lifecycle manager is compromised · Service Account Security Guide