4.5 Password Policy and Account Recovery
User Management covers adding and managing user accounts. Password policy and account recovery live elsewhere, and this is where they are.
Password policy is enforced by the identity provider, not by the platform. Configure complexity, length, history, expiry and lockout in the identity provider realm. State this clearly — an administrator looking for password settings in the platform will not find them.
Where federation is in use, password policy is the corporate provider policy entirely and the platform has no involvement.
Password reset for a local account is performed through the identity provider, either by an administrator setting a temporary password or by a self-service reset flow if enabled.
Account lockout thresholds and unlock procedures are identity provider settings.
-
For offboarding: deleting a platform user revokes their live sessions immediately, and removing them at the identity provider prevents new authentication. Do both — the first alone leaves an account that can log back in, and the second alone leaves a live session running until it expires.
A baseline policy
Set these in the identity provider realm. The values below are a defensible starting point for a platform holding a cryptographic inventory; adjust to your own standard where it is stricter.
| Setting | Suggested | Reasoning |
|---|---|---|
| Minimum length | 14 characters | Length contributes more than composition rules. |
| Composition rules | Few, or none, with a longer minimum | Complexity rules push people toward predictable substitutions and a sticky note. |
| Password history | 5 or more | Stops rotation becoming a two-password cycle. |
| Maximum age | Do not expire without cause | Current guidance from most standards bodies is against routine expiry; rotate on evidence of compromise instead. |
| Failed attempts before lockout | 5 to 10 | Low enough to stop guessing, high enough not to lock out a typo. |
| Lockout duration | 15 minutes, increasing | A temporary lockout defeats online guessing without creating a denial-of-service against your own users. |
| Breached-password check | Enabled if available | The single most effective control here. |
| Multi-factor | Required for administrators, at minimum |
Where federation is in use, none of this applies to federated users. Their password policy is the corporate provider's policy entirely and the platform has no part in it. These settings then govern only the local accounts that remain — which should be the break-glass administrator and any service accounts.
Multi-factor authentication
Configured in the identity provider, not here. Two things are worth deciding deliberately:
Require it for administrators. The administrator role can change the permission map, read every stored credential's metadata, and export the whole audit trail. It is worth a second factor even if nothing else is.
Decide what happens to the break-glass account. Multi-factor on an account whose purpose is to work when other things do not is a genuine trade-off. If you enable it, make sure the second factor does not depend on the same directory you are breaking glass to get around, and that more than one person can produce it.
Password reset
For a local account, through the identity provider:
Administrator reset — set a temporary password and require a change at next sign-in. The usual path.
Self-service reset — if the flow is enabled in the realm and the account has a verified email address.
Neither path exposes the existing password; it is not recoverable, only replaceable.
For a federated user there is nothing to reset here. Send them to the corporate password reset process.
Lockout and unlock
Lockout thresholds and the unlock procedure are identity provider settings. An administrator can unlock an account there immediately rather than waiting out the duration.
A lockout that affects everyone at once is not a lockout. If every sign-in is failing, the cause is the identity provider or an expired federation client secret, not a policy threshold. Check that before unlocking accounts individually.
Offboarding
Both halves, in this order:
Delete the platform user, which revokes their live sessions immediately.
Disable or delete the account at the identity provider, so it cannot authenticate again.
The first alone leaves an account that can sign back in. The second alone leaves a live session running until it expires.
Full offboarding guidance, including federated users and service accounts, is under User Management.
Credentials that are not passwords
Three other secrets have expiry or rotation requirements, and none of them is covered by a password policy. Each one fails in the same way: everything works until a date nobody recorded.
| Secret | Fails as |
|---|---|
| Federation client secret | Sign-in stops for everyone, at once, with no prior symptom |
| External TLS certificate | Console, API and agent submission all stop |
| Integration credentials — API keys, tokens | That integration silently stops synchronising |
Put each expiry date in a calendar someone reads. The notification engine can alert on certificate expiry once the platform's own endpoint is in the inventory; the other two need a human reminder.
The credential encryption key is the exception that should not be rotated routinely — rotating it means re-encrypting every stored target credential. See Certificates for how to protect it instead.