CMMC Level 2 compliance on AWS: Why control ownership is where organizations struggle

Cybersecurity Maturity Model Certification (CMMC) Level 2 compliance challenges stem not from a lack of security controls but from a fundamental misunderstanding of who owns them. This post brings guidance on Customer Responsibility Matrices (CRMs), authorization boundary definitions, and multi-provider control ownership into a single actionable framework for defense contractors preparing for third-party assessment.

With Certified Third-Party Assessment Organization (C3PAO)-assessed certifications becoming a condition of contract award and noncompliance carrying risks including disqualification and False Claims Act liability, the window for preparation is closing.

If your organization handles Controlled Unclassified Information (CUI) and operates on Amazon Web Services (AWS), you’re well positioned to address CMMC Level 2 requirements, but only if you understand the shared responsibility model and how control ownership works in practice.

The critical takeaway is that hosting in a Federal Risk and Authorization Management Program (FedRAMP)-authorized environment doesn’t automatically satisfy CMMC requirements. Every control must answer three questions: who implements the control, where it operates, and what evidence proves it.

Organizations that can’t clearly answer all three of these questions for each of the 110 National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 Rev 2 controls could struggle during assessment. This is especially consequential in multi-provider environments where managed service providers (MSPs) build enclaves on top of cloud service provider (CSP) infrastructure. These enclaves fall outside the CSP’s FedRAMP authorization boundary and must independently demonstrate compliance with all 323 FedRAMP Moderate Baseline controls.

This post also addresses boundary drift, which is the unmanaged expansion of an assessment scope as new applications and services are deployed. Boundary drift can silently erode compliance posture over time. It’s recommended that organizations embed continuous boundary validation in change management workflows and request explicit, independently maintained CRMs from every provider in their chain. The absence of a provider CRM is treated as a risk factor: Under CMMC, if responsibility isn’t explicitly defined and provable, then the control isn’t met.

CMMC Level 2 timeline: Where we stand

The regulatory framework behind CMMC 2.0 is now operational. The CMMC Program Rule (32 CFR Part 170) became effective on December 16, 2024, and CMMC assessments formally began on January 2, 2025. The Acquisition Rule (48 CFR) followed, which was published on September 10, 2025 and took effect on November 10, 2025. It was codified in Defense Federal Acquisition Regulation Supplement (DFARS) clauses 252.204-7021 and 252.204-7025. This means CMMC compliance is a mandatory, enforceable element of applicable contracts.

The rollout follows a deliberate four-phase schedule, as illustrated in Figure 1:

Figure 1: CMMC Level 2 phased rollout timeline

The phased rollout progresses as follows:

• Phase 1, November 2025 to November 2026 – Requires Level 1 and Level 2 self-assessments with scores uploaded to the Supplier Performance Risk System (SPRS) in most new solicitations.
• Phase 2, November 2026 to November 2027 – The critical inflection point where C3PAO-assessed Level 2 certifications become a condition of award. Only companies authorized by The Cyber AB and listed in the CMMC Marketplace can issue certifications. Contractors are advised to coordinate with a C3PAO at least 6 to 12 months in advance.
• Phase 3, November 2027 to November 2028 – Extends Level 2 certification requirements to options on existing contracts.
• Phase 4, November 2028 onward – Achieves full implementation across all applicable contracts except commercial off-the-shelf (COTS) contracts.

One point that organizations often overlook is that DFARS 252.204-7012 remains independently enforceable. CMMC Level 2 validates the same 110 NIST SP 800-171 Rev 2 controls that DFARS 252.204-7012 has required since 2017. CMMC adds a third-party verification layer to existing obligations. Noncompliance carries risks including False Claims Act liability, making it important that organizations treat compliance preparation as an urgent operational priority rather than a future concern.

Why this matters for organizations using AWS

CMMC Level 2 doesn’t mandate a specific AWS Region. It requires that you implement NIST SP 800-171 controls, and that any CSP you use meets the FedRAMP Moderate Baseline equivalent, as required by DFARS 252.204-7012. Both AWS GovCloud (US) and the commercial US East/West Regions meet this requirement. The right deployment target depends on your specific contract requirements:

• If your contract involves International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR)-controlled data, deploy in AWS GovCloud (US). ITAR workloads require the jurisdictional isolation that AWS GovCloud (US) provides.
• If your contract requires Impact Level 4 or 5, deploy in AWS GovCloud (US). Commercial regions only support Impact Level 2.
• If your workloads involve CUI without ITAR/EAR restrictions and without Impact Level 4/5 requirements, you can deploy in commercial US East/West Regions using Federal Information Processing Standards (FIPS)-validated endpoints and still meet CMMC Level 2 requirements.
• If you have mixed workloads with different regulatory overlays, consider a hybrid approach: AWS GovCloud (US) for ITAR programs and commercial regions for standard CUI workloads. Use separate AWS Organizations to maintain clear boundaries.

Regardless of which region you choose, services such as AWS CloudTrail, AWS Config, AWS Security Hub, and Amazon GuardDuty are designed to support the monitoring, logging, and configuration management that CMMC controls require. However, the availability of these services doesn’t mean the controls are met. Your organization must configure, operate, and evidence these controls, and clearly document who owns each one.

