Secure File Sharing for Government Contractors: What FedRAMP, CMMC, and ITAR Actually Require

File sharing is not a convenience problem for government contractors; it’s a compliance one.

A defense subcontractor shares design schematics with a prime. The prime shares a contract deliverable with a DoD program office. An ITAR-regulated manufacturer sends technical data to an international partner under a Technology Control Plan. In each case, the file has left your environment. In each case, a regulatory framework has something to say about how it must be protected in transit, at the destination, and after it arrives.

FedRAMP, CMMC, and ITAR are not the same framework. They do not apply to the same organizations for the same reasons. But when a government contractor sits at the intersection of all three — which most DoD subcontractors with overseas collaborators do — the file sharing requirements from each framework compound. This post maps what each one requires, where the requirements overlap, and what a compliant file-sharing architecture looks like at the data layer.

What Does CMMC Require for File Sharing?

CMMC Level 2 addresses file sharing through two primary lenses: encryption and access control.

On the encryption side, NIST 800-171 Practice SC.L2-3.13.10 requires the use of FIPS 140-3 validated cryptography when protecting the confidentiality of Controlled Unclassified Information. SC.L2-3.13.8 requires encryption of CUI in transit. These requirements do not end at your system boundary — they apply to CUI as it moves to your subcontractors, to your prime, and to any external system involved in contract performance.

The practical gap this creates for file sharing: sending CUI via a TLS-protected email attachment, a secure portal, or SFTP satisfies the in-transit requirement. The file travels over an encrypted channel. But when it arrives at the recipient's system — a subcontractor's file server, a prime's SharePoint tenant, or a DoD program office's collaboration platform — the transit encryption has done its job and stopped. The file is now at rest on a system outside your control. SC.L2-3.13.16 requires that CUI at rest is protected, but the protection on the destination system is the destination's compliance obligation, not yours, unless the file is protected at the file layer before it leaves your environment.

On the access control side, what CMMC requires for sub-tier supply chain file sharing is that access to CUI is limited to authorized users and functions. If you share a CUI-containing file with a subcontractor, the access control requirement follows the file. A file shared without file-layer access controls becomes dependent entirely on the recipient's access management, over which you have no visibility and no control.

The CMMC file sharing requirement, read precisely, is: CUI shared externally must be encrypted with FIPS-validated cryptography, and access must be governed and auditable. A secure portal satisfies part of this. Per-file encryption with a persistent access policy satisfies all of it.

What Does ITAR Require for File Sharing?

ITAR, administered by the State Department under the Arms Export Control Act, governs the export of defense articles and defense services — including technical data. When an ITAR-regulated contractor shares technical data with any party, the sharing itself is a controlled event.

The ITAR requirement for file sharing comes down to two obligations:

Authorization: Sharing ITAR-controlled technical data with a foreign national — regardless of where they are located — is a deemed export that requires a license or an applicable exemption. The internal sharing of ITAR data with a US person who is an authorized recipient under a license or exemption must be documented. Who received the data, when, and under what authorization must be traceable.

Adequate protection: ITAR Part 120.54 defines technical data handling requirements. While ITAR does not prescribe specific cryptographic standards the way CMMC does, the requirement is that controls adequate to prevent unauthorized access are in place. For digital file sharing, this means encryption and access control sufficient to demonstrate that the data could not be accessed by unauthorized parties — including foreign nationals — during or after the sharing event.

What happens to ITAR-controlled files after they have been transferred is the compliance question that trips most contractors. The authorization event covers the transfer. It does not govern what the recipient does with the file after it arrives, unless the protection follows the file. A design file shared with a domestic prime under a valid exemption, forwarded by that prime to an overseas manufacturing partner, becomes an unauthorized export — even if the original sharing was fully compliant.

The ITAR file-sharing requirement, read practically: technical data must travel with controls that prevent unauthorized access not just during transit but after arrival, and the access history must be auditable to demonstrate that only authorized recipients accessed the data.

What Does FedRAMP Require for File Sharing?

FedRAMP is different in nature from CMMC and ITAR. It is not a contractor obligation — it is a cloud service provider authorization framework. FedRAMP Moderate authorization means a cloud platform has been assessed against NIST 800-53 controls and meets the security standard for federal agency use.

For a government contractor, FedRAMP enters the file sharing picture in two ways:

Cloud service selection: When a contractor uses a cloud service to store, process, or share CUI, CMMC requires that cloud services used for CUI handling meet FedRAMP Moderate or equivalent standards. Using a FedRAMP Moderate-authorized platform for CUI file sharing is a CMMC control requirement (CMMC Practice SC.L2-3.13.5 and related).

