CMMC Asset Inventory: Source-Labeled Fields, the 5 Asset Categories, and What to Include

What is a CMMC asset inventory?

A CMMC asset inventory is the maintained record that connects every asset in your Level 2 assessment scope to its system association, its CMMC asset category, its technical identity, and its supporting evidence. It is not just a hardware list: CM.L2-3.4.1 covers hardware, software, firmware, and documentation, while 32 CFR § 170.19 governs how the Level 2 asset categories are documented. The two requirements meet in one artifact, which is why a good inventory does double duty.

Most contractors arrive with something—a remote monitoring and management (RMM) export, an Active Directory dump, a procurement list, a spreadsheet a previous IT person started. None is wrong on its face. But none should be assumed complete until it covers the required inventory content and reconciles to your actual assessment scope, because the CMMC inventory asks two different questions at once.

The two jobs — and why they converge on one record

Here’s the mapping we use throughout this page. It’s the clearest way to see why two separate obligations land on the same document.

DCR source-to-artifact map

• 32 CFR § 170.19 (scoping duties) → document each in-scope asset in the asset inventory, document the treatment of those assets in the System Security Plan (SSP), and include the in-scope assets in the network diagram of the CMMC Assessment Scope.
• CM.L2-3.4.1 (configuration-management duties) → establish and maintain baseline configurations and an inventory of hardware, software, firmware, and documentation, and keep both maintained across the system development life cycle.

Miss the § 170.19 job and you can’t survive the scoping review. Miss the CM.L2-3.4.1 job—most often by listing only hardware—and you’ve skipped the “and firmware” and “and documentation” content the assessment objective explicitly checks for (CMMC Level 2 Assessment Guide, CM.L2-3.4.1). The inventory that wins answers both.

One clarification on the SSP so you don’t over-build: § 170.19, Table 3 requires you to “document asset treatment in the SSP.” That means describe how each category of in-scope asset is treated—you do not need a separate SSP paragraph for every individual laptop. Each in-scope asset belongs in the inventory; the SSP explains the treatment; the diagram includes the in-scope assets and depicts the boundary (DoD Level 2 Scoping Guide).

What a CMMC asset inventory is not

It is not just an RMM or endpoint export. It is not a procurement list. It is not the SSP, and it is not the network diagram—though it must reconcile with both. And it is not a determination that your information is CUI (defined at 32 CFR 2002.4) or that a given control is met. It is the index that makes the rest of your evidence checkable.

Asset inventory vs. system inventory vs. CMDB

Does CMMC actually require an asset inventory?

Yes, for CMMC Level 2. Section 170.19 requires the four in-scope asset categories to be documented in the asset inventory, and CM.L2-3.4.1 requires an established and maintained inventory of hardware, software, firmware, and documentation throughout the system lifecycle. The sources define the required outcome—they do not prescribe one official spreadsheet. At Level 1 the picture differs, and we cover that in the FAQ.

The requirement lands from two directions. Seeing all four source layers keeps you from missing half of it.

One honest clarification so you don’t check a box that isn’t fully checked: a complete inventory does not, by itself, satisfy CM.L2-3.4.1. The same requirement also calls for established and maintained baseline configurations (CM.L2-3.4.1 objectives [a]–[c]). The inventory is one half; the baseline is the other. The upside: an inventory that references your baseline standards makes the configuration half far easier to evidence.

Why this matters right now

The timing is real, so treat it as real—not as a manufactured deadline. Two rules turned CMMC from “coming” to “in effect.” The CMMC Program rule (32 CFR Part 170) became effective December 16, 2024. The DFARS acquisition rule implementing the CMMC contractual requirements became effective November 10, 2025; it uses DFARS 252.204-7025 in solicitations to state the required CMMC level, and DFARS 252.204-7021 in the resulting contract to require you to have and maintain the required CMMC level.

What that means for the inventory: the DoD Level 2 Scoping Guide requires the in-scope asset categories to be documented in an asset inventory, requires their treatment to be documented in the SSP, and requires a network diagram of the CMMC Assessment Scope to facilitate scoping discussions during pre-assessment activities. Those pre-assessment document requests—an RPO’s gap-assessment kickoff, or a C3PAO’s pre-assessment scope validation—are landing now.

