03.05.07 Password management: requirements and evidence

What 03.05.07 password management asks for and why it stalls audits

Where a system relies on passwords, 03.05.07 asks the organization to control how those passwords are chosen, stored, sent and recovered. In practice that means keeping a list of commonly used, expected or compromised passwords, checking new passwords against it, protecting passwords in transit and at rest, forcing a new password on first use after account recovery, and enforcing defined composition and complexity rules. The requirement also expects the list to be refreshed on a defined schedule. The risk it addresses is simple: guessable, reused or stolen passwords let an attacker sign in as a legitimate user without breaking any control. Rev. 3 folded the Rev. 2 requirement 3.5.10 (cryptographic protection of stored and transmitted passwords) into this requirement, so an assessor will look for both the policy and the technical settings behind it.

The two organization-defined parameters (ODPs) are where most audits stall. NIST does not assign their values, so the organization must set the update frequency for the screening list and the composition and complexity rules itself. If the System Security Plan says only that passwords must be strong, an assessor has nothing to test against, and the ODPs read as undefined. Confirm with your contracting officer or assessor whether a federal agency has specified any values for your contract, since that changes who sets them. Then write the chosen values into the password policy and the system security plan, and make sure the authenticator configuration in your identity provider matches them exactly.

Assessors typically examine the password policy, procedures for authenticator management and configuration settings, then interview the people who manage authenticators and system developers. The test method usually targets the mechanism itself. Prepare evidence that shows the screening list has been updated on the schedule you defined, that a sample of attempted weak passwords is rejected, that stored passwords are hashed rather than reversible, and that a password reset forces a change at first use. An illustrative gap: a team enforces length rules in the directory but has never recorded a list update date, leaving the screening step without evidence even though the control works.

Which systems, accounts and teams fall under password management in scope

Password management under 03.05.07 reaches further than the CUI enclave itself. The scoping choices below decide which password-accepting and password-storing components the assessor will examine, which outside services need to be covered, and which teams must sign off on the policy and the recovery process. Settle them before writing the system security plan, because each one changes the evidence you need to collect.

CUI systems that accept passwords

Every workstation, server, database and application inside the CUI boundary that accepts a password is in scope for the list screening, composition rules and protected storage that 03.05.07 requires. Inventory each one and record whether it uses a password at all, because a system that relies only on certificates or hardware tokens changes which configuration settings the assessor will examine. Check that the composition rules and the screening step are enforced by the system, not only written in the policy.

Identity providers and directories

A central identity provider or directory that stores password hashes usually concentrates most of the 03.05.07 evidence in one place. If applications delegate sign-in to it, the screening and storage controls may live there rather than in each application. Confirm which system performs the check against the list of common, expected or compromised passwords, and whether the applications behind it still keep local accounts that bypass it.

Administrative consoles and privileged accounts

Admin consoles, hypervisors, network devices and break-glass accounts often have their own local password stores, and they are the accounts an assessor will ask about first. Decide whether these use the same screening and composition rules as user accounts or a stricter set, and document the exception if they differ. Privileged passwords that are shared or checked out from a vault need their own recovery path.

Service accounts and embedded credentials

Service accounts, scheduled jobs and application-to-database logins are often exempt from human password rules in practice, yet they still hold passwords that must be stored in protected form. Inventory them, decide which move to a secrets manager that issues short-lived credentials, and list the rest with an owner and a rotation method. Credentials hard-coded in source repositories are a separate exposure, so include repository scanning in the scope.

Third-party services that hold CUI credentials

Any outside service that stores user passwords, handles sign-in for CUI applications or administers CUI systems falls within the reach of the contract and the assessment. Ask each provider how it screens new passwords, how it protects stored credentials and how it handles account recovery, and record the answers. Where a provider cannot show these controls, the gap belongs in the plan of action and milestones rather than being left unrecorded.

Teams that own policy, configuration and recovery

