The configuration level required for Controlled Unclassified Information is the set of 110 security requirements in NIST SP 800-171 Revision 2 — under its 14 control families, every requirement applies to every system component that processes, stores, or transmits CUI unless you document a scoping justification or an approved assessment-scope decision under the May 2024 final rule. The common shortcut, "use the STIGs," is a hardening method for meeting specific requirements, not the requirement itself. If your SSP cites DISA STIGs and nothing else, you've described a technique, not a configuration baseline.

This is an ordinary contract question wearing a technical costume. And it's where most self-assessments either earn credibility or quietly collapse.

The 110 NIST SP 800-171 Requirements Are the Configuration Bar, Not a Framework Suggestion

SP 800-171 Revision 2, published by NIST in February 2020, carries 110 requirements across 14 families, and DFARS 252.204-7012 clause (e)(2)(ii) makes them contractual for defense contractors handling covered defense information. Every requirement gets implemented or documented as not applicable. There's no middle setting.

Where people go wrong is treating these as "best practices." They're assessment criteria. A C3PAO conducting a Joint Surveillance Voluntary Assessment — a Defense Industrial Base Cybersecurity Assessment Center process built on the DIBCAC methodology — will ask you to show implementation for each requirement, and "we have a firewall" answers about two of them.

The basic requirement applies to systems and components that process, store, or transmit CUI. Under the May 2024 revisions to 32 CFR Part 2002 — whose guidance NIST incorporated into SP 800-171 Rev. 3, published May 2024 — organizations can define Assessment Scope using three defined categories, the most common being the "CUI Enclave." That's the region of a network where CUI is handled, logically or physically separated from the rest.

Separated, yes. Isolated, no. Enclave boundaries get tested harder because auditors want to see the controls preventing CUI from roaming outside them.

The Department of Defense maintains the CMMC Program — rolled out as 32 CFR Part 170, with final rules published in October and December 2024 — and as of the November 10, 2025 phase-in, CMMC Level 2 began appearing in new DoD contracts. CMMC Level 2 aligns with the 110 requirements and adds a Process Maturity dimension. That adds process to configuration. It doesn't lower the technical bar.

Configuration Baselines for Each Family: Hardening Specifics You Can Audit Against

The 14 families — Access Control (AC) with 22 requirements, Awareness and Training (AT) with 3, Audit and Accountability (AU) with 9, Configuration Management (CM) with 9, Identification and Authentication (IA) with 11, Incident Response (IR) with 3, Maintenance (MA) with 6, Media Protection (MP) with 9, Personnel Security (PS) with 2, Physical Protection (PE) with 6, Risk Assessment (RA) with 3, Security Assessment (CA) with 4, System and Communications Protection (SC) with 16, and System and Information Integrity (SI) with 7 — each carry configuration implications you can check on a machine.

CM family requirements are the ones auditors treat as the "configuration" family. CM.L2-3.4.1 requires establishing configuration baselines. That means named, versioned, documented baselines per system type — servers, endpoints, network devices, and cloud tenants. Ambiguity there is a common finding.

Hardening comes from specific sources: DISA Security Technical Implementation Guides, the Center for Internet Security Benchmarks, and vendor baselines from Microsoft, Cisco, and Red Hat. The configuration bar is met when the deviations from those baselines are documented and approved. An unapproved deviation is a finding. An approved one with rationale and compensating controls is not.

AU family examples show how the bar applies to network devices too. AU.L2-3.3.1 requires logging of events of interest, and once the CUI overlay exists, firewall and switch logs count. How long to retain them is a business call — I'd recommend a documented review and purge cadence, usually aligned to incident response requirements, and a log retention period described in your SSP.

Version matters. Rev. 2 remains the basis of CMMC Level 2 pending DoD's transition, while Rev. 3 moved to a structure organized around 17 families. If your SSP was drafted against Rev. 2 and your assessment is under Rev. 3, expect the gap analysis to double. Reconcile before, not during.

Network Segmentation Decides How Much Configuration You Owe

