Temporary and Initial Passwords Guide: Safe Issuance, Delivery, Expiry and Replacement Options

Every new account, every help desk reset and every device out of the box starts with a secret that someone other than the final user has seen, and that first secret is where many account takeovers begin. Temporary and initial passwords are issued by people and systems under time pressure, sent over whatever channel is convenient, and too often left in place for months. This guide covers how to generate them, how to deliver them, how long they should live, how to force replacement, and when to stop issuing passwords at all in favour of one-time enrolment codes such as a Temporary Access Pass. It is written for identity engineers, service desk leads and application owners who set or audit onboarding and reset processes.

Key takeaways

• An issued secret is a shared secret. Whoever generated, read or relayed it can use it, so it must be random, single-use where possible and short-lived.
• It must never become the long-term password. OWASP ASVS 5.0 requirement V6.4.1 says initial passwords and activation codes must expire after a short period or first use and must not be allowed to become the long-term password.
• Delivery is the weak point. Separate the identifier from the secret, avoid email for the secret itself, and never put it in tickets, chat or spreadsheets.
• Prefer enrolment codes over passwords. A time-limited, one-time onboarding code that leads straight to a passkey or authenticator app removes the password from the first-day process entirely.
• Every reset needs verification and a trail. A reset that bypasses MFA or identity checks is an account takeover path; log every issuance and alert on unusual volume.

Where temporary and initial passwords appear

The same weakness appears in processes owned by different teams. Treat them as one control area.

The last row is a machine credential, not a person's password, but it fails the same way. See the Local Administrator Password Solution (LAPS) Guide.

What the standards require

• OWASP ASVS 5.0, V6.4.1 (Level 1): system-generated initial passwords or activation codes must be securely randomly generated, follow the existing password policy, and expire after a short period or after first use. They must not be permitted to become the long-term password.
• OWASP ASVS 5.0, V6.4.3 (Level 2): a forgotten-password process must not bypass any enabled multi-factor authentication.
• OWASP ASVS 5.0, V6.3.2 (Level 1): default user accounts such as "root", "admin" or "sa" must not be present or must be disabled.
• NIST SP 800-63B-4 (final, July 2025), section 3.1.1: passwords must either be chosen by the subscriber or assigned randomly by the credential service provider, must be compared against a blocklist, and must not be subject to periodic forced change. A change must be forced where there is evidence of compromise. The minimum is 15 characters where the password is the only factor and 8 characters where it is part of multi-factor authentication.
• NIST SP 800-63B-4, binding codes: codes used to bind an additional authenticator are single-use and valid for at most 10 minutes. Issued recovery codes must have at least six decimal digits (or equivalent) from an approved random bit generator, and are valid for at most 10 minutes by SMS or voice, 24 hours by email, and 21 days by post within the contiguous United States (30 days elsewhere).
• NIST SP 800-53 Rev. 5, IA-5(1)(e): require immediate selection of a new password on account recovery. IA-5(1)(c) requires passwords to be transmitted only over cryptographically protected channels.
• UK Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 1 paragraph 1: in force from 29 April 2024, passwords on relevant consumer connectable products must be unique per product or defined by the user, and unique passwords must not be based on incremental counters, public information or product identifiers such as serial numbers (unless derived using accepted cryptographic methods).

A temporary password must pass the same blocklist as any other, and the NIST rule against periodic expiry applies to the user's own password, not to the issued secret, which should expire quickly by design. See the Password Policy Guide (NIST-aligned).

Generating the secret

• Use a cryptographically secure generator: the identity platform's own generator or a CSPRNG library, never a spreadsheet formula, a pattern or a "standard" reset password reused by the desk.
• Length and alphabet: if the user will type it once, a random string of 15 or more characters, or a short passphrase from a large word list, is adequate. Avoid ambiguous characters (0/O, 1/l/I) when it will be read aloud or printed.
• No derivation from personal data: date of birth, employee number, surname plus digits and similar patterns are guessable by anyone who knows the scheme, including other staff.
• Do not let analysts choose: under pressure they reuse the same few strings, so remove manual entry from the console.
• One secret per person and per event: never issue the same initial password to a cohort of starters or a class of students.

Delivery: getting the secret to the right person only

