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
03.05.12OFFICIAL TITLEPENDING NIST SME REVIEW

03.05.12 — Authenticator Management

03.05 Identification and Authentication · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires managing system authenticators across their lifecycle: verifying the identity of the individual, group, role, service, or device receiving an authenticator as part of initial distribution; establishing initial authenticator content for organization-issued authenticators; maintaining administrative procedures for distribution, for lost, compromised, or damaged authenticators, and for revocation; changing default authenticators at first use; changing or refreshing authenticators at an organization-defined time period or upon organization-defined events; and protecting authenticator content from unauthorized disclosure and modification.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

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

What this requirement is after

Authenticators — passwords, security keys, certificates, tokens — are issued to a verified person, tracked, replaced when lost, revoked when someone leaves, and never left at factory defaults. Rev. 2 said pieces of this about passwords only; Rev. 3 says it about everything that authenticates.

Across revisions

New as a standalone requirement in Rev. 3, drawn from SP 800-53's IA-5 base control: Rev. 2 covered only password-specific handling in 3.5.7 through 3.5.10, leaving the wider lifecycle — issuance verification, loss and revocation procedures, default-credential changes — without a home.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: An MFA rollout runs an authenticator lifecycle whether it means to or not: verifying who is enrolling, registering keys and passkeys, replacing lost ones, revoking at departure. Done deliberately, that routine advances the issuance, protection, and revocation elements of this requirement for the factors the practice deploys.

What this does not claim: The requirement spans every authenticator type — passwords, certificates, tokens, device secrets — plus default-credential changes and organization-defined refresh, most of which sit outside an MFA deployment. May partially address the requirement for the authenticators the practice issues; the rest of the lifecycle needs its own procedures.

Practice-side activities
  • Verify identity before MFA enrollment and re-enrollment
  • Define and operate the lost-key replacement and departure-revocation path
  • Record authenticator issuance and revocation against joiner and leaver events
Evidence this produces
  • Enrollment-verification procedure and records
  • Revocation records tied to departures
  • Registered-authenticator reports from the identity provider

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
  • Write the lifecycle down per authenticator type actually in use: how a new hire gets a security key, what happens when one is lost at an airport, who revokes what on departure day.
  • Verify identity at issuance and enrollment — an MFA enrollment link mailed to an unverified address re-creates the phishing problem MFA was bought to end.
  • Hunt default credentials on network gear, appliances, and OT devices; the change-defaults-at-first-use element is aimed straight at them.
  • Time-based refresh mostly bites on certificates and secrets; automate renewal where the platform allows so expiry is not an outage.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Documented authenticator-lifecycle procedures per type
  • Issuance and revocation records tied to joiner and leaver events
  • A dated default-credential sweep of infrastructure and appliances

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 came from in Rev. 2

No direct Rev. 2 counterpart — this requirement is new in Rev. 3. Open the transition crosswalk →

Provenance

Sources and review status

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