Should organisations give new hires temporary credentials or permanent passwords at onboarding?

Why onboarding credentials should start temporary, not permanent

Temporary onboarding credentials are a control choice, not just a convenience issue. They let the organisation prove the new hire’s identity once, then require the person to move to a private secret before ongoing access begins. That avoids a shared starter password becoming the default long-term credential and makes the initial login a transition point rather than a standing account state.

The practical advantage is that the first password can be short-lived, tightly scoped, and easy to invalidate if onboarding data was misrouted or delayed. A permanent password issued at hire time often survives beyond the onboarding window, which increases the odds that it is copied, reused, or forgotten in a help desk workflow. This is why temporary credentials pair naturally with reset-on-first-use flows and MFA.

For teams looking at workforce access design, the same logic appears in Joiner-Mover-Leaver (JML) Guide: onboarding should create access that is immediately usable but not permanently exposed. If the onboarding secret can be shared, emailed, or written down, it has already become a weak trust anchor rather than a controlled bootstrap mechanism.

What temporary credentials change operationally

Temporary credentials change the account lifecycle in a useful way. They create an explicit handoff from identity proofing to normal authentication, which means the organisation can verify that the right person received access and that the first secret was not left in circulation. They also reduce the need to pre-create durable passwords that may outlive the hiring event, especially when the account is provisioned before the employee’s first day.

That is especially important where onboarding touches systems that later carry broader access. A starter password should not behave like a standing credential. The API Key Management Guide makes the same lifecycle point for secrets: issuance, expiry, rotation, and revocation matter more than the format of the secret itself. Temporary credentials keep the first secret in the same governed path as other identity-bearing material.

Temporary onboarding also fits better with reset workflows. The employee should change the password immediately, and the old credential should expire automatically if not used. That reduces dependency on manual cleanup and gives security teams a cleaner signal that the onboarding handoff completed successfully. The goal is not just access, but controlled transition from bootstrap access to normal account ownership.

Where permanent passwords create avoidable exposure

Permanent starter passwords create two common failure modes. First, they tend to be shared through channels that are not meant for durable credentials, such as email, chat, or printed packets. Second, they remain valid longer than intended when onboarding is delayed, rescinded, or repeated for contractors, interns, or rehires. In both cases, the password becomes a standing secret before the user has even established normal account hygiene.

That exposure is not theoretical. The more a credential behaves like a permanent secret, the more it resembles the long-lived material that secret-management programmes are designed to eliminate. Secrets Management Guide is relevant here because onboarding passwords are effectively secrets with a short intended lifetime, and short-lived secrets are easier to govern than durable starter passwords that linger after first use.

Permanent passwords also weaken accountability. If the same starter password is reused across multiple hires, or reused by HR or IT staff to “help” with login, the organisation loses confidence that the credential maps cleanly to one person and one event. That makes later troubleshooting harder and turns a normal onboarding step into a latent access-control problem.

Risk and Threat Considerations

Temporary credentials reduce the blast radius of onboarding mistakes, while permanent passwords increase the chance that a starter secret remains usable after it should have been retired. The main risk is not the password format itself, but the fact that a long-lived onboarding secret can be intercepted, reused, or handed around before the employee has established personal control of the account.

Failure mechanism: A permanent onboarding password is shared too early, stored too widely, or never rotated after first use, so the bootstrap secret becomes a standing credential that can be replayed or abused.

Impact: Attackers or insiders can gain access through a password that was meant to be temporary, and the organisation may not notice because the account appears to belong to a legitimate new hire.

Practitioner Guidance

What to prioritise: Make the first login a forced credential transition, not a normal operating password. Require password change at first use, and ensure the temporary secret expires automatically if the hire never completes onboarding.

What to verify: Confirm that the temporary credential cannot be reused after reset, that it is delivered through a controlled channel, and that MFA is enforced before the account is treated as fully active. If support staff can retrieve or resend the same secret indefinitely, the control is too weak.

Common mistake: Treating “temporary” as a label rather than an expiry condition. A temporary password that remains valid for days, or survives a help desk reset without revocation, is functionally permanent.

Practitioner takeaway: Use temporary credentials to constrain the bootstrap phase, then move quickly to a personal password and MFA so onboarding access never becomes a standing shared secret.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of stale API keys and machine tokens?
• How should teams govern automated onboarding without overprovisioning new hires?
• What should organisations do when router passwords or access credentials appear in leaked data?
• What fails when organisations rely on weak passwords and reused credentials?