NIST 800-171 enclave approach: how to limit CUI scope

Can a NIST 800-171 enclave reduce the systems in scope?

Isolating CUI in a separate security domain can limit which components the SP 800-171 requirements apply to, but the reduction holds only when the separation is documented and testable. If a contract or CMMC requirement now applies and your CUI footprint spans email, file shares, engineering tools and endpoints, an enclave is often the first scoping decision worth testing. Rev. 3 section 1.1 allows organizations that designate components for CUI to limit scope by isolating them in a separate security domain, using subnetworks with firewalls or other boundary devices, information flow controls, and physical separation, logical separation or both. A security domain, in NIST's terms, implements a security policy and is administered by a single authority.

Under 32 CFR 170.19(c), out-of-scope assets are those that cannot process, store or transmit CUI because they are physically or logically separated from CUI systems or are inherently unable to do so, and the organization must be ready to justify that separation. Assets that provide security protection for CUI assets stay in scope even when they sit outside the enclave. Expect your assessor to ask how the boundary is enforced, which flows cross it, and who can change the rules. Rev. 3 requirements 03.13.01 (boundary protection), 03.01.03 (information flow enforcement) and 03.04.11 (documenting where CUI is processed and stored) are the controls that carry most of that proof.

The organization owns its controls and its scoping decisions. DeployOpen can prepare the enclave, its boundary configuration and the evidence an assessor will sample, but DeployOpen does not issue results. Only an independent assessor, such as a CMMC third-party assessment organization or the Government's assessors, issues findings. Before you commit to a design, confirm with your contracting officer and an assessor which assets they expect you to justify, and ask a quote to show how the separation will be tested and documented in your own environment.

How CMMC Level 2 sorts assets once an enclave exists

Once CUI is isolated in an enclave, an assessor still has to decide which assets fall inside the assessment and how hard each one is tested. 32 CFR 170.19(c) sorts every asset into one of five categories, and the category decides whether an asset is tested against every requirement, against selected requirements, reviewed through the SSP, documented only, or left out of scope.

CUI assets

CUI assets are the systems that process, store or transmit CUI, and they sit at the center of the assessment. Assessors test them against all applicable requirements, so the enclave itself, its servers, endpoints and databases belong here. Check that every system holding CUI is listed in the asset inventory and documented in the system security plan, because an asset missing from the inventory is still in scope if it touches CUI.

Security protection assets

Security protection assets do not hold CUI but protect the CUI assets around them, such as firewalls, directory services, logging servers and vulnerability scanners. Assessors test them against the requirements that relate to the protection they provide, not necessarily every requirement. Check that the enclave's boundary devices, identity systems and audit collectors are classified here and that their role in protecting CUI is written down.

Contractor risk managed assets

Contractor risk managed assets can handle CUI but are not intended to, because policy and procedure keep CUI off them. They are reviewed through the SSP rather than tested in full, and they need not be physically or logically separated from CUI assets. The SSP must explain the policy that keeps CUI away from them and how that policy is enforced, so a general office laptop is defensible here only if the documented controls hold.

Specialized assets

Specialized assets include items such as test equipment, industrial control components, or purpose-built devices that cannot run the usual security controls. Under the rule they are documented in the assessment but not assessed against the requirements. Expect assessors to ask why each asset is specialized, how it connects to the enclave, and what compensating measures limit its exposure to CUI, so keep that justification in the SSP.

Out-of-scope assets

Out-of-scope assets cannot process, store or transmit CUI because they are physically or logically separated from CUI systems or are inherently unable to handle it. Assets that provide security protection for CUI cannot be placed here, however separate they are. The organization must be ready to justify each separation with evidence such as network diagrams, firewall rules and access records. A VDI endpoint that passes only keyboard, video and mouse signals is out of scope under the rule when configured that way.

VDI and cloud options: when the endpoint or provider falls out of scope

A virtual desktop infrastructure (VDI) client is the endpoint a user sees, while the desktop, applications and files run in the enclave. Under 32 CFR 170.19(c), an endpoint hosting a VDI client is treated as out of scope only when it is configured so that no CUI is processed, stored or transmitted beyond the keyboard, video and mouse signals sent to the client. The condition is about the endpoint's configuration, so the assessor will look at what the device can actually do with the session.