Which assets belong in a CMMC Level 2 asset inventory?

CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, and Specialized Assets are in the Level 2 assessment scope and must be documented in the inventory. Out-of-Scope Assets are not assessed and carry no formal Level 2 documentation requirement—but you must be prepared to justify why an excluded asset cannot handle CUI and does not protect the CUI environment. The category is not the same thing as the assessment treatment, and that distinction is where a lot of money is at stake.

This is the matrix to bookmark. Every cell is drawn from 32 CFR § 170.19, Table 3 (Level 2), with the Level 1 and Level 3 deltas from § 170.19(b) and Table 5. We verified this language against the current eCFR on July 10, 2026.

Read the CRMA and Specialized rows twice, because the difference is real money and real risk. Specialized Assets get an SSP review and are not assessed against the other Level 2 security requirements. CRMAs get an SSP review that can escalate to a limited check if the documentation or other findings raise questions (§ 170.19, Table 3). They are not the same treatment. And the Out-of-Scope row carries a duty that’s easy to miss: no formal inventory entry is required, but § 170.19 says you must “prepare to justify the inability of an Out-of-Scope Asset to process, store, or transmit CUI.”

A few definitions, because these terms carry weight. A CUI Asset touches CUI directly. An SPA provides a security function or capability to the scope—and for SPAs, “asset” is broader than a device: the DoD Level 2 Scoping Guide identifies people, technology, and facilities as possible SPAs. A system administrator (a person), a firewall or SIEM (technology), and a Security Operations Center or a co-located data center (a facility) can each be an SPA. A CRMA is capable of handling CUI but is kept from doing so by policy. A Specialized Asset is one of five groupings that can’t be fully secured: Government Furnished Equipment (GFE); IoT or IIoT devices; Operational Technology (OT); Restricted Information Systems; and Test Equipment. Out-of-Scope is genuinely separated and does neither.

On Security Protection Data (SPD): an SPA is classified by the security function it provides, not by the data it holds. SPD, defined at § 170.4, is the security-relevant information stored or processed by SPAs—configuration data, log files, vulnerability or security-status data, and passwords that grant access to the in-scope environment.

Assigning categories is the boundary-design decision—if you’re not sure where an asset falls, work through our CMMC Level 2 scoping guide first, then use this page to build the record.

Should out-of-scope assets go in your workbook?

The rule imposes no formal Level 2 documentation requirement on out-of-scope assets. Our operating recommendation—clearly a recommendation, not a mandate—is to keep a separate exclusion register recording the asset, boundary, exclusion condition, and evidence. The rule requires you to prepare to justify the exclusion; writing it down before the assessor asks is simply how you avoid reconstructing it under pressure.

What fields does a CMMC asset inventory need?

Record enough to prove identity, ownership, system association, CMMC category, CUI or security function, technical detail, SSP and network-diagram alignment, external-service responsibility, and lifecycle maintenance. The field list below labels every column by its source basis, so the template never masquerades as regulatory text. This is The DCR CMMC Asset Inventory Field Matrix v1.0 — assembled and verified July 10, 2026.

The honesty gate first, because it matters: CMMC does not mandate 40 spreadsheet columns. The authorities define required outcomes, asset-category treatment, inventory content, and examples of accountable records—not a fixed workbook. We converted them into a practical field model and labeled each field with its exact source:

• R — Required outcome, with the source noted (the rule or guide establishes the underlying information or treatment; it does not require our column name).
• A — Assessment-Guide detail, with the source noted (the CMMC Level 2 Assessment Guide names this accountability detail or evidence item).
• D — DCR operating design (a field we recommend for maintainability; not a Government-required field).

Group 1 — Record identity, scope, and accountability

Group 2 — Technical identity

This is where the Assessment Guide is most explicit; the guide names these as examples of information needed for component accountability.

