An MSP serving defense contractors does not automatically need its own CMMC certification. The decisive question is what the MSP actually does with Federal Contract Information (FCI), Controlled Unclassified Information (CUI), and Security Protection Data (SPD), and whether the provider is functioning as an MSP, another type of External Service Provider (ESP), or a Cloud Service Provider (CSP).
As of September 2026, there is another important wrinkle: the Department suspended CMMC Phase II, which had been scheduled to begin November 10, 2026. The program is currently paused in Phase I, with Level 1 and Level 2 self-assessment requirements remaining in place. That pause does not erase existing safeguarding duties under DFARS 252.204-7012. Before buying compliance software or promising a customer that your MSP is “CMMC compliant,” map your services, tools, privileged access, and data flows to each customer’s CMMC boundary.
Table of Contents
What CMMC Requires From MSPs in 2026
The first requirement is precision. CMMC does not create one universal certification requirement for every company that happens to call itself an MSP.
The MSP’s obligations depend on the defense contractor’s contract, the information involved, the systems providing security protection, and the way the MSP delivers its services. The current CMMC implementation guidance also matters because the July 2026 suspension changed the expected rollout schedule.
| MSP situation | What it means | First question to answer |
|---|---|---|
| MSP only supports ordinary corporate IT | The service may sit outside Level 2 CMMC scope if it does not process CUI or SPD | Can any MSP asset actually receive CUI or security data? |
| MSP administers the CUI environment | Its services can become part of the contractor’s assessment scope | What controls and evidence are inherited from the MSP? |
| MSP systems hold CUI | A non-CSP ESP’s relevant services are included in the customer’s scope | Where exactly is CUI processed, stored, or transmitted? |
| Provider supplies its own cloud offering that holds CUI | Cloud-specific DFARS requirements become important | Does the cloud offering meet the required FedRAMP Moderate standard or equivalency? |
| MSP is itself a defense subcontractor | Flowed-down contractual requirements may independently apply | Which DFARS and CMMC clauses appear in the subcontract? |
This distinction prevents a surprisingly expensive error: purchasing a certification project before determining which systems, services, and legal entities actually need to be covered.
The Decision Hinge: MSP, ESP, or CSP?
For CMMC Level 2, the important category is often the External Service Provider. Under the CMMC scoping rules, an ESP can include external people, technology, or facilities used to provide IT or cybersecurity services when relevant CUI or Security Protection Data resides on those external assets.
The Department’s CMMC resources and Level 2 scoping guidance draw an especially useful line for MSPs: an ESP providing technical support without hosting its own cloud platform can be an MSP rather than a CSP. Merely administering somebody else’s cloud service does not automatically turn the MSP into the cloud provider.
This matters because 32 CFR Part 170 treats a CSP holding CUI differently from a non-CSP ESP holding the same information. The underlying CMMC program rules in 32 CFR Part 170 also distinguish CUI from SPD.
| Provider and data | CMMC treatment | What the contractor should verify |
|---|---|---|
| CSP processes, stores, or transmits CUI | CSP must satisfy the applicable FedRAMP requirements referenced by DFARS 252.204-7012 | Authorization or acceptable equivalency evidence for the actual cloud offering |
| Non-CSP ESP processes, stores, or transmits CUI | Relevant ESP services enter the contractor’s assessment scope | Applicable requirements, service boundary, CRM, and evidence |
| CSP processes SPD but no CUI | Relevant services are assessed as Security Protection Assets | Which security functions and data the CSP handles |
| Non-CSP ESP processes SPD but no CUI | Relevant services are assessed as Security Protection Assets | How the MSP protects the CUI environment and proves those controls |
| Provider processes neither CUI nor SPD | For Level 2, it does not meet the CMMC definition of an ESP on that basis | Evidence that the service really remains outside those data flows |
Security Protection Data deserves special attention because it can pull an MSP into scope without the MSP storing engineering drawings or other obvious CUI. SPD includes security-relevant information such as configurations, logs, vulnerability information, and credentials that protect the assessed environment.
That means an RMM platform, security console, privileged-access system, SIEM workflow, ticketing process, or administrative workstation should not be declared out of scope merely because nobody intentionally uploads a CUI document to it. First determine what security information actually passes through the service.
Does an MSP Need Its Own CMMC Certification?
Usually, not simply because it provides managed services to a CMMC customer. A non-CSP MSP can support a contractor while the relevant MSP services are assessed as part of the contractor’s scope rather than through a separate MSP certification.
That does not make the MSP invisible. The contractor still needs evidence that applicable requirements performed by the MSP are implemented, and the assessor or self-assessment process must be able to evaluate those responsibilities.
A different answer can apply when the MSP is independently subject to a defense contract or subcontract containing CMMC requirements. In that situation, the MSP must evaluate its obligations as a contractor or subcontractor, not merely its role as somebody else’s service provider.
An MSP may also choose to obtain its own CMMC status where the program permits it. That can reduce repeated customer evidence work when many defense customers use the same defined service environment, but it should be a business decision based on customer demand and scope. It is not a magic cloak that makes every customer configuration compliant.
The 2026 Phase II suspension makes premature purchasing especially risky. Do not spend against an old assumption that every Level 2 customer will automatically require a C3PAO assessment beginning November 10, 2026. Verify the current solicitation, subcontract, and Department guidance first.
What Level 2 Means for the MSP’s Actual Work
CMMC Level 2 currently uses the 110 security requirements in NIST SP 800-171 Revision 2 for the CMMC program. This is easy to misread because NIST has since published Revision 3. For CMMC work, follow the version incorporated into the current CMMC program and the customer’s applicable contract rather than silently substituting a newer standard.
An MSP does not need to turn all 110 requirements into 110 separate products. It does need to identify which requirements its services implement wholly, partially, or jointly with the customer.
| MSP function | Typical evidence question | Where weak implementations hide |
|---|---|---|
| Identity and privileged administration | Who can administer in-scope systems, and how is that access authenticated and removed? | Shared admin accounts, forgotten vendor accounts, weak offboarding |
| Remote support | How is remote access authorized, restricted, monitored, and recorded? | Uncontrolled RMM access or support accounts outside the documented boundary |
| Configuration management | How are approved configurations and changes documented? | Technicians making production changes without traceable approval |
| Logging and monitoring | Which systems create logs, where are they stored, and who reviews relevant events? | A monitoring product exists, but evidence of review and responsibility does not |
| Vulnerability and system integrity work | How are vulnerabilities, patches, alerts, and remediation decisions tracked? | Scanner output without ownership or remediation records |
| Incident response support | Who detects, escalates, preserves evidence, and communicates an incident? | MSP and customer each assume the other party will report |
MFA is a good example of the difference between buying a capability and proving its operation. An MSP may own an identity product, but the customer still needs evidence showing where MFA is enforced, which administrative paths are covered, and how exceptions are controlled. For the implementation side, the KIOPTRIX MFA rollout guide provides a useful next step.
Build the Customer Responsibility Matrix Before the Assessment
The Customer Responsibility Matrix, or CRM, is one of the most useful documents in an MSP relationship because it converts a fuzzy statement such as “we handle security” into specific ownership.
The CMMC scoping framework expects the use of an ESP, the relationship with that provider, and the services supplied to be documented in the customer’s System Security Plan and described through the provider’s service description and CRM.
A useful CRM should identify at least four states for each relevant responsibility: customer owned, MSP owned, jointly implemented, or not applicable within the defined service. “Included” is not enough. An assessor needs to understand what is actually done and where the evidence lives.
| CRM item | MSP should document | Customer should be able to verify |
|---|---|---|
| Administrative access | Account model, authentication, approval, revocation | Which MSP identities can reach in-scope assets |
| Security monitoring | Platforms, coverage, escalation process | Which events are monitored and who responds |
| Configuration changes | Change workflow and records | How unauthorized changes are prevented or detected |
| Incident handling | Detection, escalation, evidence-preservation responsibilities | Who performs each contractual reporting step |
| Cloud dependencies | Third-party services and responsibility boundaries | Whether CUI reaches those services |
| Encryption | Where encryption is applied and who controls keys | Whether the claimed protection matches the actual data path |
If encryption ownership is still foggy, work through an encryption questionnaire before completing the CRM. Encryption decisions become much easier to assess once the data location, key ownership, transmission path, and administrative access are visible on one page.
The MSP Evidence Package Should Exist Before Anyone Asks for It
A policy saying a control exists is weaker than a policy plus technical configuration plus evidence that the process actually operates. MSPs supporting defense contractors should organize evidence around that distinction.
- Service description: what the MSP delivers, which environments are included, and what is explicitly excluded.
- Customer Responsibility Matrix: control ownership and shared responsibilities.
- Architecture and data-flow information: enough detail to show CUI, FCI, SPD, administrative traffic, and third-party dependencies.
- Privileged-access evidence: account inventories, access approvals, authentication settings, and removal records.
- Configuration evidence: relevant security settings, baselines, and change records.
- Operational evidence: tickets, alerts, reviews, vulnerability remediation, and other records showing that documented processes are actually performed.
- Incident documentation: escalation paths, contacts, evidence-preservation responsibilities, and reporting handoffs.
- Provider evidence: documentation for cloud and other subcontracted services relied upon by the MSP.
- Contracts and service agreements: commitments supporting the responsibilities stated in the SSP and CRM.
A SOC 2 report, ISO certification, vendor security questionnaire, or other third-party assurance document may help support particular claims, but it should not be treated as a substitute for demonstrating the CMMC requirements applicable to the actual service.
CUI in a Cloud Service Changes the Requirement
If an external cloud service provider processes, stores, or transmits covered defense information for contract performance, DFARS 252.204-7012 requires the contractor to ensure that the provider meets security requirements equivalent to the FedRAMP Moderate baseline and the related incident-handling requirements in the clause.
The controlling language is available in DFARS 252.204-7012. The Department also maintains separate FedRAMP Moderate equivalency guidance for cloud service offerings.
Encryption does not create a simple escape hatch. Putting encrypted CUI into an otherwise unsuitable external cloud service does not by itself remove the DFARS cloud requirement.
Also avoid a common classification error: an MSP does not necessarily become the CSP merely because it configures or administers a customer’s third-party cloud environment. Identify who actually provides the cloud service offering. Then separately document what the MSP administers and what the underlying CSP provides.
Incident Reporting Responsibilities Cannot Be Left Between the Chairs
DFARS 252.204-7012 defines rapid reporting as reporting a covered cyber incident within 72 hours of discovery. The clause also requires preservation and protection of images of known affected systems and relevant monitoring or packet-capture data for at least 90 days after submission of the incident report.
For an MSP relationship, the dangerous gap is usually not the existence of an incident response tool. It is ambiguity about who acts during the first few hours.
- Who decides that an event has become a potentially reportable cyber incident?
- Who notifies the prime contractor or next higher-tier subcontractor?
- Who submits any required government report?
- Who preserves system images and monitoring data?
- Who controls the evidence if the MSP operates the logging platform?
- Who maintains after-hours contacts?
- How quickly must the MSP escalate an alert to leave enough time for the contractor’s contractual deadline?
If the MSP itself receives DFARS 252.204-7012 as a subcontract flowdown, review those obligations separately. A service agreement between an MSP and its customer cannot silently override a federal contract clause that actually applies to the subcontract.
Your 15-Minute MSP CMMC Scope Check
Before purchasing another security product, perform this small scope exercise. A clean boundary often saves more money than a larger tool stack.
- Write down the customer’s actual requirement. Record the contract or solicitation, requested CMMC level, and relevant DFARS clauses rather than relying on a sales email.
- Identify the information. Mark where FCI, CUI, and SPD enter your service.
- Identify the assets. Include MSP workstations, RMM tools, ticketing systems, security consoles, vaults, logging systems, and other platforms that may hold the relevant information.
- Identify the provider type. Decide whether each external service is an MSP, other ESP, CSP, or unrelated provider for the particular service.
- Trace every third-party dependency. Do not stop at “our MSP handles it.” Determine which underlying SaaS and cloud platforms receive data.
- Mark control ownership. Customer, MSP, shared, or not applicable.
- Locate evidence. For every MSP-owned responsibility, identify the configuration, record, ticket, log, report, or interview evidence that supports it.
- Test the incident handoff. Confirm who calls whom, who preserves evidence, and who owns contractual reporting.
If you cannot finish steps two through five, you are not ready to price a CMMC remediation project. The uncertainty is still a scoping problem, not a software problem.
What the MSP Contract Should Make Explicit
A strong MSP contract will not guarantee that the customer “is CMMC compliant.” It will define the services and evidence that allow the customer to evaluate and demonstrate its own obligations.
| Contract question | Why it matters | Warning sign |
|---|---|---|
| Which systems and services are included? | Creates a usable CMMC boundary | “All IT” with no technical scope |
| May CUI or SPD enter MSP systems? | Changes scoping and possibly cloud requirements | Provider cannot answer at platform level |
| Which controls does the MSP operate? | Feeds the CRM and SSP | Generic “security included” language |
| What assessment evidence will be provided? | Prevents an evidence scramble later | Provider claims configurations are confidential and supplies nothing usable |
| Which subcontractors and cloud services are used? | Reveals hidden dependencies | No inventory of downstream providers |
| How are incidents escalated? | Supports contractual reporting deadlines | Only a generic support-ticket SLA |
| What happens when the service changes? | Protects the assessed configuration | Material platform changes can occur without notice |
| How does exit work? | Supports account removal, evidence retention, and data disposition | No defined offboarding or data-return process |
Defense contractors evaluating a provider can adapt the KIOPTRIX vendor security questionnaire template to collect this evidence before contract signature rather than after an assessor asks for it.
When Paying for More CMMC Help Makes Sense
The current Phase II pause makes sequencing more important than ever. Spend first on unresolved risk and evidence gaps, not on the label with the largest invoice attached.
| Approach | Reasonable when | Do not expect it to solve |
|---|---|---|
| Internal / DIY | Scope is small, contracts are clear, and staff understand CUI and NIST SP 800-171 | Independent validation or missing expertise |
| Compliance software | Many assets, customers, owners, and recurring evidence items must be tracked | Bad scoping, weak controls, or contractual interpretation |
| CMMC consultant | The MSP cannot confidently classify services, build the CRM, or translate gaps into remediation | Responsibility for operating controls after the engagement |
| Legal or contracting advice | Flowdowns, CUI designation, liability, or contract language is genuinely ambiguous | Technical implementation |
| Independent assessment support | A current procurement or future program requirement actually justifies it | Security weaknesses that remain unfixed |
For budgeting, separate scoping, remediation, tooling, documentation, internal labor, and assessment work instead of buying one opaque “CMMC package.” The CMMC compliance cost guide explains how those cost layers differ.
An MSP with one defense customer and a tightly isolated enclave may need a very different investment from an MSP standardizing a reusable service for dozens of CUI customers. The number of employees alone does not tell you which project is harder.
Common MSP CMMC Failure Modes
Most expensive CMMC problems begin as boundary or ownership mistakes rather than missing logos in the security stack.
- Calling the company “CMMC compliant” without defining the assessed scope. CMMC status attaches to a defined assessment scope, not every service a provider happens to sell.
- Assuming no CUI means no scope. Security Protection Data can make an MSP service relevant to Level 2 assessment scope.
- Letting CUI leak into support systems. Ticket attachments, screenshots, remote sessions, and technician notes can quietly change the boundary.
- Treating MSP administrator devices as ordinary office laptops. A privileged endpoint may have a very different relationship to the assessed environment.
- Confusing an MSP with the CSP it administers. The underlying cloud offering and the MSP service have different responsibilities.
- Relying on a certification name instead of a CRM. A third-party report can support evidence, but it does not answer who performs each CMMC requirement for this customer.
- Ignoring downstream providers. The MSP’s own SaaS, security, backup, and support dependencies can create additional data paths.
- Buying before scoping. Adding tools to an undefined boundary often creates more consoles, more evidence, and more places for SPD to live.
Frequently Asked Questions
Can an MSP support a CMMC Level 2 contractor without having its own CMMC certification?
Yes, depending on the relationship. A non-CSP MSP does not automatically need a separate CMMC certification merely because it supports a Level 2 contractor. Relevant MSP services may instead fall within the contractor’s assessment scope. A separate contractual requirement can change that answer, so the MSP must also review any clauses flowed down to it.
Does managing AWS, Azure, or another cloud platform make the MSP a CSP?
Not by itself. An MSP that manages a third-party cloud offering for a customer can remain a non-CSP ESP. The classification turns on who provides the cloud service offering, not simply who administers its configuration.
Can encrypted CUI be stored in a non-FedRAMP cloud service?
Encryption alone does not remove the DFARS 252.204-7012 requirement for an external CSP used to process, store, or transmit covered defense information. Verify the actual cloud offering against the applicable FedRAMP Moderate authorization or equivalency requirement.
Does the 2026 CMMC Phase II suspension mean NIST SP 800-171 no longer matters?
No. The suspension changed the CMMC rollout, not the underlying need to protect covered defense information under applicable contracts. The current CMMC Phase I posture also retains Level 2 self-assessment requirements based on NIST SP 800-171 Revision 2.
What to Do Before You Promise CMMC Support
Take one defense customer and draw a single-page service map. Put the customer’s CUI environment in the center. Around it, list every MSP administrator, endpoint, remote-access platform, security console, ticketing system, logging service, cloud dependency, and credential store that can touch CUI or SPD.
Then mark each item as customer owned, MSP owned, shared, CSP, other ESP, or outside scope. Circle any item for which you cannot identify the data involved or the evidence owner.
Those circles are your next tasks. Resolve them before purchasing another compliance platform, promising certification, or quoting remediation. In CMMC work, a clear boundary is not paperwork around the security program. It is the map that tells you which security program you actually have to build.
Last reviewed: 2026-10