PGP Email Encryption: How It Works, How to Manage Keys, and When It Fits Personal, Business, and Regulated Email

Most organizations discover the limits of their encryption posture only after an incident forces an inventory. According to IBM's 2026 Cost of a Data Breach Report, only 37% of breached organizations encrypt sensitive data both at rest and in transit, and just 34% have visibility into their cryptographic assets. That gap explains why confidential contracts, payment instructions, and health records still travel through mail systems that treat message bodies as ordinary readable text.

PGP email encryption closes part of that gap, though it introduces obligations that many teams underestimate: key generation, fingerprint verification, rotation, revocation, and recovery. Deployed without those controls, it produces encrypted messages nobody can decrypt and signed messages nobody can validate.

This guide covers:

• How PGP email encryption combines session keys, public keys, and private keys to protect message bodies and attachments;
• Which key encrypts an email under PGP email encryption and which key decrypts it, including subkeys, algorithms, and expiration;
• How digital signatures, fingerprints, and trust models establish identity in PGP email encryption;
• How organizations set up, test, and govern PGP email encryption across desktop, mobile, and webmail environments;
• Where PGP email encryption is secure, where it remains exposed, and which cyber threats it cannot stop;
• Why cybersecurity awareness training determines whether encrypted communication survives contact with social engineering.

Encrypted message bodies do nothing against phishing that targets employee decisions before encryption ever applies. Adaptive Security detects AI-generated email cyberattacks and removes them across every affected inbox.

Explore the platform

What Is PGP Email Encryption?

PGP email encryption protects message contents by combining symmetric encryption with public-key cryptography, and optional digital signatures confirm that the holder of a specific private key signed the message. PGP originally stood for Pretty Good Privacy, though modern implementations follow the OpenPGP standard and commonly rely on GnuPG, also called GPG, to encrypt and decrypt messages.

The distinction that matters operationally is scope. PGP email encryption protects the encrypted body and the attachments carried inside it, leaving the surrounding delivery information and the recipient's judgment untouched. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, internet crime drove $20.877 billion in reported losses, a 26% jump over the prior year ($16.6 billion in 2024).

Those losses accumulate mostly through deception rather than interception, which is the strategic context for any encryption decision. Understanding what is PGP email encryption therefore means understanding both the cryptographic guarantee and the guarantee it never offered.

PGP, OpenPGP, and GPG Explained

PGP began as software for protecting email and files rather than as a single encryption algorithm. The name stood for Pretty Good Privacy, a deliberately modest description of a system built to prevent unauthorized people from reading or altering digital communications. Today the term serves as a broad shorthand for email encryption based on the same public-key model.

OpenPGP is the technical standard defining how keys, encrypted messages, signatures, and related data are formatted. It allows compatible applications to exchange protected messages without requiring every user to run identical software. The Internet Engineering Task Force's RFC 9580, published in 2024, defines OpenPGP formats for public-key and symmetric encryption, digital signatures, key management, and integrity protection.

GnuPG is an open-source implementation of OpenPGP, and "GPG" commonly refers to the gpg command-line program within it. The distinction matters when evaluating compatibility: PGP describes the original product family and, informally, the overall approach, OpenPGP describes the interoperable standard, and GnuPG or GPG describes a tool that implements that standard.

PGP email encryption uses two related keys. Anyone who needs to send protected information can receive a public key, while the owner must keep the private key under tight control. The private key decrypts messages addressed to it and creates digital signatures that others verify with the matching public key.

A passphrase protects the private key on the device where it is stored, and it is neither the private key itself nor something normally sent to a recipient. If a cyberattacker copies an encrypted private-key file without guessing the passphrase, that passphrase becomes an additional barrier. Weak or reused passphrases, malware, and unauthorized sharing all erode that protection.

These mechanics make secure communication a question of people as much as technology. According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed breaches involve a human element. An organization can deploy technically sound email encryption and still expose sensitive information when an employee sends it to the wrong address, accepts an unverified public key, or answers an impersonation attempt.

Cybersecurity awareness training should teach employees to confirm recipients, protect private keys, recognize suspicious requests, and report unusual messages. Information security awareness training and phishing awareness training extend those skills to social engineering, credential theft, and unsafe data handling.

What PGP Email Encryption Protects

Email encryption converts readable content, called plaintext, into ciphertext that an authorized recipient can restore with the correct key. In a typical workflow, the sender's software generates a temporary symmetric session key and uses it to encrypt the email body and attachments, then wraps that session key with public-key cryptography for each intended recipient.

The recipient's software uses the matching private key to recover the session key and decrypt the message. This hybrid design avoids the performance cost of encrypting a large attachment directly with public-key cryptography, and OpenPGP defines the sequence explicitly.

PGP email encryption can also create a digital signature. The sender's software calculates a cryptographic hash of the message and signs that result with the sender's private key, and the recipient checks the signature with the sender's public key. A valid signature indicates that the corresponding private key signed the content and that the signed content has not changed since signing.

Encryption and signing therefore deliver different protections. Confidentiality prevents unauthorized observers from reading protected content, while authenticity and integrity help the recipient detect changes and evaluate whether the message came from the party associated with the verified signing key. A sender can encrypt without signing, sign without encrypting, or apply both.

A cryptographic result is stronger evidence than a familiar display name or company logo, because the recipient can check it independently. That result carries weight only once the recipient has confirmed that the public key belongs to the intended person. A cyberattacker can create a key labeled with a colleague's name, so employees should verify fingerprints through a separate trusted channel before using a key for high-impact communication.

In business use, PGP email encryption can protect confidential contracts, legal documents, source code, incident details, financial records, and other attachments exchanged with known recipients. It can also support secure communication with external partners once both sides agree on key ownership, expiration, revocation, software compatibility, and recovery procedures.

That protection addresses one part of human risk. According to the APWG's Phishing Activity Trends Report, 4th Quarter 2025, 3.8 million phishing attacks were observed during 2025, up slightly from 3.76 million the year before. A fraudster can send an email signed with a valid key that was stolen, or persuade an employee to encrypt information for the wrong recipient entirely.

Employees must still recognize business email compromise (BEC), the fraud pattern in which a cyberattacker impersonates a trusted executive, supplier, or partner to obtain money, credentials, or sensitive data.

1. The Hybrid-Encryption Sequence

PGP email encryption is a hybrid process because it assigns different jobs to two cryptographic methods. Symmetric encryption uses one secret key to encrypt and decrypt the content, while public-key encryption uses a mathematically related key pair so that anyone can encrypt data with the recipient's public key and only the matching private key can decrypt it.

Symmetric encryption is faster because it processes the entire message with comparatively lightweight operations. Public-key encryption requires more computationally expensive mathematics, making it inefficient for large message bodies, videos, and files. PGP therefore uses public-key cryptography to protect a small session key while symmetric cryptography protects the actual message data.

The message flow works like this:

1. 1Compose the message. The sender writes the email, selects the recipients, and attaches any files. The mail client identifies each recipient's intended public encryption key and prepares the message body, relevant PGP metadata, and attachments.
2. 2Generate a random session key. The sender's PGP software creates a fresh, unpredictable symmetric key for that message. The session key is temporary and is not normally reused for another email, which limits the exposure associated with any single encrypted message.
3. 3Assemble the message data. The email text and attachments are converted into OpenPGP data packets. Text is represented as literal data, while binary material such as a spreadsheet, image, or PDF is represented as binary data. The packet format can also carry limited file metadata, including a filename and associated timestamp.
4. 4Compress the message. PGP commonly compresses the assembled data before encryption, which reduces the amount of ciphertext sent through the email system and removes predictable repetition from the plaintext. The 2024 OpenPGP specification defines compressed-data packets, encryption, digital signatures, and packet structures within the interoperable message format.
5. 5Encrypt the content with the session key. The compressed message, including its attachments, is encrypted with the random symmetric session key. Whether the message contains a short paragraph or a large document, symmetric processing performs the bulk encryption because it handles speed and volume efficiently.
6. 6Add integrity protection. Modern OpenPGP implementations use integrity-protected encrypted-data containers. Current formats can apply authenticated encryption with associated data, or AEAD, to produce authentication tags that detect altered or truncated ciphertext, while older messages can use a modification detection code, or MDC, based on a hash. A failed integrity check indicates that the package should not be trusted.
7. 7Encrypt the session key for each recipient. The sender encrypts the same session key separately with every recipient's public encryption key. These encrypted session-key records are small compared with the message itself, and each recipient's private key later unlocks only that recipient's copy.
8. 8Create an optional digital signature. If the sender signs the message, PGP calculates a cryptographic hash of the relevant data, converting the message into a fixed-length digest. The sender signs that digest with the private signing key, creating a signature that the recipient can verify with the corresponding public signing key.
9. 9Package the encrypted data. PGP places the encrypted session-key packets alongside the encrypted message container, and a signed message also includes signature-related packets. The result can be represented as ASCII armor, a text encoding that allows binary encrypted data to pass through systems designed for ordinary email text. ASCII armor adds no encryption; it changes how the encrypted bytes are represented.
10. 10Send the package through email infrastructure. Email providers and mail servers transport the PGP package as opaque content. They can still see routing information such as the sender, recipients, delivery times, and, in many implementations, the subject line.

