How to send CUI by email under NIST 800-171

How to send CUI by email without failing the clause

If you must email CUI today, the short answer is that the message must be encrypted or sent through a secure communications system that uses a FIPS 140-2 or 140-3 validated cryptographic module, as HSAR 3052.204-72 requires. Under NIST SP 800-171 Rev. 3, requirement 03.13.08 (Transmission and storage confidentiality) asks for cryptographic protection of CUI both in transit and in storage, and it absorbs the Rev. 2 requirements on media and system communications encryption. Regular, unencrypted email is treated as acceptable only for federal information systems when a secure alternative is impractical, which is not the position a contractor should plan around. Confirm the exact wording of the clause in your contract, because agency clauses differ and some add their own transmission rules.

The answer then depends on three things: your email host, the clause that governs the contract, and whether a cloud provider stores, processes or transmits covered defense information. Under DFARS 252.204-7012, an external cloud service provider that handles covered defense information must meet security requirements equivalent to the FedRAMP Moderate baseline, so ask your provider in writing whether its service has that status for your use. Microsoft's GCC High environment restricts file sharing to other GCC High organizations, which can affect who you can exchange CUI with. Check these limits against your partners' tenants before you rely on them.

Your organization owns this control, including the decision of which email path to use, the encryption settings, the key management and the evidence that the configuration works. An implementation partner can prepare the mail configuration, document the encryption design and gather the records an assessor will ask for. Only an independent assessor can test the control and issue results, and a Basic Assessment score you submit is your own attestation. Before sending CUI, record the module's FIPS validation certificate, confirm the mode is enabled, and document who may send CUI and how it is marked.

Which email path fits your contract

Standard email can carry CUI when the message is encrypted in transit and the cryptographic module doing the work is FIPS-validated. The HSAR clause in some agency contracts requires encryption or a secure communications system using a FIPS 140-2 or 140-3 validated module, and it allows regular email only for federal information systems when that is impractical. Requirement 03.13.08 also expects cryptographic protection of CUI in storage, so the mailbox, archives and backups matter as much as the transport.

Transport encryption: Confirm that TLS or S/MIME or PGP is enforced for every message containing CUI, not just offered as an option.
Validation question: Ask the email provider which cryptographic module is used and whether that exact module, version and mode is listed as FIPS-validated.
Stored messages: Check encryption at rest for mailboxes, archives, journaling and backups, including who holds the keys.
Recipient reach: Outside recipients must be able to receive the protected message, so test the workflow with an external account before relying on it.
Provider scope: If the provider stores or transmits CUI, it may need to meet FedRAMP Moderate equivalency under DFARS 252.204-7012.

Before choosing this path, confirm with the contracting officer which clause applies and get the provider's validation documentation in writing.

Does your email provider need FedRAMP Moderate?

The FedRAMP Moderate question applies only when your email provider is an external cloud service provider that stores, processes or transmits covered defense information. DFARS 252.204-7012(b)(2)(ii)(D) requires that kind of provider to meet security requirements equivalent to the FedRAMP Moderate baseline, along with the clause's incident reporting and forensic support duties. The clause does not say that every email product is covered. Whether your hosted mailbox, archive, gateway or collaboration suite falls under it depends on the contract and on where CUI actually travels, so the answer has to be worked out for your data flow rather than assumed from the product name.

Start by mapping each place a CUI message or attachment lands: sender and recipient mail stores, journaling or archiving systems, spam and malware filtering services, and any file-sharing links that point to cloud storage. For each one, ask whether the provider holds, processes or transmits the CUI in its own environment. A provider that only relays encrypted traffic you control is in a different position from one that stores message bodies. Record the answer in your system security plan, since assessors will expect the boundary to be documented and not inferred from a vendor brochure.

Get the position in writing from two parties. Ask the contracting officer whether the clause applies to the email service as your contract defines the data flow, and ask the provider to confirm in writing whether its environment is FedRAMP Moderate authorized or equivalent and how it handles incident reporting and forensic access. Keep both answers with your assessment evidence. The MORSECORP settlement, described in the enforcement material on this page, turned on a third-party email host used without that equivalent security, so an informal assumption is the risk to avoid.

How to bring an email path into compliance

This sequence takes an email path from an unmapped flow to documented, configured and verifiable protection for CUI in transit and at rest. The output is evidence an assessor can test against the requirements, not a general statement that email is secure.