Technical fields 17–30 apply only where relevant. For a person or facility SPA, record the role or site identifier, employer or owner, location, security function provided, organizational-system association, responsible owner, and evidence source instead.

Group 3 — Documentation, evidence, and lifecycle

Don’t force all 40 into one flat sheet.The workbook uses linked tabs keyed by Asset Record ID: Asset Register, Software Register, Firmware Register, Documentation Register, External Services, Change & Review Log, Reconciliation Exceptions, and a Definitions & Source Basis tab. A single asset can then carry many software titles or documents without a monster row—and it stays maintainable.

The one thing we’ll admit before we hand you the checklist

Here’s the honest part, and it’s the opposite of what a vendor would tell you: you do not need to buy anything to satisfy this requirement. CMMC mandates the inventory, its content, and its maintenance—it never mandates a tool. A spreadsheet with the right fields and a real update process can satisfy CM.L2-3.4.1; the format is not what gets assessed. The Assessment Guide even confirms centralized inventories are acceptable, as long as each record ties back to its system and owner.

What a spreadsheet doesn’t fix is currency. When device churn, multiple sites, cloud services, and disconnected or specialized assets make manual reconciliation unreliable, that’s when discovery-fed tooling earns its place—and the scope you present has to reflect the environment as it exists at assessment time.

What does a completed CMMC asset inventory look like?

A completed CMMC asset inventory shows each asset with its category, the reason for that category, its system association, its SSP and network-diagram references, and where the supporting evidence lives. The example below is sanitized and covers all five categories—including a person SPA and a facility SPA—so you can see how the same field model handles very different assets. It is illustrative; your own classifications depend on your environment’s facts.

Notice what the record captures beyond a device name: why the category applies, where the treatment is described, and what evidence backs it. That’s the difference between an inventory an assessor can validate and a list that generates questions.

How do you classify an asset as CUI, SPA, CRMA, Specialized, or out of scope?

Classify an asset by its actual use, security function, policy intent, configuration, and separation—not by the vendor’s name or product category. Check whether it’s one of the five Specialized groupings first, because those can also handle CUI; then whether it handles CUI, provides a security function, is capable-but-restricted, or is genuinely separated. The order matters, and it’s the reason a naïve tree misfires.

The classification triage sequence

1. Is it GFE, an IoT/IIoT device, OT, a Restricted Information System, or Test Equipment that can handle CUI but can’t be fully secured? → Yes: evaluate as a Specialized Asset. No: continue.
2. Does it process, store, or transmit CUI? → Yes: evaluate as a CUI Asset. No: continue.
3. Does it provide a security function or capability to the CMMC Assessment Scope? → Yes: evaluate as an SPA. No: continue.
4. Is it capable of handling CUI but kept from doing so by documented policy, practice, or configuration? → Yes: evaluate as a CRMA. No: continue.
5. Is it inherently unable to handle CUI or physically/logically separated from CUI Assets, and provides no security protection for a CUI Asset? → Yes: evaluate as Out-of-Scope. No or uncertain: mark it pending determination and escalate.

This is DCR’s triage sequence, not a category-precedence rule stated in § 170.19. We put Specialized first because a CNC, OT system, GFE item, or test system that handles CUI would otherwise be swept up as a CUI Asset before you reach the Specialized question—and the rule carves those asset types out precisely because they can’t be fully secured.

What the triage can’t decide for you

It can’t tell you whether the underlying information is CUI. It can’t tell you which CMMC level your contract requires. It can’t confirm whether a specific architecture satisfies a contractual obligation, whether a provider is a CSP or a non-CSP ESP, or whether your separation is technically sufficient. For those: use a Registered Practitioner or RPO for scoping and implementation questions; use the contracting officer or another authorized Government source for solicitation, contract, and CUI-applicability determinations; and use qualified federal-contracts counsel for legal interpretation.

The hard calls: 15 real-world assets and what changes the answer

These are starting points, not verdicts. The VDI row is an official example from § 170.19 and the DoD Scoping Guide; the other rows are DCR conditional synthesis from the category definitions and must be treated as conditional.

