How is Athena different from Secureframe, Strike Graph, Paramify, Risk Cognizance, SMPL-C, or Kiteworks?

Those platforms optimize the contractor's readiness workflow — live SPRS tracking, AI controls dashboards, fast SSP/POA&M drafting, continuous control monitoring, LLM document analysis, or CUI data movement. Athena adds the assessor-facing submission layer that almost none of them ship: SAR narrative drafting, eMASS-ready JSON packaging, OSCAL output, and cryptographic provenance (SHA-256 + chain-of-custody) for every artifact a C3PAO or DIBCAC assessor opens on engagement day.

Does Athena replace Secureframe, Strike Graph, or Paramify?

No — Athena is the assessor-side submission layer that sits on top of whatever readiness GRC you already use. Bring evidence from any tool; Athena drafts the SAR, generates the POA&M with prioritized remediation, scores SPRS, and exports eMASS / OSCAL packages with provenance.

What does Athena export for a CMMC Level 2 assessment?

SAR draft with citations, POA&M with milestone estimates, SPRS scoring package, eMASS-ready JSON, OSCAL package, evidence binder with SHA-256 hashes, and a chain-of-custody manifest signed for the assessor.

What does CMMC 3.4.1 require?

Establish and maintain baseline configurations and inventories of your systems — including hardware, software, firmware, and documentation — throughout the system life cycle. Both a documented baseline and an accurate inventory, kept current.

How is 3.4.1 different from 3.4.2?

3.4.1 is about HAVING a documented baseline and inventory (what your systems should look like, and what you have). 3.4.2 is about establishing and ENFORCING the security configuration settings within that baseline.

How many SPRS points is 3.4.1 worth?

3.4.1 carries a weighted deduction under the DoD Assessment Methodology. Confirm the exact current weighting against the official methodology.

CMMC 3.4.1 (Baseline Configuration & Inventory): Evidence Examples & What Assessors Actually Check

Control: NIST SP 800-171 Rev. 2 §3.4.1 · CMMC Practice: CM.L2-3.4.1 · Updated June 2026

Plain-English answer

3.4.1 requires two things you establish and keep current: a documented baseline configuration (what a properly-built system should look like — hardware, software, firmware, documentation) and an accurate inventory of those systems. "We know our environment" isn't enough; it has to be written down and maintained.

Who this applies to

Every organization seeking CMMC Level 2 for a CUI environment. It's the foundation the rest of configuration management (and your scope) rests on.

Why it matters

You can't secure or assess what you haven't inventoried, and you can't detect drift without a baseline. It carries a weighted SPRS deduction if unmet (verify the exact value against the DoD Assessment Methodology).

Control lineage

CMMC Practice: CM.L2-3.4.1
NIST 800-171 Rev. 2: §3.4.1 — establish and maintain baseline configurations and inventories of organizational systems (hardware, software, firmware, documentation) throughout the respective system development life cycles.
NIST 800-171A objectives: [a] a baseline configuration is established; [b] it includes hardware, software, firmware, and documentation; [c] it is maintained throughout the life cycle; [d] a system inventory is established; [e] it includes hardware, software, firmware, and documentation; [f] it is maintained throughout the life cycle.

What the assessor will EXAMINE

The documented baseline configuration(s) for system types in scope.
The hardware and software inventory — and how it's kept current (automated discovery preferred).
Configuration-management policy/plan and the SSP narrative for 3.4.1.
Records of baseline/inventory review and updates over time.

What the assessor will INTERVIEW & TEST

Interview: "Where's your baseline, and how do you know your inventory is current?" — point to the documented baseline + the discovery tool / review cadence.
Test: Compare the inventory against what's actually on the network — unknown devices/software are a finding.
Test: Confirm a sampled system matches its documented baseline.

Evidence examples (produce these)

Documented baseline configuration(s) per system type (with version/date).
Hardware + software inventory export, dated, with the maintenance process described.
Automated asset/software discovery output (e.g., MDM/RMM, endpoint manager) backing the inventory.
Configuration-management policy/plan.
SSP section 3.4.1 referencing the above.

Platform-specific

Microsoft GCC High: Intune device inventory + configuration profiles as baselines; software inventory from endpoint manager.
Google Workspace / endpoints: endpoint management device list + your MDM/RMM software inventory.

Common failure patterns

An inventory exists but is a stale spreadsheet that doesn't match the live network.
No documented baseline — just "we configure them the same way."
Software inventory missing (only hardware tracked), so objective [e] fails.
Baseline/inventory never reviewed, so it drifts out of date.

SPRS impact & POA&M

SPRS: 3.4.1 carries a weighted deduction (verify the exact value). POA&M: confirm 3.4.1's POA&M eligibility against current CMMC rules before assuming it can be deferred.

Assessor-ready summary

You're good on 3.4.1 when documented baselines exist for in-scope system types; an accurate hardware/software inventory is maintained (ideally via discovery); both are reviewed/updated; the inventory matches the live network; and the SSP reflects it.

Is your inventory assessor-ready, or a stale spreadsheet? Get a configuration-management evidence map →

Athena prepares organizations for CMMC Level 2; certification rests with C3PAOs/DIBCAC. Verify all control facts against NIST SP 800-171 Rev. 2, NIST SP 800-171A, and current CMMC rules.