For multiple recipients, the sender normally encrypts one shared session key separately to each recipient's public key while encrypting the message content only once. Adding a recipient requires another encrypted session-key packet instead of another full copy of the encrypted message. Each recipient's software searches the package for the session-key record it can open, recovers the session key, and decrypts the same content.

2. How Attachments and Files Are Handled

PGP email encryption treats an attachment as data inside the protected message structure rather than as an exception to encryption. The client reads the file as bytes, records it in a literal-data packet with its binary format, then compresses and encrypts that packet with the same session key used for the email body.

This process protects the file contents while the message is encrypted. A confidential spreadsheet, contract, or archive is not left as a separate unencrypted object simply because it was attached to an email. After decryption, the recipient's PGP software reconstructs the attachment and presents it in its original usable file type.

Compression occurs before encryption because encrypted data appears statistically random and generally does not compress effectively afterward. Compressing first also prevents the encryption process from preserving repeated patterns in the original text or file. Already-compressed formats such as JPEG images, MP4 video, and ZIP archives often produce little additional size reduction, though they still pass through the same packet and encryption sequence.

Large attachments create operational risks because they increase processing time and storage requirements, and mail gateways can reject or modify messages that exceed size or content-handling limits. Encrypted content can also prevent ordinary inspection, since a mail filter cannot read the protected body without the private key. Organizations should define approved handling procedures, protect decryption keys, and establish a separate malware-scanning process for files after authorized decryption.

A hash supports integrity and signature operations without being encryption itself. Anyone who can calculate the same hash can compare it with a published value, while a digital signature binds the hash to the sender's private key and an authenticated encryption tag binds the ciphertext to the key used for decryption. A signature helps establish which key signed the content, whereas an integrity check reveals whether the protected package was altered.

PGP email encryption does not automatically prove that a public key belongs to the person named in an email address. The sender must verify the key's fingerprint through a trusted channel or an organization-managed key directory. Without that step, a cyberattacker could supply a different public key and receive encrypted information intended for someone else.

3. How the Recipient Decrypts the Message

The recipient's mail client identifies the encrypted session-key packet addressed to one of the recipient's public keys. The recipient unlocks the corresponding private key, usually with a passphrase or hardware-backed protection, and uses it to decrypt the session key. The private key never needs to be transmitted to the sender or the email provider.

After recovering the session key, the client decrypts the encrypted-data container and checks its authentication tag or integrity mechanism before displaying the content. If the check fails, the software should warn the recipient and avoid presenting the message as trustworthy. Successful decryption proves that the recipient possesses the matching private key, though it establishes nothing about who authored the message.

The client then reverses the packaging sequence, verifying any digital signature with the sender's public signing key, decompressing the inner packet sequence, and reconstructing the message body and attachments. For a signed and encrypted email, the recipient should confirm both that the integrity check passed and that the signature belongs to a public key whose fingerprint was independently verified.

The process is similar for several recipients, since each one uses a different private key to open an individual encrypted copy of the same session key. All authorized recipients can then use the recovered session key to decrypt identical message content. Someone whose public key was never included cannot decrypt the message merely by obtaining the ciphertext.

Encryption strength collapses when an employee accepts an unverified public key under time pressure. Adaptive Security runs realistic phishing simulations that rehearse exactly that decision before it costs something.

Take a self-guided tour

Which PGP Email Encryption Key Encrypts an Email and Which Key Decrypts It?

In PGP email encryption, the sender uses the recipient's public key to encrypt the message session key, and the recipient uses the matching private key to decrypt that session key and recover the message. The sender's private key creates a digital signature, while the sender's public key verifies it.

These functions depend on compatible algorithms, trusted key identity, and disciplined private-key protection. Confusion about which key performs which operation is the most common source of failed deployments and information encrypted to the wrong party.

Public Key Versus Private Key

A PGP key pair contains mathematically related public and private components. The public key is intended for distribution through a directory, key server, company portal, or direct exchange. The private key, also called the secret key, must remain under its owner's control and is typically protected by a passphrase.

Publishing a public key reveals nothing about the private key and grants no access to messages encrypted with it. The encryption direction is the point most often misunderstood: if Alice sends an encrypted email to Bob, Alice selects Bob's public encryption key rather than her own private key.

Bob's software then uses the corresponding private key to recover the session key and decrypt the message. Alice can encrypt one message for several recipients by including a separate encrypted copy of the same session key for each recipient's public key.

Signing uses Alice's own key pair. Alice uses her private signing key to create a signature over the message, usually after hashing its contents, and Bob uses Alice's public signing key to verify that the signature matches the message and that the content has not changed. A valid signature supports integrity and key-based origin authentication without proving that the email address or real-world identity attached to the key is trustworthy.

Recipients must therefore validate the key fingerprint through a trusted channel before treating a signature as meaningful evidence about a person. According to Verizon's 2026 Data Breach Investigations Report, stolen credentials were involved in 13% of all breaches, which is precisely the condition under which a legitimate key can produce a fraudulent message.

A keyring is the local database that stores and manages public keys, private keys, user IDs, signatures, trust information, expiration data, and revocations. Bob's keyring must contain the private material matching the public encryption key Alice selected, and it must also contain Alice's public key to verify her signature. If Bob imports the wrong key, the message can remain undecryptable even when the displayed email address appears correct.

Modern OpenPGP keys commonly separate duties between a primary key and subkeys. The primary key usually certifies the relationship between a person and a user ID and can sign or certify other keys, while a dedicated encryption subkey handles message decryption and a signing subkey handles signatures.

This separation limits exposure because an organization can rotate an encryption subkey or keep the primary certification key offline without rebuilding the entire identity. The current OpenPGP specification describes public subkeys as separate key material associated with a primary key and defines modern version 6 key formats. Senders should match the exact subkey and fingerprint shown by the recipient's trusted key record instead of relying on a matching display name.

The PGP Email Encryption Session Key

PGP email encryption does not normally encrypt the entire email directly with RSA or another public-key algorithm. Instead, the sender's software generates a random, temporary session key for that message and uses it with a symmetric cipher, such as AES, to encrypt the email body and attachments. Symmetric encryption handles large data efficiently, avoiding the performance and size limitations of applying public-key operations to every byte.

The sender encrypts the session key with the recipient's public key and places that encrypted session-key record alongside the encrypted message. During decryption, the recipient's private key unlocks the session key, and the session key unlocks the message.

The session key is random so that identical messages do not produce identical ciphertext under normal operation. It is temporary because it belongs to one encrypted message rather than to the recipient's long-term identity. Exposing one session key therefore affects that message alone rather than every message protected by the recipient's long-term key.

Diffie-Hellman terminology requires precision here. Traditional OpenPGP can use ElGamal, a public-key encryption method derived from Diffie-Hellman, while modern elliptic-curve options use ECDH or X25519-style key agreement.

