Should You Password Protect Shared Files? A Practical Answer
Published 2026-05-12 · Updated 2026-06-19 · 7 min read · By the SENDIT team
When a password on top of an access code adds real protection, when it is theatre, and how to deliver passwords without undoing the point.
Adding a password to a shared file feels responsible. Whether it is actually useful depends entirely on how the password is delivered and what it is protecting against. Done well it is a genuine second factor. Done the way most people do it, it is decoration that adds friction without adding safety.
The delivery problem
A password only helps if it travels separately from the thing it protects. Sending an encrypted archive by email and then sending the password in a follow-up email to the same address protects against precisely nothing, because any adversary with access to that mailbox has both halves. This single mistake accounts for the majority of pointless password protection in ordinary business communication.
Separation must be real. Different message in the same thread is not separation. Different app, different medium, or spoken aloud is separation. A phone call is excellent because it is a genuinely different network with a different compromise path.
When a password genuinely earns its place
- Identity documents, financial statements, medical records and legal papers, where the consequence of exposure is severe and lasting.
- Anything sent to a shared or role-based mailbox such as info@ or accounts@, where several people read the inbox.
- Files sent to an address you are not completely sure of, where a typo could deliver to a stranger.
- Content that must remain protected after download, since the password stays with the archive on the recipient's disk.
- Situations where regulation or a client contract explicitly requires it.
When it is theatre
If the file is already behind a short-lived access code, the transport is encrypted, and the recipient is a known individual you are speaking to directly, adding a password mostly adds a support conversation. Weak passwords make it worse: a four-character password on a ZIP file is cracked in under a second on any modern laptop, so it provides the feeling of protection while providing none of the substance.
Worse still, password prompts train recipients to expect them, which makes phishing easier. An unexpected protected archive with a password in the same message is a classic malware delivery pattern precisely because it looks legitimate and defeats mail scanners.
Choosing a password worth using
For a one-time transfer, length beats complexity. Four unrelated common words are easy to read over a phone, easy to type on a phone keyboard, and far stronger than a short string with substituted characters. Avoid anything derived from the recipient, the project, the date or the company name, because those are the first guesses. Never reuse a transfer password across recipients; each share deserves its own.
Layering correctly
The strongest arrangement stacks independent layers, each on its own channel. The receive page arrives by link or QR. The access code arrives by message. The file password arrives by voice call. The share expires within hours. Compromising any single channel yields nothing usable, and there is no single artefact that unlocks everything.
This is not excessive for a passport scan or a set of financial records. It is roughly two extra minutes of effort, and it converts a single point of failure into three.
Practical etiquette
- Tell the recipient in advance that a protected file is coming, so an unexpected archive is treated with suspicion.
- Say how the password will arrive before it arrives.
- Use ZIP with AES rather than legacy ZIP encryption, which is broken.
- Confirm the recipient successfully opened the file, then delete the share.
- Never write the password into the filename, which people do more often than you would believe.
The short answer
Use a password when the content is genuinely sensitive, when the destination is shared or uncertain, or when protection must persist after download. Skip it when a short-lived access code to a known person already covers the risk. And in every case, deliver it on a different channel — because a password sent alongside the file is not security, it is a note taped to the key.
What password protection does not cover
A password protects the contents of the file. It does not hide the filename, the file size, the fact that a transfer happened, or who was involved. For most situations that is fine, but if the existence of the exchange is itself sensitive, encryption of the payload is the wrong layer to be working at.
It also does nothing after the recipient opens it. Once decrypted on their machine, the file is an ordinary file, sitting in a downloads folder, backed up to their cloud, and forwardable. Protection travels only as far as the first successful open.
Helping the recipient succeed
A surprising share of password-protected transfers fail for entirely practical reasons: the recipient's phone cannot open an encrypted archive without an extra app, or a copied password picks up a trailing space, or an autocorrected capital letter breaks it. Prefer lowercase word-based passwords, warn them about trailing spaces, and ask what device they will open it on before choosing archive-level encryption. If the answer is a phone, a file-level password inside the transfer service is usually kinder than a ZIP.