Assessment Scope is the highest-leverage decision a contractor makes. Under the May 2024 32 CFR Part 2002 rule, three categories exist: the CUI Enclave — a set of components where CUI is stored or processed; the CUI Assets category — components that merely protect CUI without processing it, like a firewall; and the Security Protection Assets category — security systems like endpoint detection and response platforms. Each category carries different requirements.

A gap assessment usually reaches one of two answers: isolate CUI into a documented enclave, or treat the enterprise as in scope. Isolated enclaves are cheaper per unit for small firms. But they redirect IT labor and frustrate users who need to move files across boundaries — and those frustrations drive exceptions that erode the boundary over time.

Access control configuration inside the enclave isn't optional. AC.L2-3.1.3 requires controlling the flow of CUI in accordance with approved authorizations. Firewalls, VLANs, or software-defined perimeters all work — what actual traffic permits you configure, and what your SSP says the permits should be, must match. That gap is where failed JVAs tend to originate.

The 32 CFR 2002 guidance says to define the scope reduction with rationale and record it in the SSP. That paragraph is the one auditors read first. If the enclave boundary and the diagram in your SSP disagree about which switch hosts CUI, the assessment can get paused until they agree.

Which STIGs and Benchmarks Actually Apply to Each Asset Type

Asset type Baseline source Common configuration failure
Windows Server 2022 DISA STIG or CIS Benchmark (Microsoft Windows Server 2022) Audit policy not aligned to AU requirements
Windows 11 endpoints DISA STIG plus Microsoft Security Baselines USB mass storage not blocked (MP.L2-3.8.7)
Cisco switch/router DISA Cisco IOS/IOS XE STIG Management VLAN shares user subnet
Linux server CIS Benchmark or DISA RHEL STIG SSH session timeouts exceed AC policy
Microsoft 365 tenant Microsoft 365 CMMC (Level 2) configuration guidance Conditional Access exclusions undocumented
Firewall Vendor hardening guide plus independent rule review Permit-any rules in place of SC.L2-3.13.1 flow control
Mobile and remote endpoints Vendor baseline plus MDM enforcement MFA gap against IA.L2-3.5.3

The failure cases come from nearly every assessor's finding log. The left column is a starting point. Trade studies show deviations are inevitable — validated, documented, and approved deviations are what survive.

One row deserves a warning. Disabling USB mass storage satisfies MP media-requirement intent, but if that device is the only way to run the external hard drive used to boot maintenance tools, restricting it can block the maintenance requirement (MA family). Sequence and compensate accordingly: use a tested, documented alternate and log the exception.

These baselines age. A STIG version update can create new findings overnight, so track the release cycle — DISA typically refreshes its STIG packages quarterly — and re-baseline on documented cadence. Never during an assessment.

Washington, DC and Pentagon procurement rules touch the word "configuration" in odd ways — the Federal Register's 32 CFR Part 2002 codification and DoD's 32 CFR Part 170 addendum set the legal meaning. For an MSP adding CMMC-audited environments to a practice, that's about an incentivized boundary, not a pricing point. Standard industry pricing for CMMC readiness work runs well north of a $100,000 engagement for a mid-sized contractor; skip naming figures we can't verify.

Authentication and Access Control Settings You Cannot Leave at Default

IA family requirements are the most-cited in C3PAO findings, and the reason is boring: defaults don't satisfy them. IA.L2-3.5.3 requires multifactor authentication for privileged accounts and nonlocal network access. Giving sysadmins MFA on the domain but letting them SSH from the office without it is a finding.

Password configuration is where IT pushes back hardest. IA.L2-3.5.7 sets minimum password complexity and length requirements, and IA.L2-3.5.8 requires enforcing a documented change cadence or replacement policy. NIST's SP 800-63B guidance moved toward longer passphrases and away from forced rotation, but 800-171's wording is what you're assessed against. Align policy to the requirement and the current credential guidance, then document the reconciliation. Forced quarterly rotations with an eight-character minimum is the configuration auditors most often flag as both weak and inappropriate for the stated risk. Rev. 3 renumbered this area; the substance remains.

