The DoW has updated their CMMC Frequently Asked Questions document for the 3rd time since November 2025. The problem is they didn’t tell anybody about it. It’s not clear where they get frequent questions because they barely interact with industry outside of FAQ updates. On the other hand we interact with new and exciting questions every Friday! Maybe we should put out an FAQ doc…
Transcript
[0:12] Daniel
Hello everybody. Welcome to CUI Hotline. I don’t even know what episode we’re on anymore.
Producer Dustin might know. Are we around 100? I’ve been gone so long I honestly don’t remember.
For those of you watching via Jacob’s livestream, you’ll notice the bearded wonder himself is not here today. We have the wonderful Ryan Bonner filling in.
Ryan, thanks for joining us. For the people out there on the internet who don’t know who you are, tell us a little about yourself.
[0:45] Ryan
Hey everybody. My name is Ryan.
I’m the founder and CEO of Defcert. We’re a compliance consulting firm and a Summit 7 partner.
We’ve been working in the Defense Industrial Base and helping organizations navigate CUI safeguarding requirements since 2019.
It’s always fun to spend a Friday on the Hotline, especially the Friday before Memorial Day weekend. I know a lot of people are already mentally at the beach, so we’ll save all the good stuff for the diehards who are still watching.
[1:25] Daniel
Speaking of good stuff, let’s jump into our weekend review.
I’ve been thinking about something lately.
As far as I know, DIBCAC hasn’t really started pushing completed Level 3 assessments through the pipeline yet. We’ve heard they’ve worked some assessments, but I haven’t seen anyone publicly announce a Level 3 certification.
At the same time, everybody is talking about Golden Dome.
One of the requirements floating around is Level 3 certification.
That got me wondering:
If DIBCAC becomes the bottleneck and companies can’t get assessed in time, what happens when contracts start requiring Level 3 certification for award?
Do you think organizations could protest awards because they never got the opportunity to be assessed?
[2:47] Ryan
I think it depends entirely on how the Level 3 requirement gets deployed.
There are really two possibilities.
In one scenario, certification becomes a factor in the evaluation process. Maybe it’s a technical evaluation factor or a risk consideration that influences award decisions.
In another scenario, the solicitation simply says:
“You must have Level 3 certification.”
At that point, it’s binary.
You either have it or you don’t.
Pass or fail.
If the requirement is embedded directly into the 7021 clause and DIBCAC can’t assess organizations quickly enough, I absolutely think that becomes noteworthy.
If an organization can demonstrate that it was unable to obtain certification because there was no assessment availability, I could see that becoming the basis for a protest.
For other uses of Level 3, where it’s simply one factor among many, the argument becomes much harder to make.
[5:10] Daniel
What’s interesting is that we’re already seeing a version of this problem with Level 2.
Everybody keeps talking about November 10, 2025.
They say:
“If I don’t get certified by then, I lose all my business.”
The reality is that DoD isn’t giving everyone a universal certification deadline.
The market is creating those deadlines.
I talked to a company this week that I had spoken with several months ago.
At the time they said:
“We’ll think about it.”
Now they’re calling and saying:
“We have to be certified by July.”
I asked if they had done anything since we last spoke.
They said no.
They assumed they could hire somebody and get certified in sixty days.
Unfortunately, that’s not how this works.
This was a large organization with multiple operating companies and significant implementation work still ahead of them.
They’re simply not going to get there in two months.
[7:08] Daniel
Let’s talk about something everyone loves to argue about.
Artificial intelligence.
We’ve got OpenAI.
We’ve got Anthropic.
We’ve got Elon.
We’ve got data centers.
We’ve got lawsuits.
We’ve got AI everywhere.
One of the questions we get all the time is:
Can I use AI in a CMMC environment?
Let’s break that into two pieces.
First, AI for compliance automation and governance.
Second, practical use of AI inside a governed CMMC environment.
Ryan, let’s start with the compliance side.
[8:01] Ryan
When it comes to AI for compliance activities, I think we need to establish some ground rules.
If we’re talking about compliance automation, we’re generally talking about environments handling Security Protection Data rather than directly processing CUI.
That’s an important distinction.
At the lower-risk end of the spectrum, we’re seeing AI used to support GRC activities, documentation management, and compliance workflows.
We’re also seeing security operations providers integrating AI into alert triage and analysis.
Honestly, I don’t hate that approach.
If AI is handling entry-level analyst work and escalating more complex situations to a human, that makes sense.
The more complicated question is what happens when AI starts operating near systems that actually process or protect CUI.
[9:50] Ryan
At that point, data flows become critically important.
I’m perfectly comfortable with Security Protection Data flowing into an AI-assisted process.
What I don’t want is organizations using off-the-shelf AI tools exactly as they come out of the box without understanding what those tools are doing.
The technology is evolving too quickly.
Every week there’s a new capability.
The first time we saw AI generating source code, that was exciting.
Then AI started controlling browsers.
Then AI started clicking buttons.
Then AI started acting on behalf of users.
Now we’re having an entirely different conversation.
Because at that point, the AI isn’t just helping the user.
It’s operating as the user.
[11:19] Ryan
That’s where governance becomes critical.
You’ve effectively introduced a digital actor capable of interpreting goals and taking actions on your behalf.
Not because it’s malicious.
But because that’s literally what you’ve instructed it to do.
For organizations just getting started, I’d strongly consider using completely separate devices.
Separate computer.
Separate account.
Separate environment.
Don’t domain join it.
Don’t give it privileged access.
Learn how the technology works before integrating it into production systems.
And if you’re using AI agents, give them their own credentials.
Give them their own Entra accounts.
Treat them like brand-new employees with minimal privileges.
That’s a much safer model than letting them operate with administrative access through your own account.
[13:15] Daniel
That’s exactly what worries me.
You hear stories about AI agents running wild because somebody connected them to the wrong thing.
Now imagine the AI has access to CUI.
Or intellectual property.
Or sensitive financial information.
Maybe somebody asks:
“Ryan, why did you send F-16 specifications to your Gmail account?”
And the answer becomes:
“My AI agent did it.”
That’s not a great position to be in.
I’m a huge believer in AI.
I use it constantly.
But governance matters.
A lot of organizations are rushing toward AI before they’ve built the governance structure necessary to control it.
That’s where the real risk lives.
[14:47] Daniel
All right.
That was just the warmup.
Now we’re getting into the fun stuff.
Somebody in chat said Ryan and I look alike, which may be the nicest compliment I’ve ever received.
I’ll take it.
If I’m twinning with anybody, it’s Ryan Bonner.
Now let’s jump into the topic everybody wants to talk about:
Significant change.
[15:07] Daniel
Ryan Bonner, how should people interpret the concept of significant change following the latest CMMC FAQ?
We’ve been talking about this for weeks.
Jacob and Jason recently did a podcast on it.
The concept isn’t new, but we’ve been waiting for DoD to clarify what significant change actually means outside of broad phrases like “architectural boundary changes.”
One of the examples in the FAQ talks about situations where a reassessment would be required.
Let’s say I build a virtual desktop environment. It’s fully configured, fully documented, and sitting there ready to go.
But it never touches my on-premises environment until I win a contract.
Then suddenly I need to connect it.
Or maybe I wasn’t using wireless before, and now I am.
The FAQ seems to suggest that if a control previously wasn’t applicable, but now becomes applicable because of how the environment is being used, that can trigger a reassessment.
How do you interpret that? How much flexibility do organizations really have here?
[17:18] Ryan
Honestly, I don’t hate this example.
The reason is that we’re talking about requirements that previously didn’t apply.
You never had to defend them.
You never had to demonstrate compliance with them.
You got credit because your architecture made them irrelevant.
That’s great.
Congratulations.
But if you’re going to reverse that design decision later, it makes sense that somebody would want to evaluate the requirement that previously didn’t exist.
From a strategic perspective, it changes how I think about system design.
Now I’m weighing two competing costs.
One cost is implementing a requirement today that I might not technically need.
The other cost is potentially triggering a reassessment later.
If implementing the requirement now only takes a few hours, but reassessment later costs tens of thousands of dollars and introduces audit risk, then maybe the easy answer is to implement the requirement now and move on with life.
[19:29] Ryan
My team uses a phrase all the time:
Easy decisions, hard life.
Hard decisions, easy life.
This feels like one of those situations.
If you have an opportunity to meet a requirement today with relatively little effort, even if you don’t need it immediately, there may be real value in doing so.
That way you’re not forced into a reassessment because you suddenly decided you needed wireless six months after certification.
[20:00] Daniel
That’s exactly my concern.
A lot of people don’t even know these FAQs exist.
It’s almost an insider knowledge problem.
If you’re active in the community, you’ve seen them.
If you’re not, there’s a good chance you’ve never read them.
Which raises another question.
Neither of us are lawyers.
Let’s get that disclaimer out there.
But do you think these FAQs could actually become relevant in something like a False Claims Act case?
If somebody had a significant change, didn’t reassess, and their only defense was “Well, the FAQ isn’t in the rule,” does that hold water?
[20:52] Ryan
I don’t think the Department of Justice is sitting around asking purely academic questions.
They’re looking for cases they can pursue.
They’re looking for compelling facts.
They’re looking for situations that can be resolved.
Would this FAQ alone be enough?
Probably not.
But this particular example is about as simple as it gets.
A jury could understand it.
You had a requirement.
Then you didn’t.
Then you brought it back.
And you didn’t reassess.
That’s not a difficult story to explain.
So while I wouldn’t expect this to be the sole reason somebody gets pursued, I also wouldn’t want to be defending against it.
[21:59] Daniel
Let’s look at another example.
The FAQ specifically says that routine security upgrades don’t require reassessment.
One example they give is upgrading a solution to something with the same or better security capability.
I was happy to see that because it addresses a question we get constantly around FIPS 140-2 and FIPS 140-3.
A lot of organizations are upgrading equipment.
They’re moving to newer technology.
They’re improving their security posture.
It’s nice to see DoD acknowledge that improving security isn’t automatically a trigger for reassessment.
[22:51] Daniel
Then we get to the gray area.
The FAQ says major functionality changes, new security approaches, or introducing systems that weren’t previously assessed require additional consideration.
They use an example involving a Windows environment being merged into a Linux environment.
The determining factor appears to be whether the resulting environment includes systems, configurations, or security tools that haven’t been previously assessed.
That’s where people start wrestling with interpretation.
And honestly, I’m glad they’re wrestling with it.
It means they’re thinking about it.
What do you make of that example?
[24:42] Ryan
I think most organizations immediately jump to the wrong conclusion.
They see:
Linux plus Windows equals reassessment.
Then they generalize that into:
“Any time I add anything new, reassessment.”
I don’t think that’s what the FAQ is saying.
Most real-world changes aren’t entire environments colliding together.
Most changes are additive.
You’re adding a tool.
Adding a capability.
Adding a configuration.
Something much smaller.
The FAQ also tells us that replacing solutions with something equally secure is acceptable.
And it reminds us that organizations are already required to do risk assessments, change control, configuration management, and all the other things NIST 800-171 expects.
Those processes exist specifically to absorb change.
[27:29] Ryan
The real question is whether your internal processes can absorb the change without fundamentally altering the way your environment operates.
Can you introduce a new tool?
Can you add a new configuration?
Can you improve security?
Can you document the change?
Can you assess the risk?
Can you update your SSP?
If all of those things happen and the SSP doesn’t need to be rewritten from scratch, I’d be pretty comfortable saying the environment hasn’t experienced a significant change.
The burden falls on the organization to define a reasonable decision-making framework and apply it consistently.
[30:09] Daniel
That’s why we bring you on, Ryan.
You always have the answers.
And speaking of answers, let’s jump into some audience questions about significant change.
[30:18] Daniel
Let’s start with one that came in through the website.
If I replace my MSP after certification, does that automatically trigger a significant change and require reassessment?
This is one of those questions that sounds simple but gets complicated very quickly.
[30:43] Ryan
My answer is the same one everyone hates:
It depends.
If you’re replacing one MSP with another MSP that provides the exact same services, using the same tools, supporting the same architecture, and operating under the same security model, then I’m not immediately concerned.
But if changing MSPs means changing security tools, changing administrative processes, changing monitoring solutions, changing privileged access workflows, or changing your architectural design, then we’re having a different conversation.
The MSP isn’t the change.
The resulting changes to the environment are what matter.
[32:05] Daniel
That’s a really important distinction.
People focus on the provider.
The provider itself isn’t necessarily the issue.
It’s what changes because of the provider.
If your new MSP comes in and says:
“We don’t use that tool.”
“We don’t support that configuration.”
“We manage things differently.”
Then you may be introducing changes that require additional evaluation.
[32:54] Ryan
Exactly.
And this is why documentation matters so much.
Organizations should already know:
What tools they’re using.
Why they’re using them.
What controls those tools support.
How those controls are implemented.
If you can’t answer those questions, changing providers becomes much riskier because you don’t really understand what you’re changing.
[33:48] Daniel
Here’s another one.
Can an organization use an operational POA&M to manage a significant change until reassessment occurs?
We’ve talked about this before, but people continue asking because there isn’t a clearly defined timeline for reassessment.
[34:10] Ryan
I think that’s a dangerous assumption.
An operational POA&M is a useful management tool.
But it doesn’t magically make a significant change disappear.
The FAQ doesn’t say:
“Put it on a POA&M and you’re fine.”
The FAQ says significant changes may require reassessment.
Those are two different concepts.
Could a POA&M help document the transition?
Absolutely.
Would I rely on it as my only justification for delaying reassessment?
Probably not.
[35:34] Daniel
That’s where I land too.
People are looking for a bright-line answer and I don’t think one exists yet.
The reality is that organizations are making risk decisions every day.
The best thing you can do is document your reasoning and be able to explain why you made the decision you made.
[36:12] Daniel
Let’s shift gears.
I want to talk about Security Protection Data because I think that’s still one of the least understood concepts in the entire CMMC ecosystem.
We spend a lot of time talking about CUI.
We spend a lot of time talking about FCI.
But Security Protection Data is becoming increasingly important.
Ryan, what’s the biggest misconception you see?
[36:45] Ryan
The biggest misconception is that people think Security Protection Data is a data classification.
It isn’t.
It’s a data category.
That’s an important difference.
Organizations hear the term and immediately start trying to label documents.
They start asking:
“Should this file be marked SPD?”
That’s not really the point.
The purpose of Security Protection Data is identifying information that could compromise security controls if disclosed.
Think about:
Firewall configurations.
Network diagrams.
Security monitoring information.
Identity management configurations.
Things that help protect the environment.
The concern isn’t that the information is classified.
The concern is that exposing it could weaken security.
[39:11] Daniel
I think that’s one of the reasons people struggle with it.
Most people are comfortable with classification systems.
Public.
Internal.
Confidential.
CUI.
Security Protection Data doesn’t fit neatly into that model.
It’s describing function rather than sensitivity.
And that’s a different way of thinking.
[40:02] Ryan
Exactly.
And once you understand that distinction, a lot of the confusion disappears.
You stop asking:
“What label should I put on this?”
And start asking:
“Does disclosure of this information weaken my security posture?”
That’s a much more useful question.
[41:15] Daniel
We’ve got another audience question.
This one is about AI again.
If an AI tool has access to Security Protection Data, does that automatically make the AI provider an External Service Provider?
That’s a spicy one.
[41:42] Ryan
I think we’re still waiting for clearer guidance there.
My instinct is that we shouldn’t immediately jump to labels.
Instead, start with data flows.
What information is leaving the environment?
What services are being provided?
What security functions are being performed?
Those questions matter more than the marketing description attached to the product.
The technology is moving faster than the guidance.
That’s why organizations need to be thoughtful before deploying these tools.
[43:25] Daniel
That’s probably the theme of the whole AI conversation.
The technology is moving faster than the compliance framework.
Which means organizations have to make good decisions before someone publishes a FAQ telling them what to do.
[44:18] Ryan
And that’s always been true in cybersecurity.
The organizations that do best aren’t the ones waiting for perfect guidance.
They’re the ones building sound governance processes and applying good judgment consistently.
[45:10] Daniel
Well said.
Let’s take one more question before the break.
How should organizations think about future-proofing their environments against changing CMMC requirements?
That’s something I hear constantly now that people are talking about Revision 3, Security Protection Data, and whatever comes next.
[45:48] Ryan
My advice is simple.
Build good systems.
Don’t build compliance theater.
If your security program only works because a specific FAQ says something specific today, you’re going to struggle when the rules evolve.
Instead, focus on:
Strong governance.
Good documentation.
Effective change management.
Consistent risk assessment.
If you build those capabilities, adapting to future requirements becomes much easier.
[47:12] Daniel
That’s a great place to stop.
When we come back, we’ll get into more audience questions and probably argue about something.
That’s usually how these things go.
[47:12] Daniel
That’s a great place to stop.
When we come back, we’ll get into more audience questions and probably argue about something.
That’s usually how these things go.
[48:45] Daniel
All right. Here’s a fun one.
Our High-Level Organization changed in SPRS and SAM.gov following an acquisition and no longer matches our CMMC Level 2 certificate. However, the in-scope CAGE code and CMMC UID are still the same.
Is this reassessment-worthy or not?
Is this a significant change?
I have a semi-official answer, but let’s hear your quick reaction first, Ryan.
[49:13] Ryan
I’m going to go with no.
I don’t think that’s reassessment-worthy.
The way I’m reading it, the legal entity name changed, but the assessed environment did not.
The CAGE code is the same.
The CMMC UID is the same.
It’s almost the equivalent of a DBA.
You were this. Now you’re this.
I don’t think that’s a reassessment-worthy event.
The only downside is that you’ll probably have to explain it over and over again to people who see the certificate and wonder why the names don’t match.
But from a compliance standpoint, I don’t immediately see a reason to reassess.
[50:03] Daniel
This is one of those questions that looked scary at first.
The more I thought about it, the less concerning it became.
I’ll put it this way.
This is not an official answer.
It’s an unofficial answer that a little birdie may or may not have shared.
That little birdie suggested this would not be reassessment-worthy on its face because:
The in-scope CAGE code is unchanged.
The CMMC UID is unchanged.
The assessed environment is unchanged.
The boundary is unchanged.
The recommendation would be to treat the mismatch as an administrative reconciliation issue in SPRS and SAM.gov and notify the contracting officer appropriately.
Now, if the acquisition materially changes how the environment is managed, configured, or operated, that could lead to an internal risk assessment that reaches a different conclusion.
But based solely on the HLO change itself, reassessment would not appear necessary.
[51:10] Ryan
That’s actually a pretty well-spoken little birdie.
I don’t think I’d disagree with that assessment.
[51:20] Daniel
Next question.
This one comes up constantly.
How should organizations think about wireless networking when all CUI is already encrypted and stored in GCC High?
We’ve talked about this before, but it keeps coming back because of the FAQ language around encrypted CUI remaining CUI.
[52:19] Ryan
This is definitely one of those sliding-scale situations.
But there is some good news.
When the FAQ first came out and stated that encrypted CUI remains CUI, a lot of us immediately started asking whether every transport mechanism was suddenly in scope.
At first glance, that sounds terrifying.
But when you walk through the requirements, the outcome isn’t quite as dramatic.
If the endpoint systems are properly encrypting the data using approved cryptographic modules, then many of the transport systems have relatively limited responsibilities.
In practical terms, that means you may not suddenly inherit a massive number of additional controls.
The transport exists.
The data is encrypted.
The endpoint is carrying most of the burden.
[53:37] Ryan
The biggest thing is not giving intermediary systems access to the keys.
Don’t let those systems decrypt the traffic.
Don’t let them inspect protected content.
Don’t turn them into something they weren’t intended to be.
If you keep those boundaries intact, the implementation challenge becomes much more manageable than many people initially feared.
[54:18] Daniel
That’s probably one of the biggest lessons from the encrypted CUI discussion.
A lot of people assumed the FAQ fundamentally changed everything.
What we’re finding is that it changed some things, but not necessarily in the catastrophic way people originally feared.
[55:02] Daniel
Here’s another one.
Let’s talk about SD-WAN.
People love trying to argue that if traffic is encrypted before it reaches the SD-WAN platform, then the SD-WAN platform is out of scope.
What do you think?
[55:25] Ryan
I wouldn’t sleep on that argument.
If I have any network component routing traffic, applying rules, filtering traffic, or otherwise influencing security decisions, it’s probably providing security functions.
Even if I can’t see inside the encrypted packets, I’m still making decisions about how traffic flows.
I’m still enforcing policy.
I’m still performing security-related actions.
Once I start describing those functions in my SSP, it’s very easy to see how that system becomes a Security Protection Asset.
[56:44] Ryan
There’s another factor too.
If encrypted CUI remains CUI, then there’s a reasonable argument that the SD-WAN infrastructure is processing CUI traffic regardless of whether it can decrypt the contents.
That doesn’t automatically mean every requirement applies.
But it does mean I’d be very cautious about assuming the technology is completely out of scope.
[57:30] Daniel
And most of the certified environments we’ve seen using SD-WAN capabilities are doing so through FedRAMP-authorized platforms anyway.
They’re using Azure.
Cloudflare.
Zscaler.
Or similar technologies that already fit into a compliant architecture.
I don’t know many organizations successfully arguing that a rented cloud networking platform is equivalent to the public internet.
[58:05] Ryan
Exactly.
A rented cloud networking platform is not common-carrier internet.
Nice try.
But that’s probably not the argument I’d want to make in front of an assessor.
[1:00:05] Daniel
All right.
We are at 1:00 p.m. Central, and that sadly means the end of this week’s Q&A.
Thank you everybody for joining us.
We hope this was informative.
If you have questions, leave us a voicemail through the Hotline, reach out on LinkedIn, visit the website, or send us a message.
Ryan, it’s always a pleasure having you on.
Somebody actually requested that we bring you back because, apparently, you know what you’re talking about.
I still love playing the “Stump Ryan” game, and so far nobody has managed to do it.
[1:00:50] Ryan
I appreciate it.
Always happy to be here.
[1:00:55] Daniel
Everybody have a great Memorial Day weekend.
We’ll see you next time on the Hotline.
Contact
Speak With Our Team
Our team of compliance and cybersecurity experts are on standby and ready to help. We’ll walk you through what you need and what to expect.