3.5 Identification and Authentication: the NIST SP 800-171 requirements

Ensure every user, service process, and device has a unique identifier in your directory: unique usernames per person, dedicated named service accounts per application (no reuse), and device identities via domain join or MDM enrollment. Purge duplicate and legacy identifiers. Evidence: directory exports showing the naming convention and a device inventory tied to unique device identities.

Require authentication before any access to systems handling CUI: no anonymous shares, no blank passwords, no auto-logon, and 802.1X or equivalent for network-level device authentication where feasible. Audit for and eliminate any unauthenticated access paths (open file shares are a common finding). Evidence: authentication policy settings, a share permissions audit, and screenshots showing login enforcement on each system type.

Enforce MFA via your identity provider (Entra ID, Duo, Okta) on all accounts, covering local and network access for privileged accounts and network access for all users: including VPN, email, and cloud apps. Prioritize privileged and remote users first: under DoD scoring, MFA implemented for remote and privileged users but not general users scores a 3-point deduction instead of the full 5, so partial rollout still improves your SPRS position while you finish. Use Duo for RDP/Windows logon to cover local privileged access on servers. Evidence: conditional access/MFA policy exports, enrollment reports showing 100% coverage, and VPN MFA configuration.

Use authentication protocols that resist replay: modern MFA with time-based or challenge-response tokens, Kerberos, and TLS-protected logons all qualify: the practical work is disabling legacy protocols (NTLMv1, basic auth in Exchange Online, unencrypted LDAP binds) that do not. Blocking legacy authentication in your cloud tenant is a high-impact quick win. Evidence: conditional access rules blocking legacy auth and domain policy settings disabling NTLMv1.

Set a written rule that user and device identifiers are never reassigned to a different person or device for a defined period (many organizations simply never reuse them: disabled accounts are archived, not recycled). Enforce it in your provisioning procedure. This is a documentation-plus-process fix with no tooling cost. Evidence: the identifier management procedure and directory records showing departed users' accounts retained in disabled state.

Automate disabling of accounts inactive beyond your threshold (commonly 30-90 days): a scheduled PowerShell script against last-logon timestamps, an Entra ID access review, or your identity platform's built-in inactivity policy. Run a one-time cleanup of stale accounts immediately: most environments find several. Evidence: the automation script/policy, its schedule, and a report of accounts disabled by it.

Enforce password complexity and minimum length via GPO or your identity provider (14+ characters is a common modern target), and consider a banned-password list (Entra ID Password Protection) to block trivial choices. Ensure the policy requires changed character content when passwords are updated. Evidence: the password policy export and a test showing weak passwords rejected.

Enable password history in your directory policy so previous passwords cannot be reused for a defined number of generations (24 is the common Windows default target). This is a single policy setting: verify it applies to cloud accounts as well as on-prem AD. Evidence: the password history setting in your policy export.

Configure "user must change password at next logon" for all temporary and initial passwords issued at onboarding or reset, and deliver temporary credentials out-of-band from the username. Write this into your account provisioning procedure so helpdesk staff apply it consistently. Evidence: the provisioning procedure and a screenshot of the change-at-next-logon flag on a newly created account.

Verify passwords are stored only as salted cryptographic hashes and transmitted only over encrypted channels: modern AD and cloud identity providers handle storage correctly, so the real work is hunting down plaintext passwords in scripts, config files, spreadsheets, and legacy apps, and eliminating protocols that send credentials in the clear (telnet, FTP, HTTP logins). Deploy a password manager for the team as a quick win. Evidence: a credential-scanning sweep of file shares and repos, and scan results showing no cleartext authentication services.

Confirm every login interface masks password entry (dots/asterisks) and returns generic failure messages rather than revealing whether the username or password was wrong: check internally developed apps and legacy systems, since mainstream OS and cloud logons already comply. Evidence: screenshots of each custom login screen showing obscured entry and generic error text.