03.05.12 Authenticator management: requirements and evidence

What NIST SP 800-171 03.05.12 authenticator management asks for

03.05.12 requires a documented, controlled lifecycle for every authenticator, from the moment it is issued to the moment it is revoked. An authenticator is anything a user, device or service presents to prove identity: a password, a token, a certificate, a cryptographic key or a one-time code. The requirement asks the organization to control six things: verify the identity of whoever receives an authenticator at initial distribution; establish the initial content of each authenticator; define procedures for lost, compromised or damaged authenticators and for revocation; change default authenticators at first use; change or refresh authenticators at a defined frequency or after defined events; and protect authenticator content from unauthorized disclosure and modification. The risk behind it is simple. A strong login method does little if the credential was handed to the wrong person, shipped with a factory default, left unchanged for years, or stored where an attacker can read or alter it.

This requirement is new in Rev. 3. NIST's change analysis lists 03.05.12 among the 19 requirements added in that revision, and maps no Rev. 2 requirement to it. Rev. 2 covered parts of this ground through its identification and authentication requirements, but it had no single requirement that asked for the whole lifecycle. The practical result is that CMMC Level 2, which assesses the 110 Rev. 2 requirements, has no matching requirement ID for 03.05.12. Organizations that must meet both Rev. 3 and a Rev. 2 based assessment should not assume a Rev. 2 control set answers this requirement. Confirm with the contracting officer which revision applies to the contract before you map your evidence.

Which systems, accounts and third parties fall under authenticator management

Authenticator management applies to every credential that proves identity inside the CUI system, not only to user passwords. The decisions below determine which authenticators, teams and external providers must be inventoried, controlled and evidenced before an assessor can test 03.05.12.

Passwords and user credentials

Human passwords, PINs and recovery secrets are the authenticators most assessors ask about first. Confirm which directories, applications and local accounts still accept passwords, and who can reset them. Record how initial passwords are issued, how identity is checked before a user receives one, and how lost-credential requests are handled. Passwords that cross a boundary also fall under transmission and storage protection in 03.13.08.

MFA tokens and hardware authenticators

Hardware keys, authenticator apps, smart cards and one-time code devices are issued to individuals and must be tracked from distribution to revocation. Identify the team that enrolls them, the process for replacing a lost token, and how a departing employee's token is retired. Check whether any token is shared or sits in a drawer as a spare, since those are common findings.

API keys, service accounts and machine credentials

Non-human authenticators, such as API keys, service account passwords and CI/CD tokens, often sit outside the identity team's view. Inventory where each one is stored, which owner rotates it, and what event triggers replacement, such as a staff change or a suspected leak. Because the Rev. 3 ODPs for this requirement require the organization to define refresh frequency and trigger events, these credentials need the same defined schedule as human ones.

Certificates and cryptographic keys

TLS certificates, code-signing keys and private keys used for device or service authentication are authenticators too. Assign ownership to the team that deploys them, record expiry dates, and confirm that revocation is possible and tested. Coordinate with the key management controls in 03.13 so that key storage, rotation and destruction follow one documented procedure rather than two.

Account management, access and least privilege owners

The Rev. 3 discussion of 03.05.12 refers to 03.01.01 account management, 03.01.02 access enforcement and 03.01.05 least privilege, so the people who approve accounts and privileges are in scope. Their records should show which authenticators belong to each account and who may hold privileged credentials. An authenticator issued to an account that no longer has a documented need is a finding even if the password itself is strong.

External identity providers and managed secret services

Cloud identity services, managed secret stores and outsourced help desks may hold or reset authenticators on the organization's behalf. Obtain their contracts or documentation, confirm how they verify identity at distribution, and confirm who is accountable for lost-credential procedures. The organization remains responsible for the requirement, so the reader should ask each provider for evidence it can give an assessor, and confirm the rules of behavior in 03.15.03 apply to their staff.

How an assessor tests authenticator management under SP 800-171A

This table compares the three assessment methods SP 800-171A Rev. 3 uses for 03.05.12, the evidence each one asks for and the gaps assessors most often report. Read it as a preparation checklist: each row names what the assessor will look at, who they will ask, and where the organization's own records usually fall short.