Three teams usually share 03.05.07: security or compliance owns the password policy and the update frequency for the screened list, platform or IT operations owns the configuration, and help desk or identity administration owns account recovery and the reset that must follow it. Name one accountable owner for each in the system security plan. Gaps appear when the help desk resets passwords through a path that skips the screening step.

What changed when Rev. 3 folded 3.5.10 into 03.05.07

Rev. 2 split password topics across two requirements. Requirement 3.5.7 covered the password rules themselves, while 3.5.10 covered storing and transmitting passwords in cryptographically protected form. Rev. 3 withdrew 03.05.10 and incorporated it into 03.05.07, so the single Rev. 3 requirement now carries both the screening, recovery and composition rules and the protection of passwords in transit and storage. NIST's Rev. 2 to Rev. 3 change analysis classifies the 3.5.7 to 03.05.07 change as significant, with more detail and foundational tasks. Read the change analysis directly before you build a crosswalk, because the analysis is the authoritative record of which Rev. 2 language moved where.

Rev. 2 assessments still score the two requirements separately. Organizations assessed under CMMC Level 2 are measured against Rev. 2, so IA.L2-3.5.7 and IA.L2-3.5.10 are scored as distinct items under the 32 CFR 170.24 methodology. Confirm with your contracting officer which version governs your contract before you plan any work, because the DoD guidance on which revision applies has changed during 2026. An organization that folds its evidence into one Rev. 3 record may still need to show the Rev. 2 pair separately, so keep the storage and transmission evidence tagged to both identifiers.

Map evidence to the wording, not the number. The storage and transmission controls that once sat under 3.5.10 now appear inside the 03.05.07 assessment objectives, so an examiner will look for them alongside the screening list, the list update frequency and the composition rules. Document where the list update frequency and composition rules are set as organization-defined parameters, since Rev. 3 requires those values to be defined. A password policy that covers only composition rules will leave the protection of stored and transmitted passwords without evidence under either version.

How an assessor tests 03.05.07 with examine, interview and test methods

This table maps each SP 800-171A Rev. 3 assessment method for 03.05.07 to what the assessor looks at, what they ask, the evidence they expect and where organizations usually fall short. Read it as a checklist of what to prepare before an assessment, since the same password control is judged from paper, from people and from the running system.

Method	What the assessor examines or asks	Evidence requested	Common findings
Examine: policy and procedures	Whether identification and authentication policy and procedures cover password handling, and whether they are current and approved	Approved identification and authentication policy, password procedures, review history and version dates	Policy exists but never names the list of compromised passwords or the update frequency
Examine: password policy	Whether the password policy sets composition and complexity rules and states how new passwords are screened	Password policy document, the defined composition rules and the screening list reference	Composition rules are described in general terms with no organization-defined values
Examine: authenticator management procedures	How new passwords are checked against the list, how account recovery triggers a new password and how the list is refreshed	Written procedures, recovery workflow documentation, list update records	Recovery procedure resets accounts but does not require a new password on first use
Examine: system design documentation	How passwords move between components and where they are stored, including protection in transit and storage	Architecture diagrams, data flow diagrams, authentication design notes	Design shows passwords sent over channels or stored in forms that are not cryptographically protected
Examine: system configuration settings	Configured values for password length, composition, screening and storage on in-scope systems	Configuration exports, directory policy settings, screenshots dated to the assessment period	Settings in the directory differ from the written policy, or applications keep local password rules
Interview: authenticator management staff	How they add, change and reset passwords, and how they keep the compromised-password list current	Named roles, interview notes, examples of recent resets and list updates	Staff describe a process the documents do not show
Interview: information security staff	How the organization sets and reviews the ODP values and monitors compliance with the password rules	Governance records, review minutes, exception approvals	Staff cannot say who assigned the frequency or composition values
Interview: system developers	How password handling is built into applications, including hashing, transport and screening hooks	Code review notes, developer guidance, secure coding standards for authentication	Custom applications store or log passwords in plain form or skip screening
Test: password-based authenticator management mechanisms	Whether the system rejects a password on the list, enforces composition rules, forces a change after recovery and protects stored and transmitted passwords	Test scripts, test results, screenshots or logs from attempted weak passwords and recovery steps	Screening runs only at initial setup and not on later password changes

