CMMC External Service Providers
Scope, Security Protection Assets, and the Shared Responsibility Matrix
If your managed service provider touches your CUI environment — directly or through the security tools they manage — they are in your CMMC assessment scope. Understanding exactly when that happens, what it costs you, and how to contain it is one of the most consequential decisions in your compliance program.
The DoD CIO scoping guidance defines two terms that every contractor relying on external IT must understand. An External Service Provider (ESP) is any organization providing services to you that may affect the confidentiality, integrity, or availability of CUI — cloud platforms, managed IT firms, security vendors, and co-managed providers all qualify. A Security Protection Asset (SPA) is any technology or service that provides security functions protecting your CUI environment — firewalls, SIEM platforms, EDR tools, vulnerability scanners.
The governing scoping principle: SPAs are inside your assessment boundary and are evaluated against the CMMC Level 2 requirements relevant to the security function they perform. It does not matter that the tool belongs to a vendor, or that an MSP employee — not your staff — manages it. If it protects your CUI environment, it is in scope, and the people managing it are subject to interview.
When an MSP or ESP Is in Scope — and Why
CMMC scoping follows the data and the security function, not the org chart. The question is not "do we employ them?" but "does their access or their tools touch the CUI environment?" Three conditions independently bring an external provider into scope.
| Provider Activity | Scope Classification | What It Means for Your Assessment |
|---|---|---|
| MSP directly accesses, stores, or transmits CUI (e.g., remote desktop into CUI server, backup of CUI data) | CUI Asset — Full Scope | All 110 controls apply to this provider's people, technology, and facilities. Their systems must be assessed. Their staff will be interviewed. |
| MSP manages security tools protecting the CUI environment (firewall, SIEM, EDR, vulnerability scanner) | Security Protection Asset | The tool and the MSP staff managing it are assessed against CMMC practices relevant to that security function. The personnel managing the SIEM can be interviewed. |
| Cloud provider hosts systems that process or store CUI | CUI Asset — Full Scope | Must be FedRAMP Moderate or High authorized, or demonstrate equivalent security. Controls inherited from the provider's authorization must be documented in a Customer Responsibility Matrix. |
| Provider delivers services entirely outside the CUI environment with no access to FCI or CUI | Out of Scope | Not assessed. However, if the scope of their work changes and they later gain access to CUI systems, they immediately become in scope — without a formal transition process to manage the change, this can surface as a surprise during assessment. |
Security Protection Assets: Which Provider Functions Trigger SPA Classification
An ESP does not need to hold or view CUI documents to be in scope. The security functions they deliver to your CUI environment are sufficient. The following provider-delivered capabilities are the most common SPA triggers — each brings the tool and its operators into your assessment boundary.
Firewall and Network Management
An MSP managing the firewall rules, ACLs, or VLAN configuration that enforces your enclave boundary is controlling the primary technical control protecting your CUI. They are an SPA. The firewall configuration is assessed, and the MSP engineer who maintains it can be interviewed.
SIEM and Log Monitoring
A provider operating a SIEM that ingests logs from CUI systems — or a managed SOC reviewing those logs — is performing the audit log review function. The SIEM platform is an SPA. Log retention, review procedures, and alert response workflows are all in scope for assessment.
Endpoint Detection and Response (EDR)
An EDR agent deployed on CUI endpoints, managed by a provider, is a Security Protection Asset. The provider's console — and the personnel with access to it — are in scope. If CUI endpoint telemetry flows to the provider's platform, that platform's security posture is evaluable.
Vulnerability Scanning
A scanner that reaches CUI systems — whether run by an MSP, a dedicated security vendor, or a co-managed security service — is an SPA. The scanner's configuration, scan frequency, and results management are assessed. An uncredentialed scan that misses vulnerabilities is a finding, not a defense.
Identity and Access Management
A provider managing MFA enforcement, privileged access controls, or identity governance for accounts that can reach CUI is providing a security function that directly controls who accesses the enclave. Their platform and their administrative access are in scope.
Backup and Recovery Services
A provider managing backups of CUI data — even if they store encrypted snapshots and never open a file — has custody of CUI. The backup platform is a CUI Asset, not just an SPA, and the provider's encryption management, access controls, and retention procedures are fully assessed.
Assessment Boundary vs Certification Boundary: What Changes and What Does Not
One of the most misunderstood aspects of CMMC scoping with external providers is the distinction between two overlapping but legally separate concepts.
The Certification Boundary is tied to your legal entity — your specific CAGE code. Only your organization receives the CMMC certificate. Your MSP does not receive a certificate simply because their tools and personnel participated in your assessment. The certification belongs to you.
The Assessment Boundary is broader. It includes all people, technology, and facilities that must be evaluated for your certification to be valid — including your ESP and their tools, if they are in scope. If your MSP is not independently CMMC certified, your assessor must evaluate them as part of your engagement.
Shared Responsibility: The Customer Responsibility Matrix
When a cloud service provider or MSP has already undergone a CMMC Level 2 assessment or holds a FedRAMP Moderate or High authorization, you do not need to re-audit their controls from scratch. You can inherit the controls they have already demonstrated — but only with documented evidence of exactly what they cover and what you must still configure yourself.
That evidence is the Customer Responsibility Matrix (sometimes called the Shared Responsibility Matrix). It is a control-by-control breakdown that defines, for each of the 110 CMMC practices, whether the provider is responsible, you are responsible, or responsibility is shared. Your assessor will review this matrix and verify that every gap — every control the provider does not cover — is addressed by your own implementation.
| Control Domain | Practice | Provider Responsible | You Are Responsible | Notes |
|---|---|---|---|---|
| Physical Protection (PE) | PE.L1-3.10.1 — Limit Physical Access | ✓ | ✗ | Provider secures the data center. You inherit this control. No action required on your end. |
| Access Control (AC) | AC.L2-3.1.1 — Authorized User Access | ✗ | ✓ | Provider delivers the platform. You configure the user accounts, security groups, and access permissions. You must evidence this configuration. |
| Identification & Auth (IA) | IA.L2-3.5.3 — Multi-Factor Authentication | ⊘ | ⊘ | Provider enables MFA capability. You must enforce and configure MFA policy for all accounts. Shared — both parties have obligations. |
| System & Comm Protection (SC) | SC.L2-3.13.11 — FIPS-Validated Cryptography | ✓ | ✗ | Provider uses FIPS-validated modules for data in transit and at rest. Inherited — verify with FIPS CMVP certificate number from provider. |
| Audit & Accountability (AU) | AU.L2-3.3.1 — System Audit Logging | ✗ | ✓ | Provider generates logs. You must enable audit logging, configure retention, and implement a log review process. Platform alone does not satisfy this control. |
| Configuration Management (CM) | CM.L2-3.4.2 — Security Configuration Settings | ✗ | ✓ | Default platform settings are not CMMC-compliant. You must configure, document, and maintain baseline security settings for your tenant. |
A Customer Responsibility Matrix gives both parties and the assessor a single reference showing which controls are inherited, which are your obligation, and which are shared. Every gap — every row where you are responsible — must be evidenced in your SSP.
Evidence You Must Collect From Providers Before Your Assessment
The evidence package you assemble for provider-delivered controls must be ready before the assessment begins. Assembling it under time pressure during the assessment is a common cause of delays and unexpected findings.
Provider Pitfalls That Expand Scope — and How to Prevent Them
Ownership is irrelevant to CMMC scoping. If a tool performs a security function protecting your CUI environment, it is an SPA — regardless of whether it belongs to you, your provider, or a third-party vendor your provider contracts with. The org chart does not define the assessment boundary; the technical function does.
A general IT firm without CMMC preparation that manages your CUI environment's firewall, patches your CUI servers, or holds administrative credentials to your enclave will be evaluated by your assessor — their documentation, their staff, their practices. If they are not prepared, the findings are yours. Many organizations discover this problem for the first time during their assessment.
A FedRAMP-authorized cloud platform is a foundation, not a finish line. The authorization covers the provider's controls — physical security, infrastructure encryption, platform availability. The controls you must configure in your tenant — user access, MFA enforcement, audit log retention, data classification — remain entirely your responsibility, regardless of what the provider's authorization package says.
Adding a new security vendor, switching EDR platforms, or expanding an MSP's access scope are all events that change your assessment boundary. If your asset inventory, network diagram, and SSP are not updated before the assessment, the assessor will find systems and relationships not accounted for in your documentation — and that discrepancy becomes an immediate confidence and scope problem.
The Bottom Line
Your CMMC certification boundary ends at your CAGE code. Your assessment boundary does not. Every external provider whose tools or personnel touch your CUI environment is inside that assessment boundary — their documentation, their staff, their practices, and their security posture are all evaluable during your engagement.
The path to containing that liability is deliberate: use CMMC-certified or FedRAMP-authorized providers where possible, obtain Customer Responsibility Matrices for every cloud service, document every provider relationship in your asset inventory and SSP, and treat any change to a provider relationship as a documentation event that must be captured before your next assessment.
Your MSP's preparedness is not their problem — it is yours. An assessor reviewing an uncertified provider's firewall configuration, interviewing their engineer about log review procedures, and finding gaps in their practices will mark those findings against your certification. Choose providers accordingly, and document the relationship before the assessor asks about it.