In those designs, the sender and recipient derive shared key material from the recipient's public key, the recipient's private key, and, depending on the scheme, ephemeral sender-side key material. That derived material wraps or derives the session key, and the security outcome remains constant: only the recipient holding the matching private key can recover the message-encryption key.

Algorithms, Key Sizes, and Expiration

Algorithm selection determines whether a PGP email encryption deployment remains maintainable and defensible. RSA remains widely supported, though new deployments should use a current implementation, a strong RSA key size such as 3,072 bits or higher, and modern padding and signature settings. Elliptic-curve options such as X25519 for encryption and Ed25519 for signing provide strong security with smaller keys when both parties' software supports them.

Compatibility remains essential, because an algorithm the recipient cannot process prevents legitimate decryption. AES is a standard symmetric encryption choice for message content, with AES-128 and AES-256 both current options and AES-256 often selected for long-lived or highly sensitive data.

Teams should use an integrity-protected or authenticated-encryption mode supported by the implementation and avoid creating new messages with obsolete ciphers such as IDEA or unauthenticated legacy packet formats. Historical ciphertext may still require older algorithms, though archive compatibility is a poor reason to make them the default.

SHA-family hashes support several operations, including hashing data before a digital signature and supporting key-derivation functions. SHA-256 or a stronger SHA-2-family digest is the appropriate choice, alongside any other modern hash explicitly supported by the current OpenPGP profile. MD5 has no place in new keys or signatures, and SHA-1 should be avoided for new signing configurations.

Hash selection does not replace encryption, since a hash produces a digest supporting integrity and signatures while encryption protects confidentiality. Key size alone establishes no trust either: a 4,096-bit RSA key attached to an impersonator remains the wrong key.

Security teams should confirm the full fingerprint through a second trusted channel, record the approved fingerprint in the organization's key inventory, and monitor changes to user IDs, subkeys, expiration dates, and revocation status. For high-value communications, an administrative key-approval process is more defensible than allowing an employee to download whichever public key appears first in a search result.

PGP keys do not automatically expire simply because time passes. A key expires only when an expiration time is configured and the receiving software determines that the key or relevant subkey is no longer valid. Administrators should set an expiration date, rotate encryption subkeys according to policy, and publish updated public-key material before the old key expires.

Expiration limits future use without erasing old private material or making previously decrypted information disappear. A lost private key creates an immediate recovery problem, because messages encrypted only to that key cannot be decrypted with a replacement.

Organizations therefore need protected backups, documented recovery procedures, and carefully controlled escrow where policy and law permit. A revoked or expired key should receive no new messages, although a recipient who still possesses the private material can often decrypt older messages depending on the message and software rules.

If the private key is compromised, security teams should assume a cyberattacker can decrypt messages encrypted to it and forge signatures made with it. According to the CrowdStrike 2026 Global Threat Report, the average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured at just 27 seconds. Revoke the key, distribute the revocation status, issue a new key pair, update every sender and keyring, and investigate messages and signatures created during the exposure window.

That lifecycle discipline turns PGP email encryption from a one-time software setting into a managed identity system. The message format itself then determines how the session key, encrypted content, signatures, and recipient records travel together.

Key confusion sends confidential material to the wrong recipient long before any cyberattacker gets involved. Adaptive Security trains employees on recipient verification, key handling, and reporting through interactive, role-specific modules.

Book a demo

How Does a PGP Email Encryption Digital Signature Verify Identity and Message Integrity?

A digital signature in PGP email encryption verifies that a specific private key produced the signature and that the signed content has not changed since. RFC 9580, the 2024 OpenPGP specification, defines signatures as bindings between public keys and data.

A valid signature establishes key control rather than personal trustworthiness. That distinction matters because a cyberattacker who controls a legitimate account can send harmful content signed with the account owner's genuine private key, producing a message that passes every cryptographic check an implementation performs.

Encryption Versus Signing in PGP Email Encryption

PGP email encryption and signing address different security problems. Encryption protects confidentiality by scrambling a message so only the intended recipient can read it, while signing provides authentication and integrity by allowing recipients to test whether the message came from the holder of a particular private key and whether the signed content changed afterward.

The signing process starts with the message. PGP software processes it through a cryptographic hash function and produces a short, fixed-length digest, where a change to even one character produces a different result. The sender's private signing key creates a digital signature over that digest and relevant metadata, including the hash algorithm, signature type, and creation time.

The sender transmits the readable message and its signature together, or sends the signature separately as a detached signature. The recipient's software independently hashes the received message, uses the sender's public key to verify the signature, and compares the resulting values. The 2024 OpenPGP specification's signature calculation rules describe how signed data is hashed and processed by the signature algorithm.

A valid signature proves three things:

• The signed bytes match the content that was verified;
• The signature was created with the private key corresponding to the public key used for verification;
• The message was not altered after signing without detection.

What a valid signature leaves unresolved is equally specific. It offers no evidence that the sender is trustworthy, that the email account is secure, that the message is safe to act on, or that the visible name and email address accurately identify the key owner. PGP software confirms cryptographic consistency, while identity verification depends entirely on how the recipient obtained and validated the public key.

That limitation creates a direct business risk. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest number of reports of any category. If a cyberattacker compromises an executive's email account and gains access to the associated private key, that cyberattacker can send malicious invoices, credential requests, or malware attachments carrying valid signatures.

Even without extracting the private key, someone controlling the account can distribute a different public key or persuade recipients to trust a cyberattacker-controlled key. Signing therefore belongs inside a broader verification process alongside private-key protection, fingerprint confirmation, and out-of-band checks on unusual requests. Employees should pause on unexpected payment instructions or credential requests even when the message displays a valid signature.

Signing and encryption can also be combined. The sender signs the message with the sender's private key and encrypts the signed package with the recipient's public key, and the recipient uses the recipient's private key to decrypt the package and the sender's public key to verify the signature. Encryption hides the content while signing tests its origin and integrity, and neither function substitutes for the other.

Fingerprints and Trust Models in PGP Email Encryption

A PGP fingerprint is a compact identifier derived from a public key. It lets people compare the key they possess with the key the owner intended to distribute without comparing a long block of key material. Modern OpenPGP version 6 fingerprints use a 256-bit SHA-256 digest of the public-key packet, while older version 4 keys use a 160-bit SHA-1 fingerprint.

Key IDs are shorter identifiers that should never serve as the sole basis for identity verification, because different keys can share the same short identifier. The practical verification method is direct: the key owner reads or displays the full fingerprint through a separately authenticated channel, and the recipient compares it with the fingerprint shown by the local PGP software.

A phone call to a known number, an in-person meeting, a previously verified video call, or an established corporate directory can each provide that second channel. Verifying a fingerprint by replying to the same suspicious email, or by accepting a fingerprint sent through the account whose authenticity is in question, defeats the purpose of the check entirely.

After confirming the fingerprint, a user can mark the key as trusted for that identity or certify the relationship with a personal key. This certification records that someone checked the connection between the public key and the named user ID. It endorses neither every future message from that person nor the continued security of that person's device and account.

PGP email encryption supports several trust models:

• Direct trust means an individual personally verifies a key and accepts it as belonging to the named owner;
• Hierarchical trust places confidence in designated authorities that certify identities, creating a structured chain from a trusted root to a user certificate;
• Web of trust distributes identity validation among users, who sign one another's keys so software can evaluate whether enough trusted paths connect a key to already-trusted identities.

In a web-of-trust model, a trusted introducer is someone whose signatures are trusted to validate other people's keys, and a meta-introducer can designate additional trusted introducers. Delegated validation increases coverage while making judgment quality critical, since trusting someone to sign messages is a different decision from trusting that person to verify other identities carefully.

No universal number of trusted signatures applies to every deployment. The threshold is a local policy decision based on each signer's trust level and the implementation's configuration. A policy might accept one signature from a fully trusted introducer, require several signatures from marginally trusted introducers, or require direct fingerprint verification for high-value transactions.

More independent, carefully verified paths increase confidence while increasing administrative effort. For finance, procurement, and executive communications, direct verification should override a convenient trust score, and a PGP warning, unexpected key change, or new signing identity is a reason to pause and confirm rather than a technical nuisance to dismiss.

