Secure File Sharing for Law Firms

A law firm's file exchange is not one problem. It is four: taking documents in from a client who has never used your systems, sending work product back out, moving material between co-counsel, experts and opposing parties, and holding the whole matter somewhere for as long as your retention policy says you must. Each has a different threat model, and most firms solve all four with the same tool — email — because it is the only channel every counterparty already has.

This page is about deciding what to use instead. It covers what your confidentiality obligations actually require of a tool, what "encrypted" does and does not cover for privileged material, how intake, retention and deletion work when the provider cannot read the files, and the questions that separate a real answer from a marketing one. ShieldFive appears at the end, with its gaps named — several of them are disqualifying for some firms, and it is better to read that here than to find it out after migration. None of this is legal advice; your own bar's rules and your clients' engagement terms govern, and they vary by jurisdiction.

Confidentiality and privilege are two different obligations

They are routinely collapsed into one, and the collapse causes bad tool decisions.

The duty of confidentiality is the broad one. In most jurisdictions it covers essentially everything relating to a representation, regardless of source, and it obliges you to make reasonable efforts to prevent unauthorised disclosure. "Reasonable" is the operative word: it is a standard, not a checklist, and it moves as the available technology moves. A tool choice that was defensible a decade ago is not automatically defensible now.

Attorney–client privilege is narrower and evidentiary. It protects confidential communications made for the purpose of legal advice, and it can be lost — by disclosure to a third party, by careless handling, sometimes by inadvertent production. Whether routing privileged material through a vendor that can technically read it affects privilege is jurisdiction- and fact-specific, and no vendor page can answer it for you. But the direction of the risk is not in doubt: the fewer parties who are technically able to read the material, the shorter the argument you ever have to make about it.

That is the practical link between the ethics rules and the architecture question. A provider that holds your clients' documents in a form it can read is a party with access. It may be a trustworthy one with a good security programme — most are — but its ability to read the files is a fact about the system, and it survives every promise in the contract. A provider that is architecturally unable to read them removes the question rather than answering it.

What "encrypted" does and does not cover

Almost every file tool on the market says it encrypts your data. The word covers at least three different arrangements, and the difference only shows up under pressure.

Most "bank-level encryption" claims describe the middle row. It is a legitimate and common posture — encrypting at rest with keys you manage is genuinely better than not doing it — but it is a promise about behaviour, not a constraint on capability.

Now the part vendors say less often. Even in the strongest model, encryption does not cover:

• The endpoints. A compromised laptop, a shared machine, a paralegal's phone with no screen lock. Encryption protects the file in transit and at rest, not the device where it is decrypted and read.
• The recipient. Once you share a document with opposing counsel, they have it. Expiry and download caps limit re-access to the copy on the server; they do not reach the copy on their disk.
• The link, if the link is the key. Link-based sharing is a bearer capability: whoever holds the URL can open it. Emailing a link to the wrong address is the same exposure as emailing the file, unless a second factor travels separately.
• Metadata, unless it is encrypted too. File and folder names leak matters. A folder named for a party plus a file named "settlement draft v4" is a disclosure even if the documents themselves are sealed. Ask specifically whether names are encrypted or merely stored.
• Legal process against anyone else. Your client, your co-counsel and your expert can all be compelled independently. Encryption changes what the vendor can be made to produce, not what the parties can.
• A web app's delivery path. Any browser-based encryption depends on the JavaScript the server sends. The honest formulation is "encrypted in the browser, ciphertext at rest" — not "no server could ever subvert this". Any vendor claiming the stronger version is overselling.

The four exchanges, and what each one needs

Client intake. The hardest of the four, because the constraint is not security but friction. A client who has to create an account, choose a password and remember it will send the documents by email instead, and you will have solved nothing. What intake needs is a link the client can open cold, a visible checklist of what is outstanding, and encryption that happens without the client knowing it happened. Whatever else you evaluate, test this step with a real, non-technical client before committing.

Sending work product out. Here you have more control and should use it: an expiry, a download cap, and — the one that matters most — a second factor that does not travel in the same email as the link. A password sent by text or read over the phone converts a bearer link into something closer to two-factor delivery.

Co-counsel, experts, opposing parties. These are professional counterparties with their own systems and their own obligations, and they will often insist on theirs. Expect to meet them where they are. What you can still control is what leaves your side: a scoped share of specific documents rather than access to a matter folder, and a record of what you sent and when.

Holding the matter. This is document management, not file sharing, and the two are frequently and expensively confused. If you need matter-centric filing, conflicts checking, version history tied to a matter number, and retention rules that fire automatically, you need a document management system or a practice-management suite. A sharing tool bolted into that role becomes a shadow repository nobody can search — which is worse than the email you replaced. For bulk disclosure and diligence, see data room versus secure file sharing; the controls a data room adds (per-document watermarking, Q&A, granular viewer analytics) are real and a sharing tool does not have them.

Retention and deletion

Deletion is where encrypted tools behave differently from the ones your firm is used to, and the differences matter for a retention policy.

Start with the distinction that causes most of the confusion: revoking a share is not deleting a file. Revocation kills the route in; the document stays in your vault. Deletion removes the stored object. A policy that says "links expire after 30 days" has said nothing about how long the firm holds the material, and an auditor will notice.

Second, in a zero-knowledge system deletion is genuinely destructive and there is no vendor-side undo. Nobody at the provider can reconstruct a file they never had the keys to. That is the point, and it is also the risk: the same property that defeats a subpoena defeats your own recovery request. Any firm adopting one needs a passphrase and recovery-key custody arrangement written down before it puts a live matter through the tool — held by more than one person, stored outside the system, and tested.

Third, auto-expiry and legal hold are in direct conflict. A tool that deletes on a timer will happily delete material you are obliged to preserve. Where a hold is foreseeable, keep the authoritative copy in the system your retention schedule governs and treat the sharing tool as a channel, not a repository.

Fourth, ask what deletion means downstream. Encrypted backups may retain ciphertext for a period after the record disappears from your interface. That is usually fine — it is unreadable — but it should be a documented answer, not an assumption.

What to ask a vendor

The questions below are the ones whose answers actually differ between products. Vague answers to these are themselves informative.

1. Can you read my clients' files? Is that a policy or an architecture? The only durable answer is architectural. "We don't look" and "we can't look" are different statements.
2. Who holds the keys, and what do you produce if you are served? A provider holding keys produces documents. A zero-knowledge provider produces ciphertext and metadata. Ask which, in writing.
3. What metadata do you hold, and are file names encrypted? See above — names leak matters.
4. Where does the data physically sit, and under whose jurisdiction? Then ask whether a DPA is standard or gated behind an enterprise contract.
5. What controls does a share link carry, and is the key in the link? Expiry, download cap, revocation, an optional password that travels separately. If the key rides in the URL, say so to yourself plainly: forwarding the link forwards the access.
6. What happens when a lawyer leaves? Removing an account is table stakes. Ask what happens to material they already decrypted and cached, and whether there is a key rotation that makes future material unreadable to them.
7. Can you give me an access record for a specific matter? Many tools cannot, or can only show it in an interface with no export. If a client's outside counsel guidelines require access reporting, resolve this before you buy.
8. What third-party assurance do you have? SOC 2 Type II, ISO 27001, a recent penetration test with a summary you can read. "We take security seriously" is not an answer, and neither is a certification held by a parent company unless the product is in scope.
9. What happens if we lose the passphrase? For an encrypted tool the honest answer is "the data is gone". Confirm the recovery mechanism and who holds it.

Where ShieldFive fits, and where it does not

ShieldFive provides client-side encrypted file storage, sharing and document collection. Files are encrypted on the device before upload and encrypted file data is stored in the EU. Your password never reaches our servers: the browser turns it into a separate login value with Argon2id and sends only that, and the key that opens the vault is derived separately and stays on the device. The app code is delivered by us, so the client you are served on each visit remains part of the trust boundary. This is not an absolute provider-cannot-decrypt guarantee. Web uploads default to ML-KEM-1024/XChaCha20-Poly1305 with AES-GCM fallback; Android also defaults to the hybrid format, with the same AES-GCM fallback, and reads both formats. The crypto core is open source, but the apps are not fully open source and no external security audit has been completed.

For a firm, that maps onto three of the four exchanges. Inbound, a document request for law firms gives the client a PIN-gated link with a checklist and no account to create, and each upload is sealed to the firm's keys in the client's browser. For questionnaire-style intake rather than documents, encrypted client intake forms work the same way. Outbound, a share link carries an expiry, a download cap and an optional country allowlist — useful, but treat the allowlist as friction rather than a control, since a VPN defeats it. The control worth using every time is the share passphrase: set one and it stays out of the link and is shown to you separately, so the URL alone is no longer enough. Leave it unset and an auto-generated key rides in the link fragment, which means the link is the credential.

On offboarding, ShieldFive is more honest than most and the detail is worth knowing before you rely on it. Removing a firm member deletes their wrapped key, so they lose access from any new device or session. But a member who had already unlocked and cached the firm key keeps access to documents received before the removal until you rotate the firm keys. Rotation issues a new firm key for future requests and re-wraps it to the remaining members; it does not re-encrypt what was already received. Plan departures accordingly.

Now the limits, which are the reason this section exists. ShieldFive is not a document management or practice-management system: no matter-centric filing, no conflicts checking, no court-rules calendaring, no time and billing, no e-signature. It is not a data room: no per-document watermarking, no Q&A workflow, no viewer analytics. It has no legal-hold feature — nothing suspends an expiry or blocks a deletion because a hold is in place. It records security events server-side but does not expose a self-serve, exportable access report you could hand to a client under outside counsel guidelines. And it has no completed third-party audit: no SOC 2, no ISO 27001, no BAA. What it offers instead is an open-source crypto core and a published internal security review, which is a different kind of evidence, not a substitute.

If your firm's procurement requires a completed SOC 2 today, or your matters need a real DMS, ShieldFive is not the tool — and a page that told you otherwise would be doing you a disservice.

A workable setup for a small firm

1. Decide what the authoritative repository is, and make sure it is the one your retention schedule governs. The sharing tool is a channel into and out of it.
2. Write the passphrase and recovery-key custody rule down before the first live matter: who holds them, where, and how a second person gets in if the first is unavailable.
3. Pick the matter types that must always use encrypted exchange — typically anything with identity documents, financial records, health information, or a client with contractual security terms — and make it the default for those, not an option.
4. Standardise one outbound pattern: expiry set, download cap set, passphrase set and sent over a different channel than the link. One pattern that everyone follows beats five configurable ones that nobody does.
5. Test intake on a real client, ideally an impatient one on a phone. If they route around it, the tool has failed regardless of its cryptography.
6. Put departures in the offboarding checklist: remove the member, then rotate the firm key, and know that already-received documents stay readable to anyone who cached the old one.
7. Review after one matter cycle and check the thing that actually matters: what share of sensitive exchange still happens over email. That number, not a feature list, tells you whether the rollout worked.

For adjacent reading, email versus secure file sharing covers why the default channel fails, the client document sharing checklist is the short operational version of the rollout above, and secure document collection for immigration lawyers works through the same decision for one practice area with a full vendor comparison. If you are comparing zero-knowledge providers generally, ten of them rated honestly is the wider survey.

Frequently asked questions

Does using a cloud file-sharing tool waive privilege?

Not on its own, and no vendor page can give you a jurisdiction-specific answer. The general position is that using a third-party service does not automatically waive privilege where the firm has taken reasonable precautions to preserve confidentiality — which puts the weight on what "reasonable" means for your matters, your jurisdiction and the sensitivity of the material. The practical takeaway is that the argument is shorter and stronger when fewer parties are technically capable of reading the documents. Check your own bar's guidance and your clients' engagement terms; treat this page as background, not advice.

Is end-to-end encryption necessary, or is encryption at rest enough?

For a great deal of firm material, encryption at rest with a reputable provider is a defensible choice, and pretending otherwise would be dishonest. The distinction bites in specific situations: material where the client has contractual confidentiality terms, matters where the vendor could plausibly be served, cross-border work with data-residency constraints, and anything where a vendor breach would itself be a reportable disclosure. Match the model to the matter rather than adopting one posture for everything.

What should a firm do about lost passphrases in a zero-knowledge system?

Plan recovery before storing live matters: test the documented recovery process and keep an independent backup. ShieldFive issues a recovery key at setup, shown once, and cannot recover it for you. The workable arrangement is the same one firms already use for safe combinations and escrow: the recovery key stored outside the system, held by at least two people, with a written rule for how the second person gets access. Confirm it works before the tool holds anything you cannot afford to lose.

Can ShieldFive be used as our document management system?

No, and it is not designed to be. There is no matter-centric filing, no conflicts checking, no version history tied to a matter number, no automated retention rules, and no e-signature. Using it as the firm's repository would create a second store your DMS does not see. The role it fits is the channel: collecting documents from clients, and sending sensitive material out — with the authoritative copy living wherever your retention policy says it lives.

Does ShieldFive support legal hold or produce an audit trail for clients?

Neither, today. There is no hold mechanism that suspends an expiry or blocks a deletion, so a matter under hold should not depend on a timer-based tool. Security events are recorded server-side, but there is no self-serve, exportable access report you could attach to a client's outside counsel guidelines. If either is a hard requirement for your practice, that is a genuine reason to choose something else — and worth confirming with any vendor, since a surprising number cannot export an access log either.