IA.L2-3.5.9 Temporary passwords: requirements and evidence

What IA.L2-3.5.9 temporary passwords requires and why assessors check it

A new account or a password reset almost always starts with a temporary password, and IA.L2-3.5.9 exists to make sure that password never becomes a long-term credential. The requirement allows temporary passwords for system logon only, and only when the user must change to a permanent password immediately at first use. It is the Level 2 counterpart of NIST SP 800-171 Rev. 2 requirement 3.5.9, a derived requirement in the Identification and Authentication family. NIST SP 800-171A (June 2018) assesses it with one objective: an immediate change to a permanent password is required when a temporary password is used for system logon. Assessors look for the password policy, the authenticator management procedures and the password configurations that enforce this behavior, and they test the mechanism itself by attempting a logon with a temporary password.

The risk is predictability. The CMMC Assessment Guide for Level 2 warns that temporary passwords following a consistent style within an organization are easier to guess than passwords users create, and that this practice should be avoided. Generate temporary passwords randomly per account, deliver them through a channel separate from the username, and set an expiry so an unused temporary password cannot sit open indefinitely. Requirements like this are hard in practice for three reasons: provisioning tools that set a default password and never force a change, help desk resets that hand out a temporary password without enforcing rotation at logon, and legacy applications that accept a temporary password and keep it valid. Inventory every path that creates or resets credentials, then test each one. Confirm with your own identity platform and application owners which of these settings they can enforce and what evidence they can export.

For scoring, IA.L2-3.5.9 is worth 1 point under 32 CFR 170.24. Because it is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), it can be placed on a plan of action and milestones for Conditional Level 2 status if the score is at least 88 of 110, with closeout due within 180 days. Treat that as a narrow fallback, not a plan. The Department of War suspended CMMC Phase II on 13 July 2026, but Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place, and the current implementation schedule should be confirmed against the DoW CIO About CMMC page. The suspension changes when certification assessments begin; it does not change what an assessor will test.

Which systems, accounts and teams does IA.L2-3.5.9 cover?

IA.L2-3.5.9 applies wherever a temporary password can be used to log on, so the scope question is less about the number of systems and more about every path that issues a first-time credential. Each card below names one scope area and the decision it forces, so you can map your environment before an assessor does.

Systems that process CUI

Start with the systems inside the CUI boundary, including the workstations, servers, databases and applications that handle controlled unclassified information. Every logon path into that boundary is in scope for 3.5.9, so any account that can be created with a temporary password must be listed. Decide whether the boundary also covers administrative jump hosts and management consoles, since those are often where temporary credentials are issued first. Confirm the list against your system security plan.

Directory services and their authenticators

Decide whether the corporate directory is the single place where temporary passwords are set, or whether each application keeps its own. A directory such as Active Directory or an LDAP service usually governs logon for many systems, so a single setting can satisfy the requirement across them. Check whether the directory forces a change at first logon and whether that setting is applied to every organizational unit that holds CUI users. Document the configuration as the evidence an assessor will request.

Identity providers and federated sign-in

An identity provider such as authentik, FreeIPA or Keycloak may issue the first password for users who then sign in to many applications through it. Decide where the forced change happens, in the identity provider or in the connected directory, and make sure applications do not present their own temporary credentials. Federation can move the requirement away from the application, but the identity provider's configuration then becomes the evidence to show.

Applications that keep local accounts

Some line-of-business applications, network appliances and databases keep local user tables that are not tied to the directory. Each of these needs an inventory entry and a documented first-logon behavior, because a vendor default or a reset email may issue a temporary password that never prompts for change. Ask each vendor whether the temporary credential expires on first use and whether that behavior can be configured. Where it cannot, record the gap before scoring.

Help desk reset and recovery paths

Password resets performed by help desk staff are the most common source of temporary passwords in practice. Decide who may reset an account, how the temporary password is delivered, and whether the user is forced to change it at the next logon. A reset that bypasses the forced change is an assessment failure even if the directory policy is correct. Include self-service reset tools in this scope, since they generate temporary credentials too.