AC family requirements follow close behind. AC.L2-3.1.5 requires separating duties so no single account can push code to production and approve the release, or administer backups and restore them at will. That's an org setting. Enforce with RBAC and privilege tiers on the directory, and record it in the SSP. What auditors usually want to see is an actual enforced configuration and a role-mapping document.

AC.L2-3.1.20 requires controlling remote access sessions. That's not one setting — it's a stack: a VPN or ZTNA gateway with terminating endpoints, MFA inside the tunnel, session logging, and the routing table that prevents split tunneling to unmanaged networks. When split tunneling is on and a CUI-bearing application sits on the same browser session as a personal mail account, that requirement is effectively broken no matter what the gateway configuration says.

An Enclave Build Sequence in the Order an Engineer Would Actually Run It

The sequence below matches the order an enclosure build usually follows. Each numbered step should generate its own SSP evidence.

1: Draw the data map and boundary proposal. Get retention locations and flows on paper — a JPG in your head is not evidence. Mark which storage systems hold CUI and which are just adjacent. 2: Choose and document the Assessment Scope category for each component under the May 2024 framework. Name the assembling vendor's CUI-handling endpoint in the diagram or the boundary will be challenged. 3: Rebaseline configuration management. In your CM platform, register the baselines (STIG or CIS version, OS build, hash or image ID) and lock down changes. 4: Bake security controls into the golden images you promote to the enclave — syslog forwarding to the SIEM, EDR agent, MFA-aware apps, restricted local admin. 5: Build access policy before content lives in the enclave. Directory role mapping, session limits, split-tunnel decision, and privileged access for the enclave-administrator group only. 6: Configure the jump host and remote-access stack first; test from an outside network. MFA that fails at step 6 is easier to fix than after users onboard. 7: Test the boundaries. Have someone try to reach an unmanaged host from the enclave and CUI from a personal device. Log and fix. 8: Stand up your evidence package: SSP narrative, baseline register, approved deviation log, audit log retention plan. 9: Run a scoped security assessment (CA family) before the external one, and put the fixes on the risk register with owners and dates.

The sequence can't be compressed, and step 7 gets skipped most often. Any failure at step 7 — unmanaged hosts reachable from the enclave, CUI visible from a personal device — is a finding or a stop-the-line condition. The mid-build fix is usually a boundary rule and an exception; the post-assessment fix is usually manual work and rework.

Cloud Tenants and Hybrid Environments Add Requirements the Network Do List

Cloud is not exempt. If a CUI-bearing file lives in a commercial SaaS tenant, the configuration bar includes tenant-level settings — multi-tenant feature flags, conditional access policies, data-loss prevention, and audit log retention — and the contract flow-down. DoD's cloud security requirements (the 32 CFR rulebook and FedRAMP process) sit alongside 800-171, and an env procurement policy that demands FedRAMP equal or higher is the safe path.

A shared-responsibility handoff does not shift the evidentiary burden. Under CA.L2-3.12.4, you need system security plan evidence for controls a CSP operates on your behalf — the provider's attestation letter, the relevant FedRAMP authorization, and a mapping of CSP-provided controls to the 110 requirements.

Cloud boundary confusion is contractually dangerous. If CUI resides in a commercial tenant, the service must clearly meet FedRAMP equivalence — and if it doesn't, your configuration baseline doesn't save you.

Specific tenant settings that show up in findings:

Conditional Access exclusions for legacy authentication protocols, with justification documented Priva/Purview labels applied and tested on documents shared outside the tenant eDiscovery and audit log retention meeting AU requirements Privileged role assignments reviewed for a defined cadence and recorded

Hybrid cuts both ways. On-premises domain controllers authenticate cloud-hosted enclave resources, so their configuration is in scope even if CUI never lands on them. The SCOPE analysis has to walk through the authentication path, not just storage path.

Where Implementations Actually Fail: Audit Findings and the Five-Year Evidence Trail

