How to Ensure Your File Encryption Vendor Has Zero Access to Your Keys — and How to Verify They're Telling the Truth

Every encryption vendor claims to take your security seriously. Many of them will tell you, in some variation, that your data is safe with them. Fewer will be able to explain, at the architecture level, exactly what happens to your decryption keys — where they live, who holds them, what technical mechanisms prevent the vendor from accessing them, and what a government compelled-access order directed at the vendor would actually produce.

That last question is the one that matters most. Not because a compelled-access order is the likely threat vector — it isn't — but because a vendor that cannot answer it confidently has not designed their key management architecture for zero-knowledge. They've designed it for convenience and added a privacy policy on top.

This post covers what zero-knowledge key architecture actually means in file encryption, how to ask the right evaluation questions, what technical evidence to request, and why the answer matters specifically for ITAR, CMMC, and regulated data environments where vendor key access is a compliance event, not just a security preference.

What "Zero-Knowledge" Actually Means — and What It Doesn't

Zero-knowledge, in the context of file encryption, means that the vendor cannot decrypt your data. Not that they won't. Not that their policy prohibits it. That they architecturally cannot — because the decryption keys are never in their possession.

This is distinct from several related concepts that vendors often conflate:

"We don't look at your data" is a policy statement. It means the vendor has made a business decision not to access customer data. It says nothing about whether they could if they chose to, or were ordered to.

"Your data is encrypted in transit and at rest" describes transmission and storage security. It says nothing about key custody. Data can be encrypted at rest while the encryption keys are managed by the same vendor who holds the encrypted data — which means the vendor can decrypt on request.

"We use AES-256" describes the encryption algorithm. AES-256 is the right algorithm choice, but an algorithm is only as strong as its key management. If the vendor controls the keys, the algorithm's strength is irrelevant to the question of vendor access.

Zero-knowledge has a specific technical meaning: the keys used to encrypt your data are generated under your control, stored under your control, and never transmitted to the vendor's infrastructure in a usable form. When the vendor receives a request to decrypt your data — whether from law enforcement, a foreign government, a malicious insider, or a hacker who has compromised the vendor's systems — they produce nothing, because they have nothing.

Why Vendor Key Access Is a Compliance Problem, Not Just a Privacy Preference

For organizations handling ITAR-controlled technical data, the question of vendor key access is not a security preference. It is an export control compliance requirement.

ITAR Part 120.54 defines technical data protection obligations for defense contractors. When a vendor holds the decryption keys for ITAR-controlled files, and that vendor is subject to a government request — from any government, including a foreign government under mutual legal assistance treaty provisions — the vendor's compliance with that request constitutes an export. The vendor has effectively exported your technical data to whoever made the request, without your authorization, potentially without your knowledge.

Zero-knowledge key architecture removes the vendor from this chain entirely. A compelled-access order directed at a zero-knowledge vendor produces ciphertext the vendor cannot decrypt. The vendor's compliance with the order is not an export of your technical data — it's a disclosure of data the vendor cannot make usable. That distinction is what "vendor has no access" means in a compliance context.

For CMMC Level 2 assessments, the same logic applies at the SSP documentation level. SC.L2-3.13.10 requires FIPS-validated cryptography for CUI. The CMMC assessment process examines not only whether encryption is in place but how key management is structured — specifically whether key custody creates a vulnerability in which a third party could access CUI through the vendor. A zero-knowledge architecture that the assessor can verify through technical documentation and key custody architecture is a materially stronger SSP position than "we use AES-256 and the vendor has a good privacy policy."

The Evaluation Questions That Separate Real Zero-Knowledge From Claims

When evaluating a file encryption vendor's zero-knowledge architecture, the following questions produce differentiated answers. Vendors with genuine zero-knowledge architecture can answer them technically and specifically. Vendors who have made policy commitments rather than architectural ones will answer in generalities.

Where are my encryption keys generated?

In a genuine zero-knowledge architecture, keys are generated on the client side — either on the end-user's device or within infrastructure you control. The vendor's systems never receive the keys in usable form. The correct answer involves a specific description of where key generation occurs and on what infrastructure.

Red flag answer: "Your data is encrypted before it reaches our servers." This describes transmission encryption, not key custody. Ask specifically where the key generation happens, not where the encryption happens.

Who holds the master key or key wrapping key?

Multi-layer encryption typically involves data encryption keys (DEKs) that are wrapped by key encryption keys (KEKs). In a zero-knowledge architecture, the vendor never holds a usable KEK. Ask specifically whether the vendor can unwrap any key in the key hierarchy, under any circumstances.