Onboarding, offboarding and third-party accounts

New-hire provisioning workflows, contractor accounts and accounts created by managed service providers all issue initial credentials on the organization's behalf. Decide who owns the provisioning step, whether a provider is bound by the same first-logon rule, and how temporary passwords are communicated without being stored in tickets or chat. Ask each provider for written confirmation of their process, and keep it with your evidence. Provisioning automation such as midPoint can enforce the workflow, but the rule itself must be defined by you.

How an assessor tests the first-use password change

This table pairs each test step an assessor uses for IA.L2-3.5.9 with the evidence to prepare and the gap that most often causes a finding. Read it as a checklist: if your organization can produce each piece of evidence in final form, the single assessment objective is much easier to show as met.

Test approach	Evidence requested	Common finding
Review the password policy and authenticator management procedures	Approved password policy stating that temporary passwords are issued only for logon and must be changed at first use, plus the written procedure for issuing them	Policy says temporary passwords are allowed but is silent on mandatory change, or the procedure is an unapproved draft
Examine password configurations for forced change on temporary credentials	Directory or identity provider settings showing the must-change-at-next-logon flag or equivalent, exported or screenshotted with the date and system name	Setting exists in policy but is not enforced in the directory, or it is enabled for some account types only
Test a temporary credential in a non-production account	Test account record, the log of the first logon, and the screen or log entry showing the forced password change before access is granted	Assessor can log on and reach system resources without changing the password, or the change happens after access
Review how password resets and new accounts are handled	Account provisioning workflow, help desk reset ticket template, and sample of recent resets and new accounts showing the forced change flag	Help desk resets set a fixed or predictable temporary password and do not flag the account for change
Check whether temporary passwords follow a consistent pattern	Password generation method or tool settings showing that each temporary password is unique and random	Temporary passwords share a pattern, such as a site name plus a number, which the CMMC Assessment Guide Level 2 warns is easier to guess
Confirm the configuration applies to every system that accepts logons	Inventory of systems with local or network logon and their authentication source, showing which use the central directory	Standalone applications or network devices keep their own local accounts with no forced change
Interview administrators on the reset and provisioning process	Interview notes and names of staff who perform resets, with their training records	Staff describe a process that differs from the written procedure

How to configure temporary passwords so each one expires at first use

This sequence proves that every temporary credential in the environment forces an immediate change to a permanent password at first logon. Each step produces a record that an assessor can trace from the account creation path to the tested result.

