April 24, 2026 · 10 min read · architecture

FedRAMP Moderate Inheritance for CMMC Level 2: What You Can and Can't Inherit

If you've moved your CUI workload to AWS GovCloud, Microsoft Azure Government, or GCC High, you've probably been told you can "inherit" most of CMMC Level 2 from the cloud's FedRAMP Moderate authorization. That is partially true — and the gap between "partially true" and "what your assessor will accept" is where projects fail.

This post lays out exactly what FedRAMP Moderate inheritance covers for a CMMC L2 SSP, what it doesn't, and how to document the hand-off in a way that survives a C3PAO assessment. If you're still scoping which systems handle CUI, start with our CUI Boundary Scoping Tool first — inheritance is meaningless if the boundary is wrong.

The short version: FedRAMP Moderate covers the cloud provider's portion of a shared infrastructure. CMMC L2 covers your tenancy on top of it. The cloud takes care of the data center, the hypervisor, and the physical hardware. You still own identity, configuration, audit, incident response, and the application layer — and most CMMC L2 practices live there.

Why DoD requires FedRAMP Moderate (or equivalent) for CUI in the cloud

DFARS 252.204-7012(b)(2)(ii)(D) says that if you store, process, or transmit covered defense information in a cloud service, that cloud must meet "FedRAMP Moderate baseline (or equivalent)" and the contractor must comply with the additional requirements in DFARS 252.239-7010[1]. The DoD Cloud Computing SRG raises this to Impact Level 4 (IL4) for most CUI[2].

So FedRAMP Moderate is a floor, not a ceiling. It is necessary for the CSP to be eligible to host your CUI; it is not sufficient for you to claim CMMC L2 compliance. The two authorizations cover different layers of the same stack.

What you can inherit from a FedRAMP Moderate CSP

FedRAMP Moderate is a NIST SP 800-53 Rev 5 control baseline[3]. CMMC L2 is built on NIST SP 800-171 Rev 2, which is itself a tailoring of 800-53[4]. Where the two baselines overlap and the responsibility rests entirely with the CSP, you can inherit. Practically, that means:

Fully inheritable — physical & environmental

The PE family (3.10) is the cleanest inheritance. The cloud provider runs the data center, controls physical access, monitors visitors, manages environmental hazards. You inherit PE.L2-3.10.1 through 3.10.6 in full, citing the CSP's authorization package.

Fully inheritable — media destruction at end-of-life

MP.L2-3.8.3 (sanitize media before disposal) is the CSP's responsibility for the underlying disks. You inherit destruction of the physical hardware. You still own logical sanitization of the data your users wrote — that's a configuration management task, not a physical one.

Partially inheritable — system & communications protection (SC)

The cloud provides the network fabric, hypervisor isolation, and FIPS 140-validated cryptographic modules[5]. You inherit the existence of those primitives. You still own:

Run our control explorer to see which SC.L2 practices have shared-responsibility hand-offs in your specific cloud.

Partially inheritable — system & information integrity (SI)

The cloud handles host-level patching for managed services (RDS, Lambda, ECS Fargate). You handle patching for everything you brought (EC2 AMIs, container images, application dependencies). The split is service-by-service and changes whenever you swap from a managed service to a self-managed equivalent.

Not inheritable — access control (AC), audit & accountability (AU), identification & authentication (IA)

These are entirely your responsibility. The cloud provides IAM as a service; you decide who gets access, what permissions, with what authentication factor, and how those decisions are logged and reviewed. AC.L2-3.1.1 (limit system access to authorized users) is about your users, not the CSP's. AU.L2-3.3.1 (create and retain audit records) is about your CloudTrail/Sentinel/M365 audit data, not the cloud's internal logs.

Not inheritable — configuration management (CM), incident response (IR), awareness & training (AT)

CM.L2-3.4.1 (baseline configurations) is about your AMIs, your Terraform, your IaC. IR.L2-3.6.1 (incident response capability) is about your runbook and your team. AT.L2-3.2.1 (security training) is about your employees. None of these can be delegated to a CSP, even when running entirely on managed services.

The Customer Responsibility Matrix is the contract

Every FedRAMP-authorized CSP publishes a Customer Responsibility Matrix (CRM) — sometimes called a Control Implementation Summary (CIS). The CRM enumerates each of the 800-53 controls in the FedRAMP Moderate baseline and assigns each one to the CSP, the customer, or "shared"[6]. AWS publishes its CRMs through Artifact, Microsoft through the Service Trust Portal, Google through the Compliance Resource Center.