• Split the identifier and the secret: send the username through one channel and the secret through another, so a single intercepted message is not enough.
• Keep secrets out of systems of record: no initial passwords in ITSM tickets, HR system notes, onboarding spreadsheets, chat threads or welcome emails. These are searched, exported and retained for years. The Poland ArcGIS password leak shows how a login sent by email can stay usable and exposed long after it was issued.
• Do not send the secret to the manager: sending a starter's password to their line manager turns a personal credential into a shared one before the person has even started.

Expiry and forced replacement

An issued secret should be used once and replaced, or time out. Both are needed, because many issued passwords are never used by the intended person.

Lifetimes are an organisational choice unless a standard sets one. As NHI Mgmt Group recommendations rather than standard values: issue new starter secrets no earlier than the start day, keep remote reset secrets valid for minutes to a few hours, and treat anything valid for more than 24 hours as an exception that needs a reason. Restrict the temporary session to the change or enrolment step, and if a temporary password is used from an unexpected location or device, invalidate it and investigate.

Replacing passwords with enrolment codes

The strongest option is to issue no password at all. A one-time enrolment code lets the user sign in once, register a phishing-resistant method such as a passkey or a platform authenticator, and never learn a password.

• Microsoft Entra Temporary Access Pass (TAP): lets users register passkeys, Microsoft Authenticator or Windows Hello for Business without a password. Microsoft documents that Entra-joined devices can be joined and Windows Hello for Business registered with a TAP and no password. Each user can have only one TAP; creating a new one overrides the existing pass.
• Who can issue: in Entra, Authentication Administrators can create a TAP for member users and Privileged Authentication Administrators can also create one for administrators; neither can create one for themselves. Keep TAP issuance for privileged accounts with a small team.
• Session limits: Microsoft states that tokens issued during a TAP sign-in are capped at the TAP's expiry, but existing sessions are not revoked retroactively when the TAP is deleted. Use sign-in frequency controls if a short session matters.
• Equivalent patterns elsewhere: most identity providers and customer identity platforms offer expiring activation or enrolment links. The properties to check are the same: random, single use, short lifetime, bound to one account and leading straight to MFA registration.

See the Passkey Rollout Guide and the Joiner-Mover-Leaver Guide for how first-day enrolment fits into onboarding.

Help desk resets: verification before issuance

A temporary secret is only as safe as the check done before it is issued. Attackers who cannot steal a password will ask the service desk to issue a new one. In the MGM Resorts breach, a help desk phone call was the entry point, and the Co-op attack also relied on help desk social engineering.

1. Verify the caller with something the attacker is unlikely to have: a call back to the number on record, a video check against the HR photo, or a verification push to an already registered device.
2. Do not reset MFA and the password in the same call without a higher level of verification and a second approver. OWASP ASVS V6.4.3 requires that password reset does not bypass enabled MFA.
3. Prefer to issue an enrolment code or trigger self-service reset rather than reading out a password.
4. Apply stricter rules to administrators, executives and finance staff, and route their resets to a named team.
5. Notify the user through every registered channel that a reset happened, so a victim can report a reset they did not ask for.

See the Account Recovery and Help Desk Security Guide and the Help Desk Identity Verification Policy Template.

Customer and application accounts

