Clarion Street

CUI's Last Mile: Shipping Controlled Data to the Shop Floor

·5 min read

For most of the CMMC conversation, Controlled Unclassified Information is an office problem. It lives on desktops and file shares, and the enclaves people build for it sit in a server room next to the network gear. The parts those enclaves describe get made somewhere else, on a shop floor, by machines that in a lot of shops can reach a file share exactly one way: SMB.

That gap is real and it is mostly physical. A CNC controller has no browser and no API that speaks OIDC. It reads programs off an SMB share and drops its output somewhere. The controller may speak only SMB2, or SMB1, and hold no password at all. Getting controlled data to it, and getting its output back under control, is the specific problem Open-CMMC v2.0 is aimed at.

Open-CMMC v2.0.0, released September 21, 2026, is an attempt to close that mile. Open-CMMC is the Apache-2.0 fork of filebrowser/filebrowser that Trout Software turned into a single-binary CUI enclave for CMMC Level 2. I have written about the enclave before. What is new in v2.0 is that it now reaches the shop floor: an opt-in feature that sends NC programs to CNC and OT machines over SMB and takes their output back, on the same host, with no second appliance. The install flag is --with-smb --ot-ip <address>.

The mechanics

The design starts from what the floor will actually accept. The cabinet itself is never exported. A Samba container serves two host directories on an OT-side interface only. One is a read-only “out” share per cell, holding released programs. The other is a per-machine write folder for returns. The host does not forward between the OT interface and the LAN, and a firewalld zone admits only the inventoried machine addresses.

A released file is decrypted from the cabinet, written with a manifest that records the SHA-256, the CUI mark, the actor, a timestamp, and an expiry, logged as file.release.ot, and expired after a per-cell TTL of thirty days by default. ITAR-marked files go only to ITAR-designated cells. Returns are quarantined, passed through an allow-list gate (extension, size, daily quota, no executables, no archives, text only), scanned by ClamAV, and only then filed back under the cell’s CUI mark. The feature refuses to run the return path without antivirus in required mode.

The honest part

The Open-CMMC docs do not claim the hop is encrypted end to end. They state that the Samba container is a non-validated cryptographic module. NTLMv2 requires MD4, which the FIPS-mode host refuses, so the shop-floor hop does not get FIPS-validated confidentiality from the tool. The docs name what stands in for it.

The architecture doc scopes the CNC controllers as Specialized Assets, Operational Technology, under 32 CFR 170.19(c)(1). They are inventoried, described, and drawn on the network diagram, not scored control by control. For the plaintext SMB hop, the docs cite 3.13.8’s “alternative physical safeguards” clause, which in their framing means the cell attests a Protected Distribution System: cabling in conduit or locked cabinets, a dedicated switch, no wireless, and controlled access to the cabinet. You file photos and a labeled diagram with the SSP. For controllers too old to do anything else, the docs invoke the SMB1 enduring exception under 32 CFR 170.4, isolated to the legacy listener over a PDS. Whether an assessor accepts that scoping is a separate question the docs leave to you.

A vendor publishing the exact place where its cryptography does not hold, and then naming the compensating control, is rare. A C3PAO can read the source and the scoping notes instead of taking a claim on faith. That candor is the inspectable-enclave argument made concrete.

The catch

The tool does not make the deployment compliant. It generates the SSP rows. cmmc-smb ssp-table prints the asset inventory, the crypto-module disclosure, and the enduring-exception statement. The compliance itself is the contractor’s documentation: the photos, the diagrams, the attestation that the cabinet is locked. If you will not attest a PDS, the loader refuses to run no-password machines. Open source removed the seat tax and handed back a physical-security documentation obligation.

I have a few reservations, the same ones that apply to the project as a whole. v2.0.0 is a day old, the repository shows thirteen stars and two forks, and there is no independent assessment of the SMB path yet. Trout Software is a commercial OT-security vendor that sells a product, Access Gate, in front of this enclave, so I read the blog as marketing and the repo docs as the substance. The coverage claim has also moved. The September blog says “~75 of 110” controls; the v2.0 compliance-posture.md says 59 direct, with a warning that a control counted there is not automatically one you can evidence on your own deployment. The SMB hop is deliberately non-FIPS. The docs argue that is acceptable under 32 CFR 170, but that is the vendor’s reading, and it is exactly the nuance an assessor will press on.

Bottom line

The useful thing here is a worked example of honest CMMC scoping when controlled data has to reach a machine that can only do SMB. You do not pretend the controller is a CUI asset and score it control by control. You do not claim encryption the protocol cannot deliver. You treat the controller as a Specialized Asset, you attest a protected physical path, and you write the non-validated module and the SMB1 exception into the SSP with their subjects named. Most of CMMC is deciding what a control actually applies to and saying so on paper. This release is that decision written down, including the part the software cannot cover.

Sources

  1. Open-CMMC v2.0.0 release notes (GitHub)
  2. Shop-floor SMB delivery (Open-CMMC docs)
  3. Architecture (Open-CMMC docs)
  4. Compliance posture (Open-CMMC docs)
  5. Introducing Open-CMMC (Trout Software)
  6. TroutSoftware/Open-CMMC (GitHub)