CMMC Level 2 is no longer a future problem for defense industrial base contractors. The DoD rule that codified CMMC went final on 2024-12-16 and the assessment requirements are now appearing in solicitations. If you handle Controlled Unclassified Information for the DoD, you are aligning a 110-practice control surface against NIST SP 800-171 Rev 2, and you are doing it on a clock.
A managed cloud provider cannot make you CMMC Level 2 ready. The certification belongs to the contractor handling the CUI, not to the underlying infrastructure. What a managed cloud provider can do is take a meaningful number of those 110 practices off your plate, document its share of the work, and give you the evidence trail you need when the C3PAO walks in.
This post walks the 14 CMMC Level 2 domains and shows what the Open Edge Cloud platform already addresses, where the line sits between platform and customer, and where the gaps are honest.
A note on strategy: we are building to FedRAMP Moderate, not CMMC L2
CMMC Level 2 is a 110-practice baseline drawn from NIST SP 800-171 Rev 2. FedRAMP Moderate is a much larger baseline drawn from NIST SP 800-53 Rev 5, plus FedRAMP-specific enhancements. The two baselines look like they are addressing different audiences, but they are addressing largely the same control surface.
DoD formally recognizes the “FedRAMP Moderate Equivalent” path for CUI handling on cloud infrastructure (DoD CIO guidance, December 2023). A platform that can credibly map to FedRAMP Moderate falls out as substantially covering CMMC Level 2, with only a few add-on items: CUI marking process, DFARS 252.204-7012 incident timelines, and the C3PAO engagement itself.
That is why our compliance program targets FedRAMP Moderate. We maintain a Compliance Trestle / OSCAL workspace: the NIST SP 800-53 Rev 5 catalog, a resolved Moderate baseline profile, and eight tiered control-gap reports (tiers A through H) that map our live posture to the baseline. CI runs OSCAL validation on every change. The per-component control implementations, the system security plan, and the POA&M are authored at the point of acquirer engagement, on a documented multi-checkpoint plan; we do not represent them as complete today. (On the profile: we currently track the NIST 800-53 Rev 5 Moderate baseline. The FedRAMP-specific tailoring delta is documented separately and applied when an authorizing path is engaged, because the canonical FedRAMP OSCAL profile is mid-migration under FedRAMP 20x.)
We are not a CMMC Authorized Cloud Service Offering. We have not been assessed by a C3PAO. We do not hold a FedRAMP Moderate authorization. The platform is designed to support workloads subject to CMMC Level 2 controls, and we will not represent it as anything more than that. If you need a fully authorized CSO today with a federal sponsor and an active ConMon program, we are not it. If you need a partner with a credible engineered compliance posture and a real plan to get there under acquisition, the rest of this post is for you.
A note on shared responsibility
Every cloud provider has a shared responsibility model. Most of them have a glossy chart. The honest version is: the practices your provider runs end-to-end are the ones where your evidence is “the provider’s audit trail and access policy.” The practices that are shared are the ones where both parties produce evidence. The practices that are yours alone are the ones where the provider is a bystander.
For each domain below we mark practices as:
- Platform: the platform addresses the practice end-to-end and supplies the evidence
- Shared: the platform supplies infrastructure; the customer supplies workload-side configuration and evidence
- Customer: the platform is a bystander; the customer owns the practice
There are 110 practices. We will not enumerate all 110 here. We will name the ones where the platform makes a meaningful contribution and group the rest.
AC: Access Control (22 practices)
This is the largest domain and the one where a managed cloud platform contributes the most.
Platform-addressed practices include AC.L2-3.1.1 (account management), AC.L2-3.1.2 (transaction authorization), AC.L2-3.1.5 (least privilege), AC.L2-3.1.7 (privileged function auditing), AC.L2-3.1.12 (remote access monitoring), AC.L2-3.1.13 (remote access encryption), AC.L2-3.1.14 (remote access routing), and AC.L2-3.1.20 (external connections).
Concretely:
- Keycloak fronts every authenticated path. Account management is centralized. Account lifecycle events emit to the audit log.
- Built-in dashboard roles implement least privilege, scoped per project rather than per organization. Underneath the dashboard, oslo.policy enforces new-defaults and scope across every OpenStack API service. The three-tier admin/member/reader policy is enforced at the service layer, not just at the dashboard layer.
- Privileged function execution at the OpenStack API surface is logged with requester identity, project, timestamp, and parameters. Host-level sudo command execution is logged with full input and output capture.
- Remote administrative access is gated by federated SSO with MFA. There is no shared bastion account. Operator SSH access is keyed to individual engineers and audited per session.
- All remote access transits TLS 1.3 with restricted AEAD cipher suites or SSH with FIPS-pinned ciphers.
Shared: AC.L2-3.1.3 (CUI flow control between systems), AC.L2-3.1.4 (separation of duties), AC.L2-3.1.22 (publicly accessible content). The platform provides the boundary controls and the identity surface; the customer owns workload-level data flow policy.
Customer: AC.L2-3.1.9 (privacy and security notices on logon) is a workload concern.
AT: Awareness and Training (3 practices)
Customer: AT.L2-3.2.1 through 3.2.3 are organizational practices. Your security awareness training, your role-based training, and your insider threat training are yours.
AU: Audit and Accountability (9 practices)
The audit chain at Open Edge Cloud is built for this domain. Most of the work for AU is platform-addressed when the workload runs on managed infrastructure.
Platform: AU.L2-3.3.1 (system auditing), AU.L2-3.3.2 (user accountability), AU.L2-3.3.4 (audit failure alerting), AU.L2-3.3.5 (audit review and analysis), AU.L2-3.3.6 (audit reduction and reporting), AU.L2-3.3.8 (audit information protection), AU.L2-3.3.9 (audit access restriction).
The implementation:
- Every OpenStack API call is logged with requester identity, project, timestamp, parameters, and outcome. Every API service emits structured audit notifications; a hardened collector ships them onward.
- Logs ship to real-time analysis and to a long-term encrypted archive on a multi-year retention horizon. The archive is GPG-AES-256 encrypted at the source host before it leaves the machine. The encryption keys are not on the source host. WORM/object-lock immutability and an off-site mirror are tracked roadmap items.
- A heartbeat metric watches the archive pipeline. If a daily window goes silent, an alert fires to the operations channel.
- Audit data access is restricted to operators with the auditor or security role. Customer audit access is read-only and is itself audited.
- An audit reduction surface is available in the dashboard with CSV export and search filters mapped to SOC 2 and ISO 27001 control families. The same surface can be extended for CMMC reporting.
Shared: AU.L2-3.3.3 (auditable events review) and AU.L2-3.3.7 (system clock synchronization). NTP is platform-managed.
CM: Configuration Management (9 practices)
Platform: CM.L2-3.4.1 (baseline configurations), CM.L2-3.4.2 (security configuration enforcement), CM.L2-3.4.3 (configuration change tracking), CM.L2-3.4.4 (security impact analysis), CM.L2-3.4.6 (least functionality), CM.L2-3.4.7 (nonessential functions disabled).
The implementation:
- Kolla-Ansible is the deployment substrate. The inventory, globals, group variables, and service templates are the baseline configuration in version control. There is no out-of-band drift surface.
- Every container image is built from a pinned upstream tag plus a small set of declared customizations. Image digests are recorded and reproducible. Promotion runs on a weekly cron.
- The deployment tree is git-managed with GPG-signed commits. Production deploys are gated on signed commits from a known-good signer.
- The control-plane configuration mirror is pull-only on cluster hosts. The signing key never leaves the operator workstation. Hosts cannot mutate the configuration that produced them.
- Every cluster host is hardened against a tailored Canonical USG CIS Level 2 profile. The tailored hardening lands the cluster in the high nineties on effective CIS L2 pass, with an independent OpenSCAP STIG cross-check moving in step. Residual CIS failures are formally accepted with documented compensating controls and NIST family mappings.
- Wazuh runs continuous Security Configuration Assessment against the CIS Ubuntu 24.04 baseline on a weekly cadence, which exceeds the FedRAMP Moderate monthly OS-scan baseline.
Shared: CM.L2-3.4.5 (access restrictions for change), CM.L2-3.4.8 (allowlist-based execution control), CM.L2-3.4.9 (user-installed software). Workload images and customer-installed software are the customer’s; the platform supplies the change control surface for infrastructure changes.
IA: Identification and Authentication (11 practices)
Platform: IA.L2-3.5.1 through 3.5.11.
The implementation:
- Federated SSO with the customer’s identity provider is the supported authentication path. Local accounts exist only for break-glass scenarios and are themselves MFA-required.
- MFA is enforced through the IdP. TOTP and WebAuthn are the supported factors. Hardware key WebAuthn meets IA.L2-3.5.3 by any reading of the practice.
- Replay resistance is provided by OIDC nonce handling and short-lived OpenStack tokens.
- Identifier lifecycle (disable, reuse prevention) is enforced through the IdP integration.
- Passwords are stored under PBKDF2-SHA512, FIPS-approved per SP 800-132. The legacy bcrypt path has been retired across the cluster with a monitoring rule that flags any regression.
- Authentication feedback obscures credential entry per IA.L2-3.5.11.
Shared: The customer is responsible for the policies in their IdP. The platform enforces what the IdP says.
IR: Incident Response (3 practices)
Shared: IR.L2-3.6.1 (operational incident handling), IR.L2-3.6.2 (incident tracking and reporting), IR.L2-3.6.3 (incident response testing).
Platform-side: containment substrate includes per-tenant network isolation, default-deny security groups, edge boundary protection, and a fast-path config reload at the edge.
The operational half of IR (24×7 SOC, on-call rotation, incident command, customer notification SLAs, US-CERT and CISA reporting workflows) is explicitly out of platform scope under the FedRAMP Moderate Equivalent scope-reduction model. It is the acquirer’s responsibility.
Customer-side: workload-level IR is the customer’s. We integrate with customer IR processes when we provide the data they need.
MA: Maintenance (6 practices)
Platform: MA.L2-3.7.1 through 3.7.4. The platform handles hypervisor maintenance, hardware replacement, and decommissioning. Decommissioned drives undergo crypto-erase. Physical destruction is documented for drives that left a confidential workload.
Customer: MA.L2-3.7.5 and 3.7.6 cover authorization of maintenance personnel.
MP: Media Protection (9 practices)
Platform: MP.L2-3.8.1 through 3.8.4 and MP.L2-3.8.9.
The implementation:
- Block storage in the production cluster is encrypted at the device layer with AES-XTS.
- Cinder volumes can be encrypted at rest with an AES-256 XTS encrypted volume type using customer-managed Barbican keys.
- Object storage supports server-side encryption with customer-provided keys and object lock for WORM compliance.
- Backups are GPG-AES-256 encrypted at the source host before they leave the machine. The encryption keys are not on the source host.
Customer: MP.L2-3.8.5 (media transport accountability) and MP.L2-3.8.6 (cryptographic protection during transport). The platform does not exchange physical media with customers.
PS: Personnel Security (2 practices)
Customer: PS.L2-3.9.1 (personnel screening) and PS.L2-3.9.2 (personnel termination and reassignment). The platform supports rapid identity revocation and session termination.
Provider-side: Open Edge personnel with production access are US persons. Personnel screening is acquirer responsibility under the scope-reduction model.
PE: Physical Protection (6 practices)
Platform: PE.L2-3.10.1 through 3.10.6 are addressed by the datacenter providers. Iron Mountain VA-1 in Manassas, Virginia and STACK POR02A in Hillsboro, Oregon are both SOC 2 and ISO 27001 audited facilities with biometric access, badge access, surveillance, and visitor logging. Facility attestations are available on request.
The platform does not operate any infrastructure outside these two facilities.
RA: Risk Assessment (3 practices)
Platform: RA.L2-3.11.1 (periodic risk assessment), RA.L2-3.11.2 (vulnerability scanning), RA.L2-3.11.3 (vulnerability remediation).
The implementation:
- Wazuh runs continuous vulnerability detection against installed packages on every cluster host.
- Wazuh SCA runs weekly against the CIS Ubuntu 24.04 baseline.
- OpenSCAP STIG baseline scans run on a documented cadence with results stored as immutable artifacts.
- Critical vulnerabilities are tracked against a documented Patch SLA.
Shared: Workload vulnerability scanning is the customer’s. Platform-provided scanning extends to images that the customer pulls from our curated catalog.
CA: Security Assessment (4 practices)
Platform: CA.L2-3.12.1 (control assessment), CA.L2-3.12.2 (plan of action), CA.L2-3.12.3 (continuous monitoring), CA.L2-3.12.4 (system security plan).
The implementation:
- An OSCAL-based artifact program managed with Compliance Trestle and validated in CI: NIST SP 800-53 Rev 5 catalog, a resolved Moderate baseline profile, and tiered control-gap reports authored today. Per-component control implementations, the SSP, and the POA&M are authored at acquirer engagement.
- Per-host assessment bundles capture pre and post-hardening results from OpenSCAP STIG, USG CIS L2, and Wazuh SCA. The bundles are stored as immutable artifacts.
- Continuous monitoring substrate is built. The operational ConMon program (monthly scan submission, agency reporting, formal POA&M cadence) is acquirer responsibility under the scope-reduction model.
Customer: Workload-level SSP and assessment are the customer’s.
SC: System and Communications Protection (16 practices)
Platform: SC.L2-3.13.1 (boundary monitoring), SC.L2-3.13.2 (architectural design for security), SC.L2-3.13.5 (public-facing component separation), SC.L2-3.13.6 (default-deny network policy), SC.L2-3.13.8 (cryptographic protection in transit), SC.L2-3.13.10 (cryptographic key management), SC.L2-3.13.11 (FIPS-validated cryptography), SC.L2-3.13.15 (session authenticity), SC.L2-3.13.16 (cryptographic protection at rest).
The implementation:
- Boundary monitoring at the edge with WAF rules and rate limiting. Cloudflare WAF in front for the marketing surface.
- Per-tenant isolated networks with default-deny security groups. A visual traffic simulator and shadowed-rule detection are unique features that make the boundary policy auditable rather than just declarative.
- Public-facing components run in a DMZ pattern with no path to the management network.
- TLS 1.3 only on every public listener, AEAD ciphers only.
- Cryptographic operations run against a FIPS 140-3 validated OpenSSL provider on Ubuntu 24.04 LTS (CMVP Certificate #5115, searchable on the NIST validation list). This is the practice that drove our entire FIPS effort and it is the one that distinguishes us from most general-purpose managed OpenStack providers.
- Key management through Barbican with customer-managed keys for block storage, object storage, and application secrets. Customer-managed key generation supports RSA up to 4096-bit and P-521 EC.
- All persistent storage in the production cluster is encrypted at the device layer. Volume-type encryption with customer-managed keys is available end-to-end.
- Session authenticity through short-lived OpenStack tokens and OIDC nonce validation.
Shared: SC.L2-3.13.3 (process isolation), SC.L2-3.13.4 (information in shared resources). The platform provides hypervisor-level isolation; the customer is responsible for in-workload process isolation.
SI: System and Information Integrity (7 practices)
Platform: SI.L2-3.14.1 (flaw remediation), SI.L2-3.14.2 (malicious code protection), SI.L2-3.14.3 (security alerts and advisories), SI.L2-3.14.4 (malicious code detection updates), SI.L2-3.14.5 (information system monitoring), SI.L2-3.14.6 (monitoring inbound and outbound communications), SI.L2-3.14.7 (unauthorized use identification).
The implementation:
- Flaw remediation runs against a documented Patch SLA on the platform side.
- Wazuh runs file integrity monitoring (real-time plus whodata) on all sensitive system directories: configuration, secrets, SSH state, TLS material, audit configuration, and certificates. Any change outside a known deployment window pages an operator.
- Rootkit detection runs with the upstream Wazuh ruleset and a curated IOC pattern set.
- Wazuh signature updates run on a daily cadence with a manual override path.
- Information system monitoring runs at three layers: Wazuh on the host, platform metrics and logs centralized for real-time analysis, and synthetic transaction monitoring at the boundary.
- Inbound and outbound communications monitoring runs against the edge access logs and the connection tracker.
- Unauthorized use detection runs through anomaly rules on the audit log (off-hours admin actions, geographically improbable session origins, privilege escalation patterns).
Customer: Workload-level integrity monitoring is the customer’s. The platform extends FIM to customer images on request.
What this adds up to
Of 110 CMMC Level 2 practices, the platform meaningfully contributes to roughly 75. The exact count depends on how you treat shared practices and on which managed applications the customer subscribes to. We have walked the mapping with prospective DIB customers and the result is broadly consistent: the platform takes a substantial portion of the control surface off the contractor’s plate, and the remaining surface is workload-side practices or operational program practices that no infrastructure provider can address for you.
The underlying engineering work is captured in an OSCAL workspace: 800-53 Rev 5 catalog, a resolved Moderate baseline profile, and tiered control-gap reports that map our live posture to the baseline. Acquirers and prospects with a signed NDA can read those artifacts directly, and we will author the per-component implementations, SSP, and POA&M on engagement. CMMC L2 coverage is the marginal additional surface (CUI marking, DFARS 7012 timelines, C3PAO engagement) on top of that work.
We are not selling CMMC certification. We are selling a managed cloud platform with a compliance posture built to support workloads subject to CMMC Level 2 controls, anchored in a FedRAMP Moderate engineering program. The certification is yours. The supporting evidence from the platform is ours.
If you are running a CMMC readiness assessment right now and want a control-by-control conversation with the platform team, send us your mapping spreadsheet. We will fill in our column with specifics, not adjectives.
Reach out at https://open-edge.io/contact.