What 32 CFR 170 says about ESPs
32 CFR 170.4 defines an External Service Provider as external people, technology or facilities that an organization uses to provide and manage IT or cybersecurity services on its behalf. Within the CMMC Program, a provider counts as an ESP only if CUI or Security Protection Data (SPD) is processed, stored or transmitted on the ESP's assets. SPD includes data such as security logs and configuration data.
That gives three cases. Work out which one your MSP is in before anything else.
Case 1: the MSP is not a cloud service provider and handles your CUI. Its services are in your assessment scope and are assessed as part of your assessment. Your System Security Plan (SSP) must document that you use the ESP, your relationship with it, and the services it provides. The rule does not require the MSP to hold a CMMC certification of its own in this case.
Case 2: the MSP provides security services only, and touches your SPD but not your CUI. This covers managed EDR, SIEM or log monitoring, and vulnerability scanning. The assets that deliver those services are Security Protection Assets (SPAs), and they are assessed within your scope against the Level 2 requirements that apply to them. In practice, the MSP's RMM console, its SIEM tenant and its admin accounts are what an assessor follows.
Case 3: the MSP touches neither CUI nor SPD. It does not meet the ESP definition. An example is a help-desk provider with no access to in-scope systems, logs or configurations. Document why it is out of scope so you can answer that question at assessment.
ESP vs CSP: the cloud line
A cloud service provider (CSP) offers cloud services: on-demand network access to a shared pool of configurable computing resources. Some MSPs are CSPs too, because they run their own hosted "private cloud", backup vault or virtual desktop platform. When a CSP stores, processes or transmits your CUI, a different rule applies. DFARS 252.204-7012(b)(2)(ii)(D) requires the cloud offering to meet security requirements equivalent to the FedRAMP Moderate baseline. In practice that means a FedRAMP Moderate (or higher) authorization, or FedRAMP Moderate equivalency. 32 CFR Part 170 repeats the same condition for using a cloud offering with CUI (170.16(c)(2); 170.19(c)(2)(i), Table 4). Either way, it is a FedRAMP condition, not a CMMC certification the CSP earns.
Plain-English test:
| Question | If yes |
|---|---|
| Does the MSP run its own multi-tenant cloud that holds your CUI? | CSP rules apply. Require FedRAMP Moderate (or higher) authorization or equivalency evidence for that offering. |
| Does the MSP administer your systems or your cloud tenant? | It is an ESP in your scope (Case 1 or Case 2 above). |
| Both? | Both apply. Its hosted platform needs FedRAMP Moderate or equivalent, and its administration of your environment is assessed in your scope. |
Failure pattern: an MSP-hosted "private cloud" or backup vault holds CUI, but there is no FedRAMP authorization and no equivalency evidence. Calling the platform "secure" or "government-grade" proves nothing. See FedRAMP vs CMMC for how the two frameworks fit together.
Does my MSP need its own CMMC certification?
Not as a rule requirement, if the MSP is not a CSP. A non-CSP ESP is assessed within your assessment scope. It does not need a CMMC certification of its own. It may voluntarily undergo a CMMC certification assessment, which the rule says can reduce the ESP's effort in supporting your assessment. If it does, the minimum assessment type is set by your DoD contract requirement (32 CFR 170.19(c)(2)(ii)). Voluntary results do not replace your assessment, and the MSP's services still appear in your SSP and your scope.
A CSP holding your CUI is different. It needs FedRAMP Moderate or equivalent under DFARS 252.204-7012. That is a separate requirement from CMMC certification.
What this means right now. On July 13, 2026, the Department of War suspended the November 2026 Phase 2 transition. During the suspension, DoD requirements may designate only CMMC Level 1 (Self) or Level 2 (Self). As of mid-October 2026, DoD has not announced an end to the suspension. None of that removes your obligations under DFARS 252.204-7012. That clause requires NIST SP 800-171 (DoD currently enforces Revision 2) and requires you to report cyber incidents to DoD through DIBNet within 72 hours of discovery. Any requirement your MSP performs is still part of your self-assessment, your SPRS score and your affirmation. See current CMMC status for the timeline.
How inheritance flows to clients
The rule itself uses the term Customer Responsibility Matrix (CRM). Your SSP must document or refer to the CRM requirements for any provider whose responsibilities you rely on. A CRM is only useful at the level of individual objectives. NIST SP 800-171A breaks the 110 Level 2 requirements into 320 assessment objectives. The CRM should mark each one as one of the following:
- ESP-owned: the MSP performs the objective and supplies the evidence.
- Shared: both parties perform part of it. The CRM must say exactly which part each one owns.
- Client-owned: you perform it, even if the MSP's tools are involved.
An objective you say is inherited needs evidence behind it. Without a client-specific CRM and the MSP's supporting evidence, an inherited objective is just an assertion. That is true whether you are self-assessing or facing a third-party assessment. For how to build and maintain the matrix, see the Shared Responsibility Matrix for CMMC.
SPRS and POA&M note. A gap on an ESP-owned objective is your gap. It lowers your score under the CMMC Scoring Methodology (32 CFR 170.24), the same as a gap you own directly. You can carry it on a POA&M only if it meets 32 CFR 170.21:
- The score must be at least 0.8 of the maximum.
- No POA&M item may have a point value above 1. The one exception is 3.13.11 when encryption is used but is not FIPS-validated.
- Some requirements can never go on a POA&M: 3.1.20, 3.1.22, 3.12.4, 3.10.3, 3.10.4 and 3.10.5.
- Items must be closed within 180 days of the Conditional CMMC Status Date.
Several of the never-eligible requirements fall to MSPs. 3.1.20, for example, covers connections to external systems.
What to ask your MSP for: the evidence list
NIST SP 800-171A assesses objectives in three ways: EXAMINE (documents and records), INTERVIEW (people) and TEST (live mechanisms). Ask your MSP for evidence that will stand up to all three.
EXAMINE: documents to request
- A service description and a CRM written for your environment, mapped to the 800-171A objectives. A generic template the MSP gives every client does not count.
- SSP excerpts or implementation statements for every objective you claim to inherit. They should describe how the MSP performs the objective in your environment.
- Contract and SLA clauses that cover:
- incident notification to you within a defined window, short enough for you to meet the 72-hour DIBNet reporting requirement in DFARS 252.204-7012(c)
- evidence access and response times
- cooperation with your assessment
- CUI handling
- termination, data return and destruction
- For any cloud offering that holds your CUI: its FedRAMP Marketplace listing at Moderate or higher, or evidence that the offering meets security requirements equivalent to the FedRAMP Moderate baseline (DFARS 252.204-7012(b)(2)(ii)(D)).
- An inventory of subprocessors and tools. It should cover RMM, PSA, backup, EDR and SIEM, and say where each one stores your data or SPD.
- A personnel access list naming every MSP staff member with administrative rights to your environment, plus the screening attestation (3.9.1) and offboarding records (3.9.2).
- The MSP's own CMMC status, if it holds one: level, status date and scope. This is optional, and it is not a substitute for items 1 through 6.
INTERVIEW: people to talk to
- A named MSP point of contact who can explain how access control (3.1.x), audit logging (3.3.x) and identification and authentication (3.5.x) are performed in your tenant. They should answer from your environment, not from a sales deck.
TEST: things to see working
- MFA enforced on every MSP administrative account that reaches your environment (3.5.3)
- RMM and remote session logging that captures MSP activity (3.3.1)
- Log retention and review that matches what the CRM claims (3.3.x)
- Privileged access separated from the MSP technicians' everyday accounts (3.1.5)
Control lineage for the TEST items
| CMMC practice ID | NIST SP 800-171 Rev. 2 | What to see in NIST SP 800-171A terms |
|---|---|---|
| AC.L2-3.1.5 | 3.1.5 Least privilege | Privileged MSP functions limited to authorized accounts |
| AU.L2-3.3.1 | 3.3.1 System auditing | Audit records created and retained for MSP sessions |
| IA.L2-3.5.3 | 3.5.3 Multifactor authentication | MFA on privileged and network access by MSP staff |
| PS.L2-3.9.1 | 3.9.1 Screen individuals | Screening before MSP staff get access to CUI systems |
| PS.L2-3.9.2 | 3.9.2 Personnel actions | MSP staff access removed at termination or transfer |
Red flags:
- The MSP says "we're CMMC compliant" but has no artifacts behind it.
- One CRM is used for every client.
- A SOC 2 report is offered in place of mapping to 800-171A objectives.
- The MSP refuses to give assessors or your own assessment team access to evidence.
What an ESP package must contain
This is the MSP side of the list above. If you are the MSP, deliver this to each client before they need it.
- A CRM for each client, mapped to all 320 NIST SP 800-171A objectives and marked ESP-owned, shared or client-owned.
- SSP excerpts for inherited objectives. The client needs evidence that you actually do what the CRM claims.
- SLA language covering incident notification windows, evidence access and response times, assessment cooperation, CUI handling, and data return at exit.
- A personnel screening attestation and an access list for every staff member with access to the client's CUI or SPA environment.
- Subprocessor disclosure: every tool and vendor in the client's data path, including those that hold only SPD such as logs and configurations.
- For any hosted offering that holds the client's CUI: FedRAMP Moderate (or higher) authorization or equivalency evidence.
- Your own CMMC status, if you hold one: level, status date and scope.
Without this package, any objective the client claims to inherit has no supporting evidence. That holds whether the client is self-assessing or facing a third-party assessment.
Common MSP failure modes
- Same stack for everyone. One CRM for 30 clients won't survive a single assessment, because each client's CUI flow and contracted services are different. Each client needs a tailored CRM.
- "We're SOC 2, so we're fine." SOC 2 does not map cleanly to NIST SP 800-171A. Inheritance requires explicit mapping to the objectives.
- Hidden subprocessors. Every tool that stores client CUI or Security Protection Data is part of the ESP picture and must be disclosed.
- Security Protection Data overlooked. The MSP holds the client's logs and configurations, but nobody scoped it as an ESP.
- No way to scale. Rebuilding each client's CRM by hand from scratch does not scale across a client base.
Athena for MSPs
See the MSP portfolio. If you deliver CMMC services to defense contractors, see the service partner program.
Map your MSP's responsibilities before your next assessment
Whether you are the contractor or the MSP, the work is the same: one CRM per client, evidence behind every inherited objective, and an SSP that names the provider. MSPs and MSSPs can start with the service partner program. See also the MSP portfolio.
Prepared by the Athena Consulting Group CMMC practice. Athena is not a C3PAO and does not certify; this page explains the published rules so you can prepare.