How do you build a CMMC asset inventory, step by step?

Build from the assessment boundary and multiple discovery sources—not from a blank spreadsheet alone. Normalize identities, link hardware to its software, firmware, and documentation, assign a category with a written rationale, reconcile the record against the SSP and network diagram, close discrepancies, approve a baseline version, and keep it current through change. Nine steps, in the order that produces a reviewable, traceable record.

1. Step 1 — Confirm the organizational system and SSP association. Identify the assessment scope and the relevant CAGE code(s). Assign every record to the system/SSP it supports. Don’t start with category labels detached from a boundary.
2. Step 2 — Collect independent source records. Use the seven-source model below. One tool is never the whole picture.
3. Step 3 — Normalize identifiers. Reconcile serial number, hostname, device ID, cloud resource ID, service name, owner, location, and network address so the same asset isn’t three different rows.
4. Step 4 — Build linked registers. Separate assets, software, firmware, documentation, services, changes, and exceptions. This is what keeps firmware and documentation from vanishing.
5. Step 5 — Assign category and rationale. Record the factual condition, the evidence supporting it, and who approved it. Keep “pending determination” available instead of forcing false certainty.
6. Step 6 — Map supporting artifacts. For each in-scope record, note the SSP treatment reference, the network-diagram zone, the CUI-flow reference, the baseline/configuration standard, the service description and customer responsibility matrix (CRM) for any CMMC-defined ESP or CSP, and the relevant Level 2 requirements where useful.
7. Step 7 — Reconcile and investigate exceptions. Don’t delete a mismatch because one tool says an asset is gone. Run it down.
8. Step 8 — Approve and version the inventory. Record the approval date, approver, version, open exceptions, and where the evidence package lives. Scope is an operating assumption you version, not a one-time artifact.
9. Step 9 — Make updates part of normal change work. Tie additions, moves, reconfigurations, software installs, and retirements to the inventory process so it never goes stale between reviews.

Spreadsheet, RMM, CMDB, or GRC platform — what’s enough?

Any of them can support the requirement if the resulting inventory is complete, system-specific, reviewable, and maintained. The Assessment Guide allows centralized inventories when each component ties back to its organizational system and owner—but no discovery platform can decide CUI use, CMMC category, SSP treatment, or contractual scope for you. The tool is a means; the judgment is yours.

DCR editorial comparison—this table describes operating fit and limitations. It is not a CMMC requirement or a Government recommendation.

The blunt version: automation can find assets faster; it cannot make the legal, contractual, and operational judgment that a specific asset is a CUI Asset, CRMA, SPA, Specialized Asset, or out-of-scope in your environment. That’s the line between what you can buy and what you have to own. Buy the discovery; own the classification.

How do you prove the inventory is complete and current?

Our recommended way to test completeness is to reconcile independent sources and resolve the mismatches—not to declare one platform authoritative. A technically clean endpoint export can still omit external services, firmware, disconnected OT, GFE, documentation, retired systems, and assets your own SSP and network diagram describe. The rule does not prescribe this method; it’s how we’d test it.

The DCR Seven-Source Inventory Reconciliation Test v1.0 — assembled and verified July 10, 2026

Cross-check your inventory against seven independent sources. Each reveals a different class of gap.

The reconciliation checklist flags the usual suspects: discovered-but-not-recorded; recorded-but-not-observed; duplicate identifiers; missing system association; missing owner; missing category; category-without-rationale; a CUI Asset with no process/store/transmit indication; an SPA with no security function mapped; a CRMA with no restriction reference; a Specialized Asset with no grouping; an out-of-scope record with no exclusion rationale; an in-scope record with no SSP or diagram reference; missing hardware/software/firmware/documentation links; an external service with no responsibility doc; a decommissioned asset still showing active; and a stale last-review date.

What will a CMMC assessor examine, interview, and test?

The CMMC Level 2 Assessment Guide (v2.13) permits examination of your inventory and update records, architecture, change-control records, and installation or removal records; interviews with the people responsible for the inventory; and testing of the inventory processes and mechanisms. Prepare evidence for all three methods—the final spreadsheet is not the whole proof. The three methods (examine, interview, test) come from NIST SP 800-171A (June 2018), incorporated by reference in 32 CFR § 170.2.