Assessment method	What the assessor does	Evidence to have ready	Common findings
Examine: policy and procedures	Reads the identification and authentication policy and the authenticator management procedures and checks they cover distribution, lost or compromised authenticators, defaults, refresh and revocation	Approved policy with an owner and review date, and procedures that name the roles performing each step	Procedures exist but do not cover lost, compromised or damaged authenticators, or do not say who revokes them
Examine: system configuration settings	Checks configured settings for default authenticators, lifetimes, forced change at first use and protection of stored authenticator content	Exported configuration of the identity provider, secrets manager and directory, with change history	Vendor default credentials still active, or refresh settings that differ from the organization's stated ODP values
Examine: list of authenticator types and system design documentation	Compares the list of authenticator types in use (passwords, tokens, keys, certificates, service secrets) against the design and the procedures	Current inventory of authenticator types by system, and architecture diagrams showing where each is issued and stored	Service accounts, API keys or CI secrets missing from the inventory, so no procedure applies to them
Interview: personnel who manage authenticators	Asks how identity is verified before a credential is issued, how it is reset and how a lost token is handled	Ticket samples or runbook steps showing identity checks, and records of recent resets and revocations	Staff describe an informal process that differs from the written procedure
Interview: information security and system administrators	Asks how refresh frequency and event triggers are applied in practice and who receives alerts on compromise	Evidence of how the defined frequency and trigger events are tracked, such as scheduled jobs or review records	Administrators cannot name the trigger events, so the organization-defined parameters appear unset in practice
Test: mechanisms that implement the capability	Observes or runs the mechanisms that enforce issue, rotation, expiry and revocation, such as a secrets manager or identity provider	Test records showing a revoked credential is refused, an expired credential stops working and a default credential is changed at first use	Revocation is documented but not verified, or expiry is set in one system and not in the systems that consume the secret
Determination: organization-defined parameters	Checks that the frequency and the trigger events are defined and written down, using the two ODP determination statements	A written statement of the chosen refresh frequency and the events that trigger a change, approved by the responsible owner	Frequency stated as 'as needed', which assessors treat as not defined
Scope check: where authenticators live	Traces authenticators through the system boundary, including cloud, CI/CD and third-party services that hold CUI access	Boundary diagram and a list of external services that issue or store authenticators for the system	Secrets stored in source repositories or pipeline variables outside the assessed boundary

How to build an authenticator management capability in order

This sequence takes an organization from undefined credential handling to a documented, enforced and evidenced authenticator management capability for 03.05.12. Each step produces an artifact an assessor can examine, interview against and test.

