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

Authenticate (or verify) the identities of users, processes acting on behalf of users, and devices as a prerequisite to allowing access to your systems. Every claimed identity must be proven before access is granted — typically via passwords meeting policy, MFA, certificates, or keys for processes and devices.

Is 3.5.2 the same as MFA (3.5.3)?

No. 3.5.2 is the broad requirement to authenticate every identity before access. 3.5.3 is the narrower, heavily weighted requirement to use multifactor authentication for specific access types. You meet 3.5.2 with strong authentication generally; 3.5.3 adds the MFA mandate on top.

How do you authenticate a device or a process under 3.5.2?

Devices are commonly authenticated with certificates, 802.1X, or device-compliance checks before they're allowed on the network or to reach CUI. Processes/service accounts authenticate with managed credentials, keys, or certificates. The point is that non-human identities are verified too, not just interactive users.

CMMC 3.5.2 (Authentication): Evidence Examples & What Assessors Actually Check

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

Plain-English answer

3.5.2 requires you to authenticate (or verify) the identity of each user, process acting on behalf of a user, and device as a prerequisite to access. Identification (3.5.1) says who you claim to be; 3.5.2 makes you prove it before anything is granted — for humans, service accounts, and devices alike.

Who this applies to

Every organization seeking CMMC Level 2 for a CUI environment.

Why it matters

Authentication is the gate. If an identity can reach CUI without proving itself, every downstream control is undermined. It carries a weighted SPRS deduction if unmet (verify the exact value against the DoD Assessment Methodology). Note: MFA for specific access types is the separate, heavily weighted 3.5.3.

Control lineage

CMMC Practice: IA.L2-3.5.2
NIST 800-171 Rev. 2: §3.5.2 — authenticate (or verify) the identities of users, processes, or devices as a prerequisite to allowing access to organizational systems.
NIST 800-171A objectives: [a] the identity of each user is authenticated or verified as a prerequisite to system access; [b] the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access; [c] the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.

What the assessor will EXAMINE

Authentication configuration in the identity provider — password policy, MFA, sign-in enforcement for users.
How processes/service accounts authenticate (managed credentials, keys, certificates) and how those secrets are protected.
Device authentication before network/CUI access (certificates, 802.1X, device-compliance/conditional access).
Authentication/identity policy and the SSP narrative for 3.5.2.

What the assessor will INTERVIEW & TEST

Interview: "How does a user, a service account, and a device each prove identity before getting access?" — name the mechanism for all three.
Test: Attempt access with no/invalid credentials — confirm it's denied at the prerequisite stage.
Test: Confirm a sampled device must authenticate (cert/compliance) before reaching the CUI environment.

Evidence examples (produce these)

Identity-provider authentication settings (password policy, MFA, sign-in policy) export.
Service-account authentication scheme and secrets-management evidence (vault, key rotation).
Device-authentication config — certificate enrollment, 802.1X, or conditional access requiring a compliant device.
Authentication policy and SSP section 3.5.2 referencing the above.

Common failure patterns

Users authenticate, but devices reach the network with no authentication — objective [c] fails.
Service-account secrets hard-coded or shared, so process authentication can't be trusted — objective [b] weak.
Weak password policy that doesn't meaningfully verify identity.
Authentication enforced inconsistently across systems in scope.

SPRS impact & POA&M

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

Assessor-ready summary

You're good on 3.5.2 when users, processes, and devices each must prove identity before access; service-account secrets are managed and protected; devices authenticate before reaching CUI; and the SSP matches the enforced configuration.

Can an unauthenticated device reach your CUI enclave today? Get an authentication 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.