It is one of the most common habits in professional offices. You have a sensitive document to send, a tax return, a will, a financial statement, so you add a password to the PDF, email the file, and send the password in a second message. It feels careful, and it is more careful than sending the file bare. The real question is whether it is careful enough for a document that carries a client's SIN or their entire financial picture.
The honest answer is that it can be, under specific conditions most people never check, and that even at its best it leaves gaps a password cannot close. Here is what a PDF password actually does, where it falls short, and what secure sending requires instead.
There are two kinds of PDF password, and one of them is not security
A PDF can carry two different passwords, and they do very different jobs.
The first is an open password, sometimes called a user password. Without it the file will not open at all, and its contents are genuinely encrypted. This is the one that matters.
The second is a permissions password, sometimes called an owner password. This one is widely misread. A PDF can carry both passwords at once, and if it also has an open password then the contents are protected by that. But when the permissions password is the only one set, which is the usual case, the document is encrypted under a blank open password: any reader derives the decryption key on its own without being given a secret, which is exactly why the file opens without prompting you. What the owner password guards in that case is a set of flags that ask a reader not to print, copy, or edit the file. The word "ask" is doing the work there, because a tool that chooses to ignore those flags can open the document and lift the text straight out. Free utilities strip this kind of protection in well under a second. So the encryption is real while the confidentiality is not: if the PDF opens without asking you for anything and only blocks printing or copying, it is keeping its contents from nobody.
So the first thing to know is which password you actually set. Only the open password keeps the contents away from someone who has the file.
Not all PDF encryption is the same strength
Even when the file is truly encrypted with an open password, the strength depends on which encryption standard your software used, and you usually cannot see that from the outside.
PDF encryption has changed a great deal over thirty years. The oldest standard uses 40-bit RC4, which a single modern computer can break by brute force in a few hours. Later versions moved to 128-bit RC4, then AES-128, then AES-256. That progression sounds reassuring, but AES-256 arrived in two different flavours, and which one you got matters more than the key size. The first, from 2008, turned your password into a key with a single fast hash, which lets an attacker with an ordinary graphics card work through a very large number of guesses per second. The hardened flavour, available since around 2011 and the only 256-bit option the 2017 PDF 2.0 standard still sanctions, repeats that derivation many times over to make each guess slow. Both of them say AES-256.
The catch is that most people have no idea which of these their tool produced. A file created by older software, or by a default setting nobody changed, can look identical from the outside to a strong one while using a scheme that fell decades ago. Neither the icon nor the words "AES-256" tell you which derivation is underneath.
When a file is encrypted, the password is the whole game
Here is the part that surprises people. Once someone has a copy of your encrypted PDF, they can attack the password on their own machine, offline, as many times as they like, with no lockout and nobody watching. That is a very different situation from guessing a password on a website that stops you after five tries.
It means the strength of a password-protected PDF comes down to the password itself. A short or guessable one falls quickly. A six-character password can go in hours on hardware anyone can buy. What holds up is length, unpredictability, and using it for this one file only: a passphrase of several randomly chosen words is strong precisely because there is nothing in it to guess at, and it stays easy to type. What fails is anything drawn from a small pool, a name and a year, a client number, a dictionary word, or a password you already use somewhere else. Being memorable is not the problem. Being predictable is.
The bigger problem is what a password cannot do at all
Suppose you get everything above right. Modern encryption, a long random password. You still have not addressed the parts that cause most real-world exposure.
A password on a PDF cannot expire. The file works forever, so a return you sent in February is still openable in November, and next year, sitting in an inbox you do not control.
A password cannot be revoked. Once the file is out, you cannot pull it back or cut off access if it lands somewhere it should not.
A password does nothing about the copies that pile up. The encrypted file, and the decrypted version once the recipient opens it, live on in Sent folders, downloads folders, and backups for as long as those exist.
And most quietly of all, the password usually travels the same way the file does. When the PDF and its password go through the same email thread, or the password sits in the message right below the attachment, an attacker who reaches that inbox has both halves at once. At that point the encryption protected nothing.
So is it good enough?
For a low-sensitivity document, a well-encrypted PDF with a strong password sent through a separate channel is a reasonable measure. For the documents a professional handles, SINs, T4s, financial statements, wills, deeds, it is a fragile foundation. It rests on conditions you cannot verify, it loads the entire risk onto one password, and it does nothing about expiry, revocation, or the copies that outlive the reason you sent the file.
The good news is that closing those gaps does not have to be any harder than what you already do.
What secure sending actually requires
Three properties separate a genuine safeguard from a locked PDF.
- Encryption that happens on your device before the file is uploaded, so the service moving it only ever holds ciphertext, and the strength does not hinge on guessing which PDF setting your software happened to choose.
- A passphrase that travels separately from the link, through a different channel, so reaching one inbox does not hand over both halves.
- Control that survives the send, meaning you can set an expiry, cap how many times the file is opened, and revoke access after the fact.
A practical workflow
Encrypt the document with a passphrase in your browser, send the recipient the link, and pass the passphrase through a separate channel such as a text message. Set an expiry so the file does not linger. The recipient opens it with the passphrase, with no account and nothing to install. The same pattern works for the files a law practice sends every day.
This is what Send does. The file is encrypted on your device before it is uploaded, Privatt only ever sees ciphertext, and you set the expiry, the view limit, and the revocation. Your client opens it with a passphrase and no account on their end. For the files you keep on hand, working papers, prior returns, matter files, Vault keeps them encrypted on your device before they are stored, on Privatt's Canadian servers or in a Google Drive or OneDrive you already use. In Vault's device-only mode, not even Privatt can open them.
None of this makes you compliant on its own, because no tool does. What it does is replace the weakest link in the exchange, a locked file whose real safety you cannot see and cannot control once you hit send.
A short checklist for sensitive PDFs
- Check whether you set an open password or only a permissions lock. A permissions lock leaves the file readable by anyone who opens it.
- Assume you cannot tell how strong a PDF's encryption is from the outside, because in practice you usually cannot.
- If you do password-protect a file, use a long random passphrase and send it through a different channel than the file itself.
- Remember that no PDF password can expire, revoke, or clean up the copies left behind.
- For anything carrying a SIN, a financial detail, or a client confidence, use a tool that encrypts on your device and lets you expire and revoke.
Where Privatt fits
Send encrypts a document on your device, moves it through a passphrase-protected link your client opens with no account, and gives you expiry, view limits, and revocation. Vault stores your client files encrypted on your device first, in Canada under Canadian law, and in device-only mode not even Privatt can read them. If you work in accounting or bookkeeping, that covers both halves of the job, the files you send and the files you keep. And because the claim is only as good as your ability to check it, we publish how the encryption works so you, or your IT person, can verify it rather than take our word.
This article is general information, not legal or financial advice. Consult a qualified professional about your specific obligations.