Define authenticator types and owners
Start by listing every authenticator type in the system: passwords, one-time passwords, hardware and software tokens, certificates, API keys, service account secrets and cryptographic keys. For each type, name the accountable owner, the team that issues it and the systems that depend on it. Work from system configuration and design documentation so the list matches what actually exists. The output is a signed authenticator type register that assessors can compare against the system authenticator types they examine under 03.05.12.
Write distribution, loss and revocation procedures
Document the procedures that cover identity verification at initial distribution, initial authenticator content, how authenticators are delivered, what users and administrators do when an authenticator is lost, damaged or compromised, and how revocation is carried out. Name the roles responsible for each step and have the policy owner approve the document. Interview personnel with authenticator management duties afterward to confirm they can describe the steps the same way. The output is an approved authenticator management procedure, cross-referenced to the identification and authentication policy.
Set and record the two ODP values
03.05.12 has two organization-defined parameters: how often authenticators are changed or refreshed, and which events trigger a change or refresh. NIST does not assign these values, so the organization must set them unless a federal customer specifies them. Choose values that fit each authenticator type, document the reasoning, and confirm with the contracting agency whether it has published its own values. The output is a recorded parameter table with approval date and owner, referenced by the procedure from step two.
Inventory secrets and move them to protected storage
Find where authenticators currently live, including configuration files, scripts, CI/CD variables, shared spreadsheets and developer workstations. Record each secret's type, owner, location and consumers in an inventory. Then move secrets into a protected store with encryption and access control. Open-source options such as OpenBao store secrets encrypted in one place and can issue short-lived dynamic credentials for systems such as databases. Confirm with your own environment which integrations are supported before choosing a store. The output is a secrets inventory with a remediation status for every item not yet in protected storage.
Scan repositories and pipelines for exposed secrets
Before and after migration, scan source repositories and build pipelines for secrets committed in plain text. GitLab Community Edition's pipeline secret detection runs as a CI/CD job, scans files committed and pushed to the repository, and writes results to a gl-secret-detection-report.json artifact in every tier. Triage each finding, rotate any exposed credential, and remove it from the code. The output is a scan history with findings closed and rotation records that show when each exposed secret was replaced.
Enforce default changes at first use
Identify every default or vendor-supplied authenticator, including factory passwords on appliances, database accounts and administrative consoles. Configure each system so the default must be changed the first time it is used, and block the default from working after that point. Test each system by attempting first use with the default value. Record the test result per system. The output is a configuration baseline showing the enforcement setting for each default authenticator, with test evidence attached.
Automate refresh and revocation where the platform allows
Use the parameter values from step three to schedule refresh of authenticators that support it. Where a platform issues short-lived credentials, set lease or expiry periods so revocation happens automatically. OpenBao attaches leases that revoke secrets on expiry and can revoke individual secrets or whole credential trees. Central identity services such as authentik or FreeIPA can reduce the number of local authenticators that need managing. Confirm each capability in your own environment before relying on it. The output is an automation configuration and a revocation test showing a credential stops working when it should.
Set up the evidence trail and review cycle
Assemble the evidence an assessor will request: the approved procedure, the parameter record, the authenticator inventory, configuration baselines, scan reports, rotation and revocation logs, and interview notes from people with authenticator responsibilities. Store each artifact with a version and an owner, and schedule a review that checks the inventory against the live environment. The output is an evidence index mapped to the determination statements in SP 800-171A Rev. 3 for 03.05.12, with the next review date recorded. Independent assessors, not the implementation team, decide whether the evidence meets the requirement.

Which evidence passes an authenticator management assessment

An assessor testing 03.05.12 examines written policy and procedures, interviews the people who issue and revoke authenticators, and tests the mechanisms that enforce the rules. The cards below map to those objects, and each one needs a dated review or an exported log so it stays accurate between assessments.

Identification and authentication policy and procedures

This is the written policy that sets who may receive authenticators, how identity is checked at distribution, and how often authenticators change. Assign an owner, record the approval date, and review it on a fixed schedule, such as annually and after any change to the identity provider or secrets store. Keep the version history so an assessor can see the rules in force on any given date. Check that the document references the defined frequency and triggering events for the two organization-defined parameters, since an assessor will look for them by name.

Authenticator management procedure

This operational procedure covers the steps for distribution, handling lost, compromised or damaged authenticators, and revocation. Write it as a runbook that a help desk analyst can follow, with the identity check at issue, the ticket fields required, and who approves a reissue. Walk through each path once a year and record the walkthrough, so the document reflects what staff actually do. Interviews with personnel responsible for authenticator management usually test whether this procedure is known and followed.

Authenticator type inventory

Maintain a current list of every authenticator type in use, such as passwords, hardware tokens, certificates, API keys, service account secrets and recovery codes. For each type, record the issuing source, the default content, the change or refresh frequency and the revocation method. Reconcile the list against directory exports and secrets store contents at each review date. An unlisted authenticator type is a common finding because it falls outside the defined procedures.

System configuration showing changed defaults and refresh settings

Configuration exports show that default authenticators were changed at first use and that refresh settings match the defined parameters. Export the relevant settings from the identity provider, directory and secrets engine, including lease durations, rotation schedules and forced password changes on first login, and store them with a timestamp. Compare exports across review cycles to detect drift. Retain configuration-as-code in version control where possible so changes carry an author and a commit history.

Revocation and rotation logs

Logs of revoked, rotated and expired authenticators show the procedure running in practice, which is what an assessor tests when interviewing administrators. Export audit events for revocations, lost-token reports and scheduled rotations, and retain them under the organization's audit retention period. Sample a set of events each quarter and confirm each has a matching ticket or approval. Gaps between a reported compromise and the revocation event are the entries an assessor will question first.