Local storage: The endpoint must not save CUI, screenshots, clipboard content or session files to local disks or removable media.
Redirection: Drive, printer, clipboard and USB redirection must be disabled or limited so no CUI crosses into the endpoint.
Client build: The client software and the thin or zero client image should be locked down so users cannot change these settings.
Proposed FAR treatment: The June 2026 FAR overhaul proposed rule would list VDI client endpoints limited to keyboard, video and mouse traffic as out of scope under FAR 52.240-7. This is a proposal, not a final rule, so do not rely on it until it is final.

Confirm with your assessor how they will test the endpoint configuration and what evidence they expect, such as client settings exports and redirection policies.

Requirements that make the isolation hold

An enclave limits scope only if the boundary, the information flows and the inventory of CUI locations all hold up under testing. The three requirements and the evidence below are what an assessor will check first, and each one must be documented in the system security plan.

Boundary protection (03.13.01)

This requirement covers monitoring and controlling communications at the external and key internal boundaries, using managed interfaces and separate subnetworks for CUI components. Isolation depends on it: if CUI components share a flat network with general business systems, the separation claim fails. Ask the assessor to see the boundary diagram, the rule set on each boundary device, and the change records showing who approved each rule. Confirm that the boundary devices are the ones the SSP names.

Information flow enforcement (03.01.03)

This requirement asks the organization to control where CUI can flow once it is inside the enclave, including what leaves it and what enters it. A separate network does not stop a user from copying CUI into an email to a general system. Assessors typically test this by trying an unapproved transfer path and reviewing the rules that block it. Document each approved flow, such as a secure file transfer route, and show the control that enforces it.

CUI location documentation (03.04.11)

This Rev. 3 requirement, new in this revision, asks the organization to document where CUI is processed and stored. It is the requirement that connects the enclave boundary to a real inventory. An assessor will compare the documented locations with what is found in the environment, including backups, endpoints and any cloud storage. Any location missing from the record weakens the scope decision for the whole enclave.

System security plan boundary description

The system security plan (SSP) must describe the system boundary, the components inside it and how they are separated from the rest of the environment. Under Rev. 3, the planning requirement 03.15.02 makes the SSP the central record that assessors read first. Check that the SSP names each boundary device, subnetwork, information flow path and the authority responsible for each security domain. A boundary that the SSP does not describe will not be credited in an assessment.

Component and asset inventory

An inventory lists every component inside the enclave and every component that connects to it, with owner, location and function. The inventory is what proves that out-of-scope assets are truly separated, because the organization must justify each separation claim. Ask for a reconciled inventory, with a dated review showing that new systems were classified before they were connected. Gaps between the inventory and the network diagram are a common finding in assessments.

How to justify separation to an assessor

An asset outside the CUI boundary is only out of scope if you can show it cannot process, store or transmit CUI. Under 32 CFR 170.4 and 170.19(c), the organization must be ready to justify that separation, and the exclusion does not extend to assets that provide security protection for CUI assets. A firewall, identity provider, logging collector or endpoint management server that protects the enclave stays in scope even if no CUI ever touches it. Before you draft any scoping claim, list every system that sits on the enclave's boundary or supports its administration and classify each one as a CUI asset, a security protection asset or an out-of-scope asset. Confirm the classification approach with your assessing body early, because the reasoning behind it will be tested.

The evidence an assessor expects is mostly architectural and operational. Start with a current network diagram that shows the subnetworks, firewalls and other boundary devices that separate the enclave, along with a data flow diagram that records where CUI enters, is processed and is stored. Pair these with flow records or firewall rule exports that show information flow enforcement in practice, and with configuration baselines for the boundary devices. Access reviews for accounts that can cross the boundary, such as administrators and remote maintenance users, show who could move CUI out of the domain. For a VDI or cloud arrangement, retain the client configuration showing that only keyboard, video and mouse signals leave the endpoint, along with the provider's customer responsibility matrix. Ask your assessor which artifacts they want and in what format, and check each one against your own environment before relying on it.

How to scope an enclave before you build it

This sequence turns a general wish to limit CUI obligations into a documented boundary that an assessor can test. Each step produces an artifact, from the CUI data map to the scope statement handed to the independent assessor.

