How to Share Sensitive Files Without Shared Drive Passwords

The most common “secure sharing” workflow in mid-size companies is still a shared Drive folder plus a password in Slack. It works until it does not: the password leaks, the folder grows forever, and nobody can prove who opened what.

This article covers practical patterns for sharing sensitive files without shared passwords—and how sealed, zero-knowledge links change the threat model for legal, security, and operations teams.

Why shared Drive passwords fail

Password sprawl — the same string appears in email, chat, and tickets
No natural expiry — folders outlive the project
Weak evidence — screenshots replace cryptographic access records
Oversharing — one link becomes the team’s junk drawer

A better pattern: sealed links with controls

Modern sealed sharing usually combines:

Client-side encryption of the file before it leaves the device
A server-side share token for authorization and metering
Delivery of the decryption key via a channel the storage operator does not log (often the URL hash)
Policy knobs: expiry, max views, optional password, watermark

Compliance Locker follows this design: share tokens on the server; file keys in the URL fragment so they are not sent as ordinary request data. You can tighten shares with passwords, view limits, and shorter defaults. See Security for the boundary description.

Controls that actually move risk

Expiry by default

Make “forever” an explicit exception requiring justification. Most diligence and counsel shares have a natural end date—use it.

View limits

Cap how many times a link can be opened when the audience is small and known. Limits are not perfect (caches, screenshots), but they raise the cost of casual forwarding.

Optional share passwords

Add a second factor when the packet is high blast-radius. Deliver the password out of band—never in the same email as the link.

Watermarks

Useful for deterrence and attribution in reviews. They do not stop a determined adversary with a camera.

Playbook by recipient type

External counsel or auditor

Prefer time-boxed links, watermarking when appropriate, and a single packet instead of a sprawling folder. Confirm the recipient channel (email vs secure portal) in your engagement letter. Export vault activity when the review closes—see what auditors ask for.

Internal executives

Use sealed vault shares for board packs; keep working drafts in the collaboration suite. Avoid forwarding master passwords for the vault itself.

Vendors and contractors

Issue per-engagement links with expiry aligned to the SOW. Revoke when the engagement ends. Do not reuse one eternal folder for every vendor.

Investors and diligence rooms

Prefer discrete packets over a living Drive mirror. Update by minting a new sealed set rather than leaving stale materials reachable forever.

What not to do

Put the share password in the same Slack thread as the link
Reuse one mega-folder for every external party
Rely on “encrypted ZIP + email” as the long-term standard
Assume revoke is unnecessary because “they’re trusted”
Skip naming conventions—metadata may still be visible

Operational checklist

Name files for humans; assume metadata may be visible even when content is sealed
Set expiry by default—make “forever” an explicit exception
Prefer unique links over one mega-share
Record who requested access and why in your ticket system
Export vault activity when the engagement closes
Review open shares quarterly

FAQ

Are password-protected ZIPs good enough?

They are better than nothing and worse than purpose-built sealed sharing. Password distribution, reuse, and lack of revoke/expiry make ZIPs a brittle pattern for ongoing business sharing.

Should every share require a password?

Not always. Short-lived sealed links with view limits may be enough for a known recipient. Add passwords and watermarks when the blast radius of forwarding is high.

How do zero-knowledge share links keep keys off the server?

A common pattern places the file encryption key in the URL hash fragment. Browsers do not include the fragment in HTTP requests to the server under normal navigation.

What if someone forwards the sealed link?

Treat link possession like a capability. Use short expiry, view limits, optional passwords, and revoke when the engagement ends. Watermarks deter casual redistribution but do not stop screenshots.

Can I share a whole folder safely?

Prefer discrete packets for high-sensitivity work. Broad folders recreate the shared Drive problem: unbounded growth and unclear ownership of what was exposed.