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.5.1 require?

Identify system users, processes acting on behalf of users, and devices. Every user needs a unique identifier (no shared accounts), service/automated processes must be identifiable, and devices that access the system must be identified — so that later authentication (3.5.2) and accountability (audit logging) have something to attach to.

What's the difference between 3.5.1 and 3.5.2?

3.5.1 is identification — assigning and managing unique identifiers for users, processes, and devices. 3.5.2 is authentication — proving that a claimed identity is genuine before granting access. Identification says who you claim to be; authentication proves it. They're assessed as separate controls.

Are shared accounts allowed under 3.5.1?

Shared or generic accounts undermine 3.5.1 because they break unique identification and individual accountability. Where a shared/service account is unavoidable, it must be identified, justified, tightly controlled, and traceable to a responsible owner — but unique per-user identifiers are the expectation.

CMMC 3.5.1 (Identification): Evidence Examples & What Assessors Actually Check

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

Plain-English answer

3.5.1 requires you to identify three things: system users (unique identifier per person), processes acting on behalf of users (service/automated accounts), and devices that access the system. It's the foundation that authentication (3.5.2) and accountability (audit logging) build on — you can't prove or trace an identity you never assigned.

Who this applies to

Every organization seeking CMMC Level 2 for a CUI environment.

Why it matters

Unique identification is what makes individual accountability possible — without it, logs can't pin an action to a person, and least privilege can't be enforced. It carries a weighted SPRS deduction if unmet (verify the exact value against the DoD Assessment Methodology).

Control lineage

CMMC Practice: IA.L2-3.5.1
NIST 800-171 Rev. 2: §3.5.1 — identify system users, processes acting on behalf of users, and devices.
NIST 800-171A objectives: [a] system users are identified; [b] processes acting on behalf of users are identified; [c] devices accessing the system are identified.

What the assessor will EXAMINE

The user/identity directory (e.g., Entra ID, Google Workspace, Active Directory) showing unique per-user accounts.
An inventory of service/automated accounts (processes acting on behalf of users) and their owners.
A device inventory and the mechanism by which devices are identified (asset tags, certificates, device IDs, MDM).
Account/identity management policy and the SSP narrative for 3.5.1.

What the assessor will INTERVIEW & TEST

Interview: "How is each user, service account, and device uniquely identified?" — name the directory, the service-account register, and the device-identification method.
Test: Sample the directory for shared/generic accounts that break unique identification.
Test: Reconcile the device inventory against what's actually connecting for unidentified devices.

Evidence examples (produce these)

Directory export showing unique user identifiers (no shared logins).
Service-/automated-account inventory with owners and purpose.
Device inventory plus the identification method (certificates, MDM device IDs, 802.1X).
Account-management policy covering naming, uniqueness, and service accounts.
SSP section 3.5.1 referencing the above.

Common failure patterns

Shared/generic accounts (a team "admin" login) — breaks objective [a] and individual accountability.
Service accounts undocumented, so processes acting on behalf of users aren't identified — objective [b] fails.
No device identification — anything can connect — objective [c] fails.
Identifiers reused or recycled in a way that confuses traceability.

SPRS impact & POA&M

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

Assessor-ready summary

You're good on 3.5.1 when every user has a unique identifier, service/automated accounts are inventoried with owners, devices are identified before they connect, and the SSP matches your directory and inventories.

Sure there are no shared logins hiding in your directory? Get an identity & device 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.