Temporary passwords prevent permanent passwords from being exposed during initial account provisioning. You create a temporary password, give it to the user, they log in, they’re forced to set their own password immediately. Their permanent password never travels through insecure channels.
This is usually configured in Active Directory with the “user must change password at next logon” flag. It’s straightforward if you have a documented process for it. The failure is usually “we just give them a password and they use it,” with no enforced change. This works alongside account provisioning processes covered in IA.L2-3.5.5 and password protections in IA.L2-3.5.10.
What the assessor is actually evaluating
The assessor is checking that you have a process for temporary passwords and that you enforce a password change on first logon. They want to know how temporary passwords are created and delivered. They want to see that you’re not sending passwords through email or chat. They want to see that accounts are configured to force a change immediately.
If you say “we generate a temporary password, set the account to require a change at next logon, and deliver it securely,” you’ve covered this practice. The details of “securely” matter. If you say “we email it,” that’s not secure. If you say “we deliver it via [secure method] or in person,” that’s fine.
What a realistic SSP definition looks like
Practice IA.L2-3.5.9: Temporary Passwords and Change on First Logon
When new user accounts are created, temporary passwords are issued and must be changed immediately upon first logon.
Account Provisioning Process:
When a new account is provisioned in Active Directory, the account creator generates a random temporary password. The password meets our complexity requirements (see IA.L2-3.5.7). The account is configured with the “user must change password at next logon” setting in Active Directory. This forces the user to set a permanent password before they can access any systems.
Temporary Password Delivery:
Temporary passwords are delivered securely. For employees on-site, passwords are delivered verbally or in person. For remote employees, temporary passwords are delivered through [secure method: encrypted email / secure password sharing portal / phone call / etc.]. Passwords are never sent via unencrypted email, chat, or text message.
Password Change Enforcement:
Upon first logon, Windows prompts the user to change their password. The user must enter the temporary password, then create a new permanent password meeting complexity requirements. This new password becomes the user’s permanent password for domain access.
Account Reset:
If a user forgets their password and requires a reset, the same temporary password procedure applies. A temporary password is issued, the account is configured to require a change at next logon, and the user is notified.
Service Account Exception:
Service accounts are not subject to this requirement due to their non-interactive nature. Service account passwords are generated, stored in a credential vault, and are changed only through administrative processes or scheduled rotation.
This is clear about the process, the delivery method, and the enforcement mechanism. The assessor reads this and doesn’t need to ask follow-up questions.
How to present your evidence
- Account provisioning SOP or process document covering temporary password procedure
- Group Policy or Active Directory configuration showing 'user must change password at next logon'
- Example provisioning ticket documenting the process
- Evidence of secure temporary password delivery method (not email/chat)
You need:
Your account provisioning SOP. Document the process for creating accounts, including the temporary password procedure. One paragraph is fine.
Group Policy or Active Directory configuration. Show that accounts are being created with “user must change password at next logon” enabled. You can show this in Active Directory Users and Computers by looking at a test account or a recently created account and showing the setting is checked.
Example provisioning tickets. Find one or two recent new hire provisioning tickets that show how the account was set up. You don’t need to show the password itself, just show that the ticket references the provisioning process.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP or MSSP
Your MSSP should be provisioning accounts with this setting enabled automatically. When they create a new account, “user must change password at next logon” should be checked by default. If it’s not, ask them why.
Your MSSP should also have a process for delivering temporary passwords. If they’re emailing them, push back. Have them deliver them securely or let you handle delivery if you prefer.
In the assessment, your MSSP can describe the provisioning process and show examples. The contractor can speak to the delivery method if needed.
This guidance is based on assessment room experience and reflects one practitioner’s interpretation of CMMC Level 2 requirements. It is not legal or compliance advice. Always consult your compliance team and official CMMC documentation for final guidance.