Why Microsoft 365 Is a CUI Compliance Minefield
Microsoft 365 is everywhere in the defense industrial base. It is easy to deploy, familiar to end users, and powerful enough to handle the collaboration demands of most contractors. The problem is that familiarity breeds complacency. In my experience working with defense contractors across dozens of engagements, Microsoft 365 is one of the most common places where Controlled Unclassified Information (CUI) is mishandled — often without anyone realizing it until an audit surfaces the exposure.
This is not a technology problem. It is a governance problem. The platform can be configured to meet the requirements of DFARS 252.204-7012, NIST SP 800-171, and CMMC. But out of the box, it will not protect your CUI. The burden is on the contractor to configure it correctly, train employees to use it properly, and maintain controls over time. Most organizations fall short on all three fronts.
Below are the most common ways contractors mishandle CUI in Microsoft 365 — and what the consequences look like when those failures are discovered.
Using the Wrong Microsoft 365 Tenant
This is the single most consequential mistake I see, and it is surprisingly common. Contractors handling CUI under a DoD contract frequently run their operations in a commercial Microsoft 365 tenant — sometimes the same one they used before they won a government contract. Commercial tenants do not meet the requirements for CUI processing and storage under DFARS and CMMC.
The DoD's FedRAMP Moderate Equivalency guidance and CMMC requirements are explicit: CUI must be processed in an environment that meets specific security baselines. For most defense contractors, that means Microsoft 365 GCC High, not commercial or even standard GCC. The differences matter — data residency, personnel security for Microsoft support staff, and access controls are all handled differently across tenant types.
Contractors who discover this problem late — often during a CMMC readiness assessment or a DIBCAC audit — face a costly and disruptive migration, potential contract non-compliance findings, and in some cases, disclosure obligations to the government. If you are unsure which tenant your organization needs, our post on which Microsoft cloud version meets DFARS, NIST, and ITAR requirements is a good starting point.
Failing to Label CUI at the Point of Creation
CUI marking and labeling is a regulatory requirement, not a best practice. Under the CUI Federal Registry and NIST SP 800-171, CUI must be identified and marked so that anyone who encounters it understands its protection requirements. In Microsoft 365, this means implementing sensitivity labels through Microsoft Purview that are applied to documents, emails, and other content containing CUI.
What we see in practice is a wide spectrum of failure:
- No sensitivity labels configured at all
- Labels configured but not enforced — users can ignore them or apply incorrect designations
- Labels applied only to some document types, leaving emails and Teams messages unprotected
- CUI buried in SharePoint libraries or OneDrive folders with no labeling or restricted access controls
When CUI is not labeled, downstream controls cannot function properly. DLP policies cannot trigger on unlabeled content. Access restrictions cannot be scoped correctly. Audit logs do not capture the right events. The entire protection architecture depends on accurate, consistent labeling at the point of creation. Our team has written extensively on CUI marking and labeling requirements — the guidance there directly applies to your Microsoft 365 configuration decisions.
Misconfigured or Absent Data Loss Prevention Policies
Microsoft 365 includes robust Data Loss Prevention capabilities through Microsoft Purview, but those capabilities require deliberate configuration. Turning on DLP is not the same as configuring DLP correctly for CUI. Most contractors who claim to have DLP in place are running generic or default policies that do not align with the specific categories of CUI they handle.
Common DLP failures include:
- Policies scoped only to email, leaving SharePoint, Teams, and OneDrive unprotected
- Overly permissive override settings that allow users to bypass DLP alerts without consequence
- No integration between sensitivity labels and DLP rules, so labeled content is not triggering the right policy actions
- No regular review of DLP policy matches, false positives, or override logs
A well-configured DLP environment is one of the most effective controls you can implement for protecting CUI from accidental or intentional exfiltration. It requires ongoing tuning, not a one-time setup.
Excessive Sharing Permissions and Guest Access
Microsoft 365 defaults are designed for productivity and collaboration, not for CUI protection. Out of the box, SharePoint and Teams allow broad sharing, including with external users and guests. Contractors who accept these defaults — or who have not audited their sharing configurations — are routinely exposing CUI to unauthorized parties.
Specific risks include:
- SharePoint sites with "Anyone with the link" sharing enabled
- Teams channels that include external guests without proper authorization or access review
- OneDrive personal accounts used to store CUI without organizational controls
- No conditional access policies restricting access to compliant, managed devices
NIST SP 800-171 and CMMC both require that access to CUI be limited to authorized users with a legitimate need to know. Broad sharing defaults directly contradict this requirement. The consequences of a CUI disclosure to an unauthorized party can include contract termination, mandatory incident reporting to the DoD, and potential False Claims Act exposure if the contractor has been certifying compliance.
Inadequate Multi-Factor Authentication and Identity Controls
Weak identity controls remain one of the top root causes of CUI exposure. In Microsoft 365 environments, this typically manifests as:
- MFA not enforced for all users with access to CUI systems
- Legacy authentication protocols still enabled, which bypass MFA entirely
- No Conditional Access policies requiring compliant devices or blocking risky sign-ins
- Privileged accounts — including global admins — not subject to stricter controls or Privileged Identity Management
NIST SP 800-171 control 3.5.3 explicitly requires multi-factor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts. Failing this control is not a minor finding — it is a foundational gap that assessors will flag immediately. Our CMMC, CUI, and DFARS compliance services include a full review of identity and access management configurations as part of every engagement.
No Audit Logging or Incomplete Log Coverage
Microsoft 365 provides extensive audit logging capabilities, but those capabilities must be enabled and configured to capture the events relevant to CUI protection. Many contractors either have audit logging disabled, retain logs for an insufficient period, or have no process for reviewing log data.
NIST SP 800-171 requires audit records sufficient to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. In Microsoft 365, this means enabling unified audit logging, configuring log retention appropriate to your compliance requirements, and having a process — ideally automated — to alert on anomalous activity involving CUI.
Without adequate logging, you cannot demonstrate compliance during an assessment, and you cannot detect or investigate a potential CUI disclosure. Both are serious problems.
The Consequences Are Real and Escalating
The stakes around CUI mishandling have increased significantly. The Department of Justice's Civil Cyber-Fraud Initiative has made clear that contractors who fail to meet their cybersecurity obligations — and who certify compliance despite known gaps — face False Claims Act liability. Penalties can reach three times the value of the contract. Beyond legal exposure, a CUI disclosure can trigger mandatory reporting requirements under DFARS, damage customer relationships, and jeopardize a contractor's ability to compete for future awards.
CMMC enforcement is also accelerating. Defense contractors who cannot demonstrate compliant handling of CUI in Microsoft 365 during a C3PAO assessment will not achieve certification — and without certification, they cannot perform on contracts that require it. The window to remediate is narrowing.
For a detailed look at what a fully compliant program requires, our CUI in Microsoft 365 compliance checklist covers the 20 controls every defense contractor must implement.
What Compliant CUI Handling in Microsoft 365 Actually Requires
Getting this right requires more than checking boxes. A defensible CUI program in Microsoft 365 includes the right tenant type, properly configured sensitivity labels, enforced DLP policies, restricted sharing controls, strong identity governance, comprehensive audit logging, and regular configuration reviews. It also requires trained users who understand what CUI is, how to identify it, and what their obligations are when they encounter it.
Many contractors benefit from engaging a Regulatory vCISO who can own these controls on an ongoing basis, rather than treating compliance as a one-time project. The configuration drift that occurs when no one is watching is one of the most common ways that organizations that were once compliant find themselves exposed at audit time.
Take Action Before the Next Audit Finds the Gap
If your organization handles CUI and relies on Microsoft 365, the time to assess your configuration is now — not when a contracting officer or assessor asks for evidence. Cleared Systems helps defense contractors, federal agencies, and regulated organizations identify and close the gaps in their CUI handling programs before those gaps become findings. Contact us to request a quote or explore our engagement models to find the right level of support for your organization.