The short version
A cloud CUI enclave solves storage, processing and collaboration. It does not solve the moment a controlled drawing has to become a physical part.
That last hop, enclave to printer, enclave to CNC, enclave to test bench, is almost always bridged by a person downloading a file to a laptop. At that instant the CUI leaves the boundary you assessed and lands on a device with a different control set, and the gap between the System Security Plan and the observable behaviour of the shop floor opens up.
The architecture below closes it: a FIPS 140-3 validated tunnel from the enclave into an on-site protocol-aware proxy that sits in front of the equipment, so the controlled path runs to the machine and back, with nothing installed on the machine.
Why the last hop is hard
Three properties of production equipment make it resistant to everything an enclave assumes:
- It cannot authenticate. Machine tool controllers, network printers, coordinate measuring machines and bench instruments mostly predate the idea that a device should prove who it is. No agent to install, often no certificate store, no path to MFA. The enclave's identity model has nowhere to land.
- It cannot be changed. The controller is validated as part of a process. Touching its configuration can invalidate a qualification, and in regulated manufacturing the cost of revalidation dwarfs the cost of the control you were trying to add.
- It is reached by protocols that assume a trusted network. LPD and IPP for print, FTP and SMB and vendor-specific transfer for machine tools, raw sockets for much instrumentation. None were designed for a hostile network and none carry identity.
- It is physically accessible to people who are not in your directory. Contractors, calibration technicians and OEM service engineers stand in front of these machines. Whatever control you add has to survive someone with hands on the panel and a USB port.
So the two usual answers both fail, and they fail differently. Downloading to a laptop moves CUI onto an endpoint nobody scoped. Extending the VPN to the plant converts a narrow requirement, move this file to that machine, into broad network reachability that is hard to bound and worse to document.
How the three approaches compare
| Download to laptop | Extend VPN to plant | Brokered through a proxy | |
|---|---|---|---|
| Where CUI comes to rest | An endpoint outside the assessed boundary | Wherever the operator saves it | Nowhere; it is never written down en route |
| What the far end can reach | Whatever the user can reach | The subnet, and onward | One asset, one protocol |
| Identity checked against | The laptop's own login | The tunnel, once, at connect time | Every session, before the asset is touched |
| Works on a device that cannot authenticate | Only because a person carries the file | No, the device still trusts the network | Yes, enforcement sits in front of it |
| Evidence produced | None | Connection logs, not actions | Per-session record of what was done |
| Return path for derivative CUI | Undefined, usually a shared drive | Undefined | Same path, reversed |
| How it reads in an SSP | An exception you would rather not write | A large boundary that is hard to justify | One documented path per asset |
The architecture
Four elements, in order along the path.
1. The enclave holds the CUI. Nothing changes about how the enclave is built or assessed. It remains the system of record for controlled data and the place users work.
2. A FIPS 140-3 validated tunnel carries it. A site-to-site tunnel runs from the enclave to the on-site appliance, and it is worth being precise about which component holds the validation. On the appliance, an AlmaLinux VM builds and maintains the VPN, using the Kernel Cryptography Module for AlmaLinux 9 (CloudLinux Inc., TuxCare division), FIPS 140-3 Overall Level 1, under CMVP certificate #4750, validated 2 August 2024 and updated 7 August 2025. Access Gate runs as a separate VM on the same appliance and does the proxying described below.
That split matters for the paperwork. The requirement in play is SC.L2-3.13.11, employ FIPS-validated cryptography to protect CUI in transit, and it attaches to the cryptography carrying the data, not to the proxy deciding who may send it. Keeping the two functions in separate VMs means you can point an assessor at the component the control is actually about.
State it in that shape, because that is the shape an assessor can check: name the module, name the certificate, and claim that the product uses a validated module. NIST validates modules and issues certificate numbers, it does not certify products, so "FIPS certified" is a phrase that will cost you credibility in the room.
3. A protocol-aware proxy terminates the session on site. This is the load-bearing element. The proxy does not route the enclave onto the plant network, it terminates the session and opens a separate, constrained one to a single device. It understands the protocol in use, so authorization is expressible as "this identity may send a print job to this printer" rather than "this subnet may reach that subnet on port 9100". The session is recorded at the protocol level.
4. The device receives the job unchanged. No agent, no firmware change, no reconfiguration. From the machine's point of view a normal client on the local network sent it a normal job.
This is the shape of the Trout Software and CUI Vault integration. CUI Vault, from NtelSec, runs the enclave as a managed Microsoft GCC High environment, Access Gate runs the appliance in the plant or the lab, and the two connect natively, so neither side needs per-site engineering to open the path.
The consequence worth stating plainly: CUI never rests on an intermediate workstation. There is no download step to describe, restrict or monitor, because there is no download.
The return path, which is where the gap usually is
Most designs of this shape are drawn left to right and stop at the machine. That leaves the more awkward half undefined.
Equipment produces output. Inspection results, CMM measurement files, as-built records, process logs. When that output derives from controlled technical data it is commonly derivative CUI, and it is created outside the enclave, on a device with no controls, often landing on a shared folder or a USB stick because nobody specified anything better.
The same path runs in reverse. The proxy collects output from the device and returns it into the enclave, under the same identity model and the same recording. The record of what was built ends up stored under the same controls as the drawing it was built from.
If you take one architectural point from this post, take that one. A CUI journey specified only in the outbound direction is a boundary with a hole in it, and it is the hole nobody notices until an assessor asks where the inspection reports live.
Enduring exceptions, used correctly
There is a temptation to claim the CNC now "meets" the access control requirements. It does not, and writing that down is how an SSP becomes something you cannot defend in an assessment.
The honest construction is the opposite. The asset cannot meet the practice as written and will not be able to. That is what an enduring exception is for: a documented, persistent inability of a specific asset to satisfy a requirement, recorded with the compensating control that manages the resulting risk. The proxy is the compensating control. It is what enforces identity, least privilege and recording on behalf of an asset that can do none of those things itself.
Two things make this hold up under scrutiny:
- The exception names the asset and the requirement, not a general category. "Legacy equipment" is not an exception, it is an excuse.
- The compensating control is evidenced, not asserted. Because the proxy sits in the path, it produces the evidence as a by-product: who connected, to which device, over which protocol, when, and a replayable record of the session. That is materially stronger than a policy statement about how the machine is used.
One SSP instead of two
The organizational payoff is documentation, and it is bigger than it sounds.
Without this integration, a defense manufacturer typically maintains a cloud enclave with one boundary, one control set and one assessment, and a shop floor that is either out of scope by assertion or in scope and poorly described. The connection between them is a person with a laptop, which appears in no diagram.
With it, the boundary is continuous and the diagram is honest: enclave, validated tunnel, proxy, asset, and the return path. It is one System Security Plan describing one path, with the exceptions named where they genuinely exist and the compensating controls evidenced where they apply.
Where this fits in CMMC
Level 2 is where most of this conversation happens, and the architecture is aimed squarely at the access control and audit families that an assessor will spend time on.
Level 3 layers a subset of NIST SP 800-172 enhanced requirements on top, for the highest-priority programs. Those requirements push toward stronger isolation of CUI, tighter control over what may reach it, and better evidence of both. An architecture in which controlled data never lands on an intermediate endpoint, every transfer is bound to an identity, and every session is recorded, is pointed in that direction. Scope the specifics with your assessor rather than assuming a clean mapping; the useful claim is about the direction of travel, not a checklist.
A note on timing, since it changes the urgency and not the requirement: CMMC Phase II was suspended in July 2026, so no third-party certification deadline is currently forcing the calendar. The underlying NIST SP 800-171 and DFARS obligations did not go anywhere. The controls still apply, and the last hop is still where most programs are quietly out of conformance with their own documentation.
Related reading
- Trout Software and CUI Vault partner to extend the CUI boundary to the machine, the announcement, with the three use cases this architecture was built for.
- On-premise vs cloud enclave for CUI protection, for choosing where the enclave itself should live. This post assumes that decision is already made.
- CUI enclave architecture
- CMMC enduring exceptions for OT
- FIPS validated encryption