CUI on a Shared HPC Cluster: Meeting NIST 800-171 Without Fencing the Whole Machine

The email is short. A collaboration has been agreed, an agreement has been signed, and the transfer starts next month. Somewhere in the attachments is a paragraph saying the data is controlled unclassified information and must be handled to NIST SP 800-171. Nobody on that thread asked what it would mean for the machine the data is about to land on, because the machine was never part of the conversation.

That is the shape of it almost every time. The conditions arrived with the data. The cluster was not built for them.

What happens next is usually one of two things, and both are bad. Either the data gets refused and the research moves to a workstation under somebody's desk where nobody will ever assess it, or somebody proposes applying the new rule to the entire system. The second sounds responsible. It is the more expensive mistake.

How CUI lands on a research cluster

CUI is a US federal designation for information that is not classified but that the government requires to be safeguarded, and the requirement travels with the data to whoever is holding it. It rarely arrives as its own project. It arrives attached to something else: a subaward on a defense-funded program, a partner who is themselves under contract, a modeling collaboration that turns out to include design data somebody else owns.

The obligation attaches to the data, and to every copy of it. That matters here because a cluster makes copies for a living: you stage the input, a job writes intermediate state to scratch, someone pulls a slice down to look at it, a collaborator asks for the results.

And the machine it lands on was designed, correctly, for the opposite priority. Hundreds of users on the same login nodes, queuing through the same scheduler. Open research and regulated data on the same parallel filesystem. Software researchers install themselves, compiled on the box, run by the person who wrote it. Accounts that outlive the project, because the funding ends and the login usually does not.

None of that is neglect: it is what a shared research facility is for, and why it can serve a hundred groups at the cost of one machine. But every one of those properties is an answer to a question an assessor is about to ask, and none of the answers is the one they want. CUI is the version of this that gets written about, because the contract language is explicit and the assessment regime is real. The pattern is identical for the rest of what these machines carry, from controlled-access genomic data to export-controlled research, which we come back to below.

The scoping mistake

The usual mistake is to apply your strictest rule to the whole machine. It costs a fortune, it slows everyone down, and it does not make the sensitive data any safer. The third one is the one that should end the conversation.

It costs a fortune because almost every cost on a cluster multiplies by node count or user count. Endpoint licensing and its telemetry, per-host log ingestion, storage encrypted and inspected on every operation, a scanning regime run against thousands of nodes provisioned from one image. You are buying all of that for the part of the machine that will never touch the regulated dataset.

It slows everyone down because those controls have a throughput price, and on a tightly-coupled machine that price is paid by whoever happens to be running. The open research groups whose grants bought a share of this system pay for it, in queue time and in wall-clock, for a dataset they are not allowed to read.

And it does not make the sensitive data safer, which is the part that matters. The regulated data is still on the same filesystem, still reachable by the same accounts, still stageable to the same scratch, still exportable through the same data transfer path. You have spent the budget on breadth and none of it on the boundary, and the boundary is the control. The whole-machine proposal rarely survives contact anyway: the HPC team refuses it, the security team cannot approve the alternative, and six months later the difference is sitting in the risk register.

The enclave pattern

An enclave is a separately scoped environment inside the shared machine, built around the regulated work rather than around the hardware. It is not necessarily a second cluster, and treating it as one is how sites end up buying a system that sits idle. Four properties define it, and each of them answers a different kind of question.

Its own logins

The first question anyone assessing this will ask is who has access to the data. On a shared cluster the honest answer is a database query with three caveats attached, and an assessor is right not to accept it. The enclave replaces that with a roster: a separate access path, enrollment as an explicit act with a named approver and a recorded date, multi-factor enforced at that door, and credentials that expire on their own rather than static keys that travel between institutions with the people who hold them. Removal has to be an act too, because the failure mode here is not a break-in, it is the account that outlived the grant by four years. SP 800-234 gives user sessions, and access to HPC, their own groups among its tailored controls, and the single control it adds to the SP 800-53B moderate baseline is AC-10, concurrent session control.

Its own storage

This is the property that does the real work, and the hardest one to retrofit. The parallel filesystem is the machine's center of gravity: everything stages through it, and its performance comes precisely from not asking many questions. The enclave needs its own project space, scoped to the project rather than to individuals, with root-squash on the exports so a compromised client cannot walk the tree as root. It also needs a stated tiering policy, because the fast scratch tier is usually not backed up on purpose, and a regulated dataset with an undeclared copy on scratch is the most common way a clean architecture stops being clean. The rule that keeps it honest: regulated data has one home, and every path that could write it somewhere else is either closed or is the approved egress route.

Its own way out

Results leaving is the moment the obligation is either kept or broken, and it is the property teams design last. On a research machine there are usually several ways out: a data transfer node, a web portal, a filesystem someone mounts elsewhere, a collaborator with an account. The enclave has one, through the access zone, which is the part of the architecture that exists to authenticate and authorize connections in the first place. SP 800-223 notes that a ScienceDMZ architecture is often used for data transfer nodes rather than a pass-through firewall, because of the firewall's performance impact, so the design question is where you place the decision, not whether you can inspect everything on the way past. What makes it defensible is that a release is an event with a record: what left, to whom, and who approved it.