Certificates, Key Servers, and Revocation

An OpenPGP certificate is a transferable public-key package rather than a bare public key. It can contain the primary public key, encryption and signing subkeys, user IDs, self-signatures, third-party certifications, key preferences, creation and expiration information, and revocation data. A self-signature binds the owner's user ID and key components together, while other users' signatures record independent certifications of that identity-key relationship.

OpenPGP certificates differ from X.509 certificates in structure and trust design. An X.509 certificate typically binds a public key to an identity through a certificate authority that signs the certificate within a hierarchical public-key infrastructure. An OpenPGP certificate is generally self-certifying and can accumulate signatures from many users, so recipients evaluate its validity according to their local trust model instead of a single mandatory authority chain.

Key servers distribute public-key certificates and updates. They simplify key retrieval, signature exchange, and revocation discovery, though they prove nothing about whether a downloaded key belongs to the named person. A key server is a distribution mechanism, so fingerprint verification through an independent channel must still precede treating a retrieved certificate as authentic.

Revocation is the emergency control for a lost, replaced, or compromised key. A revocation signature tells recipients to stop using the key for new encryption and to stop accepting it as current. It neither erases historical signatures that were valid before the compromise nor makes old encrypted messages readable without the appropriate private key.

Organizations should generate and securely store revocation certificates when keys are created, define who can authorize revocation, and publish updated certificates through a channel recipients check regularly. Before accepting a PGP-signed email, security-conscious recipients verify the signature status, inspect the exact signing key, and check whether the key is expired or revoked.

Every new or changed key deserves fingerprint confirmation through a separate channel, and sensitive requests deserve independent verification of the business instruction as well. Cryptography establishes message integrity, while disciplined key management and human judgment determine whether the message deserves action.

A valid signature on a fraudulent invoice still reads as trustworthy to an untrained approver. Adaptive Security turns reported messages into triaged intelligence and targeted lessons for the recipients.

Explore the platform

How Do Organizations Set Up PGP Email Encryption?

Setting up PGP email encryption involves choosing a compatible OpenPGP implementation, creating a public and private key pair, protecting the private key with a strong passphrase, and exchanging the public key with each intended recipient. Configuration then extends to an OpenPGP-capable desktop client, mobile app, browser extension, or webmail provider.

Testing encryption and decryption before sending sensitive information is the step most often skipped and regretted, and every recipient key requires verification before confidential communication begins.

1. Generate and Protect a Key Pair

Organizations should select an actively maintained OpenPGP implementation that supports the current OpenPGP format and works with the existing email environment. Options include a desktop cryptography application with Gmail, Outlook, Apple Mail, or Thunderbird integration, an OpenPGP-capable mobile app, a browser extension for webmail, or a webmail provider that performs encryption within its service.

Evaluation should confirm whether the tool supports OpenPGP version 6, modern encryption algorithms, key expiration, revocation certificates, digital signatures, key fingerprints, and encrypted backups. PGP email encryption uses two mathematically related keys, so the public key is published for others to encrypt against while the private key stays secret on authorized devices.

The IETF's 2024 OpenPGP specification describes separate public and secret key material, encrypted session keys, digital signatures, key fingerprints, and key revocation. The implementation handles those packet operations.

Key pairs should be generated inside the selected application, with identity details recipients will recognize, usually a name and the email address associated with the key. Administrators should use the current key format offered by the implementation and create a separate encryption subkey where the software supports that arrangement.

An expiration date matching the organization's key-management policy limits the exposure caused by an abandoned account, though it also requires a documented renewal process.

A long, unique passphrase protects the private key, ideally several unrelated words or a password-manager-generated value. Reusing an email password, device PIN, company password, or phrase stored in a shared document eliminates most of that protection.

The passphrase defends the private key if someone copies the key file, though it offers nothing if malware captures the passphrase during entry. Key generation should therefore happen on a trusted, updated device, with multifactor authentication enabled on the underlying email account.

Public keys should be exported in the format the recipient's implementation accepts. Private keys belong in the application's protected key store or an encrypted credential store, never in an unencrypted downloads folder, email attachment, chat message, or shared drive. A revocation certificate should be created during setup and kept offline.

A lost private key makes older messages encrypted only to that key unreadable, and a stolen private key combined with a disclosed passphrase allows a cyberattacker to impersonate the owner or read future messages. Private keys, revocation certificates, and key-management instructions all require backup to encrypted offline storage controlled by authorized personnel.

For a team, documentation should record who owns each key, how access is recovered, when keys expire, how employees report a lost device, and how a departed employee's key is revoked. Copying one employee's private key across a department destroys accountability, so each person needs an individual identity and key with organizational recovery handled through approved administrative procedures.

2. Send, Receive, and Read an Encrypted Email

OpenPGP capability should be installed or enabled in the email environment before anyone composes a real message. Ordinary webmail transport provides no automatic end-to-end PGP protection, so Gmail and Outlook users typically need a compatible browser extension, desktop mail application, add-in, or webmail provider.

Apple Mail and Thunderbird users need a compatible OpenPGP application or integration that adds key management and encryption controls. Android and iOS users need a mobile email application or provider that can import the key pair and protect the private key on the device.

The next step is importing the recipient's public key into the key manager and confirming that the email address and identity match the intended person. Composing the message inside the OpenPGP-enabled client allows selection of the recipient's verified public key, and choosing both encryption and signing keeps contents private while letting the recipient check origin and integrity.

A small test message should precede any sensitive information. The recipient uses the matching private key to decrypt it, enters the private-key passphrase when prompted, and confirms that the application reports successful decryption and signature validation.

A PGP-encrypted message can appear as unreadable armored text or an attachment in ordinary email systems, and that appearance indicates a recipient mail client without the capability to interpret encrypted content rather than a failure of the encryption itself.

Replies belong inside the OpenPGP-capable client rather than in a new unencrypted email containing pasted decrypted text. The client encrypts the reply to the original sender's public key and signs it with the responder's private key, and quoted original text is encrypted again as part of the new message.

Reviewing quoted material before sending matters because a reply can expose more information than the new sentence added, particularly when the original message included confidential headers, signatures, or attachments.

Encrypting one message for several recipients requires selecting every recipient's verified public key before sending. OpenPGP creates one encrypted session-key entry for each recipient, allowing each person to use an individual private key to open the same message. Including the sender's own public key preserves the ability to read the message later from Sent Items or another authorized device.

Encrypting a message to the wrong key is not resolved by deleting the email. The sender should contact the unintended recipient through a trusted channel, ask that the message not be opened, forwarded, copied, or retained, and request deletion of the ciphertext and any decrypted files.

A corrected message then goes to the verified key. If the message contained regulated, financial, or highly sensitive information, the organization's incident-reporting process applies, and sending the private key is never an acceptable remedy.

3. Verify Keys Before Sharing Sensitive Information

Key verification prevents encryption to an impostor's public key. A public key can be distributed openly, and that availability proves nothing about whether it belongs to the person named in the user ID. Before transmitting sensitive information, the full fingerprint should be compared with the recipient through a separate trusted channel, such as an in-person exchange, a phone number already on file, a previously verified secure messenger, or an established corporate directory.

Fingerprint verification through the same email thread that delivered the key offers no protection, because a cyberattacker controlling that thread can replace both the key and the supposed confirmation. Comparison must cover every character of the fingerprint instead of a short key ID or display name, and the verified fingerprint belongs in the organization's approved key directory with defined change authority.

According to IBM's 2026 Cost of a Data Breach Report, one in four malicious breaches were AI-enabled, a 56% increase over the prior year, and those breaches cost an average of $6 million against a global breach average of $4.99 million. Synthetic impersonation at that quality makes a rushed key-replacement request far more convincing than it once was.

Verification should repeat whenever the recipient creates a replacement key, changes email addresses, reports a lost device, or receives a key-replacement notice. A new fingerprint is a security event instead of an administrative detail, so the change deserves independent confirmation, a check of expiration and revocation status, and removal of obsolete keys from active use.

