Client-side vs server-side encryption for one-time secret links

You're three weeks into vendor evaluation for a one-time secret link tool. The marketing pages all say "encrypted." The security questionnaires all check the same boxes. But your CISO asked one question in the review and the room went quiet: if a federal grand jury served the vendor with a subpoena tomorrow morning, what could the vendor turn over by lunch?

That question — not the marketing copy, not the SOC 2 PDF — is the question that separates real zero-knowledge link sharing from "encrypted in transit, decrypted on receipt." This post walks through the threat-model split your security review actually needs.

The question your security review keeps missing

Most vendor security reviews focus on the wrong axis. They ask whether data is encrypted at rest (yes, everyone uses disk encryption now), whether it's encrypted in transit (yes, everyone uses TLS), and whether the vendor has SOC 2 Type II (most do). What those three boxes don't answer is the only question that matters when you're picking a one-time link tool:

Can the vendor read the secret before it gets to the recipient?

If the answer is yes, then everything else is a conversation about how much you trust the vendor's controls. Their insider-risk program, their subpoena response posture, their breach detection, their employee offboarding. Those are real controls. But you're now in the business of evaluating people and processes at another company — and that's a much harder due-diligence job than evaluating math.

If the answer is no — if the architecture makes it impossible for the vendor to read the secret regardless of intent, court order, or breach — then the conversation shifts. You're evaluating whether the math holds, whether the client-side code is what it claims to be, and whether the vendor's own controls protect the metadata (who sent what to whom, when) that surrounds the secret.

That's a fundamentally different security review. And it's the one your CISO actually wants you to run.

Where the encryption happens — and why that's load-bearing

There are two architectures hiding under the same "encrypted link" marketing language.

Server-side encryption. The sender pastes a password, contract, or file into the vendor's web form. The browser POSTs the plaintext to the vendor's servers over TLS. The vendor's servers encrypt it with a key the vendor holds, store the ciphertext in a database, generate a link, and email/Slack/SMS that link to the recipient. The recipient clicks. The vendor's servers decrypt with their key and send the plaintext back to the recipient's browser over TLS. Then they mark the row as "burned" and delete it. Marketing copy: "your secret is encrypted." True statement. But the vendor touched the plaintext on the way in, held the decryption key the whole time, and touched the plaintext on the way out.

Client-side encryption. The sender pastes the same password into the same-looking form. Before any network request fires, the browser generates a random encryption key locally, encrypts the secret in the browser, and only then sends the ciphertext to the vendor's servers. The encryption key never leaves the browser — it gets stuffed into the URL fragment (the part after #), which browsers do not transmit to servers. The vendor stores the ciphertext, generates a link that includes the URL fragment, and the link goes to the recipient. When the recipient clicks, their browser pulls down the ciphertext, reads the key out of the URL fragment, and decrypts locally. The vendor sees ciphertext on the way in, sees ciphertext on the way out, and never holds a key that could decrypt anything.

Same marketing copy. Same checkbox on the security questionnaire. Completely different threat model.

The architectural detail that makes client-side encryption "zero-knowledge" rather than just a clever rebrand: the URL fragment. Browsers — per long-standing web standard (RFC 3986) — do not include the fragment in HTTP requests. The vendor's server logs never see it. The vendor's WAF never sees it. The CDN never sees it. The reverse proxy never sees it. It lives in the recipient's browser tab and dies when the tab closes. If the vendor's entire database leaked tomorrow, an attacker would have ciphertext and metadata, no keys.

What "the vendor can read it" actually means in practice

Security engineers sometimes wave off the client-side / server-side distinction as theoretical. It is not. There are five concrete buyer scenarios where the distinction shows up as a real outcome.

Subpoena response. A federal agency serves the vendor with an order to produce all communications between two parties for a 90-day window. A server-side vendor can comply: they have the keys, they have the ciphertext, they can decrypt and produce. A client-side vendor produces ciphertext and metadata. The plaintext is not theirs to give, and the court understands the difference. If you're in financial services, M&A advisory, legal, or healthcare, this is not a hypothetical — it's a procurement requirement. See our security architecture page for the full breakdown of what we can and cannot produce under legal process.

Database breach. The vendor's customer-data database leaks. With server-side encryption, the keys are usually in a separate KMS — but the application servers must be able to fetch keys to decrypt on read, so a breach that compromises an application server compromises the active session's ability to decrypt anything in flight. With client-side encryption, the breach yields ciphertext and metadata, full stop. The keys were never in the vendor's perimeter to lose.

Malicious insider. A vendor employee at the rogue-engineer percentile pulls a SELECT on the secrets table. Server-side: they get plaintext (or they get ciphertext plus a working key, which is the same thing). Client-side: they get ciphertext that they cannot decrypt without subpoenaing every individual recipient for their browser history.

Misconfigured logging. The vendor's observability stack accidentally logs request bodies for debugging. Server-side: the plaintext lands in the log pipeline, gets shipped to a SIEM, gets indexed, gets searchable. Client-side: the ciphertext lands in the log pipeline. Same redaction-fail incident; very different blast radius.

