The boundary test: What makes a change "significant"?

Drawing from the Scoping Guide language and practitioners doing assessments now, a consensus framework has emerged, one that several Summit speakers articulated in notably consistent terms.

The operative question is not whether something changed. Things change constantly in any active technology environment. The operative question is: Did the change alter the boundary of where CUI lives, the architecture that protects it, or the scope of what was previously assessed?

Travis Goldbach, VP of CMMC at Coalfire Federal, drew the line between routine operations and what triggers reassessment. Organizations patch systems, onboard users, and replace hardware every day — that's normal business activity, he said. But "if the change is material and it's impacting the security posture, the architecture, the scope, the control implementation, or the handling of CUI within the assessed environment, then some coordinations and reassessments are going to need to happen with your C3PAO."

Goldbach offered examples of changes that would meet that threshold: migrating to a new cloud service provider, a major architectural redesign, or expanding scope to a new program or business unit.

Adam Glover, Senior Director of CMMC Services at Insight Assurance, reinforced this point. The question, he said, is really about changes to the boundary of your environment, not the components within it. If you have a certified enclave, everything within that boundary is certified. "As long as you're adding components to that, within that, and they're configured according to what was certified, you should be fine."

Doug Barbin, President of Schellman, offered a practical test his team uses. If you're having a conversation where "the footprint of what you went through your assessment and passed your assessment on looks differently — in the footprint of where the CUI data sits," he said, that change is significant.

Koren Wise, CEO of Wise Technical Innovations, grounded the question in what it means for a contracting officer reviewing SPRS. A buyer making an award decision is looking at a contractor's UID as a representation that a specific information system was assessed and has an SSP associated with it. "So if that is no longer true," she said, "if they thought that UID means nothing, it doesn't have to be whatever was assessed back a year ago, it could be completely different now, and that would have no value for them."

The purpose of the certification is to give the government confidence that a specific, assessed environment is sufficiently protecting CUI. If your environment has drifted materially from what was assessed, the certification no longer provides that assurance, and stating otherwise is a misrepresentation.

Examining specific scenarios

When we opened the floor to audience questions during our Summit panels, the same scenarios came up repeatedly. Here's how speakers addressed them.

Adding a new laptop or replacing hardware

This scenario generates more anxiety than it should. Routine asset management within an existing, configured enclave does not constitute a significant change.

Glover addressed this directly: "Something simple, like something that's within the normal course of business — hey, you hire a new person, so you're going to add a new laptop. If you're a code developer, your environment's constantly changing, because that's what you do, is develop software." The new assets are being brought into the boundary under the existing configuration baseline, not extending the boundary itself.

Introducing new assets that weren't under the original assessment

This is where contractors can run into trouble. Gallagher walked through a specific example from the DoD's May FAQ guidance. If you're switching your technical environment or processes and controls that were previously not met are now flipping to met, the DoD says those controls need to be reassessed. 

Similarly, "if you're introducing new assets — laptops, configurations, cloud service environments that were not assessed as part of the original — that can also be considered a significant change, because it significantly changes your System Security Plan."

It's not the addition of any single new asset, it's the addition of assets that change what the SSP covers and what the assessment was validating.

Cloud migrations and MSSP/MSP changes

Moving from one cloud environment to another, say from AWS to Azure, or from one managed security provider to another, is a scenario multiple speakers identified as a clear trigger.

Adam Glover was direct: "If you go from AWS to Azure, obviously that's going to change your scope and your boundary." 

Sammy Chowdhury, Co-Founder and Chief Compliance Officer at Prescient Security, added something important: unlike FedRAMP, there is no formal significant change request process in CMMC. That means mergers and acquisitions, cloud migrations, MSSP changes, new SaaS tools, remote work shifts, and admin access changes can all alter your scope with no structured channel to flag or adjudicate the change. "You probably need to reach out to your C3PAO," he said.