Map every place CUI travels by email
Start by listing where CUI is sent and stored in mail: user mailboxes, shared mailboxes, distribution lists, archives, journaling, backups, mobile devices and any gateway or relay that handles messages. Involve the people who send CUI, since they know the real habits, not only the documented ones. The step is done when every flow has an owner, a data type and a destination, and when you can say which flows involve external recipients. This map feeds the system boundary and the system security plan.
Confirm the email host and its FedRAMP status
Identify the email provider, any third-party archiving or security service, and any hosting arrangement that touches CUI. Ask each provider in writing whether it stores, processes or transmits CUI, and whether its environment meets FedRAMP Moderate equivalent security if it does. DFARS 252.204-7012 applies this requirement to external cloud service providers handling covered defense information, so confirm the contract terms and the authorization documentation rather than relying on marketing claims. The step is done when each provider has a written answer and a file of supporting evidence, or when CUI is removed from that provider's scope.
Select validated cryptographic modules for email
Decide which cryptographic modules protect CUI in transit and at rest on the email path, including TLS for server-to-server transport, S/MIME or equivalent message-level encryption where needed, and encryption of mailbox stores and backups. Confirm that each module is listed as FIPS 140-2 or FIPS 140-3 validated on the NIST validation list for the exact version in use, and that the mode is enabled. Where a provider cannot name its validated module, treat that gap as an open finding. The step is done when each path has a named module, a validation reference and an enabled setting.
Enable and enforce encryption in transit
Configure the mail platform to require encrypted transport for connections that carry CUI, and set policy to reject or route unencrypted delivery for CUI-marked messages where the platform supports it. Test with both internal and external recipients, and confirm that downgrade to plaintext is blocked or flagged. Where the platform cannot enforce this, document the compensating control and the limits of the exception. The step is done when a test message from each path shows encrypted transport in the mail logs and a blocked or flagged plaintext attempt is recorded.
Verify encryption at rest and in backups
Check that mailbox data, archives, attachments, backup copies and any exported message stores are encrypted with validated modules, and document who manages the keys. Confirm whether keys are held by the organization, the provider or a customer-managed key service, and what that means for access to CUI by provider staff. Include backup and restore procedures in the test, since encrypted backups can still be restored into unencrypted locations. The step is done when you have a record of the storage encryption setting, the key custody model and a successful test restore that preserves encryption.
Document the mechanisms in the system security plan
Update the system security plan so that the email path, its providers, its validated modules and its key management are described in the same terms used by the requirements for transmission and storage confidentiality. Record each cryptographic mechanism, the validation reference, the owner, and any exception with its plan of action and milestones entry. The step is done when an assessor reading only the plan can trace each email flow to a requirement, a control and a named piece of evidence.
Collect configuration evidence for the assessor
Gather exported configuration, policy screenshots or API output, validation references, provider contract clauses, sample transport logs and test results, and dated change records showing when each setting was applied. Keep the evidence tied to the specific flows in the map so the assessor can sample it. Have the organization's owners review the package, since the organization owns its controls. An independent assessor decides whether the evidence meets the requirements. The step is done when the package is indexed by flow and requirement and each item has a date, an owner and a source.

What the MORSECORP settlement shows about third-party email

The March 2025 DOJ settlement with MORSECORP involved a single email decision that cascaded into three separate failures. Each card below isolates one failure and the control that would have prevented it, so you can check your own email architecture against the same points.

Third-party email host without equivalency

MORSECORP admitted that from January 2018 it used a third-party email host without ensuring FedRAMP Moderate equivalent security for that service. DFARS 252.204-7012 applies this equivalency test to any external cloud service provider that stores, processes or transmits covered defense information, so the email host is in scope even when it is a mainstream product. Before you sign or renew, ask the provider for its FedRAMP authorization or evidence of equivalent controls, and record the answer in your system security plan.

Email outside the NIST control set

The settlement also admitted that not all NIST SP 800-171 controls had been implemented. For email, that means the mail system must be covered by the same access control, audit, encryption and incident response requirements as any other system that holds CUI. Check whether your mailboxes, archives, journaling and mobile sync fall inside the assessed boundary or sit outside it by default.

Transmission and storage encryption

Requirement 03.13.08 asks for cryptographic mechanisms that prevent unauthorized disclosure of CUI during transmission and while stored. An email platform that encrypts only in transit, or that cannot show where mailbox data is encrypted at rest, leaves a gap an assessor will test. Confirm encryption for messages, attachments, archives and backups, and confirm which key options the provider offers.

No consolidated system security plan

MORSECORP lacked a consolidated system security plan until January 2021, roughly three years after the email arrangement began. A system security plan that describes the email host, its data flows and its responsibilities is the document an assessor reads first. Write it before the email service goes live, and update it whenever the provider, tenant or data flow changes.

Provider responsibilities in writing

