Why PPAP Fails as Email Security, and What to Do Instead

The short answer

PPAP — the practice of emailing a password-protected ZIP and then sending the password in a follow-up email — looks encrypted, so it feels secure. In practice it has the following problems.

• Weak against interception: sending the password through the same mail channel adds little real protection
• Insufficient against misdelivery: once the address is wrong, the incident is essentially already done
• Blocks malware inspection: password-protected ZIPs slip past security products along the path
• Does not prove sender authenticity: it is not a defense against spoofing
• Weak access control: you cannot control who is able to open the file

The pattern that needs to go is the design itself: “encrypt the attachment as a ZIP, then send the password later through the same mail ecosystem.”

The right alternatives

1. Normal business email — assume TLS / STARTTLS

Protecting the channel is the baseline. If you also need authenticity or tamper detection, consider S/MIME.

2. Confidential file transfer — authenticated downloads

If you want only the intended recipient to receive the file, control viewing rights, or be able to revoke access later, the natural choice is not an attachment but something like:

• download only after login
• time-limited links
• per-recipient permissions
• audit history when needed

3. When an attachment really is required

The minimum is to send the file and the password through completely different channels. Treat this as a stopgap and plan to move to authenticated sharing over time.

A replacement plan for SMBs

1. Stop these first
   • automatic ZIP encryption
   • automatically sending the password through the same mail channel
   • blanket rules like “always PPAP for important files”
2. Then decide
   • what may be sent over normal email
   • what must not be attached at all
   • what should go through an authenticated download instead
   • the approval flow for the rare exception that still needs an attachment
3. Minimum setup
   • normal email: business correspondence, with S/MIME where appropriate
   • confidential files: authenticated downloads, permission settings, time-limited sharing

Common misconceptions

• “The ZIP is encrypted, so it is safe” — if the key is delivered weakly, that is not enough, and it also blocks inspection along the path
• “Sending it in a separate email is good enough” — to the same person through the same mail system, it is not a strong control
• “If we drop PPAP, we cannot send attachments” — you simply combine normal email, S/MIME, authenticated downloads, and an out-of-band password for genuine exceptions
• “S/MIME is only for large enterprises” — your counterpart’s support matters, but it is more coherent than PPAP, and authenticated downloads are an alternative when S/MIME does not fit

Wrap-up

The trouble with PPAP is that the encryption makes it feel safe even when it is not. The right move is not to keep the PPAP-shaped workflow alive with small tweaks, but to protect email as email and design file transfer as file transfer.

Ending PPAP does not mean ending encryption. It means ending the wrong control and replacing it with one that actually fits the goal.