The order to implement password management controls

This sequence turns 03.05.07 from a policy statement into a working password control: two documented parameters, a maintained screening list, enforced screening at every password set or change, verified protection in transit and storage, a defined reset path after recovery, and records an assessor can examine and test.

Define and approve the two organization-defined parameters
Start by setting the two ODP values that 03.05.07 leaves to the organization: how often the screening list is updated, and the composition and complexity rules for passwords. Because NIST does not assign these values, and a federal contracting agency may or may not specify them, the organization must decide them and record the decision in its password policy. The output is an approved parameter record signed by the system owner or security lead, with the rationale for each value. Confirm with the contracting agency whether it has published any values that override your own.
Select and maintain the screening list
Choose the sources for the list of commonly used, expected or compromised passwords, and assign an owner for keeping it current. The list should cover common passwords, context-specific terms such as the organization name and product names, and known compromised credentials, as the requirement's wording describes. Set up a documented update process that follows the frequency chosen in step one. The output is a versioned list, an update log showing each refresh, and a named owner who can show when the list was last updated.
Configure screening at password creation and change
Configure each password-based system so that every new password and every changed password is checked against the screening list before it is accepted. Apply the composition rules from step one in the same place, so the user receives one clear rejection reason. Systems that cannot run the check natively may need a directory, identity provider or gateway to enforce it, so confirm this per system during design. The output is a configuration baseline per system showing the screening and composition settings, with the setting names and values recorded.
Verify protected transit and storage on each system
Review how each system transmits passwords and stores them. Passwords should move only over cryptographically protected channels and be kept in cryptographically protected form, which means no plaintext in logs, configuration files, scripts or tickets. Check each application, directory, API and integration, including service accounts that carry embedded credentials. The output is a per-system verification record listing the protocol or channel used, the storage method and any exceptions with a remediation owner.
Define the password reset after account recovery
Document the account recovery workflows, such as help desk resets, self-service recovery and emergency access, and require that the first use after any recovery forces a new password. Configure each workflow so the recovery credential cannot be reused as the new password and the user must set a new one before accessing the system. Test each recovery path to confirm the forced change happens. The output is a recovery procedure and a configuration setting or workflow screenshot for each path, which the assessor can compare against the requirement.
Collect configuration and test records for assessment
Gather the evidence an assessor will examine and test: the approved parameter record, the password policy, screening list versions and update logs, configuration baselines, transit and storage verifications, and recovery test results. Run a test pass that attempts to set a listed password, a password that fails composition, and a recovery-then-login without a forced change, and record the results. Interview the people who own authenticator management so their answers match the documents. The output is a test log and an evidence index that maps each record to the determination statements in SP 800-171A Rev. 3.

Which self-hosted open-source tools can support password evidence

No open-source tool makes a system meet 03.05.07 on its own. The tools below can produce some of the evidence an assessor examines or tests, such as where passwords are handled, how secrets are stored, and whether credentials leak into code. Each one covers a different part of the requirement, and the gaps listed on each card still need controls, procedures or other tools.

authentik for centralized sign-in

authentik is an identity provider under the MIT license. Applications delegate sign-in to it through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so password policy and login handling can sit in one place. This can support evidence that password-based authentication runs through a defined configuration. It does not screen user-chosen passwords against a compromised list on its own, so confirm in your own environment whether and how it can enforce that check, and which applications still hold local passwords.

FreeIPA for Linux and UNIX sign-in