Red flag answer: "We use envelope encryption." Envelope encryption is a key management technique, not a guarantee of zero-knowledge. Ask specifically whether the vendor's systems ever have access to a key that could decrypt a DEK.

What would you produce in response to a law enforcement request for my data?

This question cuts directly to the architecture. A vendor with genuine zero-knowledge access should answer: ciphertext that cannot be decrypted without keys we don't hold. A vendor that can produce decryptable data in response to such a request is not zero-knowledge, regardless of their stated policy.

Ask for this in writing. The answer to this question should appear in the vendor's security whitepaper and, for enterprises, in the contract.

Can you demonstrate key isolation with a technical architecture diagram?

Request a key management architecture diagram that shows the key generation path, key storage location, key transmission (or absence thereof) to vendor infrastructure, and the access control model over the key management system. A vendor who cannot produce this on request either doesn't have a zero-knowledge architecture or hasn't thought through their key management at the level a regulated-environment deployment requires.

Has your key isolation been independently verified?

Third-party security assessments, penetration tests, and SOC 2 Type II reports can verify that a vendor's stated key management architecture matches their actual implementation. Ask for the scope of the most recent third-party assessment and whether key management was specifically tested.

What to Check in Vendor Documentation

Beyond the evaluation conversation, several documents should be reviewed before relying on a vendor's zero-knowledge claim:

Security whitepaper or architecture document: This should describe the key management architecture in technical terms, including key generation location, key storage infrastructure, the key hierarchy, and access controls over the key management system. If this document exists only as a marketing PDF with no technical specifics, the architecture may not be as described.

Privacy policy and terms of service: Look specifically for language about government requests, compelled access, and data disclosure. Policy language like "we will notify you of government requests where permitted" implies the vendor can comply with government requests — which implies they have access to usable keys. Contrast with language like "we are technically unable to access or decrypt customer data" — which, if architecturally backed, is a zero-knowledge statement.

Sub-processor list: Cloud infrastructure vendors, key management service providers, and third-party analytics integrations may all be sub-processors with access to portions of the system. Review the sub-processor list with specific attention to whether any sub-processor has access to the key management infrastructure.

Cloud provider key management documentation: Many cloud-hosted file encryption tools use cloud provider key management services (AWS KMS, Azure Key Vault, GCP Cloud KMS) as the underlying key store. Understand whether the vendor uses customer-managed keys (CMK) within these services — which gives you control over the underlying keys — or provider-managed keys, which means the cloud provider (not just the encryption vendor) holds a key that can decrypt your data.

The Compliance Implication of Getting This Wrong

For an ITAR-regulated contractor or a CMMC Level 2 candidate, the consequences of deploying an encryption solution that doesn't actually achieve zero-knowledge are not theoretical:

For ITAR: Any vendor with access to decryptable ITAR technical data is a potential channel for unauthorized export. If the vendor is acquired, subject to foreign jurisdiction, or compelled under law to disclose, the contractor's ITAR exposure runs through the vendor. This is precisely the risk profile that ITAR's encryption carve-out (120.54(b)(2)) is designed to address — and it only applies when the encryption genuinely prevents unauthorized access.

For CMMC: An SSP that describes a vendor as zero-knowledge when the vendor actually holds usable decryption keys is a documentation misrepresentation. If a C3PAO assessment or a DoD damage assessment following a cyber incident examines the key management architecture and finds the description inaccurate, the finding goes to the SSP's integrity, not just the control. That is a significantly more serious assessment outcome.

For HIPAA: The HIPAA Safe Harbor requires that the decryption key was not compromised. A vendor breach that exposes both encrypted PHI files and the keys to decrypt them is not a Safe Harbor situation — the PHI is effectively exposed. A zero-knowledge architecture means the keys are never held by the vendor, so a vendor breach cannot expose the keys.

The Right Architecture Is Verifiable

Zero-knowledge encryption is not an assurance claim. It is an architectural property that can be independently verified. Vendors who implement it genuinely welcome the technical scrutiny. Vendors who make the claim without the architecture will deflect detailed key management questions or provide answers that, on examination, describe policy rather than technical isolation.

The difference matters because your compliance posture, your ITAR exposure, and — in the event of a breach — your regulatory obligation all depend on what is actually true about your vendor's key access, not what their marketing materials say about it. Protect the content, not the container — and verify that the vendor protecting the content cannot access the keys that unlock it.

FAQs: Zero-Knowledge Key Management & Compliance