Allow temporary password use for system logons with an immediate change to a permanent password
📖 What This Means
This control requires that when a new user account is created or a password is reset, the system must issue a temporary password that expires after the first use. The user must immediately change it to a permanent password of their choice. This ensures that only the intended user knows the final password, reducing the risk of unauthorized access. For example, when onboarding a new employee, IT might provide a temporary password like 'Welcome123' that forces a change at first login. Another example is a password reset link that generates a one-time temporary password sent to the user's email.
🎯 Why It Matters
Temporary passwords left unchanged create significant security risks. Attackers can exploit default or shared temporary credentials to gain access, as seen in the 2020 SolarWinds breach where attackers used default passwords to move laterally. The DoD requires this control because 34% of breaches involve credential theft (Verizon DBIR). Without forced password changes, temporary credentials could remain active indefinitely, exposing systems to compromise. This control ensures only authorized users retain access after initial setup.
✅ How to Implement
- 1. In Azure AD: Configure 'Force password change on next login' in user properties (Azure Portal > Users > select user > Reset password)
- 2. In AWS IAM: Use CLI command `aws iam update-login-profile --user-name <user> --password-reset-required`
- 3. For GCP: Set `changePasswordOnNextLogin` flag via Admin SDK API or Google Workspace Admin Console
- 4. Enable audit logging for password reset events in cloud monitoring tools
- 5. Configure Conditional Access policies to block logins until password change
📋 Evidence Examples
Password policy document
Screenshot of AD user properties
Password reset logs
Test case results
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For IA.L2-3.5.9 ("Allow temporary password use for system logons with an immediate change to a permanent password"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how users, devices, and processes are identified and authenticated, including your IAM platform, password policies, MFA implementation, certificate management, and service account controls. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"IA.L2-3.5.9 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to allow temporary password use for system logons with an immediate change to a per.... The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"IA.L2-3.5.9 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to allow temporary password use for system logons with an immediate change to a per.... Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"IA.L2-3.5.9 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all authentication entry points (local login, VPN, cloud, API)
- • Document the identity provider(s) and authentication flow
- • Specify MFA methods and coverage
- • Ensure this control covers all systems within your defined CUI boundary where allow temporary password use for system logons with an immediate change to a permanent password applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Identification and Authentication Policy
- 📄 Password policy configuration
- 📄 MFA enrollment records
- 📄 Service account registry
- 📄 Evidence artifacts specific to IA.L2-3.5.9
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will test authentication mechanisms, verify MFA is enforced for required access paths, check password policy configuration, and review service account documentation.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Does your password policy require temporary passwords to expire after first use?
Question 2: Can users log in more than once with a temporary password?
Question 3: Are password reset events logged with timestamps and admin IDs?
Question 4: Is there documented evidence of testing this control within the last 90 days?
⚠️ Common Mistakes (What Auditors Flag)
1. Allowing password resets without forcing change
2. No logging of who issued temporary passwords
3. Temporary passwords don't meet complexity requirements
4. Documentation doesn't match actual implementation
📚 Parent Policy
This practice is governed by the Identification and Authentication Policy