Teams should lock an account when the immediate goal is to stop logins, such as after suspected compromise, access revocation, or user departure. Changing a password still leaves the account active, while locking with usermod -L blocks access until the issue is resolved. This is a control decision, not just a maintenance task, and it is especially useful for rapid containment.
Why Locking Is the Faster Control When Access Must Stop Now
Locking is the right choice when the priority is immediate denial of interactive access, not a full credential reset workflow. That distinction matters because a password change only updates one authenticator, while a lock changes the account state itself. For a suspected compromise or departure event, the control should be the one that closes the login path fastest.
Linux teams often need this when they are still investigating whether the account is being used, whether there are active sessions, or whether the account should be preserved for evidence and later review. A lock lets the account remain present for audit and remediation steps while preventing new sign-ins.
That makes locking especially useful in containment, because it buys time without forcing a rushed password decision. If the account is a service or automation account rather than a human login, the same principle applies, but the follow-up action usually becomes stronger because the access path may be embedded in scripts, jobs, or deployed systems.
What Password Changes Do, and Why They Are Not Always Enough
Changing a password is a good control when the issue is secret compromise and the account itself should continue to be used. It forces reauthentication with the new secret, but it does not inherently disable the account. If an attacker still has an active session, another trusted path, or a different credential tied to the same account, the password change alone may not stop access.
That is why password changes are usually the better choice for routine rotation, planned maintenance, or credential hygiene when access should continue. They are not the same as revocation. A team that wants to remove access immediately should think first about account state, then about secret replacement and session cleanup.
In practical terms, the decision turns on intent. If the intent is “stop this account from logging in now,” lock it. If the intent is “keep the account usable but refresh the secret,” change the password and verify any other login paths, including keys, tokens, or cached sessions, are also addressed.
Risk and Threat Considerations
Delayed lockout can leave a compromised account usable long enough for lateral movement, data access, or persistence, especially when the account has elevated privileges or is tied to remote access. The main exposure is not the password value itself, but the continued existence of a valid login path while the incident is still unfolding.
Failure mechanism: teams rotate the password but leave the account active, or they assume the new password has ended all access when an attacker may still hold another path, such as an active session or non-password authentication material. In that state, the account can remain a live foothold.
Impact: the organisation may lose containment speed, extend attacker dwell time, and create a false sense of remediation. That is why account locking is the safer first move when the objective is emergency access removal, followed by whatever secret rotation and investigation the situation requires.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 5 — Account Management | Locking and revocation are account lifecycle controls for stopping access. |
| Recommendation — Use Account Management to disable or remove access immediately when an account should no longer authenticate. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and Credentials Managed | The question is about choosing the right account-access action during containment. |
| Recommendation — Manage account state and credentials separately so revocation actually stops access. | ||
| NIST Zero Trust (SP 800-207) | AC-1 — Access Control Policy and Procedures | Locking enforces a stronger access-control decision than password rotation alone. |
| Recommendation — Apply access-control policy to revoke or suspend accounts when access must end immediately. | ||
Practitioner Guidance
Decision rule: if the account must not be able to authenticate right now, lock it first and treat password change as a separate follow-up step. If the account should remain in service, password change is the appropriate maintenance action, but only after you have checked whether other access paths also need to be revoked.
What to verify: confirm whether the account has active sessions, sudo or delegated privileges, SSH keys, scheduled jobs, or application dependencies before assuming a password change is sufficient. For human departures, also verify whether the account is shared, tied to automation, or used for recovery access, because those cases change the revocation sequence.
Practitioner takeaway: the correct control is the one that matches the operational goal, and for urgent containment that usually means lock first, then clean up credentials and dependencies deliberately rather than relying on password change alone.
Related resources from NHI Mgmt Group
- How should security teams weigh password manager security benefits against usability and productivity costs?
- How should households implement password sharing without weakening account security?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