Design documentation for the secrets store

Design documentation for the secrets store explains how authenticator content is protected from disclosure and modification, including encryption, access policies, dynamic credential generation and lease-based revocation. Describe the components, trust relationships and where secrets are stored or cached. For OpenBao, record the storage backend, the policies that scope access, and whether dynamic short-lived credentials replace static ones. Update the document whenever the architecture changes, and pair it with pipeline secret detection reports so the design claims can be tested against what is committed to repositories.

What meeting 03.05.12 costs in money and effort

This table breaks down the cost components of meeting 03.05.12 Authenticator management, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to decide which parts to fund internally, which to scope to an implementation partner, and what to request in a written quote. No price or duration is implied; the figures depend on the environment.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Tooling or licenses	Recurring if commercial secrets or identity products are bought. Open-source platforms such as OpenBao, authentik and FreeIPA carry no license fee, but hosting and staff time remain.	Number of authenticator types and whether a commercial product is already licensed. Ask whether the quote includes subscriptions, support tiers and hosting.
Engineering time to build and integrate	One-time for initial build, then recurring for changes. Paid to internal staff or an implementation partner under a fixed-scope agreement.	Number of systems that issue or consume authenticators, and whether an existing identity provider already centralizes sign-in. Systems with hard-coded credentials add the most work.
Procedure writing and ODP decisions	One-time for the first set, recurring at each review. Paid to internal compliance, security and system owners.	Number of organization-defined parameters chosen for refresh frequency and trigger events. Fewer, consistent values across systems reduce rework.
Identity proofing and distribution process	Recurring per issuance, lost or replaced authenticator. Carried by help desk and administrators.	Volume of new users, contractors and device enrollments, and how much proofing is manual. Automated proofing reduces repeat effort.
Manual rotation and refresh	Recurring. Paid as staff time on each scheduled or event-driven change.	Degree of manual rotation. Dynamic, short-lived credentials generated by a vault reduce this work, while static shared passwords increase it.
Evidence upkeep	Recurring. Paid to system owners and compliance staff to keep records of issuance, revocation, rotation logs and procedure versions current.	Logging coverage and where evidence is stored. Centralized logs and exported configuration snapshots make sampling faster.
External testing or review	Periodic, one-time per engagement. Paid to a security testing firm or consultant, separate from the assessor.	Scope of testing and the number of authentication paths. Ask for the testing scope in writing before engaging a firm.
Auditor or assessor sampling	Recurring at each assessment cycle. Paid to the independent assessor, who examines procedures, interviews staff and tests mechanisms.	Number of authenticator types and samples the assessor selects. Clear, current evidence per type shortens the assessment.

Which self-hosted open-source tools support authenticator management

OpenBao is an MPL-2.0 licensed secrets manager that stores secrets encrypted in one place. For 03.05.12 it is most relevant to the protection of authenticator content and to the lifecycle of credentials used by applications and databases. Its dynamic credentials are generated on request and are short-lived, so a system does not depend on a long-lived password that must be rotated by hand. Each dynamic secret carries a lease, and the lease revokes the secret automatically when it expires. Operators can also revoke a single secret or a whole tree of credentials, which supports the revocation step for compromised or departed users.

Encrypted storage: Secrets are kept encrypted in one store, which supports the requirement to protect authenticator content from unauthorized disclosure and modification.
Dynamic short-lived credentials: Systems such as databases receive credentials that expire, which supports defined refresh frequencies.
Lease-based expiry: Leases revoke secrets automatically, producing a record you can point to during assessment.
Single and tree revocation: Operators can revoke one secret or a whole branch, supporting procedures for compromised authenticators.

OpenBao does not verify the identity of the person who receives a credential at distribution, and it does not define your procedures for lost authenticators. Confirm with the OpenBao documentation which secret engines and auth methods you intend to use in your environment, and confirm how your administrators' own access to the store is controlled.

Where authenticator management usually falls short