The most common C3PAO findings cluster around evidence, then AU logging, then CM baselines, then MFA coverage gaps. Assessor writeups from C3PAO public summaries support this ordering.

Findings on configuration content aren't rare: a baseline registered without adoption, a firewall ruleset on cloud without documented exception, a missing flow-control rule, EDR agents installed but not reporting, and audit policy set for failed events only while the requirement calls for success too.

Ongoing evidence maintenance is where most programs show their discipline. A serious baseline program keeps an annual review, a documented update cycle for STIG releases, and a correction log tied to findings. The five-year requirement sits at DFARS 252.204-7012 (b)(2)(ii), which directs retention of the security incident data and assessment evidence for five years from creation. "Never had a finding" is not a review record.

The failure case that bites most often: a successful JVA followed by a configuration drift, and a routine audit finding that an approved deviation is stale but still listed. The corrective action has nothing to point to. Treat the deviation log as a living document, not a one-time artifact.

Scope creep in the review is the other quiet killer. A new tool gets installed on the enclave network "temporarily," acquires admin rights, and by procurement's reckoning it's a security-protection asset — all without re-scoping. Capture scope inventory at every change control board cycle and match it to the SSP narrative.

FAQ

Are the 110 requirements mandatory for every CUI system regardless of contract size?

Yes, once DFARS 252.204-7012 flows into a contract. All 110 requirements apply to systems that process, store, or transmit covered defense information. Small contracts don't automatically get a smaller bar; assessment scoping and documented not-applicable determinations are the mechanisms that reduce reduction. Confirm the clause set on your specific award.

Is FIPS 140-validated encryption required for every CUI host?

SC.L2-3.13.11 requires FIPS-validated cryptography for transmitted and stored CUI. That's the requirement. What that maps to depends on your technology: it means the module, not the marketing label, carries validation. An approved deviation with compensating controls can apply in limited cases, but narrow it and get it in writing.

Do we have to use DISA STIGs, or can CIS Benchmarks replace them?

Either baseline is acceptable if it's documented and applied consistently as your configuration. Auditors care that you have a named source, a version, and a deviation record. Mixing STIG and CIS per asset type works; mixing them per instance without documentation does not.

We only have to self-assess if we're not bidding on CMMC Level 2 contracts, right?

No. A DoD contract that includes DFARS 252.204-7012 requires self-assessment under the NIST SP 800-171 DoD Assessment Methodology — a score with an SSP — regardless of whether a C3PAO assessment later becomes a term. CMMC Level 2 adds an external assessment; it doesn't replace the self-assessment obligation.

Does cloud hosting remove CU from our configuration obligations?

No. The CSP's FedRAMP or FedRAMP-equivalent authorization is evidence for its controls, not yours. Your tenant settings, identity configuration, audit logging, and data-flow controls remain yours, and CA.L2-3.12.4 is where the shared-responsibility mapping gets documented.

How long do we keep configuration evidence?

Five years from creation under DFARS 252.204-7012 (b)(2)(ii). A common trap is treating ongoing assessments as one-time snapshots. You need change history for baseline deviations and audit evidence, not just last year's report.

What's the cost of getting to 110 requirements versus a scoped enclave?

For a 50–100 person contractor with no current enclave, after deploying a managed isolation, hosting and licensing for a small enclave typically dominates early cost, with a full enterprise-approach retooling running far higher. Pricing varies by provider and scope; request vendor quotes rather than trusting a benchmark. The cost answer is: measure your scope first, because scope is the largest multiplier.

If we're already doing the federal CIS controls, is there a gap analysis shortcut?

Partially. CIS Critical Security Controls cover much of the AU, CM, and SI ground, but 800-171 also requires dedicated predecessor management, CUI flow-control authorizations, and assessment recordkeeping that no control set automatically provides. Do the 110-item mapping — not a control-set crosswalk alone.

This article provides general educational information, not legal, compliance, or contracting advice. Obligations depend on your contract clause, your Assessment Scope determination, and the specific CMMC or DFARS requirements in force at award. For a binding determination, consult a qualified professional with defense contracting or CMMS accreditation experience.