Because they often change who can administer systems, where data lives, and which assets sit inside the certified boundary. That can alter the assessed scope even if the business process looks similar. Security teams should treat provider changes as identity and boundary changes, not just infrastructure swaps.
Why This Matters for Security Teams
CMMC scoping is not only about systems and data, but also about who can touch them and how that access is governed. A cloud migration or MSP change can introduce new admin pathways, shared responsibility gaps, and unmanaged secrets that quietly expand the certified boundary. That matters because certification evidence must show control over identities, configurations, and data flows, not just intent.
Security teams often underestimate how quickly a provider transition changes the control environment. A new cloud tenant, a different backup model, or an MSP’s remote administration tooling can shift where sensitive data is stored, which service accounts exist, and whether privileged access is still attributable. NHIMG’s Top 10 NHI Issues research highlights how often organisations struggle to manage these non-human access patterns consistently across environments. That is exactly the kind of drift that can turn a previously scoped asset into a new assessment problem. In practice, many teams discover the boundary moved only after an assessor asks for evidence, rather than through intentional change control.
How It Works in Practice
In CMMC programs, the question is not simply whether the business process stayed the same. It is whether the cloud provider or MSP changed the implementation of controls that protect CUI, including access control, auditability, and configuration management. If the new provider introduces its own admin roles, support accounts, API keys, or delegated tooling, those become part of the security story and often part of the evidence set.
Current guidance aligns well with NIST’s control model: the NIST Cybersecurity Framework 2.0 emphasises governance, access control, and resilience, while NIST SP 800-53 Rev 5 Security and Privacy Controls gives concrete control families for identifying, authenticating, logging, and restricting privileged activity. For cloud migrations, teams should map each workload to its data classification, confirm whether the provider is storing or processing CUI, and verify who can administer encryption, backups, logging, and incident response functions. For MSP transitions, they should review federation, break-glass access, session recording, and whether the MSP uses its own shared credentials or per-operator identities.
- Revalidate the CMMC boundary before cutover, not after, and update the system security plan to match the new operating model.
- Inventory all human and non-human identities, including service accounts, automation tokens, and provider support roles.
- Confirm privileged access is least-privilege, time-bound where possible, and fully logged.
- Test evidence collection for configuration changes, access reviews, and incident handling across the new provider stack.
NHIMG’s OWASP NHI Top 10 is useful here because cloud and MSP transitions often rely on machine identities, automated workflows, and delegated privileges that are easy to overlook. These controls tend to break down when migration teams preserve old access paths for convenience, because standing privileges and inherited secrets survive longer than the original project timeline.
Common Variations and Edge Cases
Tighter boundary control often increases migration overhead, requiring organisations to balance certification certainty against speed and operational convenience. That tradeoff becomes sharper when the MSP manages multiple customers from one platform or when the cloud design relies on shared services that were not originally built for CMMC scope discipline.
There is no universal standard for every provider pattern yet, so current guidance suggests treating three cases differently. First, a lift-and-shift to a new cloud account may look simple, but if logging, key management, or admin delegation change, the assessment impact can still be material. Second, a managed service arrangement can be low risk when it is isolated, well documented, and identity-scoped, but it becomes problematic when the MSP uses shared jump hosts or broad tenant-wide roles. Third, hybrid operations often create the most confusion because responsibility splits across internal staff, the cloud provider, and the MSP, leaving gaps in evidence ownership.
For organisations handling CUI, the safest assumption is that any change in provider, tenant, or remote administration model can affect both technical controls and assessment scope. NHIMG’s 230M AWS environment compromise and Codefinger AWS S3 ransomware attack illustrate how cloud misconfiguration and identity weaknesses quickly become security events. In edge cases, provider change risk is highest when inherited permissions, opaque subcontractors, or undocumented automation make it impossible to prove who can access CUI at any given moment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Provider changes often alter who is authorised to access systems and data. |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle control is central when providers add or remove admins. |
Inventory, approve, and periodically review all accounts and service identities.
