This is one of the most common misunderstandings in CMMC. A CSP's FedRAMP authorization protects the OSA against one specific failure mode — using a non-FedRAMP cloud for CUI — but does not transfer the OSA's CMMC compliance obligation to the CSP.
What the CSP's FedRAMP authorization actually covers
FedRAMP authorization (Moderate or High) demonstrates that the CSP has implemented and is operating the FedRAMP baseline of controls on its own infrastructure. The OSA inherits the CSP's implementation for the controls and objectives that are the CSP's responsibility per the Customer Responsibility Matrix.
For DFARS 252.204-7012 specifically, the FedRAMP authorization satisfies the requirement that any CUI in cloud services be protected to FedRAMP Moderate-equivalent standards.
What the CSP's FedRAMP authorization does NOT do
- It does not assess the OSA. CMMC assesses the OSA's environment, processes, and people. The CSP is one component of that environment, not the whole of it.
- It does not implement OSA-side controls. Many controls require OSA action: account management, MFA configuration, conditional access policies, data classification, audit log review.
- It does not document the OSA's SSP. The OSA's SSP must describe each practice's implementation, including any inherited from the CSP.
- It does not produce CMMC evidence. CMMC evidence is the OSA's evidence of how each practice operates, including evidence that the OSA-side responsibilities for inherited controls are operating.
The shared responsibility split (typical pattern)
| What the CSP typically owns | What the OSA typically owns |
|---|---|
| Physical security of data centers | Account creation, access reviews, deactivation |
| Hypervisor and host security | Configuration of identity provider, MFA, conditional access |
| Network infrastructure security | Workload configuration, application security, data classification |
| Foundational service availability | Audit log generation, log review, log retention |
| FedRAMP-baseline encryption capabilities | Enabling encryption settings, managing keys, FIPS-mode configuration |
| Vulnerability management of CSP-managed components | Vulnerability management of OSA-managed workloads, patching |
| Incident response for CSP-managed infrastructure | Incident response for OSA-managed environment, DIBNet reporting |
The table above is illustrative for a typical IaaS arrangement. The exact split depends on the specific service model (IaaS / PaaS / SaaS) and varies between CSPs. The authoritative source for your specific allocation is the CSP's own CRM (or SRM) and FedRAMP package. Pull these from the CSP directly — from AWS Artifact, the Microsoft Service Trust Portal, or the equivalent — before you write your SSP, and reference them by control.
What you have to do
- Obtain the CSP's CRM and FedRAMP package documentation — Customer Implementation Summary, Customer Responsibility Matrix, body of evidence references.
- Document each control's allocation in your SSP — OSA, CSP, or shared, with implementation details for each.
- Implement and operate the OSA-side controls — account management, MFA, audit review, training, etc.
- Produce evidence for OSA-side controls and operate per the CRM for inherited controls.
- Verify the inheritance pattern with your C3PAO before assessment — the C3PAO evaluates whether the inheritance is real, not just claimed.
Common errors
- "We're on AWS GovCloud, so we're CMMC-compliant." No. The CSP's authorization addresses the CSP's portion. The OSA still has its CMMC obligations.
- Assuming the CSP's FedRAMP package replaces the OSA's SSP. The OSA's SSP must reference the CRM but cannot consist of "see the CSP's documentation."
- Failing to enable controls the CSP makes available. Many CSPs have FIPS-mode toggles, audit logging, conditional access policies that the OSA must enable. Available is not the same as enabled.
- Confusing CSP-side audit logs with OSA-side audit logs. The CSP audits its own infrastructure; the OSA must collect and review logs from OSA-managed workloads.