Inventory every credential creation and reset path
List every way an account or password can be created or reset: the identity provider, the corporate directory, Kerberos or LDAP-backed services, application-local accounts, service desk tools, provisioning connectors and any break-glass or vendor accounts. The system administrator and the compliance lead own this inventory, and the output is an account path register that names each source, the person or process that triggers it and whether it can issue a temporary password. The step is done when the register covers every system in the CUI boundary and the owner of each path has signed off on it.
Confirm forced change at first logon per source
For each identity source in the register, check the vendor documentation or the product configuration to confirm that a temporary password forces a change to a permanent password at first use, and record the setting name, its location and its value. Where a platform does not enforce this natively, note the gap and the compensating procedure. Your identity engineer should confirm each setting against the version you run, not against a general guide, because product behavior varies. The output is a configuration baseline for each source that shows the enforced state.
Define how temporary credentials are generated and delivered
Write a procedure for generating temporary passwords that are unique, random and not derived from a pattern the organization uses elsewhere, because the CMMC Assessment Guide Level 2 warns that consistent temporary password styles are easier to guess. Specify how the credential reaches the user, such as an out-of-band channel, a one-time link or in-person handoff, and how it expires if unused. Security management approves the procedure. The output is an approved temporary credential procedure with a named owner and a review record.
Test each path with a fresh account
For every path in the register, create a new test account using the documented procedure, log on with the temporary credential and verify that the system blocks normal use until a permanent password is set. Also confirm that the old temporary credential no longer works after the change. Run the tests in a non-production environment that mirrors the production settings, and repeat them after any change to the identity platform. The output is a dated test record per path that lists the steps taken, the observed result and the tester's name.
Reconcile live accounts against the baseline
Export the account attributes from each source that show whether an account still carries a temporary password flag or has never completed a first change, and compare them with the expected state in the baseline. Investigate any account that remains on a temporary credential beyond first use and any source where the setting differs from the baseline. The output is a reconciliation report with each exception, its cause and its remediation owner. Keep the report because it shows the control operating in production, not only in a test.
Document the configuration and test results
Assemble the account path register, configuration baselines, approved procedure, dated test records and reconciliation report into one evidence package under the system security plan. Make sure each document is in final form, since drafts do not satisfy the assessment objective, and that each one names its owner and date. Ask your assessor, or your readiness provider, which format they prefer for traceability. The output is a versioned evidence package that maps each path to its configuration and test result for IA.L2-3.5.9.
Set a recurring check for new paths
Assign an owner to review the account path register whenever a new identity source, application, connector or onboarding workflow is added, and to rerun the first-logon test for that path before it handles CUI. Confirm with your identity platform vendor whether upgrades change the default behavior of the forced change setting. The output is a change record for each new path, linked to a fresh test record, so the evidence stays current between assessments.

Evidence that proves temporary passwords are changed at first use

An assessor testing IA.L2-3.5.9 needs to see that the rule exists, that the system enforces it, and that it worked in practice. The cards below cover the policy, the configuration, the test results, the provisioning workflow and the logs, which together show the same behavior from four different angles. Each artifact must be in final form and current at the time of assessment.

Password policy and authenticator procedure

The written policy should state that temporary passwords are issued only for system logon and must be changed to a permanent password immediately at first use. The authenticator management procedure should name who issues temporary credentials, how they are delivered, and who verifies the change. Assessors compare the procedure against the system configuration, so any gap between the two will be noticed. Confirm that the approved version carries an owner, an approval date and a review date.

Exported forced-change configuration

Capture the setting that forces a password change at first logon from the identity provider, directory or operating system, and export it as a file or screenshot with the date and system name visible. Check that the setting applies to every account type that receives temporary credentials, including service and administrator accounts where they use passwords. A setting that exists only in a template or a default that a local administrator can override will not satisfy an assessor on its own.

First-logon test records

Run a test account through provisioning, sign in with the temporary password, and record that the system blocks normal access until a new permanent password is set. Keep the timestamps for the issuance, the first logon and the password change, and the test account name and the tester. Repeat the test after any change to the identity platform, because a configuration change can silently remove the requirement. These records show the behavior, which the configuration alone cannot prove.

Provisioning and reset workflow documentation

Document how accounts are created and how passwords are reset, including who can trigger a reset and how the temporary credential reaches the user. If an identity lifecycle tool creates accounts from role assignments, the workflow document should show which step sets the forced-change flag and which step reconciles it. Assessors use this to confirm that no provisioning path bypasses the rule, such as manual account creation or a helpdesk reset.

Logs showing the password change event

Retain authentication and directory logs that record the temporary password use and the subsequent change event for the same account. Confirm that the logs capture the account identifier, the event type and the time, and that they are protected from alteration and kept for the period your audit policy requires. Review a sample of real events during readiness work to confirm the logs contain what you expect. Absence of change events for accounts still using temporary credentials is a finding to investigate.

What meeting IA.L2-3.5.9 costs in money and effort

This table breaks down the cost components of meeting IA.L2-3.5.9, who is paid for each one, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request that separates license spend from configuration and evidence work, which is where most of the effort sits.