Inherited controls: A platform deployed on FedRAMP Moderate infrastructure inherits a significant portion of the platform's NIST 800-53 control set. This reduces the contractor's direct implementation burden for the controls the platform addresses. It does not address the file-layer controls — encryption at the file object level, per-user access policy, and revocable access — that neither FedRAMP authorization nor platform permissions provide inherently.

The FedRAMP requirement for file sharing, practically: use cloud services that meet the authorization standard, but recognize that authorization covers the platform, not the files on it.

Where Do the Three Frameworks Agree?

Despite their different authorities and different scopes, CMMC, ITAR, and FedRAMP converge on one architectural requirement: protection at the file level, not just at the channel level.

All three require that the content is protected, not only the transmission. CMMC's FIPS-validated cryptography requirement applies to the file as it moves and as it rests. ITAR's adequate protection standard applies to the file after it arrives. FedRAMP's platform authorization covers the infrastructure, not the files that move through it.

The architectural answer that satisfies all three simultaneously is not three separate compliance programs. It is encryption and access control applied at the file object level — so that the protection travels with the file through every channel, to every recipient, and persists after the file arrives.

The difference between transfer encryption and persistent file-level encryption is where the compliance requirement actually lives. Transfer encryption handles the channel. Persistent encryption handles the content. When the frameworks say "protect the data," they mean the content, not the channel.

What Does a Compliant File Sharing Architecture Look Like?

Working from the specific requirements across CMMC, ITAR, and FedRAMP, a compliant file sharing architecture for a government contractor includes:

FIPS 140-3 validated encryption applied at the file layer before sharing: The file leaves your environment already encrypted with a CMVP-validated module. The encryption is not a property of the channel — it travels with the file. Your system security plan must document the specific module and its certificate number.

Per-file access policy that the recipient must satisfy to open the file: The access decision is made at the time of opening, not at the time of sharing. This means the sharing organization retains control over who can access the file — not just during transit, but after delivery. If the recipient's clearance status changes, if the authorization period ends, or if a sharing error is discovered, access can be revoked retroactively.

Revocable access with a verifiable audit trail: Every file access event generates a log entry. Who accessed the file, from which device, at which time, under which access policy. This telemetry is what satisfies the CMMC AU practices, the ITAR authorization traceability requirement, and the forensic evidence chain for DFARS 252.204-7012 cyber incident reporting.

Platform hosting that meets FedRAMP Moderate standards: The sharing infrastructure itself — the cloud environment that delivers and manages the encrypted files — must meet the authorization standard CMMC requires for CUI cloud services.

Zero-knowledge key management. When the encryption key custodian cannot access your files, government compulsion orders directed at the vendor produce no usable data. This is directly relevant to ITAR, where unauthorized access to technical data by foreign nationals — including access compelled from a vendor under foreign legal process — is a compliance event. Zero-knowledge key architecture removes the vendor from the decryption chain.

What File Sharing Scenarios Are Most Risky for Government Contractors?

Prime-to-sub CUI sharing: A prime shares CUI-containing specifications with a Tier 2 subcontractor. The prime's portal delivers the file securely. The subcontractor downloads it to their file server, which may or may not be CMMC-assessed. The file is now on a system outside the prime's control, in plaintext. What CMMC requires for sub-tier CUI protection is that the prime's compliance program accounts for this — and that the CUI flowing to uncertified subs is protected at the file layer, not just delivered through a protected channel.

International technical data sharing under ITAR license: A US prime shares ITAR-controlled design files with an authorized foreign partner under a Technical Assistance Agreement. The sharing event is licensed. The file arrives at the partner's system. A year later, the TAA expires. The partner still has the file. File-layer access revocation — tying the file's decryptability to the TAA's validity period — is the control that converts a theoretical risk into a documented protection.

Employee personal device access: A cleared engineer working from home downloads a CUI file from SharePoint to a personal laptop to work on a deadline. The file is now on an unmanaged device outside the assessment boundary. Transfer encryption handled the SharePoint-to-device transit. What protects the file on the personal laptop is a different control entirely — and without per-file encryption, the answer is nothing.

Collaboration tool spillage: A team member pastes a CUI-containing section into a Teams message, a Slack channel, or a shared document in an unauthorized workspace. The CUI is now outside the assessed boundary. What CUI spillage requires is a 72-hour reporting cycle, scope assessment, and sanitization — which is avoidable when the file content itself is protected and the sharing action produces ciphertext rather than plaintext.

FAQs: Secure File Sharing for Government Contractors