On MSPs specifically, Chowdhury was clear that boundary relevance is the threshold question: "A new MSP could trigger, if it's relevant to the boundary, a significant change." Does this service provider have access to systems or data within your assessed scope? That's the question to answer.

New CAGE codes and physical locations

This issue generated a lot of discussion at the Summit, and it trips people up because the answer differs depending on whether you're asking a definitional question or a practical one.

Tommy Kromer, GovTech Practice Manager at AWS Security Assurance Services, was unambiguous on the definitional question. Your authorization is tied to your CAGE code, he explained. A new CAGE means a new authorization, full stop. "Definitionally, it's a significant change."

The practical burden may be low, though. "From an assessment standpoint, it's not that significant. It's a very easy reassessment if it truly is a second of the same kind. But it is a completely new assessment."

Marci Womack, Managing Director at Schellman, added that the program's current tooling creates structural constraints: C3PAOs cannot simply add a CAGE code to an existing certification. The technical architecture of how certifications are issued in EMASS means any new CAGE code will require its own certification process, regardless of how similar the underlying environment is to the original. "We're not allowed to go, edit, assert, and add a CAGE code in. We're going to have to issue a brand new certification related to that CAGE code." A pared-down assessment may be possible, but some form of validation and assessment is required.

Manufacturing equipment, OT, and CNC machines

Manufacturers in the DIB need to pay particular attention here. Barbin raised OT as an underappreciated vector: robotic systems, CNC machines, and other manufacturing equipment that ingests CAD files or technical specifications from your CUI environment. As those machines come into the picture, he said, they have to be factored in. If the footprint of where CUI sits has changed, the change is significant.

The operative question for manufacturers is whether the equipment has access to or processes CUI. If CAD files or technical specifications that qualify as CUI are flowing to a machine, that machine is potentially in scope. Adding new equipment that expands or changes the CUI data flow should be evaluated carefully.

Tooling changes that alter implementation statements

One scenario that often goes unexamined is upgrading software or changing tools in a way that materially changes how a control is implemented. Womack's recommendation was to build an internal framework specifically for this. 

Organizations should have a process for asking whether a given tooling change constitutes a significant change, run a security impact analysis, and document their reasoning. "If you can defend the decision, show that you have a framework for evaluating it, and bake that into your annual self-assessment," she said, it gives the authorizing official confidence going into affirmation. 

Kromer raised a related example: version upgrades that change a tool's FedRAMP authorization status. "They go to a new product, and they're like, oh yeah, version 12 is out now, I want it. Version 12 is not FedRAMP, right? Version 10 was FedRAMP." A tool that held a given authorization status and loses it after an upgrade is a control implementation change that could constitute a significant change.

Falling out of CMMC compliance

This scenario is less obvious but came up in the Summit discussion. In Kromer's view, it's unambiguous: if you were in compliance and you're now not, that's a significant change, and it's time for a reassessment.

The implication for contractors: if you discover a gap in your compliance posture between assessments, you shouldn't simply wait for your next assessment cycle and quietly remediate. That shift in compliance status may itself require reporting and reassessment, and self-reporting is strongly preferable to having a gap discovered externally.

Navigating the gray areas of CMMC compliance

Several speakers were candid about the fact that significant gray areas remain, and that this reflects where the CMMC program is in its maturity.

Adam Glover acknowledged it plainly: "It's really discretionary right now. Like Mike said, they did put out an FAQ this month about it, but there really is a lot of gray area in what's considered a significant change and what isn't."

Womack has watched the same ambiguity play out in FedRAMP for years and sees the stakes as higher here. She said she'd love for the DoD to get the definition tighter and give the ecosystem more confidence in how they're making decisions, but the practical answer in the meantime is to build your own framework rather than wait for prescriptive guidance that may be slow to arrive. 