A third-party host controls infrastructure your organization does not, so responsibilities must be split explicitly. Document which controls the provider inherits, which your team operates (accounts, mail rules, external sharing, device access) and how incident notice reaches you. Ask the provider for a responsibility matrix and a contract clause covering incident reporting and forensic support.

Enforcement follows the paper trail

The settlement resolved a False Claims Act allegation, which means the gap was judged by what the contractor represented to the government, not only by what the system did. Keep your assessment score, system security plan and plan of action and milestones consistent with the email architecture you actually run. Review those records each time the email service changes, because a stale claim is the exposure.

What to verify before you email CUI

Emailing CUI puts the mail system, its encryption and its hosting provider inside your assessed boundary. The checks below turn that into facts you can document before the first message goes out, and they point to the same evidence an assessor will ask for.

Confirm FIPS validation of the modules

Ask the email gateway, client and encryption vendors for the validation certificate that covers the exact module and version in use, not a marketing statement that the product is FIPS-compliant. HSAR 3052.204-72 names FIPS 140-2 and FIPS 140-3 validated modules, so check which standard each certificate cites. Record the certificate number and the operating mode that must be enabled, since a validated module running in a non-approved mode does not meet the expectation.

Confirm the host's FedRAMP status

Where a third-party email host stores, processes or transmits CUI, DFARS 252.204-7012(b)(2)(ii)(D) requires security equivalent to the FedRAMP Moderate baseline. Ask the provider for its current FedRAMP authorization or a documented equivalency, and confirm the authorization covers the email service you are buying, not only the parent platform. The MORSECORP settlement turned on a host used without that assurance, so get the answer in writing.

Confirm the SSP describes the email flow

Your system security plan should show every path a CUI message takes: client, gateway, encryption layer, third-party host, archive and external recipient. Diagrams and text should agree on where each hop is protected and which component holds keys. If a gap exists, such as an unencrypted internal relay, document it and its plan of action rather than letting the diagram omit it. An assessor will trace one real message through this flow.

Confirm DLP and mailbox retention

Data loss prevention rules should detect CUI markings and block or force encryption on messages that leave the organization, and the rules must be tested with sample marked content. Confirm the retention policy for mailboxes, journaling and backups, because CUI sitting in archives is still CUI in storage. Ask the provider which retention defaults apply and whether they can be set per tenant, then record the settings you chose and why.

Confirm recipient eligibility

Before sending, confirm each recipient has a lawful and contractual need to know, and that their organization is able to receive CUI under the agreement. Some platforms share content only among tenants of the same cloud environment, which can make a commercial recipient unreachable for CUI. Maintain a list of approved external recipients and their domains, and check that the mail system enforces it rather than relying on users to remember.

Retain the 03.13.08 evidence

Requirement 03.13.08 covers cryptographic protection of CUI in transit and in storage, and the SP 800-171A assessment procedure expects examine and test evidence. Keep configuration exports showing TLS and encryption settings, the module certificates, DLP test results and key management records, each dated and tied to the system. Assign an owner to refresh them on a set schedule, because an assessor will ask whether the evidence matches the system as it runs today.

Questions buyers ask about emailing CUI

Is regular unencrypted email ever allowed for controlled unclassified information?

Generally no, at least not for contractor systems. The HSAR clause 3052.204-72 requires CUI sent by email to be encrypted, or sent within secure communications systems that use a FIPS 140-2 or 140-3 validated cryptographic module. It allows regular email only for federal information systems, and only when encryption is impractical. Contractors should treat that exception as something the agency must authorize, not a route they can choose for convenience. Confirm the exact handling rule in each contract, because agency clauses and the DFARS clause may add requirements of their own.

What does FIPS validation require for CUI email encryption?

It requires that the cryptographic module doing the encryption is validated under the FIPS 140 program, not merely that the algorithm is strong. A validated module is tested and listed against a specific version and configuration, so you need to confirm the certificate number covers the software and operating mode you actually run. Check these points with your email vendor and your own environment:

Whether TLS for transit and any message-level encryption use a validated module
Whether the validated mode is enabled in configuration, since many products ship with it off
Whether stored mailboxes, backups and archives use validated cryptography
Whether key management meets the same expectations

NIST SP 800-171 requirement 03.13.08 covers encryption in transit and in storage, so the evidence should show both.

Does Microsoft GCC High solve the problem of emailing CUI?

