Privilege Doesn’t Survive a Key Your Provider Can Turn Over

Every legal tech vendor says client files are encrypted. That claim hides the detail that actually determines protection: who holds the key. If the vendor holds it, encryption protects privileged files from outsiders and does nothing to protect them from the vendor itself, or from anyone who can lawfully compel that vendor to decrypt on a court’s order.

This is not a hypothetical concern for a firm moving matter files through third-party platforms. A locked cabinet means nothing if the vendor keeps a spare key and hands it over the moment a valid order arrives. This article looks at what key custody actually changes for law firms, why it is the detail most security reviews skip, and what genuine customer-owned key management requires in practice.

Executive Summary

Security reviews of legal tech platforms often stop at encryption algorithm and key length. The question that actually determines whether privileged data is protected is who controls the key, because whoever controls the key controls the data, encryption or not. When a vendor generates, stores and manages the key on the firm’s behalf, that vendor retains the technical ability to read matter files at any time, including under a legal demand the firm never agreed to and may never even learn about until after the fact. Customer-owned key management, backed by hardware, removes that ability entirely. For firms, this reframes encryption from a vendor claim into a specific, testable architectural fact that can be verified rather than taken on trust.

Key Takeaways

1. Encryption only protects data from parties who do not hold the key. A vendor-held key means privilege depends on the vendor’s willingness to resist a request, not on the encryption itself.
2. Bring-your-own-key models remove the vendor’s decryption capability entirely. A vendor-managed key leaves that capability fully intact, regardless of how the encryption is described in a data sheet.
3. A hardware security module makes key ownership a physical fact, not a policy. A key generated and stored in a firm-controlled HSM cannot be extracted by the platform hosting the data, even under administrative access.
4. On-demand key rotation is part of genuine ownership. A firm that cannot rotate a key on its own timeline after a suspected compromise does not have full control, whatever the ownership documentation claims.
5. Encryption strength is irrelevant if the wrong party holds the key. The question that matters for privilege is who can decrypt, not how strong the cipher is.

Why Encryption Strength Is the Wrong Question for Privileged Data

Security reviews ask about encryption constantly, and the answers almost always describe the algorithm: AES-256 at rest, TLS 1.3 in transit. These answers are true and largely beside the point.

Encrypted Data Still Has an Owner of the Key

Every encrypted matter file has exactly one thing standing between it and a plaintext read: the key. Whoever holds that key can read the data, decrypt it for someone else, or be compelled to decrypt it under legal process. The strength of the encryption algorithm has no bearing on any of this. A file encrypted with a strong cipher and a vendor-held key is not meaningfully more protected from the vendor than a file with weaker encryption, because the limiting factor in both cases is the same: the vendor can read it if it chooses to, or if it is ordered to.

Why Vendors Rarely Lead With This Distinction

Vendor documentation tends to describe encryption in terms that sound complete: “encrypted at rest and in transit using industry-standard algorithms.” This is accurate and incomplete. It says nothing about who generated the key, where it is stored, or whether the vendor’s own infrastructure has a path to it. A firm reading only the encryption claim, without asking the key-custody question separately, walks away with a false sense of coverage over its most sensitive matters.

What Customer-Owned Key Management Actually Requires

Owning a key is not a single feature so much as a chain of conditions that all have to hold. Break any link and the firm’s control over the key becomes theoretical rather than operational.

Bring Your Own Key Versus Vendor-Managed Key

In a vendor-managed model, the platform generates and stores the key. In a customer-owned key model, the firm controls key generation and storage, typically through a hardware security module it administers or has dedicated access to. The difference is not cosmetic. It is the difference between a vendor that can technically decrypt matter files and one that cannot, regardless of what either vendor’s marketing materials say about encryption strength.

Why Hardware Security Modules Matter More Than the Word Suggests

A hardware security module is a dedicated physical device built to generate, store and manage cryptographic keys in a way that resists extraction, even by someone with administrative access to the surrounding system. A software-only claim of customer key ownership can, in principle, be quietly reversed by a vendor with sufficient access to its own infrastructure. A properly integrated HSM removes that possibility by design, not by policy.

Why Rotation and Cipher Control Decide Whether Ownership Is Real

Holding a key once is not the same as controlling it continuously. Two operational details separate genuine key ownership from a claim that looks correct on a data sheet but breaks down in practice.

On-Demand Key Rotation

If a firm suspects a key may have been exposed, whether through a compromised credential or a suspected breach, the ability to rotate that key immediately, without waiting on the vendor’s release schedule, is what makes key ownership operationally meaningful.

Granular Cipher and Protocol Control

The ability to enable or disable specific cipher suites and control which TLS versions are permitted is a related but separate form of control, one a firm should be able to exercise on its own timeline rather than the vendor’s.

Building Key Custody Into Vendor Due Diligence

For a firm evaluating a vendor, the practical shift is straightforward: ask who generates the key, where it is stored, whether an HSM is involved, and who can rotate it and on what timeline. A vendor that answers all four clearly, with the firm controlling every step, has a defensible key custody model.

How a Data Control Plane Makes Key Ownership an Architectural Guarantee

A Data Control Plane that treats key custody as a foundational property ensures that the vendor’s technical inability to decrypt matter files holds across every channel that data moves through, including email, file sharing, APIs and AI agents.

The Kiteworks Data Control Plane integrates customer-owned encryption keys through a hardware security module, so that key generation and storage sit outside Kiteworks’ own reach. Firms retain the ability to rotate keys on demand, control which ciphers and TLS versions are enabled, and run on single-tenant architecture where that key custody is not shared with any other customer’s environment. Every action across every channel is captured in a tamper-proof, unthrottled audit log that feeds directly into SIEM tooling, so the key custody claim is backed by a record of enforcement rather than a line in a data sheet.

Firms that want to test their current vendor’s key custody model against this standard can schedule a custom demo to see how customer-controlled HSM integration applies to their own confidentiality obligations.