RMFInsider

An eMASS hardware software list that doesn’t match what’s actually running on your network is worse than no list at all — it tells an assessor your ISSO doesn’t know their own system, and it undermines every control response built on top of it. The hardware/software baseline is the foundation the rest of your package sits on: your authorization boundary, your control implementation statements, and your continuous monitoring all trace back to “what is actually part of this system.” Here’s how to build one that survives contact with an assessor, and how to keep it accurate after the initial package is submitted.

Why the Baseline Matters More Than It Looks

The hardware and software baseline in eMASS isn’t a formality you fill out once and forget. It’s the list an SCA cross-references against every control response you write. If your SSP says a control is implemented on a specific server and that server isn’t on the baseline, or the baseline lists a piece of software nobody can explain, that’s a finding before the assessor even opens the SSP. The baseline is also what defines your authorization boundary in practice — not the diagram, the actual list of what’s inside it.

Get this list wrong at the start and every downstream document inherits the error. Get it right and it becomes the single source of truth you can point to whenever anyone — an auditor, a new team member, an AO — asks “what does this system actually consist of.”

There’s also a practical reason to get this right beyond passing an assessment. When an incident happens — a vulnerability drops that affects a specific software version, or a new CVE targets a piece of hardware firmware — the baseline is the first place you look to determine whether you’re exposed. An inaccurate baseline means you’re answering that question by guessing instead of checking a record, and in a DoD environment that gap can mean the difference between a fast, confident answer to your ISSM and a scramble to physically verify what’s running where.

Building the List: Where the Data Actually Comes From

Don’t start the baseline by typing into eMASS from memory. Pull from sources that reflect what’s actually deployed, then reconcile:

• Asset management or CMDB exports, if your organization maintains one
• Vulnerability scan results, which report every host and installed software version they can see
• Network diagrams and firewall rule sets, cross-checked against what’s physically or virtually deployed
• System administrator interviews — the person who actually manages the boxes usually knows about the one server nobody documented
• Software license and procurement records, which catch approved software that hasn’t been installed yet or should have been decommissioned

None of these sources alone is complete. A CMDB is only as accurate as the last person who updated it; a scan only sees what’s reachable and responding. Cross-referencing at least two sources for every asset is what catches the gaps — the decommissioned server still sitting in the CMDB, or the shadow IT box a scan picked up that nobody put on the diagram.

What Belongs on the Baseline

Category	What to Capture
Hardware	Servers, workstations, network devices, storage — make/model, serial or asset tag, location, function
Operating systems	OS name, version, patch level, per host
Applications and software	Name, version, vendor, function, and which host(s) it runs on
Virtual assets	VMs and containers, mapped to their underlying physical hosts
Firmware	Version tracking for network devices and appliances, especially anything with known CVEs tied to firmware version

Every entry should map back to the authorization boundary — if it’s not inside the boundary, it doesn’t belong on this baseline. If you haven’t nailed down exactly what’s in and out of scope, that decision needs to happen before the baseline does, because the baseline is a direct reflection of it. I walked through how AOs actually evaluate that scoping decision in the authorization boundary diagram how-to.

Loading and Structuring It in eMASS

Inside eMASS, the hardware and software list lives under the system’s registration and asset inventory sections, and the entries there need to be granular enough that a reviewer can trace a specific control response to a specific asset. A vague entry like “web servers (3)” doesn’t hold up when a control response references a specific host’s patch status. Name each asset distinctly, keep the OS and version fields current, and use the same naming convention across your baseline, your SSP, and your network diagram — a discrepancy in naming between documents reads like a discrepancy in the system itself, even when it isn’t.

If you’re building a baseline from scratch on a system that’s new to eMASS, get comfortable with the registration workflow first — the asset inventory step depends on the system record already being set up correctly. That’s covered in more depth in the eMASS fundamentals guide if you’re still finding your way around the tool: eMASS for beginners.

Sample Baseline Entry

What granular actually looks like, for a single asset:

Field	Entry
Asset name	APP-SRV-02
Type	Virtual server
Function	Application server, front-end web service
Operating system	Name and version, with current patch level
Installed software	Named application(s), version numbers, vendor
Host location	Underlying physical host or hypervisor cluster
Boundary status	Inside authorization boundary — confirmed against boundary diagram
Last verified	Date of most recent reconciliation against scan data

That “last verified” field does more work than any other line on the baseline. It’s the field that tells an assessor whether this is a living document or a snapshot from initial authorization that nobody has revisited since.

Categories People Forget to Include

The obvious assets — servers, workstations, the applications everyone uses daily — rarely get missed. The gaps tend to show up in categories that don’t feel like “the system” even though they’re inside the boundary:

• Network appliances — switches, routers, load balancers — that support the system but aren’t hosts in the traditional sense
• Management and monitoring tools installed specifically to support this system, even if they’re not user-facing
• Backup and recovery software, along with the infrastructure it runs on
• Development or test instances that share the same authorization boundary as production
• Third-party libraries and dependencies bundled inside an application, not just the application itself

Every one of these is a plausible finding if an assessor discovers it running inside the boundary and can’t find it on the baseline. The fix is the same reconciliation habit from earlier — cross-reference the baseline against scan data and administrator knowledge, not just the obvious inventory list someone handed you at the start of the package.

Keeping It Current Through ConMon

A baseline built once and never touched again is a baseline that’s wrong by the next quarter. Software gets patched, servers get decommissioned, new tools get added to support a mission requirement — all of it has to flow back into the eMASS record, and the mechanism for that is your continuous monitoring process, not a once-a-year cleanup before reassessment.

The practical habit that keeps this from drifting: every change ticket that adds, removes, or modifies an asset should trigger a baseline update as part of closing that ticket, not as a separate task someone remembers to do later. Tie it to your security impact analysis process — if a change touches an asset, the person writing the impact analysis is also the person who should confirm the baseline reflects the change. Vulnerability scan results are also a built-in reconciliation check: if a scan reports a host or software version that isn’t on your baseline, that’s a discrepancy to resolve immediately, not at the next audit.

Why Audits Fail Here

The most common finding tied to the hardware/software baseline isn’t that it’s missing — it’s that it’s stale. A baseline that was accurate at initial authorization but hasn’t been touched since reads as a system nobody is actively managing, and that undermines confidence in every other control response in the package. The second most common finding is scope mismatch: assets on the baseline that aren’t actually inside the authorization boundary, or boundary assets that never made it onto the baseline. Both come back to the same root cause — the baseline wasn’t treated as a living document tied to the change process.

• Baseline last updated months before the assessment, with no evidence of periodic review
• Assets referenced in control responses that don’t appear on the baseline
• Software versions on the baseline that don’t match what a vulnerability scan reports
• Decommissioned hardware still listed as active
• Naming inconsistencies between the baseline, the SSP, and the boundary diagram

Every one of these is preventable with a review cadence tied to your ConMon cycle rather than a scramble the week before an assessor shows up.

Building the Habit

Treat the hardware and software baseline the way you’d treat any other piece of evidence an assessor is going to pull without warning: accurate as of today, not accurate as of the last time someone had a spare afternoon. That mindset is the difference between an eMASS package that survives an SCA-V walkthrough and one that generates a list of findings before the assessor even reaches your control implementation statements.

If you’re building out the rest of your RMF documentation alongside the baseline — SSP, POA&M, boundary diagram — a structured checklist keeps the pieces from drifting out of sync with each other: the RMF Checklist.