Why PPAP Is Bad for Email Security, and What to Do Instead

“Is it really safe to send a password-protected ZIP and then send the password in a separate email?” This question still comes up regularly. On the surface it looks safe because something is encrypted, but in practice that is exactly the trap.

The practice known in Japan as PPAP is weak as protection against eavesdropping, insufficient as protection against misdirected email, and on top of that it tends to obstruct inspection along the mail delivery path — so it is hard to recommend under current email security practice.¹²³⁴

In this article, based on public-sector documents and primary sources verifiable as of April 2026, we look at the problems with PPAP and what the natural replacements look like in practice.^12536748910

1. The Conclusion First

Abandoning PPAP is not about abandoning encryption. What should be abandoned is the design of “encrypt the attachment as a ZIP, then send the password later through the same email channel.”

What to consider instead are these three things.

1. For ordinary business email, assume transport protection such as TLS / STARTTLS.⁷¹⁰
2. If you need authenticity or encryption of the email itself, use a mechanism like S/MIME.⁵³⁶
3. For handing over confidential files, move away from attachments toward authenticated downloads or access-controlled sharing.⁴⁸⁹

In short, what matters is not trying to solve every email problem with a ZIP password.

2. What Is PPAP, Anyway?

PPAP here generally refers to the following flow.

1. Put the file into a password-protected ZIP
2. Send the ZIP in a first email
3. Send the password in a second email

This practice tends to be understood as “safe because we are not sending in plaintext.” In reality, however, the range of what it actually protects is quite limited.

PPAP is far less all-purpose than it looks: it appears “vaguely safe” while failing to protect the parts that matter.

3. Why PPAP Is Bad

3.1 Weak as protection against eavesdropping

Japan’s Cabinet Office has concluded that automatically sending the password through the same channel as the ZIP file is not an appropriate method.¹ The important point is that encrypting the file means little unless the design also covers how the key is delivered.

If you simply send a follow-up through the same email environment, to the same inbox, to the same recipient, the set of people who can see the ZIP and the set who can see the password end up nearly identical. What remains is the mere fact of “having encrypted,” with little real confidentiality behind it.

3.2 Insufficient as protection against misdirected email

Some operations treat PPAP as a safeguard against misdirected email, but it is weak there too.

The IPA’s published answers for the Applied Information Technology Engineer Examination list, as a problem with PPAP, that if the main email is misdirected, the decryption password also reaches the wrong recipient.³ A Digital Agency document likewise concludes, in essence, that “sending it as a separate email means sending it to the same party, so it does not function as a control.”⁴

In other words, once the ZIP has gone to the wrong recipient, if you then habitually send the password as well, the incident simply completes itself. What is actually needed is a handover method that allows recipient verification, approval, pre-send review, and post-send revocation or recall.

3.3 It obstructs malware inspection

This is a point about PPAP that must not be overlooked.

The IPA has warned, regarding Emotet attack emails carrying password-protected ZIP attachments, that because the attachment is encrypted, there is a high probability it slips past detection and quarantine by security products along the mail delivery path and reaches the recipient.²

The sender may believe they have “made it safe by encrypting,” but from the receiving and relaying side it has become an attachment whose contents are hard to inspect. On this point as well, PPAP cannot be called a method that plays well with modern email defenses.

3.4 It guarantees neither authenticity nor access control

PPAP does not prove that the sender is genuine. Nor does it provide meaningful access control: who downloaded what and when, whether access can be revoked later, whether permissions can be split per recipient.

Meanwhile, the IPA covers digitally signed email such as S/MIME, which connects contextually as an alternative to PPAP.⁵⁶ And the IPA’s web security materials conclude that websites handling non-public information need authentication and access control.⁸

Put these two together and the answer is fairly clear.

• If you want email authenticity and tamper detection: S/MIME
• If you want viewing permissions and revocation management for files: authenticated downloads

Sending the ZIP password separately answers neither of these cleanly.

4. The Right Approach Is “Separating by Purpose”

The requirement “we want to send safely” is, in reality, not a single requirement. Fail to separate it, and the design collapses into trying to cover everything with PPAP.

