1Overview
CM.L2-3.4.1 opens the Configuration Management family and is one of its most heavily weighted requirements. It requires that the organization establish and maintain baseline configurations and inventories of its systems, covering hardware, software, firmware, and documentation, across the whole life of those systems. It is a five-point requirement that cannot be deferred on a plan of action, because you cannot secure or defend an environment you have not first described.
A baseline is the known-good description of how a system is built and configured, and an inventory is the record of what systems exist. Together they are the foundation the rest of configuration management stands on: change control needs a baseline to measure change against, least functionality needs to know what is installed, and an incident responder needs to know what should be there in order to spot what should not. This control asks the organization to establish those baselines and inventories and to keep them current as systems change, so that the environment is described accurately rather than assumed.
Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
The requirement pairs two artifacts, a baseline configuration and an inventory, and requires both to be established and maintained across the life cycle. "Maintained" is the demanding word, because a baseline or inventory captured once and never updated drifts out of truth as systems change, and a stale description is worse than none because it invites false confidence. The five-point weight reflects that this description of the environment is the ground every other configuration control builds on.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.4.1 into six objectives, three for the baseline and three for the inventory: establish it, ensure it covers hardware, software, firmware, and documentation, and maintain it.
A baseline configuration is established. The organization has a documented known-good configuration for its systems.
The baseline configuration includes hardware, software, firmware, and documentation. The baseline is complete across those elements.
The baseline configuration is maintained throughout the system development life cycle. The baseline is reviewed and updated as systems change.
A system inventory is established. The organization has a record of the systems it operates.
The system inventory includes hardware, software, firmware, and documentation. The inventory is complete across those elements.
The inventory is maintained throughout the system development life cycle. The inventory is reviewed and updated as systems change.
The six objectives mirror each other across the baseline and the inventory. The common gap is at objectives [c] and [f], maintenance, where a baseline and inventory were built for the assessment but are not kept current, so they drift almost immediately. The assessor looks for descriptions that are complete and demonstrably maintained, not one-time documents.
3Failure Patterns
The failures are about incomplete descriptions and descriptions that are not kept current.
The baseline that was written once
A baseline created for the assessment and never updated drifts out of truth as systems change, which fails the maintenance objectives. A baseline is only useful if it keeps pace with the environment it describes.
The inventory that misses shadow systems
An inventory that omits systems added quietly, a spare machine, a test box, a cloud instance, leaves blind spots that no other control can protect. Maintaining the inventory means capturing what actually appears in the environment, not only what was planned.
Coverage that stops at software
Baselines and inventories that cover software but omit firmware or hardware fail the completeness objectives. Firmware in particular is often forgotten, yet it is part of what has to be described and maintained.
Documentation left out
The requirement names documentation explicitly, and a baseline or inventory that captures technical detail but no documentation is incomplete. The documentation is what makes the baseline usable by someone other than the person who built it.
4Ownership
This is an IT-owned technical control, and its main demand is the discipline to keep the baseline and inventory current rather than letting them go stale.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Establishes the baseline and inventory across hardware, software, firmware, and documentation, and maintains them as systems change. Owns the technical evidence. |
| Security or compliance lead | Confirms the baseline and inventory are complete and current, and that maintenance actually happens. |
| Program lead | Ties baseline and inventory updates to the change process so they stay current, and retains the records. |
5Tooling
The control is delivered by configuration documentation and by discovery and inventory tooling that keeps the picture current.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a], [b] | Documented baseline, configuration management database | The established known-good configuration across hardware, software, firmware, and documentation. |
| [d], [e] | Asset discovery and inventory tooling | An inventory of systems and their components, kept complete. |
| [c], [f] | Automated discovery, change-driven updates | Maintenance that keeps the baseline and inventory current as the environment changes. |
| Coverage | Firmware and documentation tracking | Inclusion of the elements often forgotten, especially firmware and documentation. |
The caveat is that automation helps but the maintenance discipline is what satisfies the control. Discovery tooling can keep an inventory current, but the baseline still needs deliberate updating as systems change, and both have to cover the full set of elements. The assessor examines whether the baseline and inventory are complete and current, so maintenance has to be demonstrable, not assumed.
6Evidence
The satisfied version of 3.4.1 shows complete, maintained baselines and inventories.
| Evidence | What it demonstrates |
|---|---|
| Baseline configuration | Objectives [a], [b]. The documented known-good configuration across all elements. |
| System inventory | Objectives [d], [e]. The record of systems and their components. |
| Maintenance records | Objectives [c], [f]. Evidence the baseline and inventory are updated as systems change. |
| Coverage confirmation | Objectives [b], [e]. Inclusion of hardware, software, firmware, and documentation. |
The evidence should show baselines and inventories that are both complete and current, with a maintenance history rather than a single snapshot. The documented baseline and inventory paired with records of their updates is the clearest demonstration, and because this control cannot sit on a plan of action, both have to be real and current at the time of assessment.
You cannot secure what you have not described
The baseline and inventory are a five-point control because every other configuration control measures against them, and the usual gap is not creating them but keeping them current as the environment changes. Establishing complete baselines and inventories and building the discipline to maintain them is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.4.1. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.4.1[a] through 3.4.1[f]. csrc.nist.gov
- 32 CFR 170.24, CMMC Scoring Methodology, listing CM.L2-3.4.1 among the five-point basic security requirements. ecfr.gov