For a team deployment, standardization should cover the approved OpenPGP implementation, supported email clients, key-rotation schedule, backup location, verification procedure, and incident workflow. Cybersecurity awareness training should teach employees to pause when a message requests encryption to a new key under urgent circumstances, because the human decision to verify the key is what stops a convincing impersonation from becoming a confidential-data disclosure.

Once these controls exist, PGP email encryption becomes a repeatable communication process rather than a one-time software installation. The security of every protected message still depends on accurate key ownership, disciplined verification, and careful handling of the decrypted content.

Written procedures rarely survive an urgent request from someone who sounds exactly like the CFO. Adaptive Security rehearses that moment with AI-driven email, voice, and SMS phishing simulations.

Take a self-guided tour

Is PGP Email Encryption Secure? Benefits, Risks, and Limitations

PGP email encryption can protect email content with strong confidentiality, integrity, and sender authentication when both parties use maintained software, verify keys, and secure their endpoints. It is a powerful control for message confidentiality and a poor substitute for malware defense, identity protection, or business email compromise procedures.

Unlike transport encryption, PGP is built to keep the message readable only to the intended recipient after delivery, whereas ordinary email security often protects data only while it moves between mail servers.

What PGP never claimed to do is make users anonymous, conceal all email metadata, or stop cyberattacks that compromise an account, device, browser, private key, or human decision.

What Does PGP Email Encryption Protect Against?

The clearest benefit appears when infrastructure is breached. An intruder who obtains stored or relayed messages from a mail server, archive, or backup system still needs the recipient's private key, so a storage compromise that would otherwise expose full message contents yields ciphertext instead.

Encrypted archives and signed files retain their protection after leaving the mail system, which matters when a cloud provider, storage administrator, or backup operator should not be able to read the underlying content.

Integrity protection carries comparable weight in commercial contexts. Contracts, payment instructions, and technical directives can be altered in transit by an intermediary with access, and a signature makes that alteration detectable rather than silent.

Authentication depends on verifying that the public key belongs to the claimed person or organization. If a cyberattacker substitutes a fraudulent public key before verification, the recipient receives a perfectly valid signature from the wrong identity, which is why fingerprint discipline is inseparable from the security claim.

Implementation quality matters as much as protocol design. The OpenPGP specification, RFC 9580, published in 2024, requires implementations to avoid releasing or parsing decrypted data before confirming its integrity, a safeguard relevant to EFAIL-style cyberattacks that abuse permissive rendering behavior.

Organizations should therefore maintain a key directory, verify fingerprints through an independent channel, define trusted administrators, and revoke compromised or retired keys promptly. Teams should also use maintained OpenPGP implementations, keep clients patched, and retest encryption workflows after upgrades.

For organizations that exchange confidential information routinely, phishing simulations should reinforce the difference between a valid cryptographic signature and a trustworthy business request. An authentic-looking signed message can still carry a malicious attachment, request an unauthorized payment, or originate from a compromised account.

What Remains Exposed Under PGP Email Encryption?

PGP email encryption usually protects message content while leaving the facts surrounding the message visible. Sender and recipient addresses remain available to mail infrastructure because servers need routing information to deliver anything at all.

Timestamps, routing headers, delivery paths, and message size also stay observable. Together they reveal who communicates with whom, when a project is active, which outside organization is involved, and whether an exchange contains a large document.

Subject-line exposure depends on the implementation and email workflow. In many PGP setups the subject remains ordinary email metadata, so a subject such as "Acquisition payroll changes" discloses sensitive context even when the body is encrypted.

Users should write neutral subjects, place sensitive details inside the encrypted body, and confirm how a given client handles headers before relying on encryption for confidential projects. The IETF's RFC 9788, Header Protection for Cryptographically Protected Email (2025), specifies how conforming implementations can protect header fields, though support varies across clients.

Anonymity is outside the scope of the technology entirely. Mail providers, network operators, endpoint administrators, and recipients can still observe account identities, connection records, message timing, and other traffic patterns.

Metadata minimization therefore requires separate controls, including restrictive mail retention, access logging, privacy-conscious routing, and tightly scoped distribution lists.

File size and compatibility create practical exposure as well. Encryption and ASCII armor can increase message size, and some gateways, mobile clients, document management systems, and archiving tools cannot process PGP attachments correctly.

A failed delivery pushes employees toward personal email, consumer file-sharing services, or unapproved messaging apps. IT teams should test common file types, publish an approved fallback process, and prohibit sensitive-data workarounds that bypass organizational controls.

Key management remains the central operational burden. Each user must protect a private key, remember a strong passphrase, recognize key expiration, and know how to recover from device loss, while security teams maintain revocation procedures, backup policies, ownership records, and offboarding steps.

A private key copied to an unmanaged device or stored in an exposed cloud folder eliminates the protection the organization expected. Usability failure is itself a security risk, because employees who cannot find a verified key, recover a lost one, or open an attachment reliably will invent unsafe workarounds.

What Cyber Threats Can PGP Email Encryption Not Stop?

PGP cannot protect an endpoint a cyberattacker already controls. Malware, ransomware, a malicious browser extension, or a hostile email plugin can capture plaintext before encryption or after decryption, a keylogger can steal the passphrase, and screen-capture malware can record the message once the user opens it.

Endpoint hardening, application control, patching, anti-malware defenses, and restricted administrative privileges must protect the environment around PGP.

Email-account takeover sits in the same category. Someone controlling a legitimate account can send signed messages, read newly decrypted correspondence, manipulate conversations, or use the account's trusted identity to request funds.

Multifactor authentication, phishing-resistant login methods, session monitoring, recovery-account protection, and out-of-band verification for payment or credential requests address that risk.

BEC illustrates why cryptography does not replace employee judgment. According to the FBI's 2025 Internet Crime Report (released April 2026), cyber-enabled fraud accounted for almost 85% of all losses reported to IC3, totaling $17.7 billion (up from $13.7 billion in 2024), and business email compromise (BEC) remains the persistent risk at the costly center, accounting for $3.046 billion in losses (24,768 incidents, averaging $123,000 per case).

A criminal can impersonate a supplier, executive, attorney, or customer through a separate unencrypted channel and pressure an employee to act. The message never needs to defeat PGP, since it only needs to create urgency, exploit authority, or redirect a transaction.

Cybersecurity awareness training should rehearse phishing, spoofing, vishing, malware delivery, ransomware indicators, and BEC payment verification so employees recognize the cyberattack path before acting. Employees become an active security control once they have clear procedures, realistic practice, and a reliable way to report suspicious requests.

Passphrase compromise and stolen private keys require containment. Organizations should use long, unique passphrases stored through an approved password-management process, protect private keys with hardware-backed storage where appropriate, revoke exposed keys immediately, issue replacements, and investigate every message signed or decrypted during the exposure window.

Backups need encryption and access control, because an unprotected key backup becomes a high-value target. Many OpenPGP workflows also lack forward secrecy, so archived ciphertext can become readable if a cyberattacker obtains the private key later, depending on the key and implementation.

Teams handling long-lived secrets should limit retention, rotate keys according to a documented policy, avoid sending permanent secrets by email, and select communication systems with forward secrecy when that protection is required. PGP protects valuable content in transit and at rest, while trained employees, controlled endpoints, resilient identity processes, and disciplined verification protect the decisions encryption cannot make for anyone.

Endpoint compromise and account takeover defeat encryption without touching a single cryptographic algorithm. Adaptive Security detects the AI-generated phishing that starts those chains and remediates it across every inbox.

Book a demo

Is PGP Email Encryption Suitable for Businesses and Regulated Organizations?

PGP email encryption can protect confidential business communications without making an organization compliant by itself. Deploying it without governance creates risks around lost keys, inaccessible records, unclear ownership, and failed recovery.

NIST key-management guidance treats cryptographic keys as assets requiring documented protection, lifecycle management, and recovery controls. On that basis, PGP belongs inside a broader information-security program rather than beside one.

Oversight quality tracks closely with resilience. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 52% of highly resilient organizations indicate that board members receive regular cybersecurity updates, and 48% report that board members are actively engaged with cybersecurity issues.

Business Use Cases for PGP Email Encryption

