[mh_key_takeaways]
PGP email encryption has been the go-to method for security-conscious technical users since the 1990s. The current OpenPGP standard, RFC 9580, still uses the same public-key model that Phil Zimmermann designed in 1991, refreshed with modern algorithms.
PGP is strong, well-audited, and free in its GnuPG form. It is also famous for being harder to use than any browser-based alternative, which is why enterprises pair it with commercial key management and why patient-facing practices usually reach for a portal-based encrypted email service instead.
This guide covers what PGP actually does, how it fits with Gmail, Outlook, and Symantec Encryption, where it stands next to S/MIME, and when a simpler alternative saves days of key management work.
PGP uses public-key cryptography to protect the message body
PGP encrypts the message body with a symmetric AES key that is itself encrypted with the recipient public key. The recipient decrypts the AES key with their private key, then decrypts the body.
The same message can be signed with the sender private key, which lets the recipient verify the sender identity by checking the signature against the sender public key.
Public keys are shared through key servers, personal websites, or attached to a first message. The recipient can verify the public key belongs to the claimed sender by comparing the key fingerprint out-of-band, typically over a phone call.
The full protocol is defined in RFC 9580. GnuPG on Linux and the command line, GPG Suite on macOS, and Kleopatra on Windows all implement the same standard.
PGP does not protect the subject line or the routing headers. It only encrypts the message body and any attached payloads inside the PGP envelope.
PGP for Gmail requires a browser extension
Gmail does not include native PGP support in either the web client or the mobile apps. A browser extension bridges Gmail and the local PGP toolchain.
Mailvelope is the most widely used extension. It stores keys in a browser-managed keyring, wraps the Gmail compose window with an encrypt and sign toolbar, and outputs an armored OpenPGP block that Gmail sends as normal message text.
FlowCrypt is a paid alternative that adds enterprise features like automatic key discovery, a shared keyring, and Outlook integration. It handles the same PGP protocol under the hood.
The recipient side needs the same extension or another PGP-aware client to decrypt. That works well for developer-to-developer mail but breaks down for patient mail because patients do not install extensions.
Practices already on Google Workspace Enterprise Plus can enable hosted S/MIME instead, which handles encryption at the Gmail server side. S/MIME setup and key management is documented in the guide on S/MIME email encryption.
PGP for Outlook uses gpg4win or a commercial add-in
Outlook on Windows integrates with PGP through an add-in. Gpg4win with the GpgOL plug-in is the free option and installs a set of encrypt, sign, and decrypt buttons in the compose ribbon.
The add-in reads keys from the local GnuPG keyring. Enterprise deployments typically populate the keyring through a central key server or a directory that stores each user public key alongside their Active Directory entry.
Symantec Encryption Desktop, sold today under the Broadcom Symantec Encryption product line, is the commercial packaging. It adds central policy control, a Symantec Encryption Management Server for key escrow, and support for Outlook and other clients.
Outlook on macOS does not have an official gpg4win port. Users on macOS typically switch to Apple Mail with GPG Suite for PGP, or they run Outlook in a browser and use a PGP-aware webmail extension.
Outlook on the web does not support PGP add-ins directly. Organizations using OWA for their primary interface generally pick S/MIME or Purview Message Encryption instead, or route mail through a gateway that applies encryption at the transport.
Symantec PGP centralizes key management for the enterprise
Symantec PGP was originally sold by PGP Corporation, acquired by Symantec in 2010, and now sold under the Broadcom umbrella. The product line is Symantec Encryption Desktop and Symantec Encryption Management Server.
The Encryption Management Server is the piece that most GnuPG deployments do not have. It centralizes key generation, escrow, revocation, and policy enforcement across the tenant.
Encryption Desktop installs on each endpoint and handles the Outlook add-in, disk encryption, and file encryption. It reads policy from the management server on start and applies encryption rules to outbound mail.
The commercial packaging removes the key management overhead that stops many teams from adopting PGP. It does not remove the recipient-side requirement, so PGP still fits internal enterprise mail and B2B mail with a matched setup better than it fits patient mail.
Support and licensing are through Broadcom. Pricing is not published publicly, and quotes come through a Broadcom sales contact or an authorized reseller.
[mh_example]
PGP compared to S/MIME on the practical decisions
PGP and S/MIME both use public-key cryptography to encrypt email. They differ on trust model, mail client support, and enterprise integration.
PGP relies on a web of trust, where users sign each other keys directly. S/MIME relies on a certificate authority, where a trusted CA signs each user certificate.
S/MIME is built into Outlook, Apple Mail, and Google Workspace Enterprise Plus without a plug-in. PGP requires an extension or an add-in for every mainstream email client.
| Feature | PGP | S/MIME |
|---|---|---|
| Trust model | Web of trust | Certificate authority |
| Standard | OpenPGP RFC 9580 | S/MIME RFC 8551 |
| Native Outlook support | Add-in required | Built in |
| Native Gmail support | Browser extension | Hosted S/MIME on Enterprise Plus |
| Native iPhone Mail | Not supported | Built in with configuration profile |
| Key exchange | Manual or key server | Certificate exchange in signed messages |
| Typical use case | Developer to developer, B2B security teams | Enterprise internal, government |
For patient mail, neither PGP nor S/MIME is a great fit because patients do not hold keys. Portal-based encrypted email services skip the key exchange step and are documented in the guide on email encryption.
Key management is the hard part of PGP
Generating a PGP key pair takes one command. Managing that key pair across a laptop, a phone, a work desktop, and a home machine, over five years and multiple client switches, is the actual work.
Best practice is to keep the private key on a hardware security module or a YubiKey rather than on the disk. That removes the risk of a stolen laptop exposing years of encrypted mail.
Public keys need to be published somewhere the sender can find them. Options include the personal Keyoxide profile, a personal website, a company directory, or the older SKS keyserver network, which is now mostly deprecated.
Key revocation is the other hard problem. When a private key is compromised, the user needs to publish a revocation certificate so that senders stop encrypting to the old key.
Enterprise deployments handle this through a management server. Individual users typically write the revocation certificate to paper when they generate the key and store it in a safe.
HIPAA compliance needs more than PGP encryption alone
PGP encryption satisfies the transmission security part of the HIPAA Security Rule when applied to messages containing protected health information. That is not the full compliance picture.
HIPAA also requires a signed business associate agreement with any vendor that handles PHI, access controls on the mailbox and the key store, audit logs of who sent and received each message, and an incident response procedure for lost or stolen keys.
Google Workspace and Microsoft 365 offer a BAA on eligible paid plans, but the practice must actively request and sign it. Free consumer Gmail and personal Outlook.com are never covered by a BAA, regardless of whether PGP is layered on top.
The HHS Covered Entities reference covers when a BAA is required. Any vendor that touches, stores, or transmits PHI on the covered entity behalf falls under the rule.
Practices building a full patient communication stack also need to think about the surrounding website. Guidance on security features for healthcare websites covers form handling, SSL, and portal integration alongside encrypted mail.
[mh_protip]
PGP fits developer and B2B mail better than patient mail
PGP shines in two common use cases. The first is developer-to-developer mail, where both sides already have keys, run a PGP-aware mail client, and value the strong cryptography.
The second is B2B mail between two security teams, where the setup cost is paid once and the volume justifies it. Enterprises exchanging incident data, threat intelligence, or contract packages often use PGP over commercial email gateways.
Patient mail rarely fits either shape. Patients do not have keys, do not run a PGP-aware client, and will not install a browser extension on the phone they use to check email.
For patient mail, portal-based encrypted email services deliver a link that the patient opens with a passcode. The message and any attachments live inside the portal, and the recipient reads and replies without installing anything.
Referring providers and insurance carriers usually accept portal-based delivery because it does not depend on their own encryption setup. That decouples the practice mail from every partner IT team.
Automation with PGP uses gpg and Bouncy Castle
Automated PGP encryption for batch mail from a report generator or a lab bridge uses the gpg command line on Linux and the Bouncy Castle PGP API on Java.
The gpg –encrypt –recipient email@example.com command reads the file from stdin, encrypts with the recipient public key, and writes the armored output. A shell script pipes the output into mutt or msmtp for delivery.
Bouncy Castle provides the PGPEncryptedDataGenerator, PGPCompressedDataGenerator, and ArmoredOutputStream classes. The Java code loads the recipient public key from a keyring, wraps the message bytes, and writes the resulting armored OpenPGP block into a MimeBodyPart.
For applications sending PHI at scale, calling a secure email API that handles encryption server-side is usually faster than adding key management inside the application. The API pattern also simplifies deployment because the container image does not carry key files.
The choice comes down to whether the recipients already run PGP. If yes, the code path stays inside the application. If no, a portal delivery service handles the recipient side without asking them to set up anything.
When PGP is the right answer and when to pick something else
PGP is the right answer when both sides already run PGP, the recipient will not accept portal links, and the volume justifies the setup cost. It is also the right answer when the recipient is a security team that expects an armored OpenPGP block in the message body.
S/MIME is the right answer for internal enterprise mail where every mailbox is on the same Outlook or Google Workspace tenant and every user already has a certificate through the corporate PKI.
Portal-based encrypted email is the right answer for patient mail, referring providers, and insurance carriers. The recipient opens a link, signs in with a passcode, and reads the message without any account setup.
For a small practice sending a mix of internal, referring provider, and patient mail from Gmail or Microsoft 365, layering a dedicated encrypted email service on top of the existing mailbox covers all three cases with one setup step.
Whichever method fits, run a round-trip test with a real recipient before rolling it out. The most common cause of failed PGP deployments is that the sender got a green Encrypt button but the recipient never received a readable message.
[mh_faqs]
