Should You Password-Protect a Document You Send a Client?

A PIN on a link is a real control with a real cost, and the cost is not the two seconds it takes to type. It is that a PIN has to travel to the reader somehow, and every way of doing that either undoes the protection or adds friction at the exact moment somebody had decided to read your work.

So the question is not “is it more secure”. It obviously is. The question is what you are buying and who pays for it.

What a PIN actually protects against

Be precise, because the answer is narrower than it feels. A PIN protects a document from someone who has the link but was not meant to have it.

• A link pasted into a chat channel with more people in it than you expected.

• A shared or role inbox — procurement@, info@, accounts@ — read by people whose names you will never learn.

• A forwarded thread that keeps travelling after the decision is made.

• A URL that ends up somewhere indexable, which is rare and is catastrophic when it happens.

What it does not protect against is the reader. The person you sent it to can screenshot it, print it, read it aloud on a call, or paste your pricing into a spreadsheet next to two competitors’. No control on any link changes that, and any product that implies otherwise is selling you a feeling.

The delivery problem

There are exactly three ways to get the PIN to your reader, and each has a defect.

1. In the same email as the link. This is what most people do and it protects against almost nothing. Anyone who has the link from that email has the PIN from that email. It stops a URL that leaked on its own, and nothing else.

2. In a separate channel — a text message, a call, a different thread. Genuinely more secure, and it introduces a delay between the reader wanting to read and being able to. Sometimes that delay is a day. Sometimes the reader who arrived through a forward has no idea who to ask.

3. Something they already have. A link PIN is a short numeric code, which rules out passphrases but leaves one good option: derive it from a number already sitting in the conversation. The last four digits of the purchase order, the reference on the tender, the invoice number from the previous job. No second message, nothing to look up, and no value at all to somebody outside the relationship.

The friction of options one and two is not evenly distributed, and this is the part worth thinking hardest about. The reader most likely to be blocked by a PIN they were not given is the one who arrived last, through an internal forward — the senior person, the one who decides.

When to use one

Four situations where the trade is clearly worth it:

• Named rates, margins or commercially sensitive numbers. Anything that would damage you in a different negotiation.

• Third-party confidential material. Another client’s data in a case study, a partner’s pricing, anything you are holding under someone else’s obligation. Here it is not your call to make loosely.

• You are under an NDA or a client security policy. Then the control is a requirement and the friction is the client’s own choice.

• You know the address is a shared one. Sending to procurement@ means sending to an unknown number of people, which is the case a PIN was designed for.

When not to

Most proposals are documents you actively want forwarded. Circulation is how they reach the person who decides. A PIN is a brake on exactly that, and a brake that acts hardest at the far end of the chain.

So for ordinary competitive work — a scope, a quote, a report, a pitch — the default should be no PIN, and the confidentiality concern should be handled by the two things that actually address it: not putting in the document anything that must never circulate, and ending access when the deal is over.

A PIN and an email gate are not the same instrument

They are frequently confused because both put a field in front of a document, and they answer completely different questions.

• A PIN answers “should this person be allowed in?” It is a real gate. Someone without the code does not get the document, full stop.

• An email gate answers “who is this?” It is not a security control at all. The address is typed by the reader and checked by nobody, which is why Quixli labels a gate address self-reported everywhere it appears rather than presenting it as a confirmed identity. Anyone can type anything and continue.

Using a gate for security is the common mistake, and it is worth reading the case for and against a gate on its own terms — should you ask for an email before someone can open your document has it.

A PDF password and a link PIN are not the same either

This is the practical difference that most often decides it, and it is rarely stated.

A password on a PDF is baked into a file that is now on somebody else’s disk. You cannot change it, you cannot revoke it, you cannot tell whether it worked, and if the reader loses it your document is a paperweight. It also has a habit of defeating the client’s own systems — document management platforms, e-signature tools and preview panes frequently cannot open an encrypted file, so the person you protected it from is your buyer’s software.

A PIN on a link is held at the link. You can change it, you can remove it, you can end access entirely, and none of that requires the reader to do anything or you to send a second file. If you are going to protect something, protecting the link is the version you can still change your mind about.

The other control with the same shape of cost is the expiry date — when a link should expire and when it should not works through it, including why a view cap is the most dangerous of the three. If the underlying worry is who else is reading, what a forwarded link tells you is the more useful piece. And which controls each kind of share supports is set out as a table rather than a promise.