Cost component	One-time or recurring	What drives it up and how to keep it down
Policy and procedure writing	One-time, with periodic review	Drives up: separate policy and procedure documents per system, and no owner for review. Keep down: one password and temporary credential standard that every system references, with a named owner and review date.
Configuration of identity sources and applications	One-time per system, recurring when systems change	Drives up: many applications that each handle first logon differently, or local accounts outside the directory. Keep down: route sign-in through one identity provider so the first-logon rule is set once and inherited.
Engineering time for provisioning and reset workflows	One-time build, recurring for new hires and resets	Drives up: manual account creation, emailed passwords, and help desk resets that bypass the forced change. Keep down: automate account creation and temporary credential issue, and make the forced change part of the reset path.
First-logon testing	One-time per system, repeated after upgrades	Drives up: each application, admin console and service account tested separately. Keep down: a short test script that covers every account type and is rerun after each change to the identity configuration.
Evidence upkeep	Recurring	Drives up: screenshots gathered at assessment time, and configuration that changes without a record. Keep down: export settings and test results on a schedule, and keep them in final form with dates and owners.
External testing or review	Optional, periodic	Drives up: broad scope and first-time review of undocumented exceptions. Keep down: agree a written scope that lists the in-scope systems and the account types covered before work starts.
Assessor sampling time	Recurring at each assessment	Drives up: assessors who must trace several systems, accounts and exceptions to find a temporary password path. Keep down: a current list of systems that issue temporary passwords, and records showing the forced change for a sample of accounts.
Open-source identity platform licenses	No license fee for the software itself	Removes license spend on the platform, but configuration, testing and evidence work remain. Confirm the license terms of each component and any paid support you plan to buy.

Which self-hosted identity tools can enforce first-use password changes

Temporary password enforcement usually lives in the identity layer, not in each application. The four tools below play different roles, from the provider that applications sign in through to the tool that moves account changes between systems. Your assessor will look for the forced-change setting in whichever component creates or governs the account, so confirm which component that is in your environment.

authentik as identity provider

authentik (MIT) acts as an identity provider, so applications delegate sign-in to it through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers. For IA.L2-3.5.9, the question is whether a temporary password issued to a user at account creation forces a change before any application session is granted. Test this with a new account from each provider type you use, because a protocol that bypasses the forced-change flow would leave an open path. Confirm the behavior is configured and tested in your own environment.

FreeIPA for Linux and UNIX

FreeIPA (GPL-3.0-or-later) provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Where a temporary password is set by an administrator, the principal's password policy determines whether first logon requires a change before access is granted. Assessors commonly ask for both the policy configuration and a test showing a new account cannot operate on the system with its temporary credential. Confirm the forced-change behavior is configured and tested in your own environment. GPL-3.0-or-later obligations apply if you distribute modified FreeIPA code.

Keycloak with directory federation

Keycloak (Apache-2.0) user federation connects to existing LDAP or Active Directory servers and synchronizes users from them, so the corporate directory remains the account source for application sign-in. The forced-change setting may sit in the directory or in Keycloak, and you must know which one governs the first logon for each user population. Document the chosen authority so the evidence matches the system that actually enforces the change. Confirm the behavior in your own environment. Apache-2.0 requires retaining license and notice text when you redistribute the software.

midPoint for account provisioning

midPoint (EUPL-1.2+) creates, updates and deletes accounts on connected systems based on user changes and role assignments, and keeps them aligned through provisioning, live synchronization, scheduled reconciliation and discovery. Its role in IA.L2-3.5.9 is to create temporary credentials consistently and to show, through its inbound and outbound rules, which system receives the account and under what policy. Reconciliation reports can reveal accounts that were created outside the process and never forced to change. Confirm the forced-change behavior in each target system in your own environment. EUPL-1.2+ obligations apply when you distribute modified midPoint code.

Who owns the control, who prepares the evidence and who issues the finding