FreeIPA is licensed under GPL-3.0-or-later. It provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, which centralizes the password store for those hosts. For 03.05.07 this can produce evidence of where hosts validate passwords and how accounts are managed. Confirm the password policy settings you need (composition rules, expiry, history and any list-based screening) against the FreeIPA version you deploy, since these are not guaranteed by the product name alone.

OpenBao for stored secrets

OpenBao is licensed under MPL-2.0. It stores secrets encrypted in one place, generates dynamic short-lived credentials for systems such as databases, and attaches leases that revoke secrets automatically on expiry. Those features can support evidence that stored credentials are protected and rotated, which matches the storage and recovery expectations in 03.05.07. It does not manage end-user passwords or check them against compromised lists, and you should confirm how it fits your key management and backup design.

GitLab secret detection for committed credentials

GitLab Community Edition is licensed under MIT. Its pipeline secret detection scans files committed and pushed to the repository in a CI/CD job and writes detected secrets to a gl-secret-detection-report.json job artifact, in every tier. This can produce evidence that the organization looks for passwords and tokens left in code and configuration. It scans only what enters the repository through the pipeline, so it does not cover secrets in chat, tickets, images or production hosts, and you should confirm its coverage and triage process for your repositories.

Which evidence passes 03.05.07 and how to keep it current between audits

What written password policy evidence does 03.05.07 need?

The approved password policy is the core artifact, and it must state the two organization-defined parameters: how often the list of commonly used, expected or compromised passwords is updated, and the composition and complexity rules new passwords must meet. An assessor will examine it against the determination statements and check that both ODP values are actually defined, not left blank or implied. The security or identity lead owns the policy, and the approver should sign it. Review it at least once a year and after any change to the authentication platform, because an outdated policy that disagrees with system settings is a common finding.

How should the screening list and its update records be kept?

The screening list shows which passwords are rejected, and the update records show it is maintained at the frequency the policy sets. Keep the source of the list, the version or date of each import, and the person who approved the change, so an assessor can trace the list back to the policy. Store the records in a change log or ticketing system rather than in someone's inbox. The identity team owns the list and the update job, and the frequency should match the ODP value you defined. Test that the most recent update is in effect, because a list that was downloaded once and never refreshed fails the requirement in practice.

Which configuration exports prove that screening and composition rules are enforced?

Configuration exports show that the rules in the policy are enforced by the systems, not just written down. Export the password policy settings from each identity provider, directory and application that accepts passwords, and capture the screening feature state and the composition rules. Keep the exports dated and stored under configuration management, with a hash or version reference where possible. The platform engineering team owns the exports and should rerun them after every upgrade or identity configuration change. Also capture a sample of rejected passwords in a test account, which shows enforcement working end to end.

What evidence shows passwords are protected in transit and in storage?

Evidence should show that passwords only cross networks over encrypted channels and are stored in a protected form. Collect TLS configuration for login endpoints, network diagrams showing where authentication traffic flows, and storage settings showing how password hashes are kept. Include the cryptographic algorithms and key management references the system uses, and confirm they match the encryption requirements elsewhere in your system security plan. The infrastructure and security teams share ownership. Scan login endpoints periodically and keep the results, because a configuration that drifts after a certificate or library change is a frequent gap.

What account recovery procedure and reset logs show the new-password requirement?

The account recovery procedure must show that a new password is required on first use after recovery, and the reset logs show it happens. Document each recovery path, such as help desk reset, self-service reset and administrator unlock, and state that the user must set a new password before further access. Export reset events from the identity system, with timestamps, the account identifier, the actor and the forced-change result. The help desk lead owns the procedure and the service desk or identity team owns the logs. Sample a set of recent resets each quarter and confirm the forced change appears in the log.

How do examine and test method results fit into the evidence pack?

Examine and test results show the assessor how the controls behave, and they should be captured as dated records tied to specific determination statements. The examine method covers policy, procedures and configuration. The interview method covers the people who manage authenticators and system developers. The test method covers the password mechanisms themselves, so run a documented test that tries a listed password, a short password and a password that fails composition, and record the outcome. Keep the test scripts and results in your compliance repository, assign the security engineer to repeat them after material changes, and schedule a full repeat before each assessment cycle.