The sections that follow explain the shared responsibility model in the context of CMMC, how to build and maintain a CRM, how to scope your assessment boundary, and how to manage compliance across multiple providers.

The shared responsibility model in practice: CSPs, MSPs, and your organization

Perhaps the most common misconception in cloud-based CMMC compliance is that hosting in a FedRAMP-authorized environment automatically satisfies security requirements. It doesn’t. Control inheritance is determined by boundary placement, not by the cloud provider. Deploying in any FedRAMP-authorized AWS Region doesn’t automatically mean controls are inherited. The Organization Seeking Assessment (OSA) must define where its boundary begins and ends.

The AWS Shared Responsibility Model operates on a layered principle. Inherited controls exist only at the AWS infrastructure layer, covering physical security, hypervisor management, and core network infrastructure. All higher layers introduce shared or customer-owned responsibility.

This means that solution configuration, access controls, monitoring, and operational controls all carry obligations that fall partially or entirely on the customer and their service providers. As illustrated in Figure 2, control responsibility is distributed across four layers in a typical multi-provider CMMC environment:

Figure 2: Multi-provider control ownership model

The CSP (AWS) provides the foundational infrastructure with inherited controls, but each additional layer, including the MSP enclave, the Managed Security Service Provider (MSSP) security services, and the organization itself introduces new shared or customer-owned responsibilities that must be independently documented and evidenced.

The MSP enclave challenge

One of the most consequential misunderstandings in the defense industrial base involves MSP enclaves. FedRAMP authorization applies to a specific system boundary, not to everything built on top of it. An MSP isn’t a CSP. When an MSP builds an enclave on AWS, they introduce new configurations, new access controls, new monitoring layers, and new administrative functions. These aren’t covered by the CSP’s FedRAMP authorization.

The MSP effectively creates a new authorization boundary, and that boundary must independently meet FedRAMP Moderate or an equivalent with full evidence. However, some MSPs market “CMMC-compliant enclaves” with “fully inherited controls,” a claim that might not withstand assessment scrutiny.

FedRAMP equivalency requirements

The December 2023 memorandum tightened FedRAMP equivalency requirements. Under the updated requirements, a cloud service offering is a FedRAMP Moderate equivalent only if it achieves 100% compliance with all 323 FedRAMP Moderate Baseline security controls, which are validated through an assessment by a FedRAMP-recognized Third-Party Assessment Organization (3PAO).

CSPs must either be FedRAMP Moderate/High-authorized or secure a third-party assessment confirming compliance with all FedRAMP Moderate Baseline controls. Defense contractors bear the verification responsibility: DFARS 252.204-7012 mandates that contractors “require and ensure” their CSP’s compliance.

The CRM is a nonnegotiable compliance artifact

If there’s one document that separates organizations that pass CMMC assessments from those that don’t, it’s the CRM. A CRM defines which controls are inherited from the CSP, which are shared between the CSP and the customer, and which are fully implemented by the Organization Seeking Certification (OSC) or MSP, along with the implementation location and the evidence source. Under CMMC, the shared responsibility matrix formally documents accountability for each of the 110 NIST SP 800-171 Rev 2 requirements and their 320 assessment objectives.

Three questions every control must answer
As mentioned at the beginning of this post, a CRM must define three things for every control:

1. Who implements it
2. Where it is implemented
3. What evidence supports it

This per-control traceability is what assessors look for. From an assessor perspective, the following questions are nonnegotiable: Where is each control implemented? Who owns it? What evidence proves it? Is this control inherited, shared, or customer-managed? If the answer is unclear, the control isn’t met.

Layered ownership across multiple providers
When multiple providers are involved, which is a common scenario in defense contracting, the CRM must reflect a layered ownership model. Inherited controls exist only at the CSP infrastructure layer. All higher layers (MSP enclave, MSSP monitoring, customer application) introduce shared or customer-owned responsibility.

MSPs operating enclaves must provide their own CRM with control-by-control mapping and clear ownership between CSP, MSP, and OSA. When MSPs don’t provide their own independent CRM, the gap compounds significantly. Inherited controls require documentation in the System Security Plan (SSP), and shared controls require proof of active configuration.

The fundamental rule is unambiguous: If responsibility isn’t explicitly defined, it’s not inherited. And in CMMC, if it’s not provable, it’s not compliant.

Boundary scoping and the five asset categories

Proper boundary scoping is the structural foundation upon which CRM documentation and control ownership rest. The CMMC Level 2 Scoping Guidance, 32 CFR §170.19, defines five asset categories that organizations must use to classify every component within their environment:

Table 1: CMMC Level 2 asset categories per 32 CFR §170.19

All assets must be documented in an asset inventory, treated in the SSP, and included in the network diagram of the CMMC assessment scope. The classification of each asset directly determines which controls apply and how they must be evidenced. Getting this wrong (for example, not identifying a SPA that provides logging functions) can cascade into multiple control findings during assessment.

