Before You Buy Enterprise File Encryption, Ask These 7 Questions

Most procurement processes for file encryption start in the wrong place. Security teams review feature matrices, attend vendor demos, run a quick proof of concept, and choose the platform with the most checkboxes. Then, six months later, an assessor asks a question the vendor’s sales deck never prepared them for.

The problem isn’t that the software doesn’t work. The problem is that “works” and “passes a CMMC or ITAR audit” are not the same thing. AES-256 is table stakes. What assessors actually evaluate — and where organizations repeatedly fall short — is the architecture behind the algorithm.

This framework covers the seven questions that separate enterprise file encryption platforms built for regulatory scrutiny from those that look good until the assessment begins.

1. Is the Cryptographic Module CMVP-Validated, or Just FIPS-Compatible?

This is where more procurement decisions go wrong than any other. A vendor claiming “FIPS 140-2 compatible” or “AES-256 encryption” is making a statement about an algorithm. An assessor asking about your encryption implementation wants a CMVP certificate number.

The Cryptographic Module Validation Program (CMVP) is a joint NIST/CCCS program that validates specific implementations of cryptographic modules, not algorithms in the abstract. A platform can use AES-256 in a way that has never been tested or certified, and still describe itself as “FIPS-compatible.” That claim will not satisfy a CMMC Level 2 or DFARS assessment.

What you need is a vendor who can point to a specific CMVP validation certificate — ideally FIPS 140-3, which superseded FIPS 140-2 in 2022 — for the module their platform uses. Understanding what FIPS 140-3 compliant actually means, and how to verify it, is the first test in any serious evaluation.

