Introducing Open-CMMC: An Open-Source CUI Enclave for CMMC Level 2

Why We Built This

CMMC Phase II was suspended on 2026-07-13, so the third-party C3PAO assessment that was due to start on 2026-11-10 is paused pending a reform review. What did not change is the obligation underneath it: any DoD contract touching Controlled Unclassified Information (CUI) still requires the 110 controls in NIST SP 800-171 Rev 2, still self-assessed and affirmed in SPRS. Manufacturers and defense suppliers we work with have been asking the same question since the Final Rule took effect: where does CUI actually live in our network, and how do we prove the storage tier is compliant?

The usual answers are either a SaaS gov-cloud tenant, which takes CUI off-premise and introduces a data-residency problem, or a patchwork of file shares with no CUI marking, no structured audit, and no crypto story. Neither is a clean answer for the defense suppliers who need to keep CUI on-site, next to the machines that produce the parts.

So we built what we wished existed: a transparent, inspectable, open-source CUI enclave that runs as a single Go binary on a FIPS-mode RHEL or AlmaLinux 9 VM and ships audit-ready. Today we're releasing it under Apache-2.0.

What Open-CMMC Is

Open-CMMC is a hardened fork of filebrowser/filebrowser, rebuilt around CMMC Level 2 / NIST SP 800-171 Rev 2 controls.

The short version:

• Single Go binary on RHEL 9 / AlmaLinux 9 / Rocky 9 with FIPS mode enabled.
• OIDC + MFA authentication, Keycloak bundled, or federate to Entra GCC-H, Okta Gov, or Ping.
• AES-256-GCM envelope encryption on every file. KEK in TPM or HSM.
• ClamAV scan-on-upload, fail-closed.
• Tamper-evident audit chain: every read, preview, mark change, admin action emits a structured event with a correlation id, chained by HMAC, forwarded via rsyslog-ossl mTLS to Splunk, Sentinel, or Elastic.
• CUI marking UI: per-folder marks (BASIC, SPECIFIED, SP-PROPIN, SP-PRVCY, SP-ITAR), admin-gated with fresh MFA required.

FIPS posture inherits OpenSSL CMVP #4774 via the RHEL / Alma go-toolset. You get a TLS-enabled file browser on port 8443, Keycloak OIDC on 8081, systemd units, firewalld rules, and envelope encryption by default, in about three minutes from extracting the release tarball.

Control Coverage

The deployed stack covers ~75 of the 110 NIST SP 800-171 Rev 2 controls:

The families with the deepest coverage are the ones the filebrowser process can enforce directly:

• 3.1 Access Control: 18 of 22 direct
• 3.3 Audit & Accountability: 6 of 9 direct (Wazuh extends the rest)
• 3.5 Identification & Authentication: 11 of 11 direct
• 3.8 Media Protection: 9 of 9 direct
• 3.13 System & Communications Protection: 14 of 16 direct

Full per-control statements are in the repo's docs/compliance-posture.md and docs/gap-analysis.md. Both are written as per-control statements, copy them into your SSP, document your ODPs, attach site-specific evidence, and hand the result to your C3PAO.

How It Deploys

There are four supported deploy shapes, pick the one that matches your environment:

1. Turnkey all-in-one: bundled Keycloak + Wazuh. One VM, install.sh deploy --with-wazuh, done.
2. Federated IdP + bundled SIEM: your Entra GCC-H / Okta Gov / Ping for auth, bundled Wazuh for monitoring.
3. Bundled IdP + federated SIEM: bundled Keycloak, forward audit to your Splunk / Sentinel / Elastic.
4. Fully federated: your IdP, your SIEM. The appliance runs only the filebrowser core.

Air-gap installs work the same way, download the tarball on an internet-connected host, scp it to the target, extract, deploy.

Why Open Source, Why Apache-2.0

Three reasons:

1. C3PAO assessors ask for source. When a control statement in an SSP says "the system encrypts CUI at rest with AES-256-GCM", the easiest way to defend that claim is a pointer to the commit where it's implemented. Proprietary black boxes force assessors to trust vendor documentation.
2. Defense suppliers are already pattern-matching on supply-chain risk. A proprietary dependency for the CUI enclave is one more thing to explain. Open source with per-release SBOM and govulncheck output in CI is not.
3. The Level 2 community benefits from shared primitives. If you fork it, harden it further, and contribute back, everyone gets a better baseline.

Apache-2.0 means no seat tax, no feature gates, no sales calls required to run it in production. Clone the repo, run the installer, read the posture, raise issues, open PRs.

How It Relates to Access Gate

Open-CMMC stands alone. It's a complete CUI enclave without any Trout commercial component.

For customers who want identity enforcement, x509 / PIV authentication, and egress allow-listing in front of the enclave, Open-CMMC runs cleanly behind Trout Access Gate. The two are designed to compose: Gate fronts TLS + strong authentication + network-layer controls; Open-CMMC handles the CUI storage and marking. Neither requires the other, you can run Open-CMMC with any network front end, and you can run Access Gate in front of any backend that speaks HTTPS.

For the full picture of who is responsible for which NIST 800-171 control in a stacked deployment, see our CMMC Shared Responsibility Matrix.

Get Started

• Landing page: trout.software/resources/open-cmmc
• GitHub: github.com/TroutSoftware/Open-CMMC
• Install guide: docs/almalinux9-setup.md
• Architecture: docs/architecture.md

If you're running a Level 2 readiness program and want an inspectable reference for the CUI storage tier, we'd love your feedback. Open an issue, open a PR, or talk to an engineer.

Full CMMC on-premise compliance guide → /solutions/cmmc-compliance