Security Protection Assets vs. CUI Assets: how does CMMC scope each?

How do CMMC asset categories decide what an assessor tests?

Each asset category in Table 3 of 32 CFR 170.19(c) carries its own assessment requirement, so the category you assign decides what an assessor tests on that asset. For an architecture, engineering or construction firm on defense work, that makes scoping the first decision behind your SPRS score and system security plan. 32 CFR 170.19(c) says the scope is based on the Table 3 asset categories, and that a contractor must specify that scope before either a Level 2 self-assessment or a Level 2 certification assessment.

Two categories carry most of the weight. CUI Assets are the systems that hold or move controlled unclassified information. Security Protection Assets are the systems, people and places that protect them. Mix the two up and you either test the wrong things or leave a tool out of scope that an assessor expects to see. At a design firm, that error shows up as an inaccurate SPRS score, a system security plan that does not match reality, or a finding during a C3PAO review.

What makes something a CUI Asset?

A CUI Asset is any asset that processes, stores or transmits CUI. Table 3 in 32 CFR 170.19 assesses CUI Assets against all Level 2 security requirements, which are the 110 requirements in NIST SP 800-171 Rev 2.

At a design firm, CUI Assets usually include the file server or cloud library holding marked drawings and specifications, the laptops and workstations that open them, the email system that sends them, and the network gear they travel across. The DoD CMMC Level 2 scoping guide (version 2.13, September 2024) says each CUI Asset must appear in the asset inventory, be addressed in the system security plan (SSP), and be shown on a network diagram of the assessment scope.

What makes something a Security Protection Asset?

A Security Protection Asset provides security functions or capabilities to the assessment scope, whether or not it ever touches CUI. Table 3 assesses these assets against the Level 2 requirements that are relevant to the capabilities they provide, a narrower set than the full 110.

The scoping guide gives examples in three groups:

• People: consultants who provide cybersecurity services, enterprise network administrators, and managed service provider personnel who perform system maintenance.
• Technology: cloud-based security solutions, hosted VPN services, and SIEM solutions.
• Facilities: co-located data centers, security operations centers, and the contractor's own office buildings.

Security Protection Assets need the same three pieces of documentation as CUI Assets: an inventory entry, treatment in the SSP, and a place on the network diagram. A firewall that segments the CUI environment, an identity provider that enforces MFA, or an endpoint protection console that manages CUI laptops all fit the definition, because each provides a security capability to in-scope systems. An identity provider would be assessed against the access control and authentication requirements it delivers; a logging platform against the audit and accountability requirements.

How do CUI Assets and Security Protection Assets compare?

The short version: CUI Assets are tested against everything, Security Protection Assets are tested against what they do, and both must be documented the same way.

• Definition. CUI Assets process, store or transmit CUI. Security Protection Assets provide security functions or capabilities to the scope.
• Requirements assessed. CUI Assets: all Level 2 requirements. Security Protection Assets: the Level 2 requirements relevant to the capabilities provided.
• Documentation. Both go in the asset inventory, the SSP and the network diagram.
• Typical examples. CUI Assets: file shares, project laptops, email. Security Protection Assets: SIEM, hosted VPN, security staff and providers, data centers and offices.
• Data at risk. CUI Assets hold CUI. Security Protection Assets hold Security Protection Data, such as configurations, logs and credentials for the in-scope environment.

If one asset meets both descriptions, for example a mail gateway that filters messages carrying CUI, it processes CUI and meets the CUI Asset description. The safer working assumption is to assess it against the full requirement set.

Where do firms get the line between them wrong?

Most scoping errors come from treating a security tool as out of scope because it never stores a drawing. Table 3 defines an Out-of-Scope Asset as one that cannot process, store or transmit CUI and does not provide security protections for CUI Assets. A tool has to meet both conditions to leave the scope, so a SIEM or VPN service fails the second test.

Four other patterns come up often:

• Leaving out people and facilities. The scoping guide lists administrators, security consultants, MSP staff and office buildings as Security Protection Asset examples. They belong in the inventory and SSP alongside the technology.
• Forgetting Security Protection Data held by a provider. Under 32 CFR 170.19(c)(2), an outside provider that processes, stores or transmits CUI or Security Protection Data is an external service provider, and its use and services must be documented in the SSP. Your MSP's remote management and logging tools usually fall here.
• Calling CUI laptops Contractor Risk Managed Assets. That category covers assets that can, but are not intended to, handle CUI because of policy and practice. The scoping guide says these assets must be assessed against CMMC requirements if they are insufficiently documented in the SSP, and the rule lets an assessor run a limited check on them when the documentation raises questions.
• Assuming a VDI design removes everything. A laptop that only passes keyboard, video and mouse to a virtual desktop can be out of scope, as our article on zero trust and VDI scoping explains. The virtual desktop platform and the access layer stay in scope.

Does the CMMC Phase 2 suspension change any of this?

No. On July 13, 2026, the Department of War suspended CMMC Phase II, and said Phase I self-assessment requirements remain in place. A Level 2 self-assessment under 32 CFR 170.16 still requires a defined scope, and 170.19(c) applies to self-assessments and certification assessments alike. As of early November 2026, no new Phase II date has been announced. Our guide to what still applies during the suspension covers the rest.

An accurate scope also keeps the SPRS score defensible. A score built on a scope that leaves out the SIEM or the MSP's tools overstates compliance, and the affirming official signs off on it every year.

What should a defense subcontractor do this quarter?

Rebuild the asset inventory around the Table 3 categories, then check it against the SSP:

• Tag every asset with one category. Use the five Table 3 categories and record the reason for each choice, especially for anything marked Out-of-Scope or Contractor Risk Managed.
• List what protects the CUI environment. Include firewalls, identity and MFA services, endpoint protection, backup, logging, remote access and vulnerability scanning.
• Add people and places. Record internal administrators, outside security providers, MSP staff and each office or data center that houses in-scope systems.
• Map each Security Protection Asset to requirements. Note which NIST SP 800-171 requirements each one supports, so the assessor knows what to test.
• Document your providers. For each external service provider, record in the SSP the services it delivers and whether it handles CUI or Security Protection Data, as 32 CFR 170.19(c)(2) requires. NIST SP 800-171 requirement 3.12.4 also expects the plan to describe the system's connections to other systems.
• Update the network diagram and SPRS. Show every in-scope asset on the diagram and refresh the SPRS entry if your scope or score changed. Our article on writing a system security plan an assessor can follow walks through the plan itself.

How does s90 help?

s90 works with architecture, engineering and construction firms on defense projects to build a CMMC asset inventory that matches the rule. We help sort assets into the Table 3 categories, map security tools to the requirements they support, document our own role as an external service provider in your SSP, and keep the diagram current as systems change. If you are not sure which of your tools are in scope, talk with our team.