Most gaps in 03.05.12 are not technical failures. They are missing decisions, undefined parameters and procedures that exist on paper but leave no evidence. The cards below cover the places where assessors most often find the requirement incomplete and what to put in place to close each one.

Organization-defined values never set

03.05.12 has two organization-defined parameters: how often authenticators are changed or refreshed, and which events trigger a change. NIST does not assign these values, so if the federal agency does not specify them, your organization must. Teams often skip this step, which leaves the requirement with no measurable test. Decide the frequency and trigger events in writing, approve them in the system security plan, and confirm that the configured settings match the documented values.

Default credentials left in place

Factory passwords on appliances, databases, network devices and service accounts are a frequent finding. The requirement expects default authenticators to be changed at first use. Build a pre-deployment checklist that lists every component with a default login, records the date each was changed, and uses your configuration baseline to confirm that no vendor default remains. Ask your platform team to show a sample of recently built systems during the assessment.

Secrets hard-coded in code and pipelines

Passwords, API tokens and keys committed to repositories or written into CI/CD variables are hard to revoke and easy to leak. Run secret detection on every push so findings are recorded, not just noticed. GitLab Community Edition's pipeline secret detection writes results to a gl-secret-detection-report.json artifact in each job, which gives you an evidence trail. Pair detection with a secrets manager such as OpenBao so applications fetch credentials at runtime instead of storing them.

No procedure for lost or compromised authenticators

The requirement expects documented procedures for lost, compromised and damaged authenticators, and for revocation. Many organizations have a password reset form but no written path for a stolen hardware token or an exposed API key. Write one procedure per authenticator type, name the person who verifies the requester's identity, and define how access is revoked and reissued. Test it with a tabletop exercise and keep the record, since assessors commonly ask for it during interviews.

Refresh documented but not evidenced

A policy that says keys rotate every defined period means little unless logs or system records show that rotation happened. Assessors look for the configured schedule, the change records and exceptions with approvals. Where short-lived credentials are practical, dynamic secrets with automatic lease expiry remove much of the manual work, and OpenBao can revoke single secrets or whole trees of credentials. Confirm which systems are on manual rotation and collect their change tickets.

Disconnected from account and rules of behavior owners

03.05.12 refers to account management, least privilege, transmission and storage confidentiality, and rules of behavior. When the owners of those requirements do not coordinate, authenticators are issued without matching account approvals, and users are never told how to protect their credentials. Assign one accountable owner for the authenticator lifecycle, hold a joint review with the account management owner, and make sure the rules of behavior cover password sharing and token handling. Identity providers such as authentik or FreeIPA can centralize the lifecycle so the records sit in one place.

Questions buyers ask about 03.05.12 cost, effort and outside help

How much effort does 03.05.12 authenticator management take to implement?

The effort depends mainly on how many authenticator types the system uses and how many of them are issued manually today. A organization with one identity provider and a few service credentials has a much smaller job than one with passwords in spreadsheets, shared administrator accounts, API keys in scripts and hardware tokens issued by hand. The requirement needs five things to be true: identity checks at distribution, documented initial content, procedures for lost or compromised authenticators, default changes at first use, and protected authenticator content. Each one must be written down, applied and provable. Start by inventorying authenticator types, because the inventory sets the scope of every other task. The NIST SP 800-171A Rev. 3 assessment lists the system authenticator types as an examine object, so assessors will ask for the same list.

Can our team implement 03.05.12 in-house?

Many teams can do the policy and procedure work in-house, especially if they already run an identity provider and a secrets store. The harder parts are technical: moving static secrets into a managed store, generating short-lived credentials for systems that support them, and wiring revocation into offboarding. Teams usually need engineering time from identity, platform and security staff at the same time, which is where internal capacity tends to run short. An implementation partner can prepare the systems, configuration and evidence, while the organization keeps ownership of the decisions. Ask whether the partner will deliver the written procedures, configuration records and test results in a form the assessor can examine, and whether internal staff will be trained to operate the result afterward.

What does our organization need to provide for 03.05.12 work?

