Controlled Unclassified Information (CUI) requires a minimum baseline of a moderate confidentiality impact level. System administrators and compliance teams must understand immediately that a moderate impact level is not a single toggle switch or a pre-packaged firewall template you can apply across an enterprise network. It defines a baseline degree of risk and operational rigor.
The exact technical controls needed to satisfy this mandate depend entirely on the specific environment hosting the data, the federal contracts involved, and the regulatory mandates governing those assets.
Federal guidelines explicitly separate CUI from classified defense information, yet its protection is treated with strict regulatory oversight. Nonfederal systems, including defense contractors, universities, and commercial suppliers, must rely on the structured safeguards outlined by the National Institute of Standards and Technology (NIST) to meet federal compliance expectations.
What Level of Configuration Does CUI Require?
A moderate confidentiality impact level means that unauthorized disclosure of CUI would cause serious adverse effects on an organization’s operations, its assets, or the individuals whose information is involved.
Under the federal risk model, serious is not a vague adjective. It translates to things like meaningful operational disruption, significant financial loss, or real damage to national security interests and personal privacy. That is precisely why CUI protection cannot be treated as a nice-to-have security tier that gets budget only after everything else is funded.
It also helps to separate two ideas that get conflated constantly in vendor pitches and internal memos alike. An impact level is a categorization, a statement about consequences.
A network configuration is the physical and logical implementation built to bring risk down to an acceptable level given that categorization: your firewalls, encrypted tunnels, subnetting, access control lists, and host hardening rules. Skipping straight from we’re moderate to buy this appliance is how organizations end up compliant on paper and exposed in practice.
Why CUI Requires a Moderate Confidentiality Level
This requirement isn’t a vendor recommendation or an industry best practice that someone decided sounded reasonable.
It comes directly from the Federal Information Processing Standard (FIPS) 199, which sorts information systems into three impact tiers, low, moderate, and high, based on the consequences of a confidentiality, integrity, or availability failure.
The National Archives and Records Administration (NARA), which serves as the Executive Agent for the government-wide CUI Program, made the floor explicit in 32 CFR 2002.14. The regulation states plainly that CUI Basic is categorized at no less than the moderate confidentiality impact level, and it directs agencies to use NIST SP 800-171 when setting security requirements for CUI on nonfederal systems. That single regulatory sentence is the legal anchor underneath every compliance conversation that follows.
Federal rules split CUI handling into two categories, and mixing them up is one of the more common and costly mistakes during audits:
- CUI Basic is the default standard that applies across federal agencies unless a specific law, regulation, or policy says otherwise. It expects nonfederal environments to maintain safeguards consistent with the standard moderate confidentiality controls described above.
- CUI Specified covers subcategories where a governing authority, a statute, a regulation, or a government-wide policy, layers on heightened handling instructions or tighter dissemination restrictions beyond that baseline. Export-controlled technical data is a common real-world example.
When a specifying authority calls for stricter controls, contractors have to build additional, targeted safeguards on top of the CUI Basic requirements rather than assuming the baseline covers them.
Reviewing system security plans often reveals where teams got this distinction wrong and left real gaps in place because nobody checked which specified category actually applied to the data on hand.
A defense subcontractor storing Controlled Technical Information alongside ordinary procurement-sensitive records, for instance, may find that the technical data carries dissemination limits under ITAR that the procurement records never trigger. That means a single blanket policy covering all CUI the same way is often the wrong design from the start.
What NIST SP 800-171 Requires for Systems Handling CUI
The controlling framework for nonfederal systems is NIST Special Publication 800-171, and it’s written to apply across an entire environment rather than to a single perimeter device or appliance.
DFARS clause 252.204-7012 is the specific contract language that makes compliance with this standard mandatory for defense contractors handling covered defense information, and it has anchored this obligation since long before CMMC existed as a program.
For years, organizations built their programs around Revision 2’s fourteen control families. That changed on May 14, 2024, when NIST published the final version of Revision 3, restructuring the standard into 17 control families.
It added Planning, System and Services Acquisition, and Supply Chain Risk Management as entirely new families, while introducing 88 organization-defined parameters that each entity must tailor to its own environment.
The headline number of requirements actually dropped, from 110 in Revision 2 to 97 in Revision 3, but don’t mistake that for a lighter lift.
The companion assessment guide, NIST SP 800-171A Revision 3, expanded from 320 assessment objectives to 422, meaning assessors now have considerably more granular questions to verify against each requirement.
Access Control and Least Privilege
Access control exists to guarantee that only identity-verified, authorized people can touch systems holding sensitive files. The principle underneath it is least privilege: users get only the access their specific job function requires, nothing broader.
In practice, that means privileged administrative accounts have to be explicitly walled off from everyday user accounts, because a compromised standard account should never be one step away from domain admin.
Remote connections need to route through encrypted, monitored paths rather than open RDP or unmonitored VPN tunnels. Direct user access to internal resources holding CUI should require documented business justification rather than default availability.
Organizations where everyone in IT has domain admin because it’s easier still exist, but that shortcut is one of the first things an assessor will flag.
Authentication and Multifactor Authentication
Every individual accessing the environment needs a unique, traceable credential. Shared logins and group accounts, still common in smaller contractor shops trying to save on licensing, are explicitly prohibited under this control family.
Multifactor authentication (MFA) has to be enforced for network access broadly and for any local access to privileged accounts specifically. Password policy needs to enforce genuine complexity, session timeouts, and secure credential handling rather than a checkbox policy nobody reviews.
Authenticators also need active lifecycle management. In plain terms, this means an employee’s access gets revoked the day they leave, not the following Monday during the next scheduled review.
Network Protection and System Boundaries
Sound network engineering keeps CUI from bleeding into the broader enterprise environment where it doesn’t belong. That starts with clearly defined logical and physical boundaries around every asset that processes, stores, or transmits sensitive files.
Firewalls and gateway systems need continuous monitoring of traffic crossing those boundaries, and segmentation should isolate CUI-processing nodes from general enterprise traffic and, critically, from guest networks.
Inbound and outbound paths should permit only the protocols and traffic flows the environment genuinely requires.
A flat network where the CUI database shares a broadcast domain with the guest Wi-Fi is a finding waiting to happen, and it appears more often than it should in smaller contractor environments.
How CUI Systems Should Be Configured and Hardened
Moving from policy language to actual execution means making concrete changes across operating systems, applications, and network infrastructure, not just writing a policy document and filing it away.
Establish a Secure Baseline Configuration
Secure configuration starts with eliminating factory defaults and documenting a real baseline. Engineering teams need to build and maintain documented configurations for every server, endpoint, router, and firewall in scope.
Every piece of hardware and software needs to live in a comprehensive, current inventory rather than a spreadsheet someone updates twice a year.
Configuration changes should go through a formal change control process before they touch production systems, and baselines need periodic review against new software releases and emerging security advisories. This is unglamorous work, and it’s also the single most common gap encountered in first-pass assessments. Teams get the exciting controls right, encryption, MFA, network diagrams, and then can’t produce a current inventory of what’s actually plugged into the network, which undermines confidence in everything else they’ve documented.
Disable Unnecessary Services, Ports, and Functions
Least functionality is the guiding principle here: strip out what you don’t need, because everything running is something an attacker can potentially exploit.
That means removing non-essential software, development utilities, and unused OS components from system images before deployment, disabling background services, default shares, and legacy protocols like SMBv1, and blocking unnecessary logical ports at both network and host-based firewalls.
Administrative capability should be restricted to what’s actually required for authorized business functions rather than granted broadly out of convenience.
Protect CUI During Storage and Transmission
Cryptographic controls matter because they protect data even when hardware or transmission media gets physically intercepted or stolen.
Organizations need FIPS-validated encryption, meeting FIPS 140-2 or FIPS 140-3, for data at rest across servers, laptops, and backup volumes. They also need secure transport protocols such as TLS 1.3 or IPsec VPNs for anything in transit crossing external or untrusted networks.
Network boundaries should be configured to block unencrypted legacy protocols from carrying sensitive data at all. Cryptographic keys need to live in hardened storage modules with tightly restricted access, not in a plaintext config file somewhere on a shared drive.
Logging, Monitoring, and System Integrity
Continuous visibility is what lets a team catch an anomaly before it becomes a breach report. Endpoints, firewalls, and applications need to generate detailed audit logs tracking user activity, privilege escalation attempts, and file access.
Those logs should feed into a centralized Security Information and Event Management (SIEM) system for real-time correlation rather than sitting in isolated silos nobody reviews.
Regular vulnerability scanning across all in-scope assets, with patch deployment prioritized by actual risk, needs to be routine rather than reactive. Anti-malware tooling, file integrity monitoring (FIM), and endpoint detection and response (EDR) agents round out the picture by catching unauthorized changes to system components as they happen.
Does CUI Have to Be Kept on a Separate Network?
This is probably the single most common misconception out there, and it costs organizations real money when they get it wrong. Handling CUI does not require a completely isolated, air-gapped physical network.
Federal guidance does not mandate dedicated physical infrastructure for most commercial entities, and building one when it isn’t required is an expensive overcorrection.
Logical segmentation accomplishes the same goal without the capital expense. Standing up a dedicated CUI enclave using VLANs, firewalls, and zero-trust access controls meaningfully shrinks your compliance scope.
Isolating sensitive data within that enclave limits your audit boundary to the specific servers and workstations inside it, keeping the rest of the corporate IT environment outside the assessment entirely. This is genuinely the most cost-effective path for small and mid-sized contractors, and it’s the approach to recommend first in nearly every scoping conversation.
A twenty-person engineering firm rarely has the budget to run a second physical data center just to isolate a handful of CUI-bearing workstations, and a well-built enclave gets them the same assessment boundary at a fraction of the cost. Cloud hosting is the other viable route. When CUI lives in public cloud infrastructure, the cloud service provider generally needs to meet at least the FedRAMP Moderate baseline.
Under the current Revision 5 control set from NIST SP 800-53, this requires roughly 323 security controls, or an equivalent authorized set of protections. FedRAMP Moderate has become the most commonly adopted FedRAMP tier precisely because it’s built for this use case: systems handling sensitive federal data that doesn’t rise to classified levels.
CUI Configuration and CMMC Requirements
Defense contractors face an added layer of validation through the Cybersecurity Maturity Model Certification (CMMC) program.
This is the section of CUI compliance that has moved the most, so it’s worth walking through carefully rather than relying on outdated guidance still circulating online.
CMMC Level 2 is built directly on NIST SP 800-171. The Department of Defense finalized the program structure in 32 CFR Part 170 in October 2024, and then finalized the acquisition-side rule incorporating CMMC into the DFARS on September 10, 2025.
That rule laid out a four-phase rollout: Phase 1, beginning November 10, 2025, requires Level 1 or Level 2 self-certification in new solicitations. Phase 2 was originally scheduled for November 2026 and would have made third-party assessment by a C3PAO (CMMC Third-Party Assessment Organization) mandatory for contractors handling CUI. Phase 3 was slated for 2027, extending Level 3 requirements to higher-priority programs, with full implementation targeted for 2028.
Before CMMC’s rollout, the mechanism for proving compliance was a self-generated score submitted under DFARS clauses 252.204-7019 and 7020 to the DoD’s Supplier Performance Risk System (SPRS).
That methodology assigned weighted point values (1, 3, or 5 points) to each of the 110 Revision 2 requirements, with a perfect score of 110 and penalties for unmet controls pulling the number down, sometimes into negative territory. Scores stayed valid for three years and had to be backed by a POA&M for anything short of a perfect result. That clause was formally deleted on February 1, 2026, folded into the CMMC self-assessment structure now governing Phase 1.
If you’re working from older guidance that still references 7019 as a standalone requirement, it’s worth updating your compliance documentation accordingly. Third-party assessments, when Phase 2 eventually resumes, are performed by organizations accredited through the Cyber AB, the official CMMC accreditation body, not by DoD staff directly.
What Documentation Is Needed for a CUI Environment?
Demonstrating compliance on paper is its own discipline, separate from the technical build, and it’s the piece organizations most often shortchange under deadline pressure.
A System Security Plan (SSP) is the foundation document. It defines your system boundaries, describes the operational environment, and documents exactly how each required control is implemented in your specific setting rather than in the abstract.
Network topology diagrams need to accurately show internal subnet structures, firewall placement, data flow paths, and external gateways. They need to match reality, not the network as it existed eighteen months ago before three infrastructure changes.
A Plan of Action and Milestones (POA&M) tracks identified gaps against corrective actions, assigned resources, and target completion dates. Assessors read this document closely because it shows whether an organization actually addresses its own findings or just files them away.
Standard Operating Procedures (SOPs) covering account lifecycle management, baseline configuration, patch management, and incident response round out the package, giving an assessor written evidence that controls are operational habits rather than one-time projects.
None of this documentation should be written once and shelved. Organizations often treat their SSP as a one-time deliverable produced to satisfy a contract requirement, then let it drift completely out of sync with the actual network within a year.
NIST SP 800-171A Revision 3, the assessment methodology document paired with the core standard, is written from the assumption that an assessor will ask for evidence tied to each of its 422 determination statements.
A stale SSP describing a network that no longer exists is functionally the same as having no SSP at all when that conversation happens.
Bottom Line
A moderate confidentiality baseline is the universal floor for protecting CUI on nonfederal systems, set by FIPS 199 and made explicit in NARA’s regulations.
Meeting it means building a genuinely layered defense: strong access controls, mandatory multifactor authentication, real network boundary protection, encryption for data at rest and in transit, centralized logging, and continuous monitoring, not a single product purchase.
Compliance doesn’t require a fully separate physical network. Logically segmented enclaves or FedRAMP-aligned cloud hosting can manage your scope effectively and far more affordably for most organizations.
What has changed heading into the back half of 2026 is the regulatory landscape itself: CMMC’s third-party assessment phase is currently paused while the Department of War reworks its approach, and a broader FAR-wide CUI rule built around NIST SP 800-171 Revision 3 is moving toward finalization and would extend these obligations well beyond the defense sector. Technical hardening still has to be paired with real documentation, an SSP chief among it, to hold up under any version of federal review that eventually applies to your contracts.