The organization owns IA.L2-3.5.9. Its leadership decides how temporary passwords are issued, how long they remain valid, who may receive them and how users are told to change them. These decisions belong in the password policy and the account provisioning procedure, which the organization approves, maintains and enforces. The organization also decides whether any residual risk is accepted and who signs that decision.

Password policy: Defines when a temporary password may be issued, such as new accounts and administrator resets, and states that the first logon requires a permanent password.
Provisioning procedure: Names the teams that create accounts, the steps they follow and the records they keep for each temporary credential.
Temporary credential generation: Decides whether temporary passwords are random per account. The assessment guide warns that a consistent style is easier to guess.
Residual risk acceptance: Records any exception to the policy and the owner who accepts it, in writing.
Assessment readiness: Keeps the final, approved policy and procedure available to the assessor.

Confirm that the policy text, approval record and exception register are in final form, because the assessor will not accept drafts as evidence.

Where organizations fail IA.L2-3.5.9 and how to close each gap

Most failures against IA.L2-3.5.9 come from a gap between the written policy and what the system does on the day an account is created or reset. The cards below cover the places where that gap usually opens, and the check that shows whether it is closed.

Predictable temporary password patterns

When every new account receives a password built from the same template, such as a fixed word plus the year, the temporary credential is easy to guess before the user ever logs in. The CMMC Assessment Guide Level 2 warns against this practice. Generate each temporary password randomly at provisioning, make it unique per account, and confirm with the provisioning owner that no template or default string is hard-coded in scripts or runbooks.

Help desk resets that skip the change

A reset performed by a help desk agent can leave the account in a state where the temporary password is accepted but the forced change at next logon is not enforced, for example when an admin tool sets the password without the must-change flag. Test a reset end to end with a standard user account, confirm the user is prompted for a permanent password at first use, and check that the reset action is logged so an assessor can trace it.

Legacy applications with local accounts

Older applications often keep their own user tables and default password rules, outside the corporate directory. Temporary passwords issued there may never be forced to change, and the central policy will not show it. Inventory every system that stores credentials locally, record how its temporary passwords are issued, and either move sign-in to a central identity provider or document a tested, application-level forced-change setting as evidence.

Provisioning tools without a credential policy

Identity lifecycle tools can create accounts on connected systems faster than a password policy is applied to them. If the outbound rules create an account with a generated password but leave the change-at-first-use attribute unset, every new account inherits the gap. Review each provisioning rule for the credential it sets and whether it sets the first-use change, then test one account per connected system.

Policy documents without behavior evidence

A written policy stating that temporary passwords must be changed at first use does not satisfy the assessment objective on its own. Assessors look for the password configuration and tests of the mechanism, so a document that is not backed by a setting and a test record will not pass. Keep the configuration export, a dated test log showing a temporary login forced into a permanent password, and the reset procedure, all in final form.

Questions buyers ask before bringing in help for temporary passwords

What drives the cost of meeting IA.L2-3.5.9 temporary password requirements?

The cost depends mostly on how many systems issue temporary passwords and how many of them already enforce a forced change at first logon. If a central directory such as Active Directory or LDAP provisions every account, the work is largely configuration and verification. If each application creates its own local accounts, each one needs its own review, which adds effort. Cost components usually include the time of your directory and application administrators, any outside engineering time for configuration, and the evidence you prepare for the assessor. Ask any provider for a quote that lists each system in scope, who performs each change, and which evidence items are delivered. Costs are mostly one-time for setup, with recurring effort for account reviews and new applications added later.

How long does configuring and testing temporary passwords usually take?

Duration depends on the number of account sources and applications, not on the requirement itself, which has a single assessment objective. A single directory with a few integrated applications can often be configured and tested in a short engagement. Environments with many local accounts, legacy applications or separate provisioning tools take longer because each path must be traced and tested. Plan time for three activities: confirming the current provisioning behavior, changing settings, and running a test account through a new provisioning flow and a first sign-in. No fixed duration is set by the standard, so ask for a timeline in the written scope rather than relying on a general estimate.

