Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
3.5.2OFFICIAL STATEMENT BELOWBASIC REQUIREMENTPENDING NIST SME REVIEW

3.5.2 — Authentication before access

3.5 Identification and Authentication · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

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

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Identification without authentication is a name badge with no photo. Every access path — interactive, service, device — must verify the claimed identity before granting access, using an authenticator whose strength matches what the account can reach.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: Centralizing applications behind the identity provider — a step the MFA rollout forces — is how authentication-before-access becomes enforceable in one place rather than per application.

What this does not claim: The requirement covers every access path, including device authentication and paths that never join the identity provider. The practice strengthens the central path; the periphery must be evaluated separately within the organization's defined system boundary.

Practice-side activities
  • Move applications behind single sign-on as MFA enforcement expands
  • Inventory access paths that authenticate locally and assign each an owner
Evidence this produces
  • SSO application register
  • Local-authentication exception list with owners

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Map the access paths that skip central authentication: local accounts, appliance logins, legacy protocols, direct database connections.
  • Put every application you can behind the central identity provider so authentication policy is enforced in one place.
  • Treat service-to-service authentication (API keys, connection strings) as in scope — long-lived static secrets are authentication too, just bad at it.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Identity-provider policy export showing authentication required per application
  • An inventory of access paths that authenticate locally, each with a reason and an owner
  • Authentication logs demonstrating the policy operates for a sampled period

Suggested owners, derived from the mapped practices and artifacts: Identity administrator. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

No artifact in the library names this requirement yet. The library index groups everything by category and practice.

The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated