Who Holds the Encryption Keys? A Lawyer's Guide to Legal Cloud Claims

“Encrypted” answers too little.

Almost every serious cloud service encrypts traffic and storage. The harder questions are who can decrypt the information, where the keys live, how devices receive access, what happens when a key is lost, and which useful product features require the provider to see plaintext.

For legal work, those details affect confidentiality, incident exposure, recovery, offboarding, support, search, and the truth of the vendor’s marketing claims.

Four statements that sound similar but are not

Encrypted in transit

Transport encryption protects data while it moves between the device and service. HTTPS and TLS are standard examples. This helps prevent interception on the network.

It says nothing about how the service stores the data or whether the service can read it after receipt.

Encrypted at rest with provider-managed keys

The service encrypts databases, disks, or objects, and the provider’s systems manage the keys. This can provide strong protection against lost media and some infrastructure failures.

The service can ordinarily decrypt data to provide features, support, search, indexing, AI, or recovery. Access should be controlled and audited, but the provider remains technically capable of plaintext access.

Customer-managed or bring-your-own keys

The customer controls a key or key-encryption key used by the cloud service. Depending on the design, the provider may still use the key through its infrastructure and may still be able to decrypt data while the service is operating.

The label alone does not tell you whether the provider ever receives the key, where it is used, or whether administrators can authorize decryption.

Provider-blind or end-to-end encryption

In a provider-blind design, authorized endpoints encrypt and decrypt content while the service stores or relays ciphertext without the content key. Properly designed, the provider cannot decrypt the protected content.

This is a powerful property. It is also an architectural constraint, not a marketing setting. Server-side full-text search, deduplication, conflict resolution, previews, malware scanning, support, and AI analysis may need to be redesigned, limited, or performed on an authorized device.

Ask where decryption occurs

A useful diagram is more valuable than a certification logo. It should show:

lawyer's device -> network -> application service -> database or object store

For each stage, ask:

• Is the content plaintext or ciphertext?
• Which key protects it?
• Which component can obtain that key?
• Which people or service roles can authorize access?
• Is access logged and reviewed?
• Does a support process create a temporary decryption path?

If the answer is “the data is encrypted with AES-256,” ask the questions again. The algorithm does not identify the key custodian.

NIST describes cryptographic key management as one of the most difficult parts of using cryptography. Its key-management resources emphasize policies, components, procedures, distribution, recovery, and metadata, not merely algorithm selection.

Recovery is part of the security model

If only the firm holds the key, what happens when the only authorized laptop fails or the person who configured the system leaves?

Possible recovery models include:

• a recovery code stored by the firm;
• a second authorized firm device;
• split recovery among several firm administrators;
• a hardware-backed recovery key;
• customer-controlled escrow; or
• provider escrow under defined conditions.

Each model changes who can restore access. Provider escrow may improve recoverability while weakening a claim that the provider can never decrypt. No escrow may strengthen confidentiality but make permanent data loss possible.

NIST key-management guidance treats backup, recovery, roles, authorization, and key metadata as explicit policy questions. A vendor should be able to explain its choice without hiding behind “military-grade encryption.”

Sharing and offboarding are key operations

Firm-wide access requires more than one master password. Ask how the system handles:

• adding a lawyer or staff member;
• authorizing a new device;
• limiting a person to particular matters;
• creating an ethical wall;
• revoking a lost device;
• removing a departing employee;
• rotating a firm or matter key;
• preserving access to historical records; and
• recording who performed each action.

A server can stop sending new ciphertext to a revoked device. It cannot guarantee deletion from a device that remains offline, compromised, or copied. The vendor should state that limit.

Encryption does not hide every kind of information

A provider-blind service may still see metadata required to operate the account, such as:

• firm and user identities;
• device registrations;
• IP addresses and login times;
• payment and subscription records;
• object sizes and transfer times;
• the number of matters or files;
• access failures; and
• relationships needed for routing or authorization.

Some designs conceal more metadata than others. None should use “we cannot read your files” to imply “we know nothing about the account.”

Encryption is not a complete subpoena answer

Key custody can affect what a provider is technically able to produce. It does not make the firm or its devices immune from legal process, and it does not determine privilege by itself.

A provider may be able to produce ciphertext and metadata. A firm, user, or endpoint may possess plaintext or keys. Privilege and confidentiality questions depend on law, facts, agreements, and how the technology was used.

Be wary of a vendor claiming that encryption “guarantees privilege” or “shields the firm from subpoenas.” Those are legal conclusions the architecture alone cannot establish.

Professional responsibility still asks for reasonable judgment

ABA Formal Opinion 477R explains that internet transmission of client information generally may be reasonable while some circumstances require special precautions. ABA Formal Opinion 512 applies existing duties of competence and confidentiality to generative AI tools.

Neither opinion creates one required architecture for every firm. The lawyer’s task is to understand the relevant information, threats, provider practices, client instructions, legal requirements, and available safeguards.

Questions for a legal-software vendor

1. What is encrypted in transit and at rest?
2. Who creates, stores, and can use the content-encryption keys?
3. Can your employees or systems decrypt client content? Under what conditions?
4. Does customer-managed keying prevent provider decryption, or only control authorization?
5. What metadata remains visible?
6. How are new users and devices authorized?
7. How are access, key use, and administrative actions logged?
8. What happens when a device is lost or a user leaves?
9. How does key recovery work, and who can invoke it?
10. Which features require plaintext processing?
11. What content is sent to AI or other subprocessors?
12. What can the service export in response to legal process or an account request?

Ask for written answers that match the contract and product architecture.

Our interest in this question

Usus is local-first. We plan to offer a standalone edition and charge for optional firm synchronization. Our intended direction is that ordinary work remains local and that synchronized content receives protection before it reaches the cloud.

The exact cloud key-custody model is still a design decision. Provider-managed organization keys, customer-managed keys, and a truly provider-blind firm-key design support different features and recovery options. We will not claim that Usus cannot decrypt synchronized firm data unless the implemented architecture, independent review, and operating procedures make that statement true.

That caution is not a weakness in the security story. It is the beginning of an honest one.

The shortest useful test

When a vendor says “your data is encrypted,” ask:

On which component can this record first become readable, and who can make that happen?

A vendor that understands its design should be able to answer in plain language. A firm should not need to infer key custody from adjectives.