Can an internal team keep this evidence current without outside help?

Yes, many organizations maintain this evidence in-house, and the work is mostly recurring records rather than one-time building. The main recurring tasks are refreshing the screening list on the defined schedule, rerunning configuration exports after changes, sampling recovery logs and repeating the test method after upgrades. The cost is staff time and tooling, and a quote from an outside partner should separate one-time setup from these recurring tasks. Confirm with your assessor which artifacts and dates they will accept before you invest, because the assessor and the contracting agency set the evidence expectations, not the implementation partner.

What meeting 03.05.07 costs in money and effort

This table breaks down the cost components of meeting 03.05.07 Password management, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote and to compare what you would pay a partner against what you would carry in-house. No open-source platform removes the integration and evidence work, so the table focuses on where that effort actually sits.

Cost component	One-time or recurring	What drives it and how to reduce it
Tooling and licenses	Recurring where commercial	Self-hosted open-source identity and secrets tools such as authentik, FreeIPA and OpenBao remove most license spend, but not integration effort. Ask the partner to name any remaining commercial components, such as hosting or support subscriptions.
Engineering time for configuration	One-time, with later changes	Effort depends on how many applications and password-based services must enforce the screening list, storage protection and reset rules. Reduce it by centralizing sign-in in one identity provider rather than configuring each application separately.
Organization-defined parameters	One-time, revisited on review	Setting the list update frequency and composition rules requires policy decisions by the organization and, where a federal agency specifies them, agreement with that agency. Agree these values before engineering begins to avoid rework.
Testing against the assessment procedure	One-time, repeated after changes	Test effort covers proving that new passwords are screened, stored in protected form and reset after recovery. Reduce it by scripting repeatable checks and keeping the test method results with each release.
Evidence upkeep	Recurring	Assessors look for the password policy, procedures, configuration settings and the record of list updates. Keeping these current after each change, and logging each list refresh, drives ongoing effort. Automate exports where the platform allows it.
Secret scanning and code review	Recurring	Tools that detect hard-coded passwords in repositories, such as the pipeline secret detection in GitLab Community Edition, reduce manual review but produce findings that someone must triage and close. Ask who owns triage and how fast findings are resolved.
External review or testing	Recurring or per engagement	An independent reviewer of password handling is not required by the requirement itself, but many organizations buy one before an assessment. Ask for scope, deliverables and whether retesting is included.
Assessor time during the assessment	Per assessment	Assessor effort rises with the number of systems in scope, the number of interviews and how well evidence is organized. Ask your assessor for their sampling approach and prepare a single evidence index for 03.05.07 before they arrive.

What your team, an implementation partner and the auditor each own

Your organization owns the requirement. Under 03.05.07 it is your job to decide the organization-defined parameters, approve the password policy, and make the account recovery decisions that determine when a new password is required. Those decisions have to be written down, approved by someone accountable, and carried out by people who can answer questions during an assessment.

ODP values: Set the update frequency for the list of common, expected or compromised passwords, and set the composition and complexity rules. Record the values and the reasoning behind them.
Policy approval: Get the identification and authentication policy and the password procedures signed off by the accountable owner, and keep dated versions.
Account recovery decisions: Decide how recovery works for each system, who can trigger it, and confirm that a new password is required on first use afterward.
Operations: Run the list refresh and screening on schedule, and keep the records of each run.
Interviews: Make sure people with authenticator management and security responsibilities can explain the process.

Before engaging anyone, confirm that your team has the ODP values in writing, because an implementation partner can configure only what you have decided.

How much effort, time and internal input does password management take?

Can we implement 03.05.07 password management without outside help?