Document your security impact analysis process. When a change happens, run it through the framework, document your reasoning, and integrate it into your annual self-assessment cycle. The goal is not to produce a defensible paper trail for its own sake, it's to give your Affirming Official the information and confidence needed to make an accurate affirmation.

The Cyber AB's Town Hall reinforced this point. "Scope decisions are governance decisions," was the Town Hall’s framing. "Your SSP must reflect how your environment operates, not how it operated on assessment day."

Six ways contractors can manage “significant change” between assessments

Drawing from the regulatory guidance and the collective judgment of the practitioners who spoke at our Summit, here's a practical framework for defense contractors navigating this question:

1. Understand the boundary test. The central question is whether a change affects the boundary of your assessed environment: where CUI lives, what architecture protects it, and what was validated in your assessment. Changes within an established, configured boundary generally don't require a new assessment. Changes that extend, restructure, or fundamentally alter that boundary likely do.

2. Build a security impact analysis process. Don't wait for a major change to ask the question. Establish an internal process for evaluating changes against the significant change threshold, document your reasoning, and integrate it into your annual self-assessment cycle. This improves decision quality and gives your Affirming Official the confidence to make an accurate affirmation.

3. Know what your Affirming Official is signing. The annual affirmation is not a checkbox. It is a legal representation with False Claims Act implications. The Affirming Official should understand the current state of the environment, how it compares to what was assessed, and whether any changes trigger the significant change threshold. C3PAOs can support that evaluation, but they can't make it for you.

4. Read the DoD CMMC FAQs. These have been updated as recently as May 2026 and address significant change directly, along with other questions that have emerged from the program's early enforcement phase. If you're tracking CMMC guidance, this should be a bookmarked resource.

5. Engage your C3PAO before major changes, not after. Multiple speakers emphasized that C3PAOs can offer professional opinions on whether a planned change would be considered significant. That's a valuable conversation to have before you migrate cloud environments, bring on a new MSSP, open a new facility, or make major architectural changes, not after the fact when you're already committed.

6. Keep your SSP current. Your SSP is the living record of how your environment works. If it doesn't reflect your environment as it operates today, you have a problem that compounds over time. Every significant operational change should be evaluated against both the significant change threshold and the need to update your SSP.

7. Stay current as guidance evolves. The DoD has signaled it will continue to refine and publish guidance as specific scenarios arise from the program's early enforcement phase. The CMMC FAQ document is a living resource, and the Cyber AB Town Hall series has become a reliable venue for new interpretations as they emerge. We cover CMMC program and ecosystem updates extensively on the Secureframe Blog, and share recaps of each Cyber AB Town Hall on CMMC.com. Rules are being written in real time, and staying current is part of managing compliance well.

Stay CMMC compliant as your environment evolves  

The organizations that will navigate significant change most cleanly are the ones that have built the infrastructure to know when something has changed, what it means, and what to do about it before the annual affirmation.

That's the problem Secureframe Defense is built to solve. 

• Our platform's continuous evidence collection and live SPRS scoring give you a real-time view of your compliance posture, so a shift in your environment surfaces as a signal rather than a surprise. 
• Automated SSP maintenance keeps your documentation in sync with how your environment actually operates, not how it looked on assessment day. 
• Built-in scoping and implementation guidance helps teams evaluate whether a planned change crosses the significant change threshold before they're committed to it. 
• And for organizations standing up new locations or CAGE codes, Virtual Desktops and automated enclave provisioning mean a consistent, assessment-ready environment can be deployed quickly, without rebuilding your compliance posture from scratch each time.

Marc Rubbinaccio, VP of Cybersecurity and Compliance at Secureframe, went through a Level 2 assessment himself as our team built the product. "Completing our CMMC Level 2 assessment validated how assessors evaluate scope, documentation, and evidence in practice," he said. "We used that experience to build Secureframe Defense for CMMC so customers can prepare in a way that aligns cleanly with assessment expectations from the start."

Request a demo to see how Secureframe Defense supports continuous compliance across your certification cycle.