Why PPAP Is a Bad Email Security Practice and What to Do Instead

A question still comes up surprisingly often: if a file is sent as a password-protected ZIP and the password is sent in a second email, isn’t that secure enough?

In practice, the answer is no. What is commonly called PPAP is weak as a protection against interception, weak as a protection against misdelivery, and often harmful to gateway-level malware inspection. That is why it is hard to recommend as a modern email-security control.¹²³⁴

This article summarizes the practical problem with PPAP and the more defensible alternatives, based on public and primary sources available as of April 2026.^12536748910

Contents

1. 1. The short answer
2. 2. What PPAP actually is
3. 3. Why PPAP is a bad fit today
   • 3.1 It is weak against interception
   • 3.2 It is not a serious control for misdelivery
   • 3.3 It interferes with malware inspection
   • 3.4 It does not provide authenticity or access control
4. 4. What to do instead
   • 4.1 Ordinary business email
   • 4.2 Confidential file transfer
   • 4.3 Cases where attachment is unavoidable
5. 5. A practical migration path for SMEs
   • 5.1 Stop these patterns first
   • 5.2 Define these decisions next
   • 5.3 A minimal target state
6. 6. Decision flow
7. 7. Common misunderstandings
   • 7.1 “The ZIP is encrypted, so it must be safe”
   • 7.2 “A second email is enough”
   • 7.3 “If we stop PPAP, we lose the ability to send files”
   • 7.4 “S/MIME is only for large enterprises”
8. 8. Wrap-up
9. Related articles
10. References

1. The short answer

Stopping PPAP does not mean stopping encryption. What should be retired is the design pattern of encrypting an attachment as a ZIP file and then sending the password through the same mail ecosystem afterward.

In practice, the replacement usually looks like this:

1. Use transport protection such as TLS / STARTTLS as the baseline for ordinary business email.⁷¹⁰
2. Use S/MIME when message authenticity, integrity, or email encryption is actually required.⁵³⁶
3. Use authenticated download or access-controlled sharing for confidential file delivery.⁴⁸⁹

The key idea is simple: do not try to solve every email-security problem with a ZIP password.

2. What PPAP actually is

In the form that matters operationally, PPAP usually means this:

1. Put the file into a password-protected ZIP archive
2. Send the ZIP by email
3. Send the password in a separate follow-up email

At a glance, this feels safer than sending the file in plain form. The problem is that the control covers much less than people often assume.

Security objective	Does PPAP solve it well?	Practical reality
Confidentiality in transit	Not well	The benefit is weak when the password travels through the same mail path
Misdelivery prevention	No	If the recipient is wrong, the second message often completes the mistake
Malware inspection	Often worse	Encrypted attachments can bypass gateway inspection
Sender authenticity	No	It does not prove who sent the mail
Access control	No	It does not manage who can view, revoke, or audit access

That is the core issue. PPAP looks broad, but the actual protection it offers is narrow.

3. Why PPAP is a bad fit today

3.1 It is weak against interception

Japan’s Cabinet Office explicitly stated that sending the password automatically through the same route as the ZIP file is not appropriate.¹ This matters because encryption is only part of the design. The key-delivery method matters as well.

If the file and the password are both available through the same email environment, the same inbox, and the same recipient path, the real confidentiality gain is limited. You may still be able to say the file was encrypted, but that alone does not mean the control is strong.

3.2 It is not a serious control for misdelivery

Many teams have treated PPAP as a misdelivery countermeasure. That is hard to defend.

IPA’s sample answer for the Applied Information Technology Engineer Examination points out that if the main email is sent to the wrong recipient, the decryption password also reaches that same recipient.³ A Digital Agency summary makes a similar point: sending the password in a separate email to the same recipient does not function as a meaningful control.⁴

So if the wrong person receives the ZIP and the operator then sends the password as usual, the incident is already complete. Real misdelivery controls are things like recipient confirmation, approval flow, delayed sending, revocable access, and controlled delivery methods.

3.3 It interferes with malware inspection

This is one of the strongest arguments against PPAP in modern operations.

IPA warned that password-protected ZIP files were used in Emotet attack emails, and that because the attachment was encrypted, security products on the delivery path were more likely to let it pass through to the end user.²

That means the sender may think the file was protected, while the receiving side has been handed something that is harder to inspect automatically. From a mail-security perspective, that is often a step backward.

3.4 It does not provide authenticity or access control

PPAP does not prove that the sender is genuine. It also does not provide practical control over who can access the file, whether access can be revoked later, or whether download history can be tracked.