Yes, an organization can implement 03.05.07 with its own staff, and nothing in the requirement requires an outside firm. The work is mostly policy and configuration: keeping a list of commonly used, expected or compromised passwords, screening new passwords against it, protecting passwords in transit and storage, forcing a new password after account recovery, and setting composition rules. Many teams do part of this in-house and bring in a partner for the parts they lack time or experience to finish. Whatever the split, the organization owns the control, and an independent assessor is still needed for any formal assessment.

What drives the effort for password management up or down?

Effort depends mainly on how many systems take passwords and how many of them already have central identity. The main drivers are:

The number of applications, directories and services that accept local passwords instead of delegating sign-in.
Whether a password screening list already exists and how it is refreshed.
How many systems store or transmit passwords in ways that need review.
How well the two organization-defined parameters, list update frequency and composition rules, are already written down.

A single identity source with clear policy usually shortens the work considerably. Ask any provider to show which systems fall in scope before estimating.

What do our identity and security staff need to contribute?

Your identity and security staff own the decisions and the evidence. They need to confirm which systems accept passwords, document the password policy, and explain how authenticators are managed from issue to recovery. Interviews are part of the assessment, so the people who run authentication, along with the staff responsible for information security and the system developers, should be able to describe their work accurately. Expect the internal input to be recurring as well as one-time, because the screening list must be updated at the frequency you define and the policy must stay current.

Who sets the ODP values when the federal agency does not specify them?

If a federal agency does not specify the organization-defined parameters, the nonfederal organization must assign them to complete the requirement. For 03.05.07 those are the update frequency for the list of commonly used, expected or compromised passwords, and the password composition and complexity rules. Set the values in writing, approve them through your governance process, and record the rationale so an assessor can see that both ODPs are defined. Ask the contracting agency first whether it has published values, because the federal rulemaking now in progress may tie these to values published by the DoW CIO.

Can a partner issue a compliance certificate for password management?

No. A partner can prepare systems, policies and evidence for 03.05.07, but only an independent auditor, assessor or certification body can issue a report or certificate. For NIST SP 800-171 work tied to DoD contracts, the assessment process and the score recorded in the SPRS system are handled through the assessment bodies and procedures your contract names. Before signing, confirm in writing exactly which deliverables the partner produces and which the assessor will examine, interview and test.

How should we compare password management quotes?

Compare quotes on written scope, not on headline totals. A usable quote should list the in-scope systems, the policy and configuration work, the evidence to be delivered, the testing included, and the handover items. Ask which costs are one-time, such as the initial configuration and policy drafting, and which recur, such as list refresh, staff time and periodic review. Ask for the assumptions behind the effort and for the ODP values the provider will use. DeployOpen works from a written scope and does not publish a price list, so any quote should trace back to the scope agreed in writing before work starts.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, including the identity, secrets and password controls that 03.05.07 depends on. The organization owns its controls and assessment outcome, and DeployOpen prepares the systems and evidence for an independent assessment.

How we scope

We record which systems accept passwords and which identity sources they authenticate against in the written scope.
We agree who owns the password screening list, its update frequency and the composition rules before work starts.
We confirm the organization-defined parameter values with the contracting agency or the organization's own policy owner, since they are not set by NIST.

How we build

We configure the identity provider, such as authentik or FreeIPA, so applications delegate sign-in rather than storing their own passwords.
We set up secrets storage with OpenBao so service credentials are not kept in configuration files or repositories.
We enable secret detection in GitLab pipelines to flag passwords committed to code, and we keep the resulting report artifacts.

How we hand over

We document the screening list process, transmission and storage protections, and account recovery steps in a form an assessor can examine.
We map each determination statement for 03.05.07 to the configuration, policy or report that shows it, with the owner named.
We deliver the runbook and configuration records, and the organization decides what is submitted to any assessor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work is complete.
We can rerun configuration checks and secret detection after changes, so the evidence stays current between assessments.
Before any engagement starts, ask us to confirm in writing which tasks are included and which remain with your internal team.

03.05.07 Password management