Why Organizations Are Moving PGP and S/MIME Encryption to the Cloud

Many PGP and S/MIME deployments were built years ago around a dedicated gateway server in the data center. Once in production, it becomes infrastructure the business depends on but few people understand. Keeping it healthy involves:

• Patching and upgrades for the operating system, the encryption software and its dependencies, often scheduled around mail outages.
• Availability: a single gateway is a single point of failure for outbound mail, so resilience means clustering, load balancing and tested failover.
• Key and certificate custody: private keys need secure storage, backup and recovery, sometimes on hardware security modules.
• Directory integration: LDAP lookups and key publication must keep working as directories, domains and partners change.
• Capacity planning: growth in mail volume or attachment sizes means buying and installing hardware ahead of demand.
• Specialist knowledge: when the engineer who built the system leaves, routine changes become risky.

None of this work sets the organization apart from its competitors. It simply keeps encrypted mail flowing, and it competes for the same staff who maintain everything else.

Less infrastructure to maintain

The provider runs, patches and scales the encryption engine. Internal teams manage mail routing and encryption policy instead of servers, operating systems and clusters.

One policy for PGP and S/MIME

A service that handles both standards can apply rules by recipient, domain or content, and choose PGP, S/MIME or an alternative delivery method automatically. Users do not have to decide how to encrypt each message, which removes a common source of mistakes.

Centralized key and certificate lifecycle

Sender keys, recipient lookups and certificate renewals can be handled centrally rather than device by device. Centralized PGP and S/MIME key management describes the controls involved, including options for customer-managed keys.

Options for recipients without PGP or S/MIME

When a recipient has no key or certificate, policy can deliver the message through a secure portal or as an encrypted document instead of sending it unprotected or returning it to the sender.

Clearer audit evidence

Central logging of encryption decisions, key generation and delivery states makes it easier to show auditors which messages were protected, and how.

Works with the mail platform you already use

Microsoft 365, Google Workspace and secure email gateways can route mail to the service through standard SMTP connectors, so users keep Outlook or Gmail. For the platform-specific options, see how to encrypt email in Microsoft 365 and Google Workspace.

Moving to the cloud does not change the cryptography your partners rely on. A PGP partner still needs your public key, and you still need theirs; an S/MIME partner still validates your certificate against a trusted certificate authority. Cloud-hosted PGP email encryption and cloud-hosted S/MIME email encryption follow the same open standards as on-premises products.

Your users’ experience barely changes either: they keep composing and reading mail as before, and policy decides when encryption applies.

Accountability does not move either. Your organization still decides what must be encrypted, who may hold keys and how long records are kept. A provider supplies controls and operates them; it does not make an organization compliant on its own.

A cloud service is not the right answer for every organization. Staying on-premises, or choosing a hybrid model, can make sense when:

• law, contract or internal policy requires that keys and message processing remain inside your own facilities;
• the mail system is isolated from the internet;
• a recent investment in on-premises hardware still has years of useful life, and the team to run it is in place.

Even then, it is worth reviewing the full yearly effort of running the system. Customer-managed key options in a cloud service can meet many key-custody requirements without keeping the servers.

1. Inventory. List every sending domain, encryption rule, PGP key pair, S/MIME certificate, partner and directory that the current system uses.
2. Decide what moves. Choose which keys and certificates to import and which to replace. Importing keeps partner trust intact; replacing is a chance to retire weak or expiring material.
3. Preserve the archive. Keep old private keys available, securely, for as long as encrypted messages must remain readable.
4. Run in parallel. Route one domain, department or partner group through the new service while the old gateway handles the rest.
5. Test with real partners. Confirm encryption, decryption, signatures and replies in both directions before widening the scope.
6. Cut over and decommission. Move the remaining routes, then retire the old servers and dispose of their keys according to your retention policy.

The migration notes on our Cloud PGP page and our key migration and portability options cover the technical details of moving keys.

• Where is mail processed, and where are keys stored?
• Can we import our own keys, and export them if we leave?
• Which certificate authorities and directories are supported?
• What logs and reports are available for audits?
• Which delivery alternatives exist for recipients without PGP or S/MIME?
• How are recipients authenticated when they use a portal?

Our overview of cloud email encryption security controls shows how CloudPGP approaches several of these questions, including where its responsibilities end and yours begin.