4.1 Ordinary business email

For ordinary business email, transport protection such as TLS / STARTTLS is the baseline.⁷¹⁰ On top of that, if you need sender authenticity, tamper detection, or encryption of the email body itself, the sound move is to consider S/MIME.⁵³⁶

4.2 Handing over confidential files

You want the file to reach only the intended person, want to control viewing permissions, want to revoke later. For these requirements, authenticated downloads or access-controlled sharing are more natural than attachments.⁴⁸⁹

For example, requirements like the following are easier to manage on the web side than via attachments.

• Download available only after login
• Links can be time-limited
• Permissions can be split per recipient
• History can be kept where needed

4.3 When an attachment is truly unavoidable

There are situations where the other party’s circumstances leave no option but an attachment. In that case, as the Cabinet Office’s guidance also indicates, the minimum bar is to convey the file and the password through entirely separate channels.¹

But this is a stopgap, not a final form. Rather than fixing it as the standard everyday practice, plan on eventually moving to authenticated sharing.

5. A Replacement Procedure for Small Businesses

When a small business moves off PPAP, clarifying the classification first works better than introducing a large system from the start.

5.1 What to stop first

• Automatic ZIP encryption
• Automatic separate-password sending through the same email channel
• The blanket rule of “all important files go via PPAP”

5.2 What to decide next

• What may be sent by ordinary email
• What is banned from attachments
• What gets routed to authenticated downloads
• What the approval procedure is for exceptional attachments

5.3 Thinking in terms of a minimal setup

At first, simply splitting into the following two tracks is enough.

1. Ordinary email
   • Business communication
   • S/MIME where needed
2. Confidential files
   • Authenticated downloads
   • Permission settings
   • Time-limited sharing

If this stays vague, the field inevitably drifts back to “PPAP, just in case.”

6. A Decision Flow

flowchart TD
    A[What do you want to hand over] --> B{Is it a highly confidential file}
    B -- No --> C[Ordinary business email]
    C --> C1[Send assuming TLS / STARTTLS]
    C --> C2[If authenticity or encryption matters, S/MIME]

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

    D -- No --> F{Is an attachment truly unavoidable}
    F -- Yes --> G[Encrypted file + manual password via a separate channel]
    F -- No --> E

What matters in this diagram is not positioning PPAP as an all-purpose middle ground. Email and file handover are easier to design when thought about separately.

7. Common Misconceptions

7.1 “The ZIP is encrypted, so it’s safe”

Even with encryption, it is not sufficient if the key delivery is weak. Worse, password-protected ZIPs can obstruct in-path inspection.¹²

7.2 “Sending it in a separate email is enough”

A follow-up to the same recipient through the same email channel is not a strong control.¹⁴

7.3 “If we stop PPAP, we can’t send attachments anymore”

Not so. You simply use the right tool for each case: ordinary email, S/MIME, authenticated downloads, and an out-of-band password for the exceptions.

7.4 “S/MIME is for big companies and not realistic”

You do have to check the other party’s support, but at minimum it is more coherent than PPAP with respect to what you are trying to protect. And for counterparties where S/MIME does not fit, authenticated downloads remain as the other option.

8. Summary

What makes PPAP bad is that encrypting makes it easy to feel safe without being safe. In reality, these problems remain:

• Separate sending through the same email channel provides weak confidentiality
• It is insufficient against misdirected email
• Password-protected ZIPs obstruct in-path inspection
• It guarantees neither sender authenticity nor access control

¹²³⁴

So the thing to do is not to tweak PPAP-style operations a little and keep them on life support. It is to protect email as email, and design file handover as file handover.

In one sentence:

Abandoning PPAP does not mean abandoning encryption — it means abandoning the wrong control and replacing it with controls that fit the purpose.

Related Articles

• Designing Bulk Email for Small Businesses Without Locking Into a Specific Service
• How to Connect Articles and Service Pages - Internal Link Design Basics
• How to Build Service Pages - An Organizing Procedure for Technical B2B

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.