Map where CUI lives today
Start by finding every place CUI is created, received, processed, stored or transmitted, including email, file shares, collaboration tools, backups, printers, laptops and contractor-held copies. Owners of the contract and the data should sign off on the list, because teams often miss copies made outside the main system. The output is a CUI data flow map that shows each source, path and destination. The step is done when a system owner can trace every CUI flow on the map to a named system.
Designate the CUI components
Mark each system, device and service that processes, stores or transmits CUI as a CUI component, then mark each component that protects those components, such as identity, logging and monitoring tools. SP 800-171 Rev. 3 applies only to components that handle CUI or protect those that do, so this designation decides what the requirements touch. The output is a written component list with a role for each entry. Confirm the classification with the assessor's current rules before you rely on it.
Draw the security domain boundary
Decide how the CUI components will be separated from everything else, using separate subnetworks, firewalls or other boundary devices, information flow controls, or a combination of physical and logical separation. Name the single authority that administers the domain, since a security domain is defined by one administering authority and one security policy. The output is a boundary diagram with every entry and exit point labeled. The step is done when the network team can explain each allowed flow and why it is allowed.
Classify assets against the boundary
Sort each asset inside and near the boundary into the CMMC Level 2 asset categories: CUI assets, security protection assets, contractor risk managed assets, specialized assets and out-of-scope assets. For each out-of-scope claim, record the physical or logical separation that prevents CUI from reaching the asset, because you must be ready to justify it. Check cloud services, external providers and VDI endpoints against their specific rules. The output is an asset register with a category and a justification for each row.
Document the SSP and asset inventory
Write the system security plan so it describes the boundary, the components inside it, the separation method, the external services and the customer responsibility matrix for any cloud provider. Pair it with the asset inventory and the CUI location record that shows where CUI is processed and stored. The output is a current SSP that matches the diagram and the register. The step is done when every boundary claim in the SSP points to a diagram element or register entry.
Test the boundary and its controls
Attempt the flows the boundary is supposed to block, using firewall rule reviews, traffic captures, access tests and a check of information flow policies. Confirm that the configuration matches the diagram and that logs record allowed and denied flows. Record every failed test as a finding with an owner and a fix before the scope is final. The output is a dated test record with results, retest evidence and any open items. The step is done when each boundary claim has a test result behind it.
Hand the scope to an independent assessor
Give the assessor the boundary diagram, asset register, SSP, test record and the justification for each out-of-scope asset, then agree on the assessment scope in writing before the assessment begins. The organization owns the scope decision, and only an independent assessor or certification body reports on the result. Ask the assessor which evidence they expect and whether they accept your separation method. The output is a signed scope statement that the assessment team has reviewed.

Enclave, whole-environment or hybrid: which option fits

This table compares a dedicated CUI enclave, bringing the whole environment into scope, and a hybrid where users reach CUI through VDI. Read each row against your contract's systems and your ability to justify separation to an assessor, and confirm the details with your assessor before committing.

Option	When it fits	What is assessed and trade-offs	Evidence each option needs
Dedicated enclave	CUI lives in a small set of systems that can be separated by subnetworks, firewalls or other boundary devices with defined information flows.	Only the separated CUI components and the assets that protect them are in scope under the SP 800-171 Rev. 3 section 1.1 approach. Trade-off: the separation itself must be designed, administered and defended.	Boundary diagram, firewall and information flow rules, a security domain definition, and documented justification for each out-of-scope asset.
Whole environment in scope	CUI is spread across the organization, separation is impractical, or the organization prefers one set of controls to apply everywhere.	All components that process, store or transmit CUI, and the security protection assets around them, fall into scope. Trade-off: the largest assessment surface and the most SSP content to maintain.	System security plan covering all in-scope components, complete requirement evidence across the families, and a current component inventory.
Hybrid with VDI for users	Users need occasional access to CUI from endpoints the organization does not want to hold it, and the CUI stays on hosted systems.	An endpoint is out of scope only when configured so that no CUI goes beyond keyboard, video and mouse signals. Trade-off: the hosted environment stays in scope and the endpoint configuration must be proven.	VDI configuration showing no file transfer, clipboard or storage of CUI on the client, plus evidence on the hosted side and the SSP entry.
Cloud service in the boundary	A cloud provider stores, processes or transmits CUI for the organization.	A CSP that handles CUI must meet FedRAMP requirements in DFARS 252.204-7012, and on-premises infrastructure that connects to it stays in scope. Trade-off: shared responsibility must be mapped.	Provider's FedRAMP evidence, the customer responsibility matrix documented or referenced in the SSP, and on-premises connection diagrams.
Contractor risk managed assets	Some assets could handle CUI but are kept from it by policy and procedure rather than by separation.	These assets are reviewed through the SSP and do not need physical or logical separation. Trade-off: the policy must be enforced and documented well enough to survive assessment.	Written policy and procedures, technical or administrative controls that enforce the restriction, and SSP descriptions.
Assessor agreement	Any option that depends on a separation or out-of-scope claim.	Out-of-scope status must be justified, and the organization must be ready to defend it. Confirm with your assessor which evidence they will accept for separation and VDI configurations.	Written scoping rationale and a walkthrough of the boundary with the assessor before the assessment begins.

