What a CUI enclave actually includes

Published

A CUI enclave is a small, separate environment where all work on Controlled Unclassified Information happens: its own sign-in, its own computers or virtual desktops, its own file storage, and the logging and backup that protect them, with controlled paths in and out. Everything else in the business stays outside it, and outside most of the assessment.

It’s the most common way small defense suppliers make NIST SP 800-171 achievable. Instead of bringing every laptop, server and shop-floor PC up to the standard, you bring a few systems up to it and keep CUI there.

What goes inside

Identity

A directory and sign-in with multifactor authentication for everyone who works with CUI. It can be part of your existing directory, but enclave accounts and policies are separate and tighter.

Where people work

Dedicated workstations, or virtual desktops that people reach from their everyday computers. Virtual desktops keep CUI off laptops entirely, which shrinks the boundary further.

File storage

A file server or cloud storage that holds CUI and nothing else, with access granted per project or contract.

Email, if CUI travels by email

Either an email system that meets the same requirements, or a rule that CUI arrives and leaves through a controlled file transfer instead.

Logging

Records of sign-ins, file access and administrative changes, kept centrally and actually reviewed.

Backup

Protected, encrypted copies of enclave data, tested by restoring them.

Boundary protection

Firewall rules and network separation so systems outside the enclave can’t reach in, and data leaves only through paths you’ve defined.

The systems that protect it are in scope too

CMMC’s scoping guidance sorts assets into categories. The systems that store, process or transmit CUI are obvious. Less obvious are security protection assets: the identity provider, endpoint management, logging and backup systems that protect the enclave. They’re assessed too, even if CUI never sits on them.

That’s why an enclave design starts with a diagram: every system, what it does, which category it falls in, and the lines between them. The diagram becomes the backbone of your System Security Plan.

What makes the separation real

  • People outside can’t open CUI. Not by policy alone: by permissions, network rules and accounts that simply don’t have access.
  • Paths in and out are defined. How CUI arrives from customers and how it goes back out, written down and enforced.
  • Nothing quietly crosses the line. No shared drives mapped from both sides, no synced folders, no copy-paste from a virtual desktop to a personal laptop unless you’ve decided that’s allowed.
  • It’s documented as built. The boundary diagram matches what’s actually on the network.

Cloud, on-premises or a mix

Enclaves can live in a government cloud (such as Microsoft 365 GCC High with virtual desktops), on a small on-premises system you own, or both. The choice depends on how many people need access, what kinds of CUI you handle, whether any of it is export-controlled, and what you already run. Our CMMC and CUI environments page compares the approaches.

Questions we hear

How many people should be in the enclave?

Only the people whose work requires CUI. In most small suppliers that’s a fraction of the company, often engineering, program management and a few in production or quality.

Can the enclave share our existing network?

It can share physical infrastructure, but it needs logical separation: its own segments and firewall rules, so systems outside it can’t reach in.

Does an enclave make an assessment cheaper?

Usually. Fewer systems to secure, document and assess means less work everywhere, as long as the separation holds up when someone checks.

Get new Insights by email

One email when a new article is published, about twice a month. No sales sequences. Unsubscribe any time.

We use your email only to send Insights and never share it. See our privacy policy.

Working through this yourself?

Tell us where you are and what you’re trying to get to. An engineer reads every request and replies by email.