You're about to send a board deck, signed contract, employee roster, or customer export by email. You compress the files, add a password, and assume that's enough.
Often, it isn't.
A password-protected ZIP can be either a reasonable layer of protection or a weak wrapper that creates false confidence. The difference comes down to the encryption method, the tool you used, and whether the recipient can open the archive on their device without falling back to something less secure. That matters when the file is moving through Gmail, Outlook, or Microsoft 365, where the attachment may be forwarded, synced across devices, or left sitting in an inbox longer than intended.
Table of Contents
- Why Most Password-Protected ZIPs Are Not Secure
- Choosing Your Encryption Standard ZipCrypto vs AES-256
- How to Create AES-256 Encrypted ZIPs on Windows
- Creating Encrypted Archives on macOS
- Encrypting Files on Linux with Command-Line Tools
- Secure Sharing The Last Mile of Encryption
Why Most Password-Protected ZIPs Are Not Secure
The common mistake is simple. People think password-protected automatically means secure.
It doesn't. A ZIP file can ask for a password and still use an outdated protection method that's far weaker than people realize. If you're emailing sensitive business material, the method matters as much as the password itself.
The false sense of safety
ZIP encryption has history behind it. The ZIP format originated in 1989, and by 1993 PKZIP 2.0 introduced ZipCrypto as the standard for ZIP passwords. Its weaknesses were exposed by 1994. AES-256 support arrived later, in 2003, and offers a 2^256 key space that is infeasible to brute-force with current technology. A separate issue still remains: a 2006 SANS disclosure found that ZIP metadata such as filenames often stays visible, and OWASP testing in 2023 found this issue in 70% of ZIP tools tested (Mailfence on ZIP encryption).
That's the part most quick tutorials skip. They show how to add a password, but they don't explain whether the resulting file uses weak legacy encryption, whether filenames are exposed, or whether the recipient's default unzip app will fail.
Practical rule: If the file contains personal data, financial records, legal material, board communications, or customer information, treat “password-protected ZIP” as incomplete advice.
Why this matters in email
Email is where bad assumptions become operational risk. An executive assistant sends a “protected” ZIP from Outlook. A founder forwards a customer spreadsheet from Gmail. An IT admin shares an incident export with an outside law firm. In each case, the archive may pass through multiple inboxes and devices before anyone opens it.
If the ZIP uses weak encryption, the attachment isn't much of a barrier. If filenames are exposed, the subject matter may still leak even when the file contents stay encrypted. That's especially relevant when the filename itself contains client names, case numbers, or phrases like “Payroll-Q4” or “Acquisition-Plan.”
Security-conscious teams should pair encrypted attachments with tighter inbox controls too. A contact-first email posture reduces the odds that sensitive replies or password follow-ups get buried or spoofed. That's part of the broader operational discipline covered in founder inbox OPSEC guidance.
What actually works
For practical business use, the baseline is straightforward:
- Use AES-256, not ZipCrypto: Legacy ZIP protection is the wrong choice for confidential email attachments.
- Assume metadata may leak in standard ZIP workflows: File names can still reveal too much.
- Test recipient compatibility before you send: Security that the recipient can't open becomes a help desk problem.
That trade-off is where most of the actual work sits.
Choosing Your Encryption Standard ZipCrypto vs AES-256
The security decision here is simple. If the ZIP will carry confidential business information over email, choose AES-256. Use ZipCrypto only if you are forced to support an older tool and the file does not create real business risk if exposed.
The real difference
These two options are not in the same class.
| Standard | Security profile | Compatibility | Best use |
|---|---|---|---|
| ZipCrypto | Old and weak. Attack tools can recover passwords far more easily than with modern encryption. | Broad support in built-in ZIP utilities and older archive software | Low-sensitivity files where legacy compatibility matters more than confidentiality |
| AES-256 | Modern encryption suitable for sensitive business files when paired with a strong password | May require 7-Zip, Keka, WinRAR, PeaZip, or another compatible archive tool | Finance, legal, HR, customer data, board materials, incident exports |
For email workflows, that distinction matters. A password prompt can create a false sense of security if the archive uses ZipCrypto. The attachment looks protected, but the protection is weak enough that it should not be trusted for payroll files, contracts, customer exports, or executive communications.
AES-256 is the safer default because it solves the right problem. It protects file contents with a modern standard that is widely supported by serious archive tools across Windows, macOS, and Linux.
The trade-off that breaks cross-platform sharing
Security teams run into the same problem again and again. The sender creates a properly encrypted ZIP with AES-256, the recipient double-clicks it with a built-in archive tool, and the file will not open.
That failure is usually a compatibility issue, not a bad password.
Windows File Explorer and macOS Archive Utility do not give the same predictable support for AES-encrypted ZIPs as third-party tools. In mixed-device teams, that creates friction fast. One person is on Windows with 7-Zip, another is on a Mac using Finder, and outside counsel may be opening the attachment on a locked-down laptop with whatever tool IT approved years ago.
For business email, the practical question is not just "Which standard is stronger?" It is "Which standard is strong enough and still likely to open on the recipient's device without a support thread?" That is the trade-off many tutorials skip.
My rule is straightforward. If the file is sensitive, keep AES-256 and solve the compatibility issue upfront by telling the recipient which app to use. Do not weaken the archive just to match a default unzip tool.
Choose the encryption standard based on the impact of exposure, then manage compatibility as an operational step.
A workable policy for executives and admins
A reliable cross-platform workflow looks like this:
- Use AES-256 for confidential attachments
- Confirm the recipient has a compatible archive app before sending
- Send brief opening instructions with the file, such as "Open with 7-Zip, Keka, WinRAR, or PeaZip"
- Share the password in a separate channel
- Use neutral filenames so the attachment name does not reveal the subject matter
- Use 7z instead of ZIP if filename privacy or stronger archive controls matter more than built-in compatibility
The password still matters. Use a long passphrase, not a short business word with a number at the end. In practice, I recommend at least 14 to 16 characters for anything tied to legal, financial, HR, or executive communications.
This fits the same operational mindset used in Microsoft 365 executive account hardening. Strong controls only help if the workflow around them is clear enough that people follow it.
If a leaked attachment would create legal exposure, deal friction, or reputational damage, AES-256 is the correct choice. Then document the recipient steps and send with fewer surprises.
How to Create AES-256 Encrypted ZIPs on Windows
On Windows, the most reliable way to create an encrypted ZIP for email is 7-Zip. It's straightforward, it gives you control over the encryption method, and it avoids the biggest mistake people make with Windows sharing.
That mistake is assuming the default compressed folder workflow gives you modern encryption. It doesn't.
The exact 7-Zip workflow
The verified 7-Zip sequence matters here. The secure workflow is:
- Right-click the file or folder
- Select 7-Zip > Add to archive
- Set Archive format to zip
- Enter the password twice
- In the encryption method dropdown, select AES-256
- Click OK
That fourth and fifth click sequence is the whole game. The guidance is explicit that skipping the encryption-method selection and leaving the default can weaken the archive by falling back to ZipCrypto. Institutional documentation also confirms this workflow supports recipients across Windows, macOS, and Linux when they use compatible tools.
What to check before clicking OK
In practice, I tell teams to pause for five seconds and verify three fields:
- Archive format: It should say zip if you need a ZIP file specifically.
- Password fields: Enter and confirm carefully. One typo creates needless resend loops.
- Encryption method: It must say AES-256.
Operational check: If you don't explicitly verify the encryption dropdown, assume the file may not meet your security standard.
That quick pause matters most when you're attaching files in Outlook during a busy day or sending from Gmail after dragging in a freshly created archive. Rushed users often create the archive first, attach it second, and never reopen it to confirm the setting.
A Windows sharing example
Suppose you need to send a customer renewal spreadsheet to outside counsel.
In Outlook, create the AES-256 ZIP first, then attach it to a new message. In the email body, state that the attachment is an encrypted ZIP and that the password will be sent separately. Send the password through a different channel, such as a phone call or secure message.
In Gmail, the same rule applies. Don't upload the raw spreadsheet and rely on “I'll delete it later.” Create the encrypted archive locally, attach only the encrypted file, then send the password out-of-band.
For teams tightening executive messaging controls, inbox hardening matters alongside attachment handling. If you're standardizing Microsoft 365 for leadership, this executive Microsoft 365 hardening guide is a useful companion process.
What not to use for sharing
Windows also has Encrypt contents to secure data through EFS. That can protect files tied to a Windows user profile, but it's not the right tool for sending encrypted archives to other people by email. Shared access and portability get messy fast.
If your goal is send securely to another person, use a standard archive tool with explicit AES-256 settings instead.
A visual walkthrough may help if you're rolling this out to non-technical staff:
Creating Encrypted Archives on macOS
A common failure point starts after the email is sent. A finance lead on Windows creates an encrypted ZIP, sends it to a Mac-based executive, and the recipient cannot open it with the default tools. The file is fine. The workflow is not.
macOS can create encrypted archives, but the built-in path is limited and easy to misread. Archive Utility handles basic compression well. It does not give business users a clear, dependable interface for creating modern encrypted ZIPs for email sharing.
Option one for technical users
If you already use Terminal, macOS includes a built-in command:
zip -e secured.zip file.txt
This prompts for a password and creates an encrypted ZIP. It is fast and requires no extra software.
Use it carefully. On many macOS systems, zip -e produces a password-protected ZIP with older encryption methods, not AES-256. That may be acceptable for low-sensitivity files or one-off compatibility cases, but it is a poor default for sensitive business documents sent by email. If the archive contains board material, legal drafts, customer data, or financials, use a tool that lets you choose stronger encryption explicitly.
Option two for business users who need a reliable GUI
A dedicated archive app such as Keka is usually the better choice on macOS. The value is not just convenience. It lets you set the archive format and password intentionally, which reduces mistakes when an assistant, executive, or sales leader is sending protected files under time pressure.
Use this workflow:
- Open Keka.
- Choose ZIP only if the recipient specifically requires a ZIP file.
- Set a strong password.
- Add the files or folder.
- Create the archive.
- Extract the archive once on your own Mac to confirm the password works.
- If the file is going to a mixed Windows and Mac audience, test opening it on the recipient platform before you make it part of a repeat process.
That last check prevents the usual email thread where someone asks for the attachment again because their default archive app could not open it.
macOS-specific problems to avoid
The biggest mistake is assuming "password-protected ZIP" means the same thing across every tool. It does not. A file created from Terminal may open in places where a stronger AES-encrypted ZIP does not, while an AES-encrypted ZIP may be the right security choice but require the recipient to use Keka, The Unarchiver, 7-Zip, or another compatible app.
That trade-off matters in business email. If confidentiality is the priority, create the stronger archive and tell the recipient what they need to open it. If broad compatibility is the priority, confirm what the recipient can open before you send the file.
Another common problem is compressing the wrong item. Mac users often drag a folder into an archive tool without checking whether it includes hidden files, drafts, or exported copies they did not intend to share. Review the folder contents before you build the archive.
A practical Mac workflow for email
For Gmail on macOS, create the encrypted archive first and attach only that file. In the email, say that the attachment is encrypted and note any app requirement if the recipient is also on a Mac.
For Outlook for Mac, use the same process. Send the password through a separate channel, such as a phone call, text message, or secure chat. If the recipient is an executive or outside counsel, add one short instruction line so they do not fall back to asking for an unencrypted resend.
A good example is simple: “Attached is an encrypted ZIP. Open it with Keka or another compatible archive tool if the default Mac utility does not work. I'll send the password separately.”
That keeps the exchange secure and cuts down on support back-and-forth.
Encrypting Files on Linux with Command-Line Tools
Linux users usually want the shortest path that works. There are two practical options, depending on whether you need a standard ZIP file or stronger privacy around filenames as well.
Using zip for an encrypted archive
For a basic encrypted ZIP, use:
zip -e secured.zip file.txt
You'll be prompted for a password. This is simple and widely available, which makes it useful when the recipient specifically asked for a ZIP archive.
The limitation is that standard ZIP workflows can still expose metadata depending on the toolchain. If the filename itself is sensitive, a plain ZIP may not be the right container.
Using 7z when filename privacy matters
If p7zip or a compatible 7z implementation is installed, use a 7z archive when you want stronger protection around both content and names:
7z a -p secret.7z file.txt
If your tool supports header encryption options, enable them so the archive also protects filenames. That's the key advantage of 7z over standard ZIP in sensitive workflows.
A practical rule for Linux admins:
- Use ZIP when interoperability is the top requirement.
- Use 7z when confidentiality is the top requirement.
- Test extraction on the recipient platform before making it part of a recurring process.
Where this fits in email workflows
For Gmail, Linux senders usually work from a browser and attach the finished archive. For Outlook on the web, the flow is similar. The archive format matters more than the mail client.
If you're supporting executives or legal staff, document one approved command and one approved recipient workflow. That keeps users from improvising with ad hoc flags and inconsistent archive behavior.
Secure Sharing The Last Mile of Encryption
Your CFO emails board materials as an encrypted attachment at 5:40 PM. The archive is protected, but the filename says exactly what it is, and the password goes out in the reply right after. At that point, the encryption adds far less protection than people assume.
The last mile is where file security usually breaks. The archive format matters, but the delivery method, password handling, and recipient setup decide whether the protection holds up in a real email workflow.
Start with a password the recipient can use and an attacker cannot guess
Avoid passwords tied to the company name, deal name, quarter, sender, or document title. Those are the first patterns an attacker will try, especially if the archive name gives them context.
Bad examples:
Contract2025AcmeBoard1Q4Payroll
Use a unique passphrase that is unrelated to the file and long enough to resist guessing. For executive, legal, HR, finance, or customer data, length matters more than complexity rules copied from old password policies. A memorable multi-word passphrase is usually better than a short mixed-format password if you need someone to enter it correctly on the first try.
Split the file and the password across different channels
Do not send the attachment and the password in the same email thread. If that mailbox is compromised, forwarded, or accessed on an unmanaged device, the attacker gets both.
Use one of these patterns instead:
- Email + phone call for one-time sensitive sends
- Email + approved messaging app for recurring exchanges
- Email + separate corporate channel managed under policy
This is basic operational discipline. It matters as much as the encryption setting.
Treat filenames as exposed unless you have tested otherwise
A password can protect file contents while still exposing the archive name, and in some tools, even the names of files inside the archive. That is a real trade-off between compatibility and confidentiality.
A file named Layoff-Plan-Executive-Team.zip says too much before anyone enters a password.
Use neutral names such as documents-2025-05.zip or a ticket number that only the sender and recipient understand. If the names inside the archive are also sensitive, standard ZIP may not be the right container. In that case, use 7z with header or filename encryption enabled and confirm that the recipient can open it on their platform before you send anything time-sensitive.
Choose the format based on the recipient, not just the sender
This is the part many tutorials skip. The most secure option is not always the best choice if the recipient cannot open it without help.
| Need | Better choice |
|---|---|
| Broad compatibility across Windows, macOS, and Linux | AES-256 ZIP |
| Better privacy for filenames and contents | 7z with filename encryption |
| Low-risk internal sharing where compatibility matters more than secrecy | Standard ZIP, if policy permits |
In practice, AES-256 ZIP is often the safe middle ground for business email because recipients can usually open it with a common archive tool. 7z gives better privacy controls, but it adds friction if the recipient relies on built-in OS tools or has a locked-down workstation. For board packets, M&A drafts, disciplinary records, or customer exports, that extra setup is often worth it. For routine external exchanges, it may slow the process enough that users work around it.
A clean workflow for Gmail and Outlook
For Gmail:
- Create the archive locally.
- Rename it so the filename does not reveal the subject.
- Attach only the encrypted archive.
- Tell the recipient the password will arrive separately.
- Send the password through a different approved channel.
For Outlook:
- Follow the same process.
- If the recipient is outside your organization, tell them what app they need to open the file.
- If you used 7z, say so clearly. Do not assume the recipient knows the difference between ZIP and 7z.
- For urgent sends, test the workflow with the recipient in advance.
Attachment security is only one part of inbox security. If executives use Gmail, this guide to protecting Gmail accounts from phishing attacks covers controls that reduce the chance of a bad message reaching the point where an attachment becomes the problem.
A reliable business workflow is simple. Use AES-256 ZIP when cross-platform compatibility is the priority. Use 7z when filename privacy also matters. Share the password out of band. Test extraction before a critical send, especially when Windows, macOS, and Linux users are all involved.
Prepared with Outrank app