For CMMC L2, you cannot just attach the CRM to your SSP and call inheritance done. Two reasons:

  1. The CRM is keyed to 800-53, not 800-171. CMMC L2 practices are 800-171 control IDs (e.g. AC.L2-3.1.1), and the mapping between 800-171 Rev 2 and 800-53 is many-to-many. NIST publishes Appendix D of SP 800-171 Rev 2 as the bridge[4], but a single 800-171 practice can pull from three or four 800-53 controls.
  2. The CRM doesn't know your architecture. Whether AC.L2-3.1.5 (least privilege) is "shared" or "customer" depends on whether you're using IAM Identity Center, federated SSO, or static IAM users. The CRM tells you what the cloud will do; it cannot tell you what you must do.

Your SSP needs an inheritance statement per 800-171 practice that names the underlying 800-53 controls, cites the CSP's CRM by section, and describes the customer-side configuration that completes the control. Our SSP-as-code post walks through how to express this in OSCAL component-definitions so the inheritance is machine-readable instead of buried in a Word table.

Three common inheritance mistakes that fail assessment

Mistake 1: Citing the CSP's FedRAMP authorization without naming controls

"AWS GovCloud is FedRAMP Moderate authorized, so this control is inherited." This is not an inheritance statement. The assessor needs to see which 800-53 control in the CSP's authorized package satisfies your 800-171 practice, the section of the CRM that confirms the CSP's responsibility, and the customer-side configuration evidence that completes the control. No assessor will accept a one-line citation.

Mistake 2: Inheriting controls the CSP didn't actually take

The default assumption among contractors is that managed services like Amazon RDS or Azure SQL fully inherit configuration management, patching, and audit. Read the actual CRM. RDS shifts some patching to AWS, but you still own engine version selection, parameter group configuration, and audit log routing. Azure SQL shifts some auditing to Microsoft, but you still own enabling Defender for SQL and configuring the audit destination. Inheriting a control the CSP did not commit to taking is one of the fastest ways to fail an assessment.

Mistake 3: Forgetting that inheritance is conditional on the service being in scope

FedRAMP authorizations cover a specific list of services. AWS GovCloud's authorization covers about 90 services[7]; Azure Government covers a different set. If you use a service that is in the cloud provider's commercial region but not in their FedRAMP-authorized region or service list, you cannot inherit anything from the FedRAMP authorization for that service. Verify every service against the FedRAMP Marketplace listing[8] before claiming inheritance.

How to document inheritance in OSCAL

If your SSP is a Word document, inheritance documentation is a table that drifts every time AWS adds a service or your team changes a configuration. If your SSP is OSCAL, inheritance is a structured relationship between your component-definition and the CSP's component-definition that can be verified by tooling.

The OSCAL component-definition format supports an inherited element on each implemented requirement, pointing at a provided element in another component[9]. AWS publishes OSCAL component-definitions for many GovCloud services through the awslabs/aws-security-hub-oscal repository. When your SSP-as-code pipeline assembles the component-definitions for your tenancy, the inheritance hand-off is checkable: every inherited claim must resolve to a provided statement in a CSP component you've actually pulled in.

This turns inheritance from an assertion in prose into a graph that can be validated by trestle validate at build time, and re-validated whenever AWS or you change something. That's the difference between an SSP that ages well and one that's stale by the time the assessor walks in.

What to do this week

Get an inheritance map for your tenancy. We produce machine-readable OSCAL component-definitions for AWS GovCloud, Azure Government, and GCC High that map each FedRAMP Moderate control to its corresponding CMMC L2 practice with the customer-side configuration evidence wired in. The output drops directly into your trestle pipeline. Book a 30-minute scoping call and we'll deliver the first three component-definitions for your environment.

References

  1. DFARS 252.204-7012, "Safeguarding Covered Defense Information and Cyber Incident Reporting." acquisition.gov/dfars/252.204-7012
  2. DoD Cloud Computing Security Requirements Guide (SRG) v1 r4. public.cyber.mil/dccs
  3. FedRAMP Rev 5 Baselines. fedramp.gov/rev5/baselines
  4. NIST SP 800-171 Rev 2, "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations." csrc.nist.gov/pubs/sp/800/171/r2
  5. NIST FIPS 140-3 Cryptographic Module Validation Program. csrc.nist.gov/projects/cryptographic-module-validation-program
  6. FedRAMP Customer Responsibility Matrix template. fedramp.gov/documents-templates
  7. AWS GovCloud (US) services in scope of FedRAMP Moderate authorization. aws.amazon.com/compliance/services-in-scope/FedRAMP
  8. FedRAMP Marketplace. marketplace.fedramp.gov
  9. NIST OSCAL Component Definition Model. pages.nist.gov/OSCAL/concepts/layer/implementation/component-definition

See also: GCC High Decision Guide · Control Explorer · Readiness Quiz · CUI Boundary Guide