By contrast, S/MIME is directly related to message authenticity and signed or encrypted email.⁵⁶ And IPA’s website security guidance makes clear that non-public information on the web should be protected by authentication and access control.⁸

Put together, the practical split becomes clear:

• If the problem is authenticity or message integrity, use S/MIME
• If the problem is controlled file delivery, use authenticated download or access-controlled sharing

PPAP fits neither problem particularly well.

4. What to do instead

The main replacement is not one single product. It is a clearer separation of requirements.

4.1 Ordinary business email

For standard business mail, transport protection should be the baseline. TLS / STARTTLS belongs here.⁷¹⁰ If you additionally need authenticity, tamper evidence, or message-level encryption, S/MIME is a much cleaner answer than PPAP.⁵³⁶

4.2 Confidential file transfer

If the real need is to let the intended recipient access a confidential file and nobody else, email attachment is often the wrong delivery mechanism.

Authenticated download or access-controlled sharing is usually better when you need to:

• require login before download
• set an expiry date
• restrict access per recipient
• disable access later
• keep an audit trail when necessary

This aligns much better with the access-control guidance described in public security references.⁴⁸⁹

4.3 Cases where attachment is unavoidable

Sometimes the recipient side cannot use a portal or controlled download flow. In those cases, a manually communicated password over a genuinely separate channel may be the minimum acceptable fallback.¹

Even then, that should be treated as a temporary exception, not the standard pattern you optimize around.

5. A practical migration path for SMEs

SMEs do not need a huge transformation project to stop PPAP. What they usually need first is a cleaner classification of delivery methods.

5.1 Stop these patterns first

• automatic ZIP encryption for every important attachment
• automatic password follow-up through the same email ecosystem
• blanket rules that say all sensitive files must go through PPAP

5.2 Define these decisions next

• what can still be sent as normal email
• what should no longer be sent as an attachment
• what should move to authenticated download
• who approves exception cases

5.3 A minimal target state

A simple two-lane model is often enough at first:

1. Ordinary email
   • business communication
   • S/MIME only where justified
2. Confidential file delivery
   • authenticated download
   • access control
   • expiry and revocation where needed

If these categories remain unclear, teams tend to drift back to “just do PPAP.”

6. Decision flow

flowchart TD
    A[What are you sending?] --> B{Is it a confidential file?}
    B -- No --> C[Ordinary business email]
    C --> C1[Use TLS / STARTTLS as baseline]
    C --> C2[Add S/MIME when authenticity or encryption matters]

    B -- Yes --> D{Can the recipient log in to receive it?}
    D -- Yes --> E[Authenticated download / access-controlled sharing]
    E --> E1[Add expiry, revocation, and per-recipient access if needed]

    D -- No --> F{Is attachment unavoidable?}
    F -- Yes --> G[Encrypted file + manually shared password over a separate channel]
    F -- No --> E

The important point here is that PPAP is not treated as a general-purpose middle ground. Email security and file-delivery control are different design problems.

7. Common misunderstandings

7.1 “The ZIP is encrypted, so it must be safe”

Not necessarily. If the password-delivery method is weak, the overall control is weak. And encrypted ZIP attachments can reduce the effectiveness of gateway inspection.¹²

7.2 “A second email is enough”

A second email to the same recipient through the same system is not a strong control.¹⁴

7.3 “If we stop PPAP, we lose the ability to send files”

No. You are usually just replacing one weak pattern with a better combination of standard email, S/MIME, authenticated download, and narrowly defined exceptions.

7.4 “S/MIME is only for large enterprises”

Recipient readiness still matters, but from a security-design perspective it is far more coherent than PPAP when authenticity and message protection are the real requirements. And when S/MIME is not the right fit, authenticated delivery remains a viable alternative.

8. Wrap-up

The reason PPAP is a bad practice is not that encryption itself is bad. The problem is that PPAP gives many teams the feeling that they solved confidentiality, while several core risks remain:

• sending the password through the same ecosystem weakens the real confidentiality benefit
• it does little to prevent misdelivery
• encrypted ZIP attachments can hinder malware inspection
• it does not solve authenticity or access-control requirements¹²³⁴

So the better direction is not to create a slightly different PPAP. It is to separate the problem correctly:

• protect email as email
• design file delivery as file delivery

That is the practical meaning of “stopping PPAP.”

Related articles

• How SMEs Can Design Bulk Email Without Locking Themselves into One Vendor
• How to Connect Articles and Service Pages - The Basics of Internal Linking
• How to Structure a Service Page for a Technical B2B Website

References