You configure password expiry and reuse rules in OCI Identity Domains by setting password policy controls for the relevant identity domain and user population. Define how long passwords remain valid and how many previous passwords cannot be reused, then align the policy with password reset and account recovery processes. Review authentication failures and password reset trends for signs of friction or abuse.
What OCI Identity Domains Actually Controls
Password expiry and password reuse are policy decisions inside an OCI Identity Domain, not an application-level hardening trick. You define the rules once for the relevant population, then the domain enforces when passwords age out and how many prior values are blocked from reuse. The practical question is whether you want a stricter change cycle for higher-risk users, or a more forgiving policy where password quality and reset friction matter more than turnover.
Those settings only work well when they are treated as part of the full authentication flow. If the expiry window is too short, users accumulate reset friction and help desk load; if it is too long, compromised passwords remain valid longer than they should. Reuse controls matter because they stop users from rotating through a small set of known passwords, which is a common way weak policy defeats itself.
How to Set Expiry and Reuse Behaviour
In OCI Identity Domains, the core task is to configure the password policy for the identity domain and apply it to the intended user population. Set the maximum password age, then define the password history depth so the domain rejects any attempt to reuse recent passwords. The policy should be intentional, because expiry and reuse interact: a short expiry without history controls can still encourage predictable cycling, while strong history without a sensible expiry can leave old credentials in service too long.
Policy design should also reflect how users actually recover access. If password resets are rare but account recovery is well controlled, tighter expiry is easier to justify. If self-service reset is a major operational path, the policy should be tested against realistic user behaviour so you do not create repeated lockouts or workarounds. Good configuration is not just “turn the knob”, it is making sure the knob matches the operating model.
For the wider password policy context, Password Security and Password Manager Guide is the best starting point for understanding how expiry, reuse, and reset friction should fit together.
What to Check Before You Tighten the Policy
Before making the policy more aggressive, check whether the domain contains users with different risk profiles, recovery paths, or administrative roles. A single rule set may be acceptable for standard workforce users, but privileged users or high-value accounts may need a more deliberate treatment. Also verify whether password expiry will create dependency on downstream recovery processes, because the policy is only as strong as the recovery path behind it.
It is also worth checking whether the rule you are trying to fix is really about password age or about password compromise. If the concern is reuse of exposed credentials, expiry alone is a weak substitute for blocking known-bad passwords, enforcing strong authentication, and monitoring failed sign-ins. If the concern is lingering access after turnover or role change, the more important issue may be account lifecycle and deprovisioning discipline rather than password age.
When the subject is identity-domain policy design, the NHI lifecycle perspective in NHI Lifecycle Management Guide is useful for thinking about rotation, governance, and lifecycle controls as a single operating problem.
Risk and Threat Considerations
Poor expiry and reuse settings create two common failure modes: credentials stay valid after they should have aged out, or users adapt by selecting predictable variants of the same password. That combination increases the usefulness of stolen passwords for attackers and makes password-spraying or replay attempts more effective when reuse is weakly controlled.
Failure mechanism: The environment either keeps stale passwords alive too long, or lets users recycle near-identical passwords that remain easy to guess, reuse, or reuse after exposure elsewhere.
Impact: Attackers get a longer window to use compromised credentials, and defenders can end up with repeated sign-in failures, reset churn, or account takeover risk that looks like routine user friction until it becomes an incident.
For a broader threat lens on password reuse and credential abuse, 23andMe credential stuffing 2023 is a useful reminder that reused passwords can turn a small compromise into a much larger account exposure problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Password expiry and reuse are authenticator lifecycle controls. |
| IA-2 — Identification and Authentication (Organizational Users) | The policy governs workforce sign-in authentication behaviour. | |
| Recommendation — Set authenticator age and reuse limits to bound password lifetime. Enforce consistent authentication rules for organizational users. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Password expiry and reuse are credential management activities. |
| PR.AA-05 — Authenticator management | This directly covers password rotation and reuse policy decisions. | |
| Recommendation — Manage credentials through issuance, aging, reuse limits, and revocation. Apply authenticator management rules that constrain password lifetime and reuse. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Password expiry and reuse rules control authentication information handling. |
| Recommendation — Define and enforce secure handling rules for authentication information. | ||
Practitioner Guidance
What to verify: Confirm that the password expiry setting, password history depth, and reset workflow all point to the same operating outcome. If the policy is stricter than the recovery process can support, users will either flood support or find unsafe shortcuts.
Decision rule: If the account is operationally sensitive or exposed to frequent login attempts, prefer stronger reuse blocking and tighter monitoring of reset activity; if the user population is broad and low risk, avoid making expiry so aggressive that it becomes a nuisance control with little security gain.
Practitioner takeaway: Treat password expiry and reuse as a policy pair, not two separate toggles, because the real control is whether the domain can force change without creating predictable reuse or brittle recovery.
Related resources from NHI Mgmt Group
- Why does password reuse on identity provider accounts create such a high phishing risk for organisations?
- Why does identity sprawl increase password reuse and credential risk?
- What breaks when password-based identity controls still allow credential reuse?
- How do you configure password policy requirements in an AWS Cognito user pool?