PGP suits situations where both parties can exchange and verify public keys and where confidentiality must persist beyond the mail server. Legal teams use it for draft contracts, litigation documents, and privileged correspondence, while finance teams protect account details, acquisition materials, and payment instructions.

Healthcare organizations can encrypt health records when a recipient's public key is known and managed. Engineering teams sign software releases, configuration files, and update packages so recipients can verify origin and integrity independently of any distribution channel.

The same model applies beyond email. PGP-compatible tools can encrypt folders, archives, cloud data before upload, and offline backups before they leave organizational control, and a signed encrypted archive can support an audit objective by associating a protected file with a particular signing key.

Reliable timestamps, access records, and retention procedures remain necessary alongside that association. PGP email encryption becomes harder to govern when recipients are external, numerous, or unfamiliar with key management.

A secure portal can provide authenticated access, expiration dates, download records, and automatic revocation without requiring every recipient to install software or understand public-key fingerprints. Managed file exchange is often easier for recurring vendor workflows, while S/MIME fits organizations that already manage certificates through corporate identity systems.

Modern end-to-end messaging applications are practical for small, time-sensitive conversations, though they rarely satisfy records retention, legal hold, or enterprise archiving obligations. For regulated organizations, the relevant question is whether the complete workflow protects information, verifies recipients, records access, supports retention, and enables timely incident response.

Cybersecurity awareness training content mapped to SOC 2, HIPAA, GDPR, PCI DSS, ISO 27001, NIST CSF, or CMMC can teach those behaviors. PGP alone creates none of those assurances, and treating an encryption tool as a compliance artifact is a common and expensive category error.

Key Management at Scale

The security of PGP email encryption depends on private keys remaining confidential and usable by the right person or team. Each managed identity needs a documented enrollment process, identity verification, protected private-key storage, public-key publication, and a tested method for confirming fingerprints.

Security teams should define rotation triggers, including suspected compromise, role changes, device replacement, cryptographic-policy changes, and scheduled lifecycle reviews.

Recovery must be designed before deployment. A lost private key can make encrypted historical mail or archives unreadable, while an exposed private key can allow a cyberattacker to impersonate its owner.

According to Verizon's 2026 Data Breach Investigations Report, 69% of victims refused to pay ransoms in 2025, up from 65% the prior year, and the median payment fell to $139,875 from $150,000. Refusal is only viable where recovery works, and encrypted archives with unrecoverable keys remove that option.

Organizations should decide whether recovery keys, split custody, or escrow are appropriate for each data class. Escrow supports business continuity while creating a high-value target and weakening separation of duties, so no escrow model should give one administrator unrestricted access to every employee's encrypted records.

Backups require the same discipline. Private keys, revocation certificates, passphrases, and key metadata should be backed up separately, encrypted at rest, and restricted through role-based access.

Recovery drills should prove that an authorized successor can decrypt essential records without restoring unnecessary access to unrelated data. NIST Special Publication 800-57 Part 1 Revision 6, published in 2025, emphasizes policies for protecting cryptographic keying material, making lifecycle decisions, and assigning operational responsibilities.

Offboarding deserves equal attention. When an employee leaves, security staff should revoke or disable the key, preserve business records under approved ownership, transfer active projects to a designated custodian, and remove access to key servers, archives, and backups.

Ownership changes during mergers, reorganizations, or legal matters require the same controls. Quarterly access reviews should identify dormant keys, duplicate identities, unverified external recipients, and privileged recovery access.

Documentation turns encryption into an auditable control. Records should capture who owns each key, which information it protects, when it was issued, where backups reside, who can recover it, and what happens after compromise.

If a private key is suspected of exposure, incident response should revoke it, issue a replacement, identify messages signed or encrypted with the affected key, notify relevant recipients, and preserve forensic evidence. A security awareness training program focused on secure communication can reinforce those decisions through role-based exercises instead of one-time policy acknowledgments.

PGP Email Encryption Versus Other Secure-Email Options

The right method depends on recipient control, administrative visibility, message persistence, and the need for a formal audit trail. The comparison below summarizes where each approach earns its administrative cost.

PGP is a strong choice when an organization controls the participants, needs portable encrypted files, or requires signatures that remain verifiable outside a particular mail platform. Secure portals and managed file exchange are usually easier when external users, audit trails, and revocable access matter more than decentralized key ownership.

S/MIME performs well where certificate management already operates as part of enterprise identity, while encrypted messaging suits tightly scoped conversations more than contracts, archives, or regulated records. A defensible program can use all four methods, assigning each to a documented data classification and workflow.

That approach preserves the confidentiality benefits of PGP email encryption without forcing every business process through manual key exchange. Managing keys over time then requires organizations to verify fingerprints, publish current public keys, set expiration dates, protect recovery material, and revoke compromised keys quickly.

Separate procedures for end users, security teams, IT administrators, and compliance owners keep encryption usable when people change devices, roles, or employers. Every key status change deserves treatment as an operational event, because an expired, revoked, untrusted, or exposed key can block legitimate communication or expose sensitive historical email.

1. Rotate, Revoke, and Recover

Every fingerprint deserves verification through a trusted channel before a public key is accepted. Comparison can happen during an in-person exchange, through a previously authenticated voice call, or against an independently controlled directory, since an email attachment, display name, short key ID, or key-server search result proves nothing about identity.

The OpenPGP specification, RFC 9580 (2024) identifies fingerprints as stronger key identifiers and documents revocation signatures, expiration information, and key-status fields that implementations use to evaluate trust.

Approved public keys belong in one controlled directory, such as an organization-managed portal, directory service, or authenticated website. Records should list the owner, email address, fingerprint, key version, encryption subkey, creation date, expiration date, and revocation status.

When a key is replaced, the new key should be published and the old one marked as superseded. Policy should define which sources clients must refresh and how often, because certificate revocation lists, key-server revocations, and local trust databases update on different schedules.

Setting an expiration date is preferable to allowing keys to remain valid indefinitely. Expiration limits the period in which an unmanaged key stays acceptable, though it recovers no encrypted messages and replaces no revocation process.

Before expiration, administrators should generate or extend the key according to policy, distribute the updated public key, and confirm that frequent correspondents have refreshed their keyrings.

A revocation certificate should be created and stored when each key is generated, kept offline or in restricted escrow controlled by the security team rather than beside the private key on a laptop. If a private key is exposed, a device is stolen, or a passphrase is disclosed, the response is to stop using the key, issue the revocation certificate, publish the revocation, notify correspondents, and generate a replacement.

If the key is merely expired, renewal or replacement follows confirmation that the private material was never exposed.

Revocation makes no historical ciphertext readable. Organizations should retain the old private key, its passphrase or recovery mechanism, and the software needed to decrypt archived messages, then segregate that material from active email operations, limit access to authorized custodians, and record every recovery event.

2. Back Up and Migrate Keys Safely

Private keys should be backed up in encrypted form across at least two geographically separate, access-controlled locations. A backup is not reliable until an authorized operator restores it in a clean test environment, decrypts a representative historical message, and verifies a known signature.

Those tests belong on a schedule tied to every key rotation and a defined recurring interval. A backup that has never been restored is only an assumption.

When moving to a new device, teams should confirm that the replacement is managed, patched, and free of suspected malware. The encrypted private-key backup transfers through an approved channel, imports locally, and is verified against the recorded fingerprint inventory before a signed test message goes to a controlled recipient.

Temporary files, exports, and cached secret material should then be removed from the old device, which is wiped or securely reimaged before disposal. NIST Special Publication 800-63B (2025) treats authenticator loss, theft, expiration, recovery, and binding to an additional device as separate lifecycle events, a useful model for formalizing PGP migration procedures.

Emailing private keys, placing them in unapproved cloud storage, or copying them to every device for convenience defeats the entire control. For high-value organizational keys, recovery authority should be split among multiple custodians using an approved secret-sharing process.

Requiring two of three designated custodians to reconstruct recovery material prevents any single custodian from decrypting archived mail independently. Documentation should record the quorum, custody locations, succession process, and emergency access test.

3. Document and Audit the Process

