3.5.2 — Verify Before Entry

The One-Liner

Identification says who you claim to be. Authentication proves it. If any access path skips the proof step, you have a hole.

What It Says

Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.

What It Actually Means

Where 3.5.1 says “everyone has an identity,” this says “prove that identity before you get in.”

Authentication must happen on every access path — not just the front door. The assessor will check:

• Workstation login — does it require credentials?
• VPN connection — does it authenticate before granting access?
• Cloud app access — does it verify identity?
• Admin console access — does it require separate authentication?
• API access — do service accounts authenticate?

The key failure mode is a back door: a system that requires authentication for normal users but has an admin console or API endpoint that doesn’t. The assessor will look for exactly these gaps.

Device authentication matters too. If your network only checks user credentials but allows any device to connect, an attacker’s laptop with stolen credentials gets in. Certificate-based device authentication adds the second layer.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are user identities authenticated before access?	Users must prove identity (password + MFA) before accessing any system
2	Are process identities authenticated?	Service accounts authenticate via certificates, managed identities, or API keys
3	Are device identities authenticated?	Devices prove identity through certificates or MDM enrollment before connecting

---

What to Have Ready on Assessment Day

Documents they’ll review: Identification and authentication policy; procedures addressing authenticator management; system security plan; system design documentation; system configuration settings; list of system authenticator types; system audit logs and records

People they’ll talk to: Personnel with system operations responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system or network administrators

Live demos they’ll ask for: Mechanisms supporting or implementing authenticator management capability

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Walk me through every way someone can access your CUI systems. Does each path require authentication?”
• “Are there any admin consoles or APIs that can be accessed without authentication?”
• “How do devices authenticate to your network?”
• “Show me what happens when an unauthenticated device tries to connect.”
• “How do your service accounts authenticate — passwords, certificates, managed identities?”

Real-World Example

A contractor has four access paths to CUI: workstation login (Entra ID + Windows Hello), VPN (Entra ID + MFA), M365 cloud apps (Entra Conditional Access), and the Azure admin portal (Entra PIM with MFA). The assessor asks about API access — the IT team shows that all APIs use managed identities or certificate-based authentication, never embedded passwords. The assessor tries accessing an admin console without credentials and gets blocked.

---

Where Companies Trip Up

Back-door admin consoles. Main login requires MFA but an old web admin console has basic auth with a default password. Audit every access path.

Service accounts with passwords in scripts. Automation authenticates with a plain-text password in a config file. Use managed identities or certificate-based auth instead.

Network access without device auth. Users authenticate but any device connects. Add certificate-based device authentication or Conditional Access device compliance checks.

WiFi with shared PSK only. WPA2-PSK means the ‘authentication’ is just knowing the password — which everyone does. That’s not per-user or per-device authentication.

---

How to Talk About This

To a CEO or Board

Every access to our systems requires proof of identity — no exceptions. We verify users, devices, and service accounts before anything gets through.

To an Engineering Team

Auth required on all paths: Entra ID + MFA for users, Conditional Access with device compliance, certificate-based auth for service accounts, managed identities where possible. No embedded passwords. No back-door admin consoles.

---

Connected Requirements

Requirement	Why it matters here
3.5.1 — Prove Who You Are	Establishes the identities this requirement verifies
3.5.3 — MFA Everywhere	Adds multi-factor to the authentication required here
3.1.1 — Who Gets In	Uses verified identities to control system access
3.5.10 — Never Plain Text	Protects the credentials used for authentication

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: IA.L2-3.5.2 | SPRS Weight: 5 points | POA&M Eligible: No