It can help, but it does not remove the need for work. GCC High is a government-community cloud environment, and Microsoft's service description limits sharing of SharePoint and OneDrive files to other organizations also in GCC High. Some commercial features are not available there. Those limits can block exchanges with subcontractors or agencies that are not in the same environment, so the sharing model needs to be planned before you adopt it. Your organization still owns its configuration, identity, access, logging and the system security plan. Confirm with Microsoft which services and encryption settings apply to your tenant and how they map to your assessment boundary.

What must our organization do itself when emailing CUI?

Your organization owns the controls, even when a vendor or partner helps. You must decide which mailboxes and users may handle CUI, how messages are marked and encrypted, what happens when a message reaches the wrong recipient, and how external users are verified. You also need written procedures, training, audit logs of CUI email activity, and a system security plan that describes the email service as part of the boundary. An implementation partner can prepare configurations, collect evidence and document the design, but it cannot accept responsibility for your decisions. Ask any partner to state in writing which tasks are theirs and which remain yours.

How long does it take to prepare CUI email handling?

The duration depends mainly on the starting environment, and no reliable figure applies across organizations. Preparation tends to be shorter when an email platform already runs in a validated, documented configuration, and longer when the organization must move mail to a new environment, retire a third-party host, or build the system security plan from scratch. Other drivers include how many mailboxes and external partners are involved, how many systems integrate with email, and whether agencies need to approve a design. Ask for a written scope with milestones before accepting any timeline, and confirm which parts depend on your change approval process.

Who issues the assessment result for our CUI email setup?

Only an independent assessor issues the result. For Department of Defense contracts, the assessment is run under the DoD's frameworks and results are posted to SPRS by the organization, while formal assessments are performed by DCMA DIBCAC or by certified third-party assessors where the program requires them. A consultant or implementation partner, including DeployOpen, prepares systems, controls and evidence, but does not issue audit reports, attestations or certifications. Confirm with the contracting officer which assessment applies to your contract and whether your email provider's own attestations will be accepted as evidence.

Who owns the email controls and who verifies them

The organization that holds the contract owns the email controls and the system security plan that describes them, and no outside party can take that ownership over. Whether the email platform runs in your tenant, a government cloud or a third-party host, your organization must decide how CUI moves by email, document how each control is met, and answer for it to the federal agency. NIST states that application and implementation of SP 800-171, and any compliance issues, are the responsibility of the agency that holds the contract or agreement with the nonfederal organization. In practice, that means the people who sign the SSP and the plan of action and milestones must be employees who can explain each email control without reading a vendor brochure.

Obligations under DFARS 252.204-7012 and HSAR 3052.204-72 attach to the contractor even when a host, managed service or mail gateway is outsourced. The MORSECORP settlement illustrates the point: the company was faulted for using a third-party email host without ensuring equivalent security, not only for its own configuration. Before signing with any provider, ask who holds the FedRAMP Moderate equivalency evidence, who is contractually bound to incident reporting, and where the provider's responsibilities end in the shared responsibility matrix. An implementation partner can configure encryption, transport rules and logging, and can assemble the evidence binder, but cannot accept those obligations on your behalf.

Only an independent assessor reaches a conclusion on whether the email controls meet the requirements. For DoD work, that means a DCMA DIBCAC assessment or a CMMC assessment by an authorized third-party assessment organization, depending on the contract. Ask the assessor early which evidence they expect for transmission confidentiality, which test methods they will run for 03.13.08 and which FIPS validation certificates they will request. Your team should own the answers, the implementation partner should prepare the systems and records, and the assessor should be the only party whose findings count as a verdict.

How DeployOpen prepares CUI email for assessment

DeployOpen plans, implements and documents self-hosted open-source mail and file-sharing platforms inside your own infrastructure, so CUI email paths can be scoped, encrypted and evidenced for assessment. Your organization owns its controls and its assessment outcome, and an independent assessor issues any formal results.

How we scope

Each engagement starts with a written scope listing the mail, file-sharing and relay systems that carry or store CUI.
The scope identifies which transmission and storage paths need FIPS-validated cryptography and which need documented exceptions.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.

How we build

We configure encryption in transit and at rest for the agreed mail flows, with module choices confirmed against your validation records.
We harden the platform, document key management and set up logging so transmissions of CUI can be traced during review.
We test the configured paths for encryption and access restrictions, and record results against the 03.13.08 assessment procedure.

How we hand over

You receive system documentation, configuration records and test evidence mapped to the requirements in scope.
Gaps we find are listed with owners, so your team can decide on remediation or a plan of action and milestones.
Assessment remains with your organization and an independent assessor, since DeployOpen does not issue reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover platform updates that change encryption settings, so evidence stays current between assessments.
Ask us to confirm in writing which support and testing tasks a retainer includes before you sign.

How to send CUI by email