What does our internal team need to provide for this work?

Your team needs to supply access and decisions, not just time. Directory administrators must confirm how accounts are created and which settings control temporary passwords and forced change at first use. Application owners must confirm whether each application sign-in uses the directory or keeps its own user store, and whether a temporary password is ever shown to a user in a way that outlives first logon. A dedicated test account, provisioned the way real users are, is needed to prove the change happens at first use. Your team should also name who approves the password policy and who keeps the final evidence. Without these inputs, the work stalls at discovery.

Can we meet IA.L2-3.5.9 ourselves without an outside partner?

Yes, an organization can meet this requirement with its own staff, because it is an internal control that you own. The work is narrow: a single objective requires an immediate change to a permanent password when a temporary password is used for logon. The harder parts are usually finding every path that creates an account, and producing evidence in final form that an assessor will accept, such as the password policy, authenticator management procedures and password configurations listed in NIST SP 800-171A. An outside partner can help with discovery, configuration and evidence packaging, but the independent assessor is still the only party who tests and reports on your status. Decide based on how many account paths you have and whether your staff has time to test them.

How does a POA&M apply to IA.L2-3.5.9 under Conditional Level 2 status?

IA.L2-3.5.9 is worth 1 point under the scoring method in 32 CFR 170.24, and it is not on the exclusion list in 32 CFR 170.21, so it can be placed on a plan of action and milestones. Conditional Level 2 status requires a score of at least 88 of 110 (0.8). If you use a POA&M for this requirement, closeout is due within 180 days. Treat the POA&M as a short-term bridge: the item still has to be fixed, and you should not assume it will be accepted without the rule's other conditions being satisfied. Confirm the current conditions with your contracting officer and the eCFR text before relying on this path.

Does the Phase II suspension remove the need to meet IA.L2-3.5.9?

No. The Department of War suspended CMMC Phase II on 13 July 2026, but it said Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The Level 2 requirements still come from NIST SP 800-171 Rev. 2, and the Department said it will enforce Rev. 2 in the interim. Because the Phase II schedule and implementation status are changing, the timing of any certification assessment is uncertain. Meeting IA.L2-3.5.9 now still reduces your exposure under existing contract obligations and prepares your evidence for whatever schedule applies later. Check the current DoW CIO guidance before setting your own deadlines.

How DeployOpen scopes and prepares IA.L2-3.5.9 evidence

DeployOpen works on IA.L2-3.5.9 by configuring the identity systems and provisioning workflows that issue temporary passwords, then documenting the settings an assessor will check. We prepare systems and evidence inside your own environment. Your organization owns the control, and only an independent assessor can score it.

How we scope

The written scope names every system that issues or accepts temporary passwords for logon, such as directories, identity providers and provisioning tools.
Scope lists the account provisioning paths, including manual creation, bulk onboarding and helpdesk resets, so none issues a password without the forced change.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.

How we build

We configure the password policy so a temporary credential requires a change to a permanent password at first logon, with the setting enforced by the platform.
We review whether temporary passwords follow a predictable pattern, and we set generation rules that prevent a consistent style across accounts.
We test each provisioning path with a sample account to confirm the forced change occurs before any other access is granted.

How we hand over

Deliverables include the password policy and authenticator management procedures, with the configuration exported so an assessor can review it.
Test records show the forced-change behavior for each provisioning path, with dates, test accounts and results that the organization can retain.
Documentation maps the configuration to the 3.5.9 assessment objective in NIST SP 800-171A, so your team can present it to the assessor directly.

How we support

Ask your assessor which evidence they expect for IA.L2-3.5.9 before configuration changes, because the final evidence must be in final form to count as MET.
Confirm with your organization who owns the helpdesk reset process, since changes to that process can reopen the control.
Retainers can cover periodic re-testing after identity platform upgrades or new provisioning integrations, with scope agreed in writing.