• Let the user set the password: for customer accounts created by staff, send an activation link or code and let the customer choose their own credential. Do not generate a password the staff member has seen.
• Reset tokens: the OWASP Forgot Password Cheat Sheet advises tokens that are randomly generated with a cryptographically safe algorithm, stored securely, single use, expiring, and linked to one user. It advises against sending the new password by email, against automatically logging the user in after a reset, and recommends invalidating existing sessions.
• Reset links: build reset URLs from a fixed or validated host (not the request's Host header), serve them over HTTPS and set a no-referrer referrer policy on the reset page so tokens do not leak to third parties.
• Enumeration: return the same message and timing whether or not the account exists, and rate limit reset requests per account.
• Recovery through AI or chat support: automated support channels that can send recovery links need the same verification as human agents. The Meta AI Instagram account takeover is an example of recovery links reaching attackers through an AI support assistant.

Default and factory passwords

A default password is an initial password shared by every unit of a product. ATT&CK tracks the abuse of such accounts as T1078.001 Default Accounts. The NCSC's password guidance says all default vendor-supplied passwords should be changed before deployment, and NIST SP 800-53 IA-5 includes changing default authenticators before first use. The McHire default password flaw, where an administrator account used "123456", shows the cost when a setup credential stays in place. For devices sold to UK consumers, the PSTI regulations now prohibit universal default passwords.

Decision guidance

Detection and measurement

• Directory events: on Windows, event 4724 ("An attempt was made to reset an account's password") is generated under Audit User Account Management. Microsoft recommends monitoring all 4724 events for high-value accounts and local accounts. Alert on resets of privileged accounts and on one operator resetting many accounts in a short time.
• IdP audit logs: record every password reset, TAP creation and deletion, and authentication method change with the operator, target and ticket reference.
• Use of the temporary secret: alert when an issued secret is used from a new country, an anonymising network or a device that is not the expected one.
• Stale issued secrets: report accounts still flagged for forced change after a set number of days.

Metrics that show the control works:

1. Percentage of new starters onboarded with an enrolment code rather than a password.
2. Median time from issuance to first use of a temporary secret.
3. Number of accounts with an unused temporary secret older than the agreed lifetime.
4. Percentage of help desk resets with a recorded verification method and ticket reference.
5. Resets of privileged accounts per month, each reviewed.
6. Count of initial passwords found in tickets, chat or shared documents by secret scanning.

Rolling out a safer process

1. Inventory: list every place an initial or temporary secret is issued: HR provisioning, service desk, branch staff, application admins, device builds and vendor invitations.
2. Quick fixes first: remove pattern-based passwords, stop email delivery of secrets, configure random generation and enable "change at next sign-in", ideally with MFA before the change.
3. Pilot enrolment codes: start with one department or the IT team, measure completion and help desk calls, and keep the old path available as a fallback during the pilot.
4. Tighten the help desk: introduce verification scripts, call back to known numbers and a second approver for privileged resets.
5. Expand and retire: move all new starters to enrolment codes, then remove the ability for analysts to set passwords manually.
6. Rollback: if enrolment completion drops or a device build breaks, revert the affected group to random temporary passwords with forced change while the issue is fixed, rather than to a shared or patterned password.

Framework mapping

Common failure patterns

• Patterned passwords: "Company2026!" or "Welcome1" issued to every starter, known to every former employee.
• Secret in the ticket: the reset password typed into the ITSM ticket or chat, then exported and indexed.
• Issued weeks early: accounts created and passworded at offer acceptance, then unused until the start date or never used at all.
• Forced change without MFA: anyone holding the temporary password can set the permanent one and register their own MFA method.
• Defaults left on appliances: network devices, cameras and admin consoles still on the factory or setup credential.

Practitioner checklist

• Generate all issued secrets randomly in the platform; remove analysts' ability to type their own.
• Run issued secrets through the same blocklist as user passwords.
• Stop sending passwords by email; send expiring links or codes and split username from secret.
• Enable forced change at next sign-in, with MFA before the change where the platform supports it.
• Issue starter credentials on the start day and expire unused ones quickly.
• Move new starters to a one-time enrolment code that leads to a passkey or authenticator.
• Require verified identity and a ticket for every reset; second approver for privileged accounts.
• Alert on privileged resets, reset bursts and first use of temporary secrets from unusual places.
• Scan tickets, chat and shared drives for issued passwords and remove them.
• Replace device and appliance defaults before deployment and manage local admin passwords per machine.

Standards and references

• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• OWASP: Application Security Verification Standard 5.0
• NIST: SP 800-53 Rev. 5
• OWASP: Forgot Password Cheat Sheet
• Microsoft: Configure a Temporary Access Pass in Microsoft Entra ID
• Microsoft: passwordProfile resource type (Microsoft Graph)
• NCSC: Password policy, updating your approach
• UK legislation: PSTI Security Requirements Regulations 2023, Schedule 1

Related NHI Mgmt Group resources: Password Policy Guide (NIST-aligned) · Account Recovery and Help Desk Security Guide · Joiner-Mover-Leaver Guide · NIST SP 800-63B-4 Authenticator Assurance Level · Local Administrator Password Solution (LAPS) Guide