Recipient-side phishing of the link. This one cuts the other way and is worth saying out loud. Client-side encryption does NOT protect against an attacker who steals the full link from the recipient's inbox, because the link contains the key. Both architectures fail the same way against link theft. The mitigation is the same in both cases: passphrase gates, recipient identity binding, view caps, time expiry, deletion receipts. Don't let any vendor tell you their architecture solves recipient-side phishing — none of them do, the controls around the link do.

The metadata problem nobody talks about

Even with client-side encryption done correctly, the vendor still sees metadata. They see that sender A sent something to recipient B at 2:14 PM. They see how many times B opened the link, from which IP, on which device. They see the file size. They see the org both parties belong to.

For most use cases this is fine. The metadata is what makes the audit log valuable — compliance teams need to prove a contract was delivered, IR teams need to prove an incident report was viewed by the on-call lead, M&A teams need to prove every party in the data room saw the term sheet. Metadata is the trail you want.

But you should know it exists, and you should ask the vendor two questions about it:

1. How is the metadata protected at rest and in transit? Same encryption-at-rest controls, same TLS, same access controls as the rest of their stack. This should be table stakes.
2. Who at the vendor can query it, and is there a tamper-evident log of that access? This is the question most server-side vendors fail. A vendor with a tamper-evident audit log on share lifecycle events lets you prove independently that the access trail hasn't been altered. See the security architecture for how the chain is structured; signed Proof-of-Deletion Receipts (Enterprise) can be independently verified at the public verifier page without involving the vendor.

The metadata question is the place where a thoughtful security engineer separates client-side vendors from each other. Two vendors can both be zero-knowledge on the secret payload and have wildly different postures on metadata governance.

What a real security review looks like

When your team sits down to evaluate a one-time link vendor, run these eight questions instead of the SOC 2 checklist. The checklist is a prerequisite, not the review.

1. Where does encryption happen? Get them to draw it on a whiteboard. If they can't draw it, that's the answer. If they draw it server-side, the rest of the review is about their controls.
2. Where does the key live, end to end? From key generation to key destruction. If "the vendor's KMS" appears anywhere in that flow, it's server-side regardless of what the marketing says.
3. Does the URL fragment carry the key? This is the one-question litmus test for whether the vendor has done zero-knowledge correctly. If the link is https://vendor.com/s/abc123 with no fragment, the vendor has the key. If it's https://vendor.com/s/abc123#xyz789, the fragment is doing real work.
4. What happens to the ciphertext on burn? Server-side vendors mark a row deleted. Client-side vendors should also delete the ciphertext from blob storage, with a verifiable deletion receipt available. Ask to see a sample receipt.
5. What does your audit log prove, and how do I verify it independently? A vendor that can hand you a tamper-evident chain you can verify yourself is a different posture than a vendor that hands you a JSON export.
6. What can you turn over in response to legal process? Have them write the answer down. Compare it to what your legal team would want them to be able to turn over for your secrets versus unable to turn over.
7. How do you handle a malicious insider? Look for architectural answers (the vendor cannot decrypt, by construction) before procedural answers (the vendor has background checks).
8. What changes when the recipient is on a phone, in an in-app browser, behind a corporate proxy that strips URL fragments? The honest answer for client-side: those edge cases need explicit handling, and a serious vendor will have them documented.

Eight questions, twenty minutes, and you've separated real zero-knowledge from clever marketing better than three weeks of questionnaire ping-pong.

How this maps to the buyer scenarios you already have

A few common situations from the security engineers we talk to:

• You're the security lead for a 400-person SaaS company and HR wants a tool to send offer letters. The encrypted-link surface looks easy. Server-side vendors will be fast to procure. But your HR director is going to send compensation data, and that data lives in the vendor's database in a form the vendor can read. If a journalist FOIAs the wrong thing or a former employee subpoenas comp records, the vendor is a discoverable party. Client-side architecture takes the vendor off the discovery list. The HR-team workflow guide has a longer breakdown.

• You're at a regional bank and your IR team needs a way to send incident reports to outside counsel. Server-side means the IR vendor sees the incident before counsel does. Client-side means counsel sees it, the vendor sees ciphertext. The privilege story your general counsel wants to tell is much simpler with the second architecture.

• You're advising on an M&A deal and the buy-side needs a data room that can prove every document was destroyed at the close. Server-side deletion is "we ran a DELETE." Client-side deletion with signed receipts is a cryptographic artifact you can hand to the buyer's outside counsel as proof. That's the difference between "trust us" and "verify us."

• You're evaluating vendors for a federal contractor that handles CUI. The architecture question is your starting point, not the certifications question. A zero-knowledge architecture limits the scope of what's in the boundary in the first place — and your assessor will care a lot more about that than about whether the vendor's website has a logo on it.

The full vendor-evaluation rubric we hand to security engineers is in our docs, and it covers the questions above plus the answers we'd want a peer vendor to give to each.

What to do next

If your shortlist still has both client-side and server-side vendors on it, that's normal — most security reviews start there. The work from here is to run the eight-question review on each vendor in the same week, on the same call, with the same people, and let the answers separate themselves. The marketing copy will not.

When the answers come back, decide what threat model you're actually buying against: the vendor's controls (server-side) or the math (client-side). Both are legitimate choices. The mistake is shipping a vendor selection without knowing which one you picked.