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.^12345678910

Who this article is for, and what it assumes

Terms used in this article

Here are one-line definitions of the words that appear from Section 3 onward without further explanation.

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.

Knowledge map for this article

PPAP is the practice of sending a password-protected ZIP and then sending the password separately over the same email channel, but it is weak as protection against eavesdropping, it completes the incident when a message goes to the wrong address because the password reaches that same wrong recipient, its encrypted attachments slip past malware scanning easily, and it guarantees neither sender authenticity nor access control. The practical answer instead is to treat ordinary business email as protected in transit by TLS/STARTTLS, to use S/MIME when authenticity or encryption of the message body is required, and to replace the transfer of confidential files with authenticated downloads or with access-controlled sharing on OneDrive or Google Drive, which can handle permissions, expiration dates, and revocation. Only where an attachment is truly unavoidable does delivering the password through a separate channel count as a stopgap.

flowchart LR
    accTitle: Why PPAP fails and what to do instead
    accDescr: Diagram showing that PPAP is weak against eavesdropping and misdirected email and that its encrypted attachments slip past malware scanning easily, and that ordinary email therefore has to be protected with TLS or S/MIME while confidential files move to authenticated sharing.
    ppap["PPAP (Password-Protected ZIP by Email)"]
    authenticated_file_sharing["Authenticated File Sharing"]
    password_protected_zip_attachment["Password-Protected ZIP Attachment"]
    same_channel_password_delivery["Password Sent Over the Same Channel"]
    email_confidentiality["Email Confidentiality"]
    misdirected_email_impact["Impact of Misdirected Email"]
    malware_scan_evasion["Malware Scan Evasion"]
    emotet["Emotet"]
    sender_authenticity["Sender Authenticity"]
    email_access_control["Access Control for Email and Files"]
    tls_email_transport["TLS/STARTTLS Transport Encryption"]
    normal_business_email["Routine Business Email"]
    smime["S/MIME"]
    confidential_file_transfer["Confidential File Transfer"]
    link_revocation["Link and Access Revocation"]
    access_expiration["Share Access Expiration"]
    onedrive_sharepoint_sharing["OneDrive / SharePoint Sharing"]
    google_drive_sharing["Google Drive Sharing"]
    manual_out_of_band_password_delivery["Manual Out-of-Band Password Delivery"]
    ppap -->|"uses"| password_protected_zip_attachment
    ppap -->|"uses"| same_channel_password_delivery
    ppap -->|"not recommended for"| email_confidentiality
    ppap -.->|"may cause"| misdirected_email_impact
    ppap -->|"may cause"| malware_scan_evasion
    emotet -->|"uses"| malware_scan_evasion
    ppap -->|"not recommended for"| sender_authenticity
    ppap -->|"not recommended for"| email_access_control
    tls_email_transport -->|"recommended for"| normal_business_email
    smime -.->|"recommended for"| normal_business_email
    smime -->|"implements"| sender_authenticity
    authenticated_file_sharing -->|"recommended for"| confidential_file_transfer
    authenticated_file_sharing -->|"requires"| email_access_control
    authenticated_file_sharing -->|"requires"| link_revocation
    authenticated_file_sharing -->|"requires"| access_expiration
    ppap -->|"incompatible with"| link_revocation
    onedrive_sharepoint_sharing -->|"implements"| authenticated_file_sharing
    google_drive_sharing -->|"implements"| authenticated_file_sharing
    onedrive_sharepoint_sharing -->|"configured by"| access_expiration
    google_drive_sharing -.->|"configured by"| access_expiration
    authenticated_file_sharing -->|"successor to"| ppap
    manual_out_of_band_password_delivery -.->|"recommended for"| confidential_file_transfer

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (22 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

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 much in the way of 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, you want to control viewing permissions, you want to revoke access 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

Decide the conditions you need to meet before asking “what should we buy”

Starting from product names makes it impossible to compare anything, so lay out the conditions first. The difference from PPAP comes down to these six rows.

Moving from the left column of this table to the right one is what “stopping PPAP” actually consists of. Put the other way round, if a replacement does not satisfy these six rows, there is little point in switching to it.

In most cases you can already do this within your existing subscription

Before buying a new product, first check how far your current subscription already takes you. For the most common platforms, the picture is as follows.

The priority order is sharing with named individuals first, and password-protected links as the fallback. Use a password-protected link only when the recipient cannot set up an account, and convey that password over a channel other than email, such as a phone call or SMS. Push it back through the same email channel and you are back to the same structure as PPAP, only with the appearance of having replaced it.

The minimum set to have in place if you build it yourself

If you build a download feature into your own site, the things to think about do not change.

1. A way to identify the recipient Either issue an account to the person you are handing the file to, or issue a single-use token URL per engagement.
2. Expiry Give both the URL and the token an expiration. When it expires, return an explicit “this link has expired” rather than making it merely invisible.
3. A revocation control Whoever runs the system needs to be able to invalidate access immediately from an admin screen. Without this, noticing a misdirected send leaves you with nothing to do about it.
4. Access logs Record when, from which IP, and which file was retrieved. When something goes wrong, the dividing line is whether you can answer “did it actually reach anyone, or not?”
5. Protection for where the files live Meaning: do not leave them in a state where knowing the URL is enough to fetch them. The IPA likewise concludes that websites handling non-public information need authentication and access control.⁸
6. Handling the upload direction Route incoming files from the other party through the same mechanism. A receive-only form is safer than continuing to accept email attachments.

Of these six, items 2 and 3 are the decisive difference from PPAP. Build or buy, anything that lacks them is not a replacement.

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, people on the ground drift 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

For environments where the diagram does not render, here is the same decision as a table. Read from the top and take the conclusion on the first row that applies.

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.

Frequently Asked Questions

Common questions about the topic of this article.

What is PPAP?

It is the practice of putting a file into a password-protected ZIP, sending that ZIP in a first email, and sending the password in a second email. Because nothing goes out in plaintext it looks safe, but the range it actually protects is quite limited. Confidentiality on the transport path is weak, it is insufficient as a safeguard against misdirected email, and it guarantees neither sender authenticity nor access control.

Why is PPAP dangerous?

There are four main problems. Sending the password separately through the same email channel is weak against eavesdropping, because the set of people who can see the ZIP and the set who can see the password end up nearly identical. It is insufficient against misdirected email, because getting the address wrong means the decryption password reaches that same wrong recipient. A password-protected ZIP is encrypted, so it easily slips past detection and quarantine by security products along the mail delivery path, and it has a track record of being abused by attack email such as Emotet. And it guarantees neither sender authenticity nor access control.

What should we use once we stop using PPAP?

The basic move is to split the problem into three by purpose. Ordinary business email should assume transport protection such as TLS / STARTTLS, and if you need authenticity or encryption of the email itself, use S/MIME. For handing over confidential files, move away from attachments toward authenticated downloads or access-controlled sharing, which also cover permission settings, time-limited links, and revocation. The important thing is not to try to solve every email problem with a ZIP password.

What if we really do have to send an attachment?

When the other party's circumstances leave no option but an attachment, the minimum bar is to convey the encrypted 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, it is safer to treat it as something you will move to authenticated sharing later.

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.