Responsibilities need assignment before an incident occurs. End users verify fingerprints, protect passphrases, report lost devices or suspicious key prompts, and stop sending encrypted mail when a key status is unclear.

Security teams decide whether a key is trusted, superseded, expired, or compromised, maintain the revocation process, and investigate suspected exposure. IT administrators manage device enrollment, approved software, key publication, access removal, secure wiping, and migration support.

Compliance owners define retention periods, evidence requirements, legal holds, and the separation of active keys from historical-email recovery material. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 30% of highly resilient organizations reported that board members hold personal liability in the event of cyber breaches, compared with 9% of organizations with insufficient resilience.

Documentation should cover onboarding, annual review, rotation, revocation, device migration, backup testing, and offboarding in a controlled procedure. Offboarding must revoke or retire the employee's organizational key, remove the public key from directories, recover company-owned devices and backup material, transfer approved mailbox access, and preserve encrypted records under the organization's retention policy.

Each event record should keep the fingerprint, status decision, approver, timestamp, notification record, and technical evidence. Auditing the key inventory then surfaces duplicate identities, missing revocation certificates, expired keys still in circulation, untested backups, and custodians who no longer hold the assigned role.

Connecting those checks to the organization's broader reporting and audit process lets leadership see whether encryption remains recoverable instead of merely whether keys exist. Reliable lifecycle controls determine whether each message can be encrypted, decrypted, and authenticated at the moment the organization needs it.

Auditors ask for evidence of trained behavior, which a key inventory cannot produce. Adaptive Security delivers compliance training across HIPAA, GDPR, PCI DSS, and SOC 2 with audit-ready reporting.

Take a self-guided tour

How Has PGP Email Encryption Evolved Since 1991, and Is It Still Appropriate?

Phil Zimmermann created PGP in 1991 as a public-key system that let individuals encrypt messages and verify identities without relying on a central authority. Its core model remains relevant, while the software, packet formats, and deployment choices have changed substantially.

Anyone asking what is PGP email encryption today is asking about a standard that has outlived several generations of the products built on it. It remains appropriate for carefully controlled, high-value communication rather than as a universal replacement for ordinary email security.

From PGP to OpenPGP

Zimmermann's original Pretty Good Privacy software established the model still in use. A sender encrypts a message with the recipient's public key, and the recipient uses a private key to decrypt it, while digital signatures add authenticity and integrity so the recipient can verify that the message came from the expected key holder and was not altered.

The technology evolved from one software project into a community specification. OpenPGP became the interoperable format maintained through the Internet Engineering Task Force, and the IETF's OpenPGP specification, RFC 9580, published in 2024 defines version 6 keys, modern key fingerprints, authenticated encryption options, and updated packet formats while preserving compatibility with significant legacy data.

GnuPG, commonly called GPG, became the best-known free implementation for command-line and server use. The GNU Privacy Guard documentation describes GnuPG as a complete implementation of the OpenPGP standard for encrypting and signing data and communications.

Other maintained implementations can also read or create OpenPGP messages. Compatibility therefore depends on the features each implementation supports rather than on whether a product carries the PGP name.

Current Compatibility of PGP Email Encryption

PGP email encryption works across Linux, macOS, and Windows through GnuPG-compatible software, desktop email clients with OpenPGP support, mobile applications, and browser-based tools. Hosted email services can also support OpenPGP through client-side encryption, browser extensions, or application integrations.

Compatibility on paper does not mean every combination works automatically. Organizations must test key versions, algorithms, signature handling, attachments, inline versus MIME formatting, and encrypted replies.

An older client might fail to open a message created with a newer packet format, a mobile application might decrypt the body while mishandling attachments, and a browser extension might expose plaintext if its codebase is unsupported or abandoned.

Interoperability deserves treatment as an operational control. Teams should use maintained software, monitor vendor and project security advisories, and confirm that every approved client handles the organization's selected key and message formats.

Before production use, test messages should be exchanged across supported operating systems, email clients, mobile applications, and hosted services. Validating signatures and fingerprints through a separate trusted channel, testing private-key backup and recovery, and removing unsupported plugins from managed devices complete the exercise.

For broader phishing simulations and human-layer testing, employees should learn to verify unusual requests through a second channel instead of trusting a familiar name or signature alone. Technical encryption protects the message, and employees still control whether a fraudulent request reaches the workflow.

When Another Method May Be Better Than PGP Email Encryption

PGP remains strong when the sender and recipient control their keys and follow a documented process. It protects message content from intermediaries, supports signatures, and allows encrypted archives to remain protected after leaving the mail system.

What it does not do is hide communication context. Email addresses, routing information, timestamps, subject lines in some configurations, and message size can remain visible, as the IETF's Guidance on End-to-End Email Security, RFC 9787, published in 2025, explains in detail.

Key distribution is the larger barrier in practice. Users must obtain the correct public key, verify its fingerprint, protect the private key, manage expiration, and understand revocation, and losing the private key can make historical messages unreadable.

Endpoint compromise also defeats message confidentiality, because malware or an intruder with access to an unlocked device can capture plaintext before encryption or after decryption. Administrative capacity is the deciding variable, and smaller organizations rarely have it in reserve.

According to Verizon's 2026 Data Breach Investigations Report, 96% of ransomware victims were small and medium-sized businesses (SMBs), as SMBs present unpatched devices, compromised credentials, and limited recovery capabilities.

PGP additionally provides limited forward secrecy compared with protocols designed around frequently replaced session keys. A stolen long-term private key can expose stored messages encrypted to it, depending on the key and implementation, so managed end-to-end encrypted messaging or secure file-sharing services often provide better usability and recovery controls for routine employee communication.

PGP earns its administrative burden where durable, independently verifiable message protection is required. Documenting ownership, key recovery, revocation, and client support before sending critical records reveals the central operational question: whether the people handling protected messages can recognize and challenge an unexpected request before trust becomes an irreversible action.

Interoperability testing proves the software works and says nothing about whether employees verify anything. Adaptive Security measures human risk across email, voice, and SMS with realistic phishing simulations.

Take a self-guided tour

Why PGP Email Encryption and Cybersecurity Awareness Training Depend on Human Risk Awareness

When employees ask what is PGP email encryption, the technical answer covers only part of the security decision. Encryption protects selected message content so unauthorized parties cannot read it in transit or protected storage, and it decides nothing about whether a request is legitimate.

Nor does it establish whether a recipient's public key is authentic or whether the person behind the message should be trusted at all. CISA guidance emphasizes verifying unexpected requests through a trusted channel, because encryption protects information while human judgment determines how that information is used.

Measuring that judgment is where most programs fall short. As NIST computer scientist Julie Haney and University of Maryland Associate Professor Wayne Lutters concluded in their peer-reviewed analysis published in Computer (October 2020), compliance metrics do not tell the whole story and fail to measure the effectiveness of the program in a sustained change in employee attitudes and behaviors.

Encryption Does Not Replace Judgment

PGP email encryption protects the contents of an encrypted message rather than every condition surrounding the exchange. It conceals no metadata automatically, validates no business intent, inspects no attachment for malware, and prevents no authorized account from being compromised.

A signed message shows that a private key created the signature, and it cannot show that the key owner's account remains secure or that the request reflects genuine intent. The IETF OpenPGP standard, RFC 9580, defines the cryptographic functions without treating them as authorization controls.

That distinction matters during business email compromise, spear phishing, and insider threat incidents. A cyberattacker who gains access to an employee's private key can send messages that appear authentic in every respect.

A compromised mailbox produces a familiar name, normal writing style, valid signature, and accurate conversation history. None of those signals proves that a payment instruction, credential request, or sensitive-data transfer is safe.

Urgency multiplies the risk. A demand to approve a wire before the bank closes pressures a finance employee to skip independent confirmation, even when the email is encrypted and digitally signed.

The correct response is to verify high-impact requests through a separate, trusted channel and escalate when the request departs from normal procedure.

Cybersecurity awareness training should make that behavior automatic. Staff need practice distinguishing confidentiality from authenticity, treating attachments and links as separate risks, and recognizing that multifactor authentication protects account access without validating every action taken from an authenticated session.