Ask the vendor directly: 'Which CMVP certificate number validates the cryptographic module handling your encryption?' A compliant vendor will immediately provide their certificate number or point directly to the underlying CMVP-validated module (such as AWS's validated cryptographic module) running their platform.

2. Does Encryption Travel With the File After It Leaves Your Environment?

Container-based security — SharePoint permissions, Google Drive access controls, VPN-gated file servers — protects files within the container. The moment a file moves outside that environment, the protection ends.

This is not a theoretical risk. It is the standard failure mode for data loss in defense supply chains. A file shared with a subcontractor, forwarded to a personal email address, or downloaded onto an unmanaged device exits your security perimeter and takes nothing with it.

File-layer encryption binds protection to the file object itself, not to the system hosting it. That protection persists whether the file sits on a SharePoint server, a contractor’s laptop, or a USB drive in a hotel room. The question to ask is whether the vendor’s encryption model is tied to their infrastructure — or to the file.

Platforms that depend on their own cloud environment to enforce protection have a meaningful gap: coverage stops at the boundary they control.

3. Who Holds the Decryption Keys — You or the Vendor?

Key custody is a compliance question as much as a security one. When a vendor manages your decryption keys, those keys can be subpoenaed, compelled under court order, or exposed in a vendor-side breach. The vendor’s security posture becomes part of your attack surface.

Zero-knowledge architecture means the vendor has no ability to decrypt your data — because they never hold the keys. Decryption keys are generated and retained within your infrastructure. The vendor operates the platform; they cannot access the content.

The difference between zero-knowledge encryption and standard enterprise file encryption is not a marketing distinction. For organizations handling ITAR-controlled technical data or CUI, it determines whether a vendor-side incident becomes your incident.

Ask the vendor directly: “Can your engineering or support team decrypt a file in my environment without my involvement?” If the answer is yes, or “in limited circumstances,” you have the information you need.

4. Can Access Be Revoked After a File Has Been Downloaded or Shared?

Most platforms offer account deactivation. That is not file revocation. Deactivating an account prevents future logins; it does nothing about files already sitting on a former employee’s hard drive or a partner’s file server.

True revocation acts on the file object itself. When access is withdrawn, the file becomes unreadable regardless of where it lives or who possesses it. This difference matters in two concrete scenarios: contractor offboarding, where files routinely outlive the working relationship, and incident response, where the speed of containment determines the scope of exposure.

If a vendor’s revocation workflow involves logging into a portal and disabling a user account, what they are describing is account deactivation. Push them on this: “If I revoke access today, can a contractor who downloaded the file yesterday still open it tomorrow?”

5. Does It Work Across Your Existing Cloud Environments Without a Migration?

The operational cost of deployment is rarely included in feature comparisons, and it is where most evaluations underestimate total investment. A platform that requires migrating file repositories, restructuring folder permissions, or reconfiguring integrations across SharePoint, Google Drive, and Dropbox is not a two-week proof of concept — it is a six-month project.

Migration-free deployment matters for two reasons. First, it compresses the time between decision and coverage: protection extends to existing file stores without disruption. Second, it reduces the organizational friction of rollout; teams do not have to change their workflows to get protected.

Adding zero-knowledge encryption to SharePoint, Google Drive, and Dropbox without a migration is achievable when encryption operates at the file layer rather than the container layer. The right evaluation question is whether the platform requires you to restructure your environment to fit the tool, or whether the tool fits your environment as it already exists.

6. Are Access Controls Context-Aware, or Just Role-Based?

Role-based access control assigns permissions by job function. It is a reasonable baseline. It is not sufficient for insider threat scenarios or compromised credential attacks — the two failure modes that CMMC and ITAR compliance frameworks are increasingly designed to address.

An account with read access to CUI can be entirely legitimate Monday through Friday at a known IP address and completely anomalous at 2 a.m. from a foreign country. Role-based controls see the role; context-aware access controls see the behavior.

Dynamic access control evaluates access requests against attributes that change in real time: device, geolocation, time of access, network context, and behavioral anomalies. When those attributes fall outside policy, access is blocked, or step-up authentication is triggered automatically, on the file, not at the perimeter.

Ask vendors whether their access model adapts to context or simply enforces static permissions. The difference determines whether the platform can catch what role assignments alone cannot.

7. Can You Produce Compliance Documentation an Assessor Will Accept?

This is the question that separates platforms designed for security from platforms designed for compliance operations. They are not always the same thing.

A CMMC Level 2 assessor evaluating your CUI handling will ask for a specific artifact trail: what encryption is applied, which cryptographic module was used (with CMVP certificate reference), which users accessed which files and when, and whether access was revoked when personnel departed. A platform that encrypts files but produces no exportable audit log creates documentation work during an assessment that should have been automated during operation.

Your System Security Plan should reference the specific CMVP-validated module the platform uses. Access logs should be machine-readable and filterable by file, user, and time range. Policy enforcement events — blocked access attempts, anomaly triggers, revocations — should appear in the same audit trail, not in a separate system.

If the vendor’s compliance story is “our encryption satisfies FIPS,” ask what documentation the platform generates, in what format, and whether that documentation has been accepted in a C3PAO-led assessment.

How Theodosian Answers Each Question

Theodosian was built for exactly this evaluation. Per-file AES-256 encryption assigns a unique key to every file, validated through AWS’s CMVP-validated cryptographic module under FIPS 140-3. Encryption travels with the file; coverage does not stop at the boundary of any cloud environment.

The architecture is patent-pending zero-knowledge: Theodosian holds no decryption keys. Key material never leaves your infrastructure. File access is evaluated across various context dimensions such as identity, device, geolocation, time, network, and behavioral anomaly — and the autonomous Drop the Gate capability can freeze access and trigger step-up MFA without human intervention.

Deployment runs on FedRAMP Moderate infrastructure and integrates with SharePoint, Google Drive, and Dropbox without requiring a migration. Most organizations reach a working proof of concept within two weeks.

If you are mapping the major platforms against these same criteria, the enterprise file encryption comparison for 2026 provides a structured side-by-side view.

FAQs: Enterprise File Encryption & CMVP Validation