AWS services can play a role across several of these categories. For example, AWS CloudTrail and AWS Security Hub are likely SPAs in your environment, while Amazon Simple Storage Service (Amazon S3) buckets storing CUI would be classified as CUI assets. Proper classification of each AWS service in your environment is a prerequisite for accurate boundary scoping.

The silent compliance risk of boundary drift

Boundaries can initially be well-defined only to shift over time. Boundary drift is a risk that occurs when an OSA deploys new applications or services into a managed enclave, changing the boundary without formal reassessment. Those new components must be reassessed and incorporated into the CRM, meaning boundaries aren’t static and must be continuously validated.

This risk is particularly relevant in dynamic cloud environments where new workloads can be provisioned rapidly. When an OSA deploys applications into an MSP-managed enclave, the boundary changes. Those new components introduce potential new CUI touchpoints, new access paths, and new control requirements. If the CRM and SSP aren’t updated to reflect these changes, the organization’s documented compliance posture diverges from its actual environment, which is a gap that assessors are likely to identify.

Common patterns related to boundary drift include treating MSP enclaves as inside the CSP’s FedRAMP boundary, making blanket 100% inherited controls claims, and not distinguishing between infrastructure and managed services. These each represent a boundary definition issue that can result in assessment findings across multiple control families.

The mitigation strategy requires:

• Maintaining explicit CRM and supply chain risk management (SCRM) documentation that maps control ownership across all parties
• Continuous boundary validation when changes occur
• Verifying that every external service provider that builds an enclave independently meets FedRAMP Moderate or an equivalent

AWS services such as AWS Config and AWS Security Hub are designed to support continuous monitoring of your environment’s configuration state, which can help your organization detect when boundary changes occur and trigger the appropriate review processes.

Actionable steps for multi-provider compliance

Preparing for a CMMC Level 2 assessment in a multi-provider cloud environment demands disciplined, proactive effort. The following steps represent the most important recommended actions for organizations:

Step 1: Request explicit CRMs from every provider
Each CRM must define who implements each control, where it’s implemented, and what evidence supports it. This applies not only to the CSP but independently to every MSP and MSSP in the environment. If an MSP is offering a managed enclave handling CUI, they must provide their own CRM with control-by-control mapping and clear ownership between CSP, MSP, and OSC. It’s recommended that organizations treat the absence of a provider CRM as a risk factor. If your MSP or MSSP isn’t prepared, that risk falls on you.

Step 2: Contractually require DFARS flow-down and assessment-ready artifacts
MSP contracts must include cyber incident reporting requirements (72-hour notification), media preservation obligations, and access provisions for damage assessment. Beyond contractual language, MSPs must be obligated to produce evidence artifacts (configuration baselines, access review logs, vulnerability scans) that the C3PAO requires during assessment. Practices must match documentation: If an SSP states that vulnerability assessments are conducted weekly but the actual cadence is quarterly, assessors could identify the discrepancy and the control won’t pass.

Step 3: Conduct mock assessments before engaging a C3PAO
Without a mock assessment led by someone experienced in CMMC, gaps in documentation, missing evidence, and scope confusion often go unnoticed until it’s too late. A practice run can surface issues that can be remediated before the stakes are real. We recommend that organizations maintain version-controlled SSPs, traceable evidence logs, and tailored plans of action and milestones (POA&Ms) as part of their continuous compliance posture.

Step 4: Implement continuous boundary management
Given the risks of boundary drift, organizations must establish processes that trigger CRM and SSP updates whenever new applications, services, or configurations are deployed into the assessment scope. This isn’t a one-time exercise. It’s an ongoing operational discipline that must be embedded into change management workflows.

Conclusion

The transition from self-assessed to third-party verified CMMC compliance represents a fundamental shift in how the protection of CUI is validated. With C3PAO assessments becoming a condition of award and contractors facing disqualification for noncompliance, the window for preparation is narrowing.

The core lesson is that compliance isn’t about where your data is hosted, it’s about who owns each control, where that control operates, and what evidence proves it. Organizations that assume inheritance without documentation, treat MSP enclaves as extensions of CSP authorization boundaries, or allow boundary drift to go unmanaged are building their compliance posture on a foundation that might not withstand assessment.

The path forward requires:

• Explicit control ownership through thorough CRMs
• Rigorous boundary definition and continuous monitoring
• Contractual accountability across every provider in the chain
• Evidence-based verification that aligns documentation with operational reality

AWS provides a broad set of services and solutions designed to support organizations on this path, from AWS GovCloud (US) and commercial US Regions for hosting CUI workloads, to AWS Artifact for accessing AWS compliance reports, to services such as AWS Security Hub, AWS Config, AWS CloudTrail, and Amazon GuardDuty that are designed to help support continuous monitoring and evidence collection. CMMC compliance is achievable, but only for organizations willing to own every layer of their security posture.

For more information on CMMC compliance on AWS, contact AWS compliance support.

Next steps and resources

• AWS Security Assurance Services – Reach out to AWS Security Assurance Services to speak with a trusted advisor to support your CMMC certification journey
• CMMC program overview – Official CMMC program page with the latest guidance, rules, and assessment information
• AWS Shared Responsibility Model – Understand the division of security responsibilities between AWS and the customer