CMMC 3.4.1 Baseline Configuration: What Assessors Test

A baseline document tells an assessor what you intended. It says nothing about what your fleet looks like today.

CMMC practice 3.4.1 sits in the Configuration Management family and is easy to treat as paperwork. It is a paperwork requirement with an operational test attached, and the test is where teams stall.

What does CMMC 3.4.1 require?

CMMC 3.4.1 requires you to establish and maintain baseline configurations and inventories of organizational systems, covering hardware, software, firmware and documentation, throughout the system life cycle. The wording comes from NIST SP 800-171, and assessors score it against the six objectives in NIST SP 800-171A.

Those six objectives split into two halves:

• 3.4.1[a]: a baseline configuration is established.
• 3.4.1[b]: the baseline includes hardware, software, firmware and documentation.
• 3.4.1[c]: the baseline is maintained (reviewed and updated) throughout the life cycle.
• 3.4.1[d]: a system inventory is established.
• 3.4.1[e]: the inventory includes hardware, software, firmware and documentation.
• 3.4.1[f]: the inventory is maintained (reviewed and updated) throughout the life cycle.

Two of the six objectives, [c] and [f], are about staying current. Those are the ones a one-time snapshot cannot satisfy.

What do assessors examine, interview and test?

NIST SP 800-171A lists three assessment methods for 3.4.1, and each pulls on a different kind of proof. Under examine, it names configuration management policy, system inventory records, inventory review and update records, and change control records. Under interview, it names personnel with configuration management and inventory responsibilities, plus system or network administrators. Under test, it names the mechanisms that support configuration control of the baseline and the mechanisms that implement and update the system inventory.

Read the test list again. It names mechanisms, not documents. An assessor following that list can ask to see the process that keeps the inventory current, and ask an administrator to show it running.

Because the objectives are listed together, [c] and [f] matter as much as the baseline document itself.

Why do documented controls still fail assessment?

Controls fail when nobody generated evidence that they operate. An N-able analysis of CMMC evidence puts it directly: "The control is marked 'Not Met,' not because protection was absent, but because evidence of protection was never generated."

The same article makes a point that applies squarely to baselines: "Configuration screenshots alone are rarely sufficient for controls that require demonstration of ongoing process execution." A screenshot shows one machine at one moment. Objective [c] asks whether the baseline is reviewed and updated over time, and a screenshot cannot show a review.

That gap between a deployed setting and evidence of the setting is the central problem for a 3.4.1 package. We covered the broader version of it in what compliance software can and cannot prove for CMMC.

What counts as adequate versus sufficient baseline evidence?

Adequate evidence shows the right thing. Sufficient evidence shows enough of it. A Futurefeed explainer on CMMC evidence defines them this way: "Adequacy means you are showing the right thing" and "Sufficiency means you are showing enough," and it states that "You need both adequate and sufficient evidence to pass a CMMC assessment."

Its worked example is a configuration baseline, and it maps neatly onto 3.4.1:

• A current, approved baseline document that covers every system type in scope is adequate.
• Configuration exports showing the baseline applied on both Windows and Linux systems are what make it sufficient. The article notes that evidence from only one system type is insufficient.
• A baseline document with no operational proof is adequate but not sufficient.
• Windows-only screenshots in a mixed environment are insufficient.
• An outdated baseline that no longer matches current systems fails both tests.

The practical reading: the document is the starting point, and the per-device record of conformance is what closes the requirement.

How is 3.4.1 different from 3.4.2 and 3.4.3?

3.4.1 asks whether a baseline and inventory exist and are maintained. 3.4.2 asks whether settings are enforced against it, and 3.4.3 asks whether changes to systems are tracked, reviewed, approved or disapproved, and logged.

NIST SP 800-171A phrases 3.4.2 as two objectives: security configuration settings are established and included in the baseline configuration, and those settings are enforced. For 3.4.2, its test list names mechanisms that "identify and/or document deviations from established configuration settings." Objective 3.4.3[d] requires changes to be logged, and 3.4.3[a] through [c] require them to be tracked, reviewed, and approved or disapproved.

Taken together, the three practices describe one loop: define the baseline, detect deviation from it, and record the change. An assessor sampling 3.4.1 will often follow the thread into the other two. A device that drifted from baseline should show up as a documented deviation or an approved change, not as a surprise. When a device falls out of line, how you record it matters as much as the drift itself. The same logic applies to laptops that fall out of compliance during a SOC 2 period.

What should an inventory include to satisfy objectives [d] through [f]?

Objective [e] in NIST SP 800-171A says the inventory includes hardware, software, firmware and documentation, so a list of hostnames is not enough. A useful record per device ties the pieces together:

1. Identity: a stable device identifier, owner or role, and where it sits in scope.
2. Hardware and firmware: model, serial, and firmware or BIOS version.
3. Software: operating system build and installed software, including versions.
4. Baseline state: which baseline applies and whether the device conforms right now.
5. Last observed: the timestamp of the most recent observation.

The fifth item carries the most weight for objective [f]. An inventory entry with no observation date cannot show that the inventory is "reviewed and updated." Software support status belongs in that record too. A system running software past vendor support is a baseline question, and whether end-of-life software is an audit finding depends on exactly this kind of record.

How do you keep a baseline current across a fleet?

You keep it current by measuring conformance continuously and retaining the history. Quarterly spreadsheet reviews can satisfy the letter of "reviewed," but they leave a long window in which the baseline and reality diverge unobserved.

A workable pattern for the evidence side:

• Define the baseline in machine-checkable terms. Each setting becomes a test with a pass, fail or unknown result.
• Observe from the device. Sensors that report live telemetry give you the state of the device itself rather than a record of what a management tool intended to push.
• Keep the time series. An assessor asking about objective [c] wants to see reviews and updates over time, not only today's state.
• Report unknown honestly. A device that has not reported is not a passing device. Counting it as unverified keeps the inventory truthful.
• Route deviations to people. Drift should reach a named owner for approval or correction, with the decision logged to support 3.4.3.

NIST's guidance on continuous monitoring frames the same idea at program level: monitor the things whose change matters. We walked through which device attributes belong on that list.

The takeaway: what should you do before an assessment?

CMMC 3.4.1 has six objectives. Two of them, [c] and [f], require proof that the baseline and inventory stay current.

• Write the baseline and the inventory scope first. They are necessary, and they are not sufficient.
• Collect per-device conformance evidence across every system type in scope, not a single screenshot.
• Keep the history, so reviews and updates are visible over time.
• Treat unknown as unknown, and log every deviation and approved change.
• Confirm exact evidence expectations with your C3PAO, since the assessment outcome is the C3PAO's call, not a software vendor's.

SAUTERA scores device posture continuously from live telemetry and records an honest "unknown" where it cannot prove trust, so conformance history accumulates without a pre-assessment scramble. Remediation stays human-approved. Start free with 10 devices for 30 days, no card.