Key Verification as a Security Behavior

Key verification in PGP email encryption is a human security behavior rather than a one-time technical checkbox. Before encrypting sensitive information, employees should confirm that the public key belongs to the intended recipient through a trusted directory, a previously verified contact, or an independent communication channel.

They should also watch for key changes, unexpected identity details, and requests to adopt a new key under time pressure.

Scenario-based information security awareness training should rehearse the decisions employees actually make:

• Recipient verification: Confirm the key fingerprint or identity through a trusted channel before sending confidential material;
• Message evaluation: Review the request, timing, language, and business context instead of treating encryption or a signature as proof of legitimacy;
• Safe handling: Open attachments only through approved workflows, avoid unverified links, and transmit the minimum necessary sensitive data;
• Reporting and escalation: Report suspicious messages, key changes, and payment requests quickly without deleting evidence or blaming the employee.

Cybersecurity awareness training must also explain the limits of signatures. A signature helps establish message integrity and key ownership while establishing nothing about authorization, good intent, or current account security.

Employees should ask whether the request fits the sender's role, whether the transaction follows established controls, and whether an independent approver can confirm it. This approach strengthens social engineering awareness because it teaches people to evaluate the entire interaction instead of hunting for a single visual warning sign, and it gives security teams actionable signals when a user reports a suspicious key, attachment, or request.

Training for Multi-Channel Social Engineering

PGP email encryption addresses one communication layer, while modern social engineering moves between several. A cyberattacker can send an encrypted spear phishing email, follow it with a vishing call from a spoofed executive number, reinforce the request through smishing, and appear in a deepfake video meeting. According to Sumsub's 2025–2026 Identity Fraud Report, deepfake attacks with sophisticated fraud surged 180% YoY including deepfakes, synthetics, and telemetry tampering.

Each channel is designed so the others seem credible, and the 2024 Arup fraud in Hong Kong demonstrated the financial consequence of that synthetic authority. As CNN reported in 2024, an employee transferred about $25 million after joining a video conference populated by deepfake participants.

In a separate 2024 incident, an AI impersonator posing as Ukraine's foreign minister joined a call with U.S. Sen. Ben Cardin, as reported by The Washington Post in 2024. Both incidents show why deepfake awareness training must focus on verification procedures rather than visual cues, because a convincing face or familiar voice is not an approval control.

Role-specific cybersecurity awareness training should use realistic scenarios:

• Finance teams rehearse invoice and payment verification;
• Executives practice responding to cloned voices and deepfake video requests;
• IT teams handle multifactor authentication prompts, account-recovery messages, and suspicious key rotations;
• Customer-facing teams work through vishing and smishing attempts that begin outside email.

An effective information security awareness program also teaches employees to report near misses, preserve original messages, and escalate without shame. Reporting is a defensive signal that helps analysts contain compromised accounts and identify related attempts across channels.

PGP email encryption remains valuable for protecting selected content, and its benefits depend on employees who verify identities, challenge unusual requests, and apply established controls before sensitive data or money leaves the organization.

Multi-channel fraud succeeds because each channel borrows credibility from the last. Adaptive Security scores individual human risk across email, voice, and messaging so security teams can act on exposure.

Explore the platform

How Adaptive Security Strengthens the Human Layer Around PGP Email Encryption

PGP email encryption secures message contents, and the decisions surrounding those messages remain unprotected without a program that measures behavior. Adaptive Security approaches that gap as an outcome problem: its Cloud Email Security connects to Google and Microsoft environments through API instead of MX record changes, applies behavioral signals and language-model reasoning to catch AI-generated phishing that signature-based filters miss, and removes confirmed malicious messages. Each detection then feeds the employee's risk profile, so a blocked impersonation attempt becomes evidence about who needs practice.

That evidence drives the rest of the Adaptive Security platform. Adaptive Security's cybersecurity awareness training platform assigns interactive, role-specific modules on deepfake and AI cyber threats, while its phishing simulations extend rehearsal into voice, SMS, and OSINT-informed spear phishing so employees practice verification on the channels cyberattackers actually combine. Compliance Training covers HIPAA, GDPR, PCI DSS, SOC 2, ISO 27001, and dozens of other frameworks in 39 localized languages, with automated assignment, manager escalation, and audit-ready reporting that documents completion by framework and date range.

Governance extends to the tools employees adopt without asking. According to the National Cybersecurity Alliance's 2025–2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 58% of employed participants reported they have not received any training on the security or privacy risks of AI tools, despite 65% now using AI and 43% admitting to sharing sensitive work information with AI tools. This gap concentrates risk precisely where visibility is lowest, which is why Adaptive Security's AI Governance capability discovers shadow AI and SaaS usage, flags personal-account and data risk, and enforces policy through in-context coaching rather than an annual acknowledgment.

Encryption protects the message while leaving the employee decision that precedes it unmeasured. Adaptive Security closes that gap with AI-native email defense, behavior-based training, and per-employee risk scoring.

Book a demo

Frequently Asked Questions About What Is PGP Email Encryption

What Is PGP Email Encryption Used For?

PGP email encryption protects email contents and attachments from unauthorized reading and verifies that a message came from the holder of a particular private key. OpenPGP combines public-key and symmetric cryptography for encrypted messages, according to RFC 9580. Individuals use it for confidential personal communication, while organizations use it for contracts, legal records, financial information, health data, software releases, and encrypted archives. Digital signatures add integrity and sender verification without encrypting the message. PGP protects no email automatically, hides no metadata by default, and secures no compromised device. Effective use requires compatible software, verified public keys, protected private keys, and a tested recovery process.

Is PGP Email Encryption Safer Than Regular Email?

PGP email encryption provides stronger message confidentiality and integrity than ordinary email when both endpoints and keys are trustworthy. Regular email commonly relies on transport protections between mail servers, while PGP encrypts the message body for the intended recipient and can add a digital signature. OpenPGP is built for public-key or symmetric encryption and signed messages, as specified by RFC 9580. It does not make communication anonymous or stop malware, account takeover, malicious links, impersonation, or unsafe recipient selection. Security also depends on key verification, private-key protection, maintained software, and user judgment. PGP is a strong control for selected content rather than a replacement for broader security practices.

Does PGP Email Encryption Hide the Subject Line and Email Metadata?

PGP email encryption usually leaves the subject line, sender, recipient, routing headers, timestamps, and message size visible. Standard PGP/MIME protects the message body and attachments, while the subject commonly remains available to mail systems and recipients' inboxes. RFC 9787 specifically identifies visible subject lines as an information-leakage concern in end-to-end email security. Some implementations support protected headers or an encrypted subject, though compatibility and display behavior vary. Addresses, timing, routing information, and unprotected subjects should be treated as exposed. Organizations that require metadata confidentiality should use neutral subjects, avoid sensitive names in headers, and select a system that explicitly supports protected metadata.

What Happens if a PGP Private Key Is Lost?

Losing the private key needed for a message generally makes that message undecryptable unless a valid backup or another authorized recipient's private key exists. The matching private key is required to recover the session key and read content encrypted to that key. The GNU Privacy Handbook warns that a document cannot be decrypted without the required secret key and explains why users should include their own public key when encrypting files for themselves. Organizations should create an encrypted backup, protect it with a strong passphrase, test restoration, and store a revocation certificate separately. A lost key also requires issuing a replacement, notifying correspondents, and re-encrypting active archives where possible.

Can PGP Email Encryption Protect Against Phishing and Business Email Compromise?

PGP email encryption cannot by itself stop phishing or business email compromise (BEC), because cyberattackers target decisions, accounts, devices, and workflows instead of simply intercepting message contents. A valid signature confirms control of a signing key and message integrity, and it establishes nothing about whether the request is safe, current, or contextually legitimate. Federal reporting consistently identifies BEC as one of the costliest categories of internet crime, driven by fraudulent payment and credential requests rather than broken cryptography.

Cryptography settles what a message says while leaving open whether anyone should act on it. Adaptive Security builds the verification habits, phishing simulations, and reporting reflexes that decide outcomes.

Take a self-guided tour