Examine. Be ready to show the current inventory export, the change history, review and update records, your asset-management procedure, SSP references, the architecture and network diagram, change-control tickets, and software and hardware installation/removal records.

Interview. Prepare whoever owns the inventory to explain, in plain terms: who owns it, how new assets enter it, how software and firmware get recorded, how cloud services get added, how categories are assigned, how out-of-scope exclusions are justified, how records are retired, how discrepancies are investigated, and how the inventory reconciles to the SSP and diagram. The guide names the interviewees: personnel responsible for establishing and updating the system inventory, personnel with information security responsibilities, and system or network administrators.

Test. The Assessment Guide does not prescribe these exact demonstrations—they are DCR rehearsal scenarios mapped to the guide’s test objects for inventory processes and mechanisms: adding a new component, updating an existing one, removing or retiring one, detecting an unrecorded device, and producing a system-specific inventory from a centralized repository.

DCR evidence-preparation crosswalk

Map each assessment object to where it lives and who owns it:

One consequence worth internalizing, straight from the rule: if an SSP does not exist or is so out of date that it doesn’t accurately reflect the CMMC Assessment Scope at the time of assessment, the assessment can receive a finding that it could not be completed. The inventory is what makes the SSP’s scope claims checkable—so reconcile the inventory, SSP, and network diagram before assessment.

How should the inventory match the SSP, network diagram, CUI flow, and CRM?

Your inventory, SSP, assessment-scope network diagram, CUI-flow records, and external-service responsibility documents should all tell the same scope story. Each serves a different purpose, but an unexplained difference—a service in the SSP with no inventory record, or an SPA missing from the diagram—is an evidence gap that should be resolved before assessment. Consistency across artifacts is itself a signal of a mature program.

DCR cross-artifact reconciliation framework—the rule does not prescribe this table; each row tests whether the operating artifacts tell the same scope story.

Two precision points that save rework. First, you do not need a separate SSP write-up for every device—§ 170.19, Table 3 asks you to document asset treatment in the SSP, which is category-level. Second, the network diagram of the CMMC Assessment Scope should include the in-scope assets and depict the assessment boundary (DoD Level 2 Scoping Guide)—a category legend alone is not enough.

How often should you update a CMMC asset inventory?

CM.L2-3.4.1 requires the inventory to be maintained—reviewed and updated—throughout the system development life cycle, but it sets no universal monthly, quarterly, or annual interval. We recommend event-driven updates, monthly source reconciliation, quarterly owner and category attestation, and a full pre-assessment reconciliation as an operating cadence, not a CMMC mandate. The requirement is lifecycle maintenance, not a fixed calendar.

DCR recommended operating cadence—not a CMMC-prescribed schedule.

Two things worth remembering. From the DoD scoping guidance: routine operational changes within your boundary that follow the existing SSP may be covered by your annual affirmation, while a significant architectural or boundary change—a network expansion, a merger or acquisition—may require a new assessment. Annual affirmation is not an inventory-update interval. And a Level 2 (C3PAO) certification is valid for three years (32 CFR § 170.17), so the inventory has to stay accurate across that whole period, not just on assessment day.

Is the asset-inventory tool itself in CMMC scope?

Sometimes. An asset-inventory or CMDB platform can be a CUI Asset if it holds CUI, an SPA if it provides a security capability, a CRMA if it’s capable but intentionally restricted, or out-of-scope if it’s genuinely separated and performs no security function. The product name alone does not decide the category. Run it through the same triage as everything else.

Ask, in order: Does the tool contain CUI, drawings, attachments, ticket content, or CUI-bearing file names? Does it process Security Protection Data? Does it provide a security capability you rely on for a Level 2 requirement? Does it hold credentials, vulnerabilities, configuration details, or topology? Is it operated by an ESP? Is it technically separated from the CUI environment? Is its role described in your SSP and responsibility docs?