The work needs named owners, decisions made early, and access to the systems being changed. Expect to name an owner for authenticator policy, an owner for each authenticator type, and a person who can approve the identity-proofing steps used at distribution. Decisions include the change frequency for authenticators, the events that trigger a refresh, such as role change or suspected compromise, and how emergency revocation works. Because 03.05.12 has two organization-defined parameters, these choices must be recorded as values, not left implied. The organization also needs read access to identity systems, administrator access to the systems that will hold secrets, and time from staff who run the applications that use those secrets. Missing any of these usually delays the work more than the technical changes do.

How long does 03.05.12 implementation usually take?

Duration depends on the number of systems and authenticator types, the state of current credential handling, and how quickly decisions are made. No duration is given here because no researched timeline is available for this requirement. Organizations that already keep secrets in a managed store and use short-lived credentials for most systems will finish sooner than those that must first remove shared accounts and hard-coded credentials. The schedule usually depends on change windows for production systems and on how many application teams must update their code. Ask any partner to break the timeline into phases, such as inventory, policy, technical changes, evidence collection and assessor review, and to state which phases depend on decisions or access the organization must supply.

Will the auditor set the ODP values for 03.05.12?

No. An independent assessor evaluates whether the values are defined and applied, but NIST does not assign organization-defined parameter values. If the federal agency with the contract does not specify them, the nonfederal organization must assign them to complete the requirement. For 03.05.12, the two parameters are the frequency for changing or refreshing authenticators and the events that trigger a change. Check the contract, the agency's requirements and any DoD guidance first, because the proposed FAR rule would have ODP values published by the DoW CIO. Once values are chosen, document them in the system security plan and make sure procedures and configuration settings match them. Assessors test whether the stated values are followed in practice.

Does Rev. 2 or CMMC have an equivalent ID for 03.05.12?

No. NIST's change analysis lists 03.05.12 as one of the 19 requirements new in Rev. 3, and NIST maps no Rev. 2 requirement to it. CMMC Level 2 assesses the 110 Rev. 2 requirements, so it has no matching requirement ID for authenticator management in that form. Contracts that still reference Rev. 2 do not require 03.05.12 by number, but the underlying practices overlap with Rev. 2 identification and authentication requirements, which the sibling topics cover. Organizations that plan for Rev. 3 should still implement 03.05.12 now, because a contract or future rule may require it. Confirm the applicable revision with the contracting officer before scoping the work.

What should we ask a partner for in a fixed-scope quote?

Ask for a written scope that lists the systems, authenticator types and applications covered, along with the deliverables for each. A useful quote names the procedures to be written, the configuration changes to be made, the secrets store and identity integrations to be set up, the revocation and refresh tests to be run, and the evidence package to be handed over. It should state what the organization must supply, including owners, decisions on ODP values and access, and it should say what happens if scope changes. Confirm that the partner prepares systems and evidence but does not issue assessment reports or certifications, which only an independent assessor can do. Ask whether ongoing support or periodic testing is offered as a separate retainer, because that cost recurs while the implementation does not.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares the authenticator management capability and its evidence for 03.05.12. Your organization owns the control and the assessment outcome, and an independent assessor or certification body issues any report.

How we scope

Agree in writing which authenticator types, such as passwords, tokens, keys and service credentials, fall inside the 03.05.12 boundary.
Record the organization-defined frequency and refresh events for authenticators, since NIST leaves these values to you to assign.
Inventory where each authenticator is issued, stored and revoked, including the identity checks used at distribution.

How we build

Configure a secrets store such as OpenBao so authenticator content is encrypted and access is controlled per consumer.
Set up dynamic, short-lived credentials with leases so credentials expire or are revoked automatically when an event occurs.
Integrate authentik or FreeIPA so applications delegate sign-in rather than storing their own authenticator copies.

How we hand over

Document distribution, lost or compromised authenticator, default-change and revocation procedures mapped to the 03.05.12 requirement.
Produce test records for revocation and expiry, and retain configuration exports that an assessor can examine.
Deliver a walkthrough so administrators and personnel with authenticator responsibilities can explain the process in interviews.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
Review authenticator settings and scan for committed secrets, such as GitLab pipeline secret detection reports, on a schedule you agree.
Update procedures and evidence when the ODP values, systems or contracting requirements change.