When Your MSP Is In Scope: External Service Providers and CMMC Responsibility

A defense contractor called us convinced they were nearly ready for their Level 2 assessment. Their internal controls looked solid. Then we asked a simple question: who patches your servers, manages your firewall, and administers your accounts? The answer was a managed service provider three states away. The follow-up question landed harder. How does that MSP prove it does those things securely? Silence.

This is one of the most misunderstood corners of CMMC. Many contractors outsource the bulk of their IT and security operations to a managed service provider, and they assume that outsourcing the work also outsources the responsibility. It does not. When an external service provider handles security-relevant functions on your behalf, that provider is part of your assessment scope, and its practices are your problem.

The ESP Concept and Why It Matters

CMMC uses the term external service provider, or ESP, to describe an organization outside your boundary that provides services affecting the security of your CUI environment. An MSP is the most common example, but the category also covers managed security service providers, cloud service providers, and specialized vendors that touch in-scope systems.

The distinction that trips people up: an ESP is in scope when it provides services that could affect the confidentiality, integrity, or availability of CUI, even if the ESP never directly stores or processes CUI itself. Your MSP might never open a CUI file, but if it administers the domain controller, manages the firewall rulebase, or holds privileged credentials to your enclave, its security posture directly affects yours. An assessor will treat the MSP's relevant practices as part of your control implementation.

Shared Responsibility Is Not Vague

The phrase "shared responsibility" gets thrown around until it stops meaning anything. For CMMC, it has to be concrete. Every security-relevant function needs an owner, and every control that the ESP contributes to needs a documented split of who does what.

This is what a Customer Responsibility Matrix, or CRM, is for. A good CRM walks through the relevant NIST SP 800-171 controls and states, for each one, whether the responsibility is the customer's, the provider's, or shared, and describes how the provider meets its portion. Cloud providers with FedRAMP authorizations typically publish these. Many MSPs, especially smaller ones, have never produced one and don't understand why they need to.

The danger of vagueness is a control that everyone assumes someone else owns. Audit logging is a classic example. The contractor thinks the MSP centralizes and reviews logs. The MSP thinks it just forwards logs and the contractor reviews them. Nobody reviews the logs. Control 3.3.5 (correlate audit review, analysis, and reporting) is unmet, and neither party realized it until the assessor asked to see the review records.

The MSP's Own CMMC Obligations

Here is where the ground has been shifting, and where contractors need to pay close attention. The direction of CMMC policy is that ESPs handling or affecting CUI don't get a free pass on the security they provide. Depending on the nature of the service and whether the ESP processes, stores, or transmits CUI, the provider may itself need to meet CMMC requirements, and its relevant practices get evaluated as part of your assessment.

Practically, this means you can't just pick the cheapest MSP and hope. You need a provider that either carries its own certification appropriate to the services it delivers or can demonstrate that the specific practices it performs on your behalf meet the applicable controls with real evidence. An MSP that says "trust us, we're secure" but can't produce a CRM, can't show its own hardening standards, and can't hand over log-review records is a liability sitting inside your boundary.

Ask any prospective or current MSP:

• Do you provide a Customer Responsibility Matrix mapped to NIST SP 800-171?
• Which controls do you fully own, and can you show evidence of how you meet them?
• How do you handle your own administrators' access to our environment?
• What is your posture toward CMMC for the services you deliver to defense contractors?

The quality of the answers tells you whether the relationship helps or hurts your assessment.

Privileged Access Is the Sharpest Edge

The single most sensitive thing an MSP holds is privileged access to your environment. Domain admin credentials, firewall management, hypervisor access. If those credentials or the MSP technicians who use them aren't controlled to the same standard as your own privileged users, you have a gap that no amount of internal diligence fixes.

Assessors look closely at this. Does the MSP use multifactor authentication for administrative access to your systems? Are its technicians' accounts individually attributable, or is everyone sharing one admin login? Is that access monitored and logged on your side, so you'd know if it were misused? A shared, unmonitored MSP admin account is one of the fastest ways to turn a promising assessment into a bad one.

Getting the Contract Right

The relationship with an ESP is ultimately governed by a contract, and too many contractors have MSP agreements written years before CMMC that say nothing about security responsibilities, evidence, or assessment cooperation. When the assessor asks the MSP to produce records and the MSP has no contractual obligation to help, you're stuck.

Update the agreement so it obligates the ESP to maintain the practices in the CRM, produce evidence on request, support your assessment, notify you of security incidents affecting your environment, and meet the CMMC-relevant requirements for the services it provides. A security relationship that isn't written down is a security relationship you can't prove.

How NOXMON Helps

Untangling the shared-responsibility knot between a contractor and its service providers is one of the most valuable things a knowledgeable partner can do, because it's the area contractors most often get wrong without realizing it.

NOXMON's Compliance Framework Review maps your ESP relationships against the full control set and identifies exactly which controls depend on your providers, then pressure-tests whether those providers can actually back up their portion. We help build or validate the Customer Responsibility Matrix so there are no orphaned controls that everyone assumes someone else owns. Through our Technology Risk Management and Third-Party Risk services, we assess your MSPs and other ESPs as the risk exposures they are, including how their privileged access to your environment is controlled and monitored.

When gaps surface, our Virtual CISO service helps you have the hard conversations with providers, renegotiate the security terms of the relationship, and hold them to the standard your certification depends on. And where you'd rather bring security operations in-house or supplement a weak MSP, our 24x7 SOC Monitoring gives you a provider whose entire purpose is to meet the controls, with the evidence to prove it.

The Takeaway

Outsourcing your IT never outsourced your accountability, and CMMC makes that explicit. Your MSP and other external service providers are inside your scope whether you planned for it or not. Treat them as extensions of your security program, demand the same rigor from them that you apply to yourself, and document the division of responsibility so precisely that no control falls through the cracks. The provider you can't get evidence from is the provider that will fail your assessment for you.