This is also why we tell you not to enter CUI, credentials, or vulnerabilities into anything you send externally. Keeping CUI out of a general-purpose tool can reduce the chance it becomes a CUI Asset—but the tool can still be an SPA or an in-scope ESP because of the security function it provides or the SPD it processes.

When should you get help, and which CMMC provider category fits?

Use an RP/RPO or a qualified scope adviser when category and boundary decisions remain unresolved; an MSP or MSSP when the ongoing problem is discovery, configuration, or operation; a GRC platform when the problem is evidence workflow; and a CUI-enclave provider when your existing environment makes the boundary too large. A C3PAO belongs at the certification-assessment stage—not as an undisclosed substitute for the readiness provider that builds the inventory. Matching the problem to the category is an easy decision to underthink, and getting it wrong can be expensive.

This is where The CMMC Path Framework applies—the logic that maps your required level, FCI vs. CUI handling, assessment type, environment, and timeline to the provider category you need. It routes to a category, not a named provider, and it is not a score, a ranking, or compliance advice.

One independence rule you cannot ignore. Under 32 CFR § 170.8(b)(17)(ii)(G), implemented in the CMMC Code of Professional Conduct (CoPC v2.0, effective December 16, 2024), a CMMC Ecosystem member cannot participate in the Level 2 certification assessment of an organization it served as a consultant within the previous three years. Practically: keep readiness/remediation and formal assessment separate, and before engaging a provider that offers both, identify in writing which legal entity and which personnel will perform each role.

What The Defense Compliance Report actually verified

We build every CMMC page on primary sources, and we date what we check because phases and rules change. Here’s what stands behind this one.

What we verified on July 10, 2026

• The current 32 CFR § 170.19 Level 2 asset-category language, Table 3, and the Level 1 and Level 3 deltas—read directly from the eCFR (which displayed Title 32 as current through July 8, 2026, last amended June 9, 2026).
• The § 170.4 definitions of Security Protection Data, Specialized Assets, Out-of-Scope Assets, and the “asset” concept.
• The CM.L2-3.4.1 assessment objectives, accountability details, and examine/interview/test objects—confirmed against the DoD CIO CMMC Level 2 Assessment Guide (v2.13) language.
• NIST SP 800-171 Revision 2 as the current CMMC Level 2 baseline: 110 security requirements organized into 14 families (320 assessment objectives).
• The Table 4 ESP/CSP scoping rules, and DFARS 252.204-7012(b)(2)(ii)(D): a CSP handling covered defense information/CUI must meet security requirements equivalent to the FedRAMP Moderate baseline.
• The rule and phase dates: 32 CFR Part 170 effective December 16, 2024; the DFARS acquisition rule (DFARS 252.204-7025; DFARS 252.204-7021) effective November 10, 2025; Phase 1 November 10, 2025–November 9, 2026; Phase 2 beginning November 10, 2026.
• The conflict-of-interest rule at 32 CFR § 170.8(b)(17)(ii)(G) and CoPC v2.0.

What we created (our editorial framework, labeled as such)

The DCR CMMC Asset Inventory Field Matrix v1.0 with R/A/D source labels, the eight-tab workbook structure, the Seven-Source Inventory Reconciliation Test v1.0, the maintenance cadence, the 15 conditional archetypes, the completed sanitized example, and the evidence-preparation crosswalk.

What this page does not establish

Whether specific information is CUI; which CMMC level your contract requires; whether a particular classification is correct without your environment’s facts; whether you satisfy CM.L2-3.4.1 or any other requirement; or whether you’ll pass an assessment.

Who, how, and why. This page was produced by The Defense Compliance Report Editorial Team through direct review of the primary sources above, a review of the CMMC guidance currently published on this topic, and a review of practitioner discussion (used for language and decision friction only, never as regulatory evidence). It exists to give DIB contractors an actionable artifact that separates what the rule requires from what an assessor looks for from what we recommend—before you hire or enter assessment. This is educational research, not legal, contractual, or compliance advice.

CMMC asset inventory FAQ

Does a CMMC asset inventory have to include hardware, software, firmware, and documentation?

Yes. CM.L2-3.4.1 names all four as part of the required inventory outcome, and the assessment objective checks for exactly that. Structurally, you can use linked registers rather than one giant flat row.

Is an operating-system inventory enough for CMMC?

No. The OS is software, but recording only the OS doesn’t establish an inventory of your other software, firmware, hardware, and documentation. That’s one way a device list can fail to demonstrate the complete CM.L2-3.4.1 inventory outcome.

Does every application need its own row?

The sources require inventorying software but don’t dictate a flat-row format. A normalized software register can associate applications and versions with an asset, a service, a system, or an approved baseline.

Does every asset have to be written individually into the SSP?

No. Each in-scope asset belongs in the inventory, but the DoD Level 2 Scoping Guide allows the SSP to describe the treatment of the asset category—you don’t need a separate SSP paragraph for every device.

Do people and facilities belong in a CMMC asset inventory?

They can. The DoD Level 2 Scoping Guide identifies people, technology, and facilities as possible Security Protection Assets when they provide security functions or capabilities to the CMMC Assessment Scope—for example, a system administrator who manages the enclave, or a SOC that monitors it.

Do out-of-scope assets have to be included?

There’s no formal Level 2 documentation requirement for out-of-scope assets, but § 170.19 says you must be prepared to justify the exclusion. We recommend a separate exclusion register so that justification is repeatable and reviewable.

Can a spreadsheet satisfy the requirement?

Yes, when it’s complete, system-specific, maintained, reviewable, and connected to supporting evidence. CMMC does not mandate a format; the records and process have to meet the assessment objectives.

Can an RMM or asset-discovery export satisfy it by itself?

Usually treat it as one input, not the whole answer. Discovery systems often miss CMMC category rationale, documentation, firmware relationships, external-service responsibilities, SSP treatment, and disconnected or specialized assets.

Can a centralized CMDB be used?

Yes. The Assessment Guide permits centralized inventories as long as each component ties back to its organizational system and owner.

How often must the inventory be updated?

CM.L2-3.4.1 requires maintenance throughout the lifecycle but does not prescribe a universal monthly or quarterly schedule. Your process should react to additions, changes, moves, version changes, and retirements.

What will an assessor ask to see?

Potential evidence includes inventory and update records, architecture, change-control records, and installation/removal records. Assessors may also interview the people responsible for the inventory and test the inventory process and mechanisms.

Can a VDI endpoint be out of scope?

Potentially—but only when configured so it can’t process, store, or transmit CUI beyond keyboard/video/mouse interaction, per § 170.19. Don’t assume an ordinary remote-access laptop qualifies.

Do I upload my CMMC asset inventory to SPRS?

No. The asset inventory is retained as assessment evidence. DFARS 252.204-7025 and the related CMMC provisions require the applicable CMMC status, affirmation of continuous compliance, and CMMC unique identifiers (UIDs) in SPRS—not the inventory file itself.

Is a CMMC asset inventory the same as the DFARS 252.204-7019 / 252.204-7020 SPRS assessment record?

No. The NIST SP 800-171 DoD Assessment governed by DFARS 252.204-7019 and 252.204-7020 produces a separate assessment-score record in SPRS. CMMC status, affirmations, and CMMC UIDs are governed by the current CMMC provisions and clauses, including DFARS 252.204-7021 and 252.204-7025. The records are related, but the asset inventory is not the SPRS score.

Does this Level 2 matrix apply to CMMC Level 1?

The five-category Level 2 scoping model and CM.L2-3.4.1 are Level 2 concepts. Level 1 information systems handling FCI are in scope, but § 170.19(b) doesn’t impose the same inventory documentation duties, and Specialized Assets are excluded from Level 1 entirely.

Can a C3PAO build the inventory and then assess it?

Do not assume so. Under 32 CFR § 170.8(b)(17)(ii)(G) and the CoPC, an assessor cannot participate in the assessment of an organization it served as a consultant within the previous three years. Keep readiness and formal assessment separate.