PGP vs S/MIME
PGP and S/MIME are the two major end-to-end email encryption standards. They've coexisted for decades; they don't interoperate; they have different threat models and different user bases. The choice between them is mostly a question of trust model, not cryptography.
PGP and S/MIME are both end-to-end encryption standards for email. Both let you encrypt and sign messages so only the intended recipient can read them and so the recipient can verify the sender. They use different cryptographic conventions, different identity systems, and different deployment patterns. They don't interoperate — a PGP-encrypted message can't be opened with an S/MIME client and vice versa.
The core cryptographic difference
Both use the same cryptographic primitives (RSA or ECC for key exchange, symmetric ciphers for content). The difference is in how identities are validated:
- PGP uses a web of trust — users sign each other's keys, building a decentralized network of trust assertions. No central authority. Trust is bottom-up.
- S/MIME uses X.509 certificates issued by Certificate Authorities (the same CAs that issue TLS certificates). Trust flows from a few major CAs through certificate chains. Trust is top-down.
The cryptography of the encryption itself is similar; the trust models are very different.
PGP characteristics
- Decentralized. No CA required. Users generate their own keys, distribute public keys directly.
- Open source ecosystem. GnuPG (free), Mailvelope, Thunderbird, Enigmail, Proton Mail.
- Strong privacy/activism heritage. Used by journalists, activists, security researchers.
- Manual key management. Users responsible for generating, sharing, validating keys. WKD (Web Key Directory) makes some of this easier; not all of it.
- Subject lines remain in cleartext. A documented limitation that affects metadata privacy.
- Long-term keys with revocation. A revoked key can be marked as such on key servers.
S/MIME characteristics
- CA-based identity. Certificates issued by trusted authorities; identity is verified by the CA at issuance time.
- Built into Outlook, Apple Mail, Thunderbird with native UI. Less third-party software required.
- Corporate-enterprise heritage. Used by government agencies, regulated industries, large corporations with internal PKI.
- Easier user experience. Once certificates are installed, encryption and signing happen with minimal user interaction.
- Subject lines remain in cleartext. Same limitation.
- Certificate-based revocation. CRLs and OCSP, same as TLS.
The trust-model trade-offs
The difference matters when you ask: "how do I know this public key actually belongs to the person I want to send to?"
PGP's web of trust: you know because you've verified the key directly (in-person key fingerprint exchange, signed key from someone you trust). Strong when done well; weak when keys are imported casually.
S/MIME's CA model: you know because a Certificate Authority verified the identity and issued the certificate. Trusting the CA's verification process. Strong if the CA is rigorous (DigiCert validates identity carefully for individual S/MIME certs); weak if the CA is compromised or sloppy.
Both models have real failure modes; both work in practice for their respective user bases.
Deployment realities
S/MIME is more deployed in business contexts:
- US Department of Defense uses S/MIME extensively (CAC card certificates)
- Major banks and financial firms use S/MIME for customer communications
- Healthcare organizations subject to HIPAA often use S/MIME
- Enterprise PKI integration with Active Directory makes deployment manageable at scale
PGP is more deployed in activism, journalism, and technical contexts:
- SecureDrop and journalism source-protection tooling
- Linux distribution package signing (separate from email but same OpenPGP standard)
- Git commit signing (overlapping OpenPGP)
- Proton Mail (uses OpenPGP internally)
- Privacy-focused users and small communities
The interoperability gap
The two standards don't interoperate. If you have a PGP key and your correspondent has an S/MIME certificate, encrypted email between you isn't directly possible without converting one side. Multiple efforts have proposed bridges ("OpenPGP for X.509") but none have achieved practical deployment.
In practice this means: organizations standardize on one. PGP-using communities use PGP throughout; S/MIME organizations use S/MIME. Cross-context encrypted email often falls back to providers' own systems (Proton-to-Proton, Outlook-to-Outlook with internal PKI).
What's actually changed in 2026
Both standards continue to exist; neither has won. The bigger change is that secure messaging apps (Signal, WhatsApp) have absorbed most of the demand for encrypted personal communication. Encrypted email persists for asynchronous communication, legal document exchange, and journalism — niches where the latency tolerance is real.
S/MIME has incrementally improved with broader CA issuance for individuals. PGP has gotten somewhat easier with WKD and Proton Mail's polish. Both still feel dated compared to modern messaging app UX.
Frequently asked questions
- Which is more secure, PGP or S/MIME?
- Cryptographically equivalent for their core operations. The trust models differ; either can be secure in practice, either can fail in practice. The difference is fit to your environment, not raw security.
- Can I use both?
- Technically yes — you can have both a PGP key and an S/MIME certificate. Operationally it's complex; most users pick one. Some mail clients support both natively (Thunderbird does; Apple Mail does S/MIME natively and PGP via extensions).
- What about Proton Mail?
- Uses OpenPGP internally but hides it behind a clean UI. For Proton-to-Proton mail, encryption is automatic. For mail to other systems, Proton can use PGP if the recipient has a key, or send unencrypted. The Proton experience is closer to modern messaging UX than traditional PGP.
- Why don't more people use encrypted email?
- Operational friction. Setup, key management, and "the other person has to use it too" are all barriers. Modern messaging apps have collapsed similar friction to essentially zero with default-on E2E. Email's not going to match that until something fundamental changes.
- Is encrypted email still useful?
- For specific use cases yes — legal correspondence, journalism source protection, regulated industry contexts. For everyday personal communication, modern messaging apps (Signal) are usually a better fit. The category isn't dead; it has narrowed to specific niches.