Common reasons an enclave does not reduce scope

An enclave only limits scope if the isolation holds in practice. The six patterns below are where assessors most often find CUI outside the domain, and each card names the step that keeps the boundary defensible under the scoping rules.

CUI leaking into email, shares and backups

Engineers often copy CUI into a corporate mailbox, a general file share or a backup job that sits outside the domain. Any system that processes, stores or transmits CUI becomes in scope, so the enclave is only as small as its least controlled copy. Inventory every repository where CUI could land, block or tag transfers out of the domain, and confirm backups of the enclave stay inside it.

Shared administrators across both sides

When the same administrators manage the enclave and the general corporate network, the two sides are not under separate authority. A security domain is defined as one administered by a single authority, so shared administration weakens the argument that the domains are separate. Give enclave administration its own accounts, credentials and change approval, and document who can reach each side.

VDI clients that move data

A virtual desktop endpoint can become a path for CUI if it allows file transfer, clipboard sharing, local printing or client-side storage. The out-of-scope treatment for VDI applies only when the endpoint carries no CUI beyond keyboard, video and mouse signals. Disable redirection channels on the client, test them, and record the configuration in the SSP.

Undocumented information flows

Flows that nobody wrote down, such as an integration service that syncs a ticket field or a monitoring agent that ships logs, often carry CUI across the boundary unnoticed. Information flow enforcement and the CUI location requirement both expect the organization to know where CUI goes. Map every interface to the enclave, record the data elements and approve each flow through the boundary controls.

Cloud provider without FedRAMP equivalence

A cloud service that stores or processes CUI must meet the FedRAMP requirements the DFARS clause names, and the provider's customer responsibility matrix must be documented in the SSP. If the provider cannot show that equivalence, the service stays in scope regardless of how the enclave is drawn. Ask for the provider's authorization evidence and the responsibility matrix before any CUI is placed there.

SSP that does not match the real boundary

An SSP that describes an enclave that differs from the deployed network undermines the whole scoping claim, and assessors test the documentation against the systems. Drift often comes from firewall changes, new connectors or cloud accounts added after the plan was written. Reconcile the SSP against the current network diagrams and asset inventory on a fixed schedule, and after each boundary change.

Who owns the enclave, who builds it and who assesses it

Your organization remains accountable for the enclave and for every NIST SP 800-171 requirement that applies to it. Scoping decisions, risk acceptance, the system security plan, and the statements made to the contracting agency all sit with your leadership, even when outside specialists do much of the technical work. NIST states that application and implementation of SP 800-171, and any compliance issues, are the responsibility of the federal agency that holds the contract or agreement with the nonfederal organization, so the contract terms set the bar you are held to.

Scope decisions: Deciding which components process, store or transmit CUI and which are separated from them is an internal call that you must be able to justify.
Policies and procedures: Rev. 3 turns foundational policy and procedure controls into requirements, so your staff must own and approve them.
Personnel actions: Screening, access removal and security training are performed by your HR and security staff.
Daily operation: Monitoring, patching, access reviews and incident handling continue after the build, and they are your job.
Contract statements: Your officers sign the attestations and scores you post, so they need to understand what the evidence shows.

Before engaging any partner, confirm with the contracting officer which revision of SP 800-171 applies to your contract and which assessment path it triggers.

Questions buyers ask about NIST 800-171 enclaves

Does a NIST 800-171 enclave always reduce compliance cost?

No. An enclave reduces the number of assets that must meet the full set of requirements, but it adds cost of its own. Under the scoping rules in 32 CFR 170.19(c), assets that are physically or logically separated from CUI systems and cannot process, store or transmit CUI can be out of scope, but you must be ready to justify that separation. The main costs are the subnetworks, firewalls or other boundary devices, the identity and administration the enclave needs, duplicate tooling, and the evidence that the separation holds over time. Savings depend on how many systems you can move outside the CUI boundary and how often people and data need to cross it. Ask any quote to separate one-time build work from recurring operation, and to list which assets remain in scope.

What does an enclave project need from our internal team?

Your team still owns the controls, even when an implementation partner designs and builds the enclave. NIST defines a security domain as one that implements a security policy and is administered by a single authority, so the organization has to name that authority and staff it. In practice the internal team needs to provide:

A named owner who approves the enclave boundary, access model and changes to it.
Administrators who run identity, firewall rules and change control inside the enclave.
Reviewers who approve access requests and perform periodic access reviews.
An owner for the system security plan, plan of action and evidence files.

DeployOpen prepares systems, documentation and evidence for these roles, but it does not make the organization's control decisions for it. Confirm these roles and their time commitments in the written scope before work starts.

Is VDI alone enough to keep CUI out of scope?

VDI alone is not automatically enough. Under 32 CFR 170.19(c), an endpoint hosting a VDI client is out of scope only when it is configured so that no CUI is processed, stored or transmitted beyond the keyboard, video and mouse signals sent to the client. If users can download files, print, copy to the clipboard, map local drives or cache data on the endpoint, that endpoint and its data path can fall back into scope. The virtual desktop infrastructure in your data center or cloud also remains a CUI asset that must meet the relevant requirements. The proposed FAR overhaul of 23 June 2026 would make such VDI endpoints out of scope under FAR 52.240-7, but that rule was not final as of October 2026. Test the endpoint configuration directly and document the results in the system security plan.

How are cloud providers handled in an enclave's scope?

A cloud service provider that stores, processes or transmits CUI must meet FedRAMP requirements equivalent to the FedRAMP Moderate baseline, as DFARS 252.204-7012 requires for external cloud providers that handle covered defense information. Under 32 CFR 170.16(c)(2), your on-premises infrastructure that connects to the cloud service stays in the assessment scope, and the provider's customer responsibility matrix must be documented or referenced in the system security plan. Services from a non-cloud external provider that handles CUI are assessed within your scope. A provider that handles only security protection data is assessed as a security protection asset. Before you move CUI into a cloud enclave, request the provider's FedRAMP authorization details and its responsibility matrix, and confirm with your contracting officer which provider assessments apply to your contract.

How long does enclave scoping take?

How long scoping takes depends on the scope. The main drivers are the number of systems that touch CUI, how many data flows cross into and out of the enclave, whether your network is already segmented, how complete your existing asset inventory and data-flow documentation are, and how many external providers and subcontractors are involved. A narrow enclave around one application with documented flows will move faster than an enclave that must separate shared identity, email, backup and administration services. Ask for the scoping steps, the decisions that need your sign-off, and the deliverables in the written scope, so you can see which steps depend on your team's availability. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

Who issues the assessment result for an enclave?

Only an independent assessor issues the assessment result. For a DoD contract that is a Government assessment or a CMMC third-party assessment, depending on the requirement that applies. DeployOpen prepares the enclave, the documentation and the evidence that an assessor reviews, but it does not issue reports, attestations or certifications, and no partner can promise a particular outcome. Assessors test the enclave boundary against the determination statements in SP 800-171A, and they typically look for the boundary design, firewall and flow rules, access reviews, and the documented location of CUI under requirement 03.04.11. Confirm with your contracting officer which assessment applies to your contract and what evidence that assessment expects before you finalize the design.

How DeployOpen scopes and prepares an enclave

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so a CUI enclave is built in the environment you control. We scope the boundary in writing first, then prepare the isolation, controls and evidence that an independent assessor will examine. We do not issue assessment reports or certifications; that decision stays with your assessor.

How we scope

Engagements are fixed-scope, with the enclave boundary, deliverables and timelines agreed in writing before work starts.
We map which systems process, store or transmit CUI and which only protect those components, so your scope statement is grounded in your architecture.
We document each asset's role, separation method and justification, and identify cloud or external providers whose responsibilities must be recorded in your SSP.

How we build

We implement the enclave boundary with separate subnetworks, managed interfaces and information flow controls matched to the separation you choose.
We configure access, logging, encryption and remote access inside the enclave, mapping each setting to the NIST SP 800-171 requirement it supports.
We test the isolation itself, checking that traffic leaving the enclave is limited to what the scope statement allows.

How we hand over

You receive the enclave architecture, boundary diagrams, configuration baselines and the system security plan sections describing the isolation.
We provide evidence packages organized by SP 800-171A determination statement, showing where each artifact is generated and where it is retained.
We walk your security and compliance staff through the handover so your team can explain and defend the boundary to an assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover re-testing the enclave boundary after changes to networks, cloud accounts or VDI configurations.
Confirm with your assessor and contracting officer which revision of SP 800-171 and which ODP values apply before the scope is finalized.