IA.L2-3.5.2Authentication [CUI Data]
Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.
[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; and[c]
the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
Nothing reaches the VDI pool without a verified user, workload, and device claim
Implementation
AO coverage. Addresses all three Authentication objectives — user, process, and device verification as a prerequisite to access. Factor strength for those authentications is described in the IA.L2-3.5.3 and IA.L2-3.5.4 examples rather than repeated here.
Users. Every enclave entry point (virtual desktop feed, both SaaS apps, the session-host management plane) authenticates through the IdP. Legacy authentication protocols that skip modern auth are blocked tenant-wide, so there is no password-only fallback path to fail back to.
Processes acting on behalf of users. Pipelines and integration jobs authenticate as workload identities using federated OIDC credentials or certificates. Client secrets are not issued for new integrations, and the three remaining secret-based integrations have dated migration tickets. No automation reuses a human account.
Devices. Session hosts and endpoints receive a device certificate through MDM enrollment; the access policy requires a compliant-device claim, so a browser on an unmanaged laptop cannot obtain the desktop feed even with correct credentials. Verified sign-ins record the device object ID, which is what makes the monthly check below possible.
Maintenance. Monthly query for any successful enclave authentication that lacked a device claim (expected result: zero, or a documented break-glass). Quarterly workload-identity attestation by each owner, and a purge of device certificates whose MDM object is gone.
Accepted gap. One customer's file exchange accepts SSH key authentication only, with no device identity. The key lives on a single hardened transfer host — that host is effectively the authenticated device — is pinned to our egress address on the customer side, and rotates annually.
What the evidence looks like
- Conditional Access policies for the desktop feed and both SaaS apps
- Tenant setting export showing legacy authentication blocked
- Workload identity federation configuration and the secret-migration tickets
- SCEP certificate profile plus a sign-in log sample showing device claims
- Transfer-host exception record with key rotation history
Environment
Tools
2 ratings on this revision
Across the finish line
Clear separation of registration from day-to-day use. Good for a hybrid shop.
Across the finish line
Authenticator binding and recovery story are explicit. Evidence list matches what I would sample in interview.
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.