StealthTech
A defense contractor calls us with a network diagram that looks reasonable on paper — a flat topology, one domain, everything trusted because everything is “internal.” Then we ask which devices touch Controlled Unclassified Information, and the answer is a shrug followed by “probably most of it.” That shrug is the single most expensive sentence in CMMC compliance, because scoping isn’t a preliminary step you knock out before the real work starts. Scoping is the real work. Get it wrong and you either spend six figures securing systems that never needed Level 2 controls, or you leave a gap that fails you in front of a C3PAO assessor.
The CMMC scoping guidance sorts every asset in your environment into one of five categories, and each category carries a different set of obligations under NIST SP 800-171. Understanding which bucket a laptop, a server, a firewall, or a piece of shop-floor equipment falls into determines how much it costs to secure, how it gets documented, and whether it shows up in your assessment at all. This isn’t academic. We’ve watched contractors in Boston, Tampa, and Sarasota burn budget hardening systems that should have been walled off entirely, while missing controls on the handful of assets that actually mattered.
Why Scoping Determines Everything Else in Your CMMC Assessment
Every control in NIST SP 800-171 applies to an asset only if that asset falls inside the assessment boundary, and the boundary isn’t defined by your org chart or your subnet mask — it’s defined by where CUI flows, rests, and gets processed. The DoD’s CMMC program ties the entire certification model to this boundary concept, which means the scoping exercise you do in month one dictates the size, cost, and duration of everything that follows.
Contractors who skip a rigorous scoping exercise almost always over-scope by default, because it feels safer to assume everything is in bounds than to draw a defensible line. That instinct is understandable and expensive. A properly scoped environment might put 40 endpoints under full Level 2 rigor while leaving 200 others outside the boundary entirely, provided those 200 are genuinely segmented from CUI flow. Our compliance team spends more time drawing that line correctly than implementing any single technical control, because the line determines what needs controls in the first place.
CUI Assets: The Category That Drives the Whole Assessment Boundary
CUI Assets are the systems that process, store, or transmit Controlled Unclassified Information directly. This is the category everyone assumes they understand, and it’s also where scoping conversations go sideways fastest, because “touches CUI” gets interpreted far too loosely or far too narrowly depending on who’s answering.
A file server hosting a folder of technical drawings marked CUI is obviously a CUI Asset. So is the engineering workstation that opens those drawings, the email system that transmits them to a subcontractor, and the backup target that stores a nightly copy. What’s less obvious is that a help desk ticketing system referencing a CUI-marked document in a ticket description becomes a CUI Asset too, even if the system was never designed to house sensitive engineering data. We walked through this exact scenario with an engineering firm outside Boston whose service desk software had quietly become part of their assessment boundary because technicians pasted file paths into tickets.
The full definition and handling requirements for CUI trace back to the National Archives CUI program, which maintains the authoritative category list and marking standards every contractor should be referencing directly rather than relying on secondhand summaries. Our breakdown of the complete CUI lifecycle covers how this data needs to be stored, shared, accessed, and disposed of once you’ve identified where it lives — because identifying a CUI Asset is only the first half of the obligation.
Security Protection Assets: Why Your Firewall Rules Count Even If It Never Touches CUI
Security Protection Assets don’t process CUI themselves, but they provide security functions for the assets that do. Your firewall, your SIEM, your identity provider, your endpoint detection platform — none of these systems necessarily store a single CUI file, yet all of them fall inside your assessment boundary because they enforce or monitor the controls protecting the systems that do.
This category trips up contractors who think in terms of data flow only. A domain controller that authenticates users into a CUI environment is a Security Protection Asset even if it never stores CUI itself, because a compromised domain controller compromises everything downstream of it. The same logic applies to your logging infrastructure — audit trails have to be complete and retained for the required period, which is exactly the kind of requirement we unpack in our piece on audit logging under AU.L2, where the retention window itself becomes a compliance obligation independent of what’s being logged.
Zero trust architecture matters enormously here, because segmenting Security Protection Assets from general-purpose infrastructure is what keeps your assessment boundary from ballooning. We’ve written about how a zero trust approach accelerates Level 2 compliance precisely because it forces explicit verification at every boundary crossing rather than assuming trust based on network location. Our cybersecurity practice builds this segmentation as a foundational step, not a later hardening pass, because retrofitting zero trust onto a flat network after your scoping document is already drafted means redrawing the boundary from scratch.
Contractor Risk Managed Assets: The Category Most Contractors Get Wrong
Contractor Risk Managed Assets (CRMA) are the systems that could reasonably be expected to process CUI but haven’t been confirmed to, and which the contractor manages through policy, procedure, and practice rather than through the full technical control set applied to confirmed CUI Assets. This is the most misunderstood category in the entire scoping model, because it sits in a gray zone that many contractors resolve by guessing rather than documenting.
Think of a shared conference room laptop used for client presentations across multiple projects, some defense-related and some not. It’s not confirmed to touch CUI on a given day, but the risk that it might isn’t zero either. CMMC scoping guidance allows this asset to be managed through documented policy — restricting what gets loaded, requiring wipe procedures, limiting network access — rather than requiring the full Level 2 control implementation that a confirmed CUI Asset demands. The catch is that “managed through policy” only works if the policy is real, documented, and enforced, not a placeholder paragraph in a binder nobody reads. We see this exact failure pattern in incident response planning, where contractors have a policy document but not an actual plan, a distinction we cover in detail in what IR.L2 actually requires.
Getting CRMA classification right requires an honest inventory conversation, not a compliance shortcut. A vCIO engagement is often where this conversation actually happens, because it requires someone who understands both the technical environment and the contractual risk tolerance your organization is willing to document and defend to an assessor.
Specialized Assets: IoT, OT, GFE, and the Equipment You Can’t Patch
Specialized Assets cover the equipment that can’t be secured using standard IT controls, either because it’s government-furnished, because it runs operational technology that can’t tolerate patching cycles, or because it’s an IoT device with no meaningful security configuration surface. This category gets its own carve-out in CMMC scoping precisely because applying standard Level 2 controls to a CNC machine or a building access control panel is often technically impossible.
The specialized asset category generally includes:
- Government Furnished Equipment (GFE) — hardware or software provided by the government that the contractor doesn’t control the configuration of, and therefore can’t be expected to patch or harden independently.
- Internet of Things (IoT) devices — sensors, smart building controls, and similar equipment with minimal or no native security configuration options.
- Operational Technology (OT) — manufacturing equipment, industrial control systems, and machinery where a standard patch cycle could halt production or void a warranty.
- Restricted Information Systems — systems governed by a separate specification or contract requirement that limits how they can be configured or accessed.
Manufacturing environments carry a disproportionate share of Specialized Assets, since shop-floor equipment is exactly the category CMMC scoping was designed to accommodate rather than force into an unworkable technical control set. Our work with manufacturing clients typically starts by identifying every piece of equipment that falls into this bucket, because the compensating controls — network segmentation, physical access restrictions, monitoring at the perimeter rather than the device itself — look completely different from what you’d apply to a laptop.
Out-of-Scope Assets: Getting Systems Out of Scope Without Getting Burned
Out-of-Scope Assets are the systems that genuinely cannot access, process, store, or transmit CUI, and therefore fall entirely outside the assessment boundary. This is the category every contractor wants to maximize, and it’s also the category assessors scrutinize hardest, because a system incorrectly labeled out-of-scope is a system with zero controls sitting where controls were actually required.
The only way a system earns out-of-scope status is through demonstrable, enforced segmentation — not intent, not a policy that says employees shouldn’t use it for CUI, but actual technical separation that a C3PAO assessor can verify. A guest Wi-Fi network is out-of-scope only if it’s genuinely isolated from the production environment at the network layer, not merely on a different SSID with a shared switch underneath. We’ve audited environments where “out-of-scope” turned out to mean “we hope nobody does anything sensitive on this,” which is not a scoping decision an assessor will accept.
NIST SP 800-171 doesn’t define out-of-scope status directly — that’s a CMMC scoping construct — but the control baseline it establishes is exactly what you’re trying to keep an asset away from when you claim out-of-scope status. Cloud migrations are frequently where this gets decided one way or another, and our cloud transformation work often involves rearchitecting an environment specifically so that non-CUI business functions can be legitimately and defensibly separated from the CUI boundary, rather than living in the same tenant by default.
How the Five Categories Interact on a Real Network Diagram
None of these categories exist in isolation, and the real complexity of scoping shows up when you try to map all five onto one network diagram simultaneously. A typical mid-sized defense contractor might have a CUI Asset (the PLM system storing technical data packages), a Security Protection Asset (the firewall and SIEM watching traffic to that PLM system), a Contractor Risk Managed Asset (a shared laptop that occasionally accesses the PLM portal for status checks), a Specialized Asset (a CNC machine on the shop floor reading files exported from that same PLM system), and an Out-of-Scope Asset (the marketing team’s separate VLAN with no route to any of the above).
The interactions matter more than the individual classifications. A Security Protection Asset that’s improperly segmented from an Out-of-Scope network effectively drags that “out-of-scope” segment back into the boundary, because the firewall protecting your CUI Assets now has a policy path to systems you claimed were separate. This is where a lot of scoping documents look correct on paper and fall apart the moment an assessor asks to trace an actual packet path. Multi-factor authentication systems, identity providers, and VPN concentrators are notorious for this — they’re Security Protection Assets that touch nearly every other category, which means their configuration has an outsized effect on how defensible your entire boundary actually is.
This is also where AI integration into monitoring and detection tools can genuinely tighten a boundary rather than complicate it, since automated anomaly detection across segmented zones catches the lateral movement that manual log review misses. But the tooling only works if the underlying segmentation is sound — AI-driven monitoring on top of a poorly scoped network just generates faster alerts about a problem you haven’t actually fixed.
Building a Scoping Document That Survives a C3PAO Assessment
A scoping document isn’t a diagram you draw once and file away. It’s a living artifact that an assessor will test against your actual environment, and the gap between what’s documented and what’s deployed is where most Level 2 assessments stall. A defensible scoping document generally needs to demonstrate a few things clearly:
- An accurate asset inventory mapped to each of the five categories, updated on a schedule rather than reconstructed retroactively before an assessment.
- Evidence of segmentation, not just a segmentation policy — firewall rule exports, VLAN configurations, and access control lists that prove the boundary claimed on paper matches what’s enforced on the network.
- A data flow diagram showing where CUI enters, moves, and exits the environment, since NIST SP 800-171A assessment procedures specifically test whether your documented flow matches observed behavior.
- Justification for every Out-of-Scope claim, because this is the category assessors challenge hardest and the one most likely to trigger a scope-boundary dispute mid-assessment.
Configuration drift is the quiet killer of a scoping document’s credibility. A boundary that was accurate six months ago degrades the moment someone adds a new integration, stands up a new SaaS tool, or lets a CRMA laptop connect to a system it wasn’t supposed to touch. Our piece on configuration management under CMMC covers exactly this problem — a system that “works” isn’t the same as a system with a documented, current baseline, and scoping documents suffer from the same gap between functional and defensible.
Common Scoping Mistakes We See in Boston, Tampa, and Sarasota Contractors
The scoping mistakes we encounter aren’t usually about misunderstanding the five categories in theory — they’re about applying the categories inconsistently across a real, messy environment built over a decade of ad hoc IT decisions. A contractor in the Boston area will frequently have a legacy file share nobody remembers standing up, still holding CUI from a contract that closed out three years ago, sitting completely outside the current scoping document because nobody thought to check it. Our Boston clients tend to inherit this problem from mergers and acquisitions, where two IT environments got stitched together without anyone redrawing the CUI boundary across the combined footprint.
In Tampa and Sarasota, we see a different pattern more often — contractors who’ve adopted cloud collaboration tools quickly, sometimes faster than their scoping documentation kept pace, and who assume a cloud platform’s general security reputation substitutes for actual boundary verification. Whether a Microsoft 365 tenant belongs inside your CUI boundary or can be legitimately segmented out depends entirely on tenant configuration, and our comparison of GCC versus GCC High for CMMC programs walks through exactly why the wrong tenant choice either over-scopes your environment unnecessarily or under-scopes it dangerously. Our Tampa and Sarasota teams handle this tenant-boundary alignment as a standard part of onboarding, because it’s rarely done correctly on the first attempt.
A third recurring issue: contractors treat their MSP relationship as a scoping afterthought rather than as part of the boundary itself. If your managed service provider has administrative access into systems that touch CUI, your MSP’s own security posture is now part of your assessment story, a point we cover directly in what MSPs serving defense contractors must know. Our managed IT services and co-managed IT engagements are both built around this reality — the provider touching your environment needs a security posture that holds up to the same scrutiny your internal systems do, whether that provider ends up counted as a Security Protection Asset in your own scoping model or is documented as a boundary partner in your System Security Plan under the framework laid out in NIST SP 800-18.
Backup and recovery infrastructure deserves its own mention here, since it’s one of the most commonly missed CUI Assets. A backup target storing nightly snapshots of a CUI environment is a CUI Asset regardless of how “just for disaster recovery” it feels, and our backup and data recovery implementations account for this from day one rather than treating backup infrastructure as an afterthought to the “real” production systems.
Conclusion
Scoping isn’t a checkbox before the real CMMC work begins — it’s the decision that determines how much real work there is. Every dollar spent hardening a system that should have been Out-of-Scope is a dollar not spent protecting the CUI Assets and Security Protection Assets that actually carry assessment risk, and every Contractor Risk Managed Asset misclassified as fully out of bounds is a gap waiting to surface in front of a C3PAO. Getting the five categories right, and keeping the classification current as your environment changes, is what separates a scoping document that survives scrutiny from one that collapses the moment an assessor asks to trace a data flow.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