Its own nodes, when it needs them

This is the property to add last, and rarely in the form people first imagine. A scheduler partition reserved for the enclave's jobs is frequently enough, provided nodes are sanitized between tenants, which SP 800-223 treats as a posture recommendation in its own right. Where the obligation or the classification demands genuinely separate hardware, buy separate hardware and say so. The case that deserves real attention is accelerators: SP 800-234 gives shared GPUs and accelerators a group of their own among the fourteen it sorts its tailored controls into, because a device's memory is state that outlives a job unless something clears it.

What the obligations actually ask for

NIST SP 800-171 sets out requirements for protecting controlled unclassified information when it lives on systems that are not federal systems, which is exactly where a university, a research hospital or a supplier stands when that dataset arrives. Where the work is funded by the Department of Defense, the assessment regime on top of it is CMMC, which reaches an organization through the contracts and funding instruments that carry the requirement rather than through what kind of organization it is.

You will notice this post names no requirement numbers, and that is deliberate. The text that binds you is the text in your award, read against your architecture, and that reading is work for you, your contracting office and whoever assesses it. What a cluster team can do beforehand is answer the kinds of question those requirements are made of, which is what the four properties are arranged around.

Access: who may reach this data, how they were granted it, and how you would prove that on request. Storage: where it rests, what protects it there, and where else a copy could legitimately exist. Egress: what may leave, by which route, and who authorized the release. Isolation: what else shares the machinery, and what the machinery retains after a job finishes. Every regime that lands on research data asks these four things, in a different vocabulary and a different order.

The enclave does not answer them by itself. What it does is make the answers producible. The boundary turns "who has access" into a list rather than an argument, turns "where is the data" into a path rather than a search, and turns "what left" into a record rather than a reconstruction.

The deemed-export adjacency

A second obligation arrives on the same machines and behaves differently, and it catches people who have done the CUI work properly. Export-controlled research sits under ITAR and EAR, and those regimes treat access itself as the regulated event: releasing controlled technology to a foreign national can count as an export even when nothing leaves the country and nobody leaves the building. On a shared cluster, access is the whole product. Hundreds of accounts, an international research population by design, and administrators who read the storage as a condition of doing their jobs.

That extends the roster question from the first enclave property. It is not only the people who compute in the enclave: it is the people who administer it, back it up, restore it, debug the filesystem at two in the morning, and hold the vendor support contract. On a research system those roles are frequently filled by students, postdocs and contractors.

Two things here belong to someone else, and it is worth being blunt about both. Whether a project qualifies as fundamental research, and what any specific authorization requires, is a determination your institution's export control or research security office makes, not one an architecture makes. What the cluster owes that office is a truthful account of who can reach what, and an architecture that can enforce whatever determination comes back: the same four properties, with the administrative roster added to the first.

Where the zones come in

The enclave pattern can be described precisely, rather than site by site, because the machine now has a shared vocabulary.

NIST SP 800-223, High-Performance Computing Security: Architecture, Threat Analysis, and Security Posture, finalized on 9 February 2024, divides an HPC system into four function zones: the high-performance computing zone, where the compute nodes and the interconnect live; the data storage zone, the parallel and archival filesystems; the access zone, which holds the login nodes, data transfer nodes and portals and authenticates and authorizes everyone who arrives; and the management zone, which carries a separate security posture on networks not routed beyond the perimeter.

It is also where CUI meets HPC in NIST's own text, though only briefly. Its data storage zone threat analysis observes that data held on an HPC system may include PII, PHI and CUI, and that such data may require compliance with standards such as HIPAA and NIST SP 800-171. That is a passing compliance reference rather than an architecture for meeting those standards, and SP 800-223 is explicit that it is a conceptual guide rather than a checklist of requirements.

NIST SP 800-234, the High-Performance Computing (HPC) Security Overlay, finalized on 4 May 2026, is the one that carries controls. It takes the SP 800-53B moderate baseline as its base and tailors on top of it: 288 controls in its table, 287 carried from that baseline plus AC-10 added, of which 60 are tailored with supplemental guidance, discussion or both, sorted into fourteen thematic groups. The detail that matters here is that the tailoring is applied at five levels: the whole system, and then each of the four zones separately, so one control can mean one thing at the access zone and something else inside the computing zone. That is the granularity an enclave argument needs, because an enclave is a statement about zones rather than about hardware.

SP 800-234 also expects to be customized rather than adopted verbatim. Its introduction gives two examples: a system supporting multi-tenancy may need its own overlay developed from this one, and a system at a high baseline can be expanded with additional controls. An enclave carrying a stricter obligation than the rest of the machine is that situation exactly: one system with two postures inside it.

We have written up both publications in full: NIST SP 800-223 for the reference architecture and threat analysis, and NIST SP 800-234 for the overlay and its sixty tailored controls. If the argument in your queue is about individual controls rather than about scope, the companion to this post walks ten of them: why enterprise security controls break on HPC. And if a dataset with conditions attached is already on its way to a machine that was not built for it, designing the enclave is the work our HPC security practice does, so one dataset does not drag the whole machine into the strictest rule you carry.