RHEL local account password rotation

Treat local account password rotation as a focused operating pattern for brownfield systems, not as a replacement for centralized identity. We recommend using it for a narrow class of local accounts outside centralized identity systems. That class includes break-glass accounts, privileged management accounts, and other long-lived local credentials that are difficult to eliminate but risky to leave outside formal governance.

This capability is most valuable when you already run Vault as a shared service and need to reduce the security and compliance burden of manually rotated passwords. The goal is not to make local accounts a preferred pattern. The goal is to make the remaining local-account footprint smaller, safer, and easier to govern while you continue moving toward stronger identity-based patterns elsewhere.

This guide covers the OS secrets engine on Vault Enterprise, connecting to Red Hat Enterprise Linux (RHEL) hosts over direct SSH. It does not cover Windows or WinRM targets, Vault Community Edition, or other secrets engines.

Start with the right use cases

We recommend adopting local account password rotation only for accounts that meet all of the following criteria:

• The account already exists on the target host and remains long-lived.
• The current operating model cannot realistically replace the account with a centralized identity system.
• The account represents meaningful operational or security risk if its password remains static.
• The account is important enough to justify controlled onboarding, rotation, and recovery procedures.

Typical examples include:

• break-glass local accounts retained for loss-of-directory or loss-of-network scenarios
• privileged accounts with sudo access or management accounts used to repair host configuration
• local service credentials on legacy systems that cannot yet move to a different pattern

We do not recommend leading with this feature for standard human access, broad privileged access management, or general account lifecycle management. If a centralized directory already solves the identity problem for the target users, keep using it. If a use case can move to short-lived credentials instead, prioritize that path first.

Treat this as a standardization pattern, not a one-off feature

The strongest HVD pattern for this capability is to standardize how platform teams govern exceptions. In practice, that means using Vault to make local account management more predictable across many systems instead of solving each host independently.

We recommend the following operating model:

1. Define a small set of approved account classes for onboarding.
2. Standardize how teams represent hosts, name accounts, and grant onboarding authority.
3. Apply the same rotation policies, audit expectations, and recovery procedures across each account class.
4. Expand gradually only after the platform team has validated that rotation, recovery, and operational ownership are working well.

This feature reduces operational variance only when teams use it consistently. If each team onboards hosts differently, handles failures differently, and stores recovered credentials differently, you reproduce the same inconsistency that made the local-account footprint risky in the first place.

Prefer the least-privileged rotation model

We recommend self-managed (rootless) rotation as the default pattern whenever the target account can change its own password under the host's approved controls. This keeps the lifecycle of the target account isolated and avoids introducing a second privileged credential purely to support rotation.

Use a parent-managed model only when the account cannot rotate itself or when operational constraints require a separate privileged helper account. In that case:

• Create a dedicated parent account for rotation rather than reusing a broadly privileged administrator account.
• Scope the parent account to the minimum rights needed to change the target password.
• Constrain sudo permissions to the exact binary and workflow required for rotation.
• Document which target accounts depend on that parent account for continued rotation.

The important design principle is to avoid turning a password-rotation feature into a new standing administrator pattern. If parent-managed rotation becomes the default for every account, the blast radius of the helper credential becomes the real problem you now manage.

Onboard conservatively

We recommend a deliberate onboarding sequence instead of bulk importing accounts and scheduling rotation in the same change window. Start with host onboarding, validate connectivity and trust, then onboard accounts in a controlled cohort.

Set connection rules when you onboard the host. Standardize the host address, port, and host key material, and make Vault verify the first real connection before the platform accepts an account into service. Avoid deferring that first verification until the first scheduled rotation unless the platform team has accepted the risk and documented the exception.

Two practices matter here:

• Do not assume import equals readiness. Follow account onboarding with a deliberate validation step and then a manual rotation before you enable scheduled rotation.
• Preserve reversibility. During early deployment, make sure the platform team can retrieve the current credential, verify that rotation succeeded, and offboard the account cleanly if the target system is not yet ready.

This capability fits phased adoption better than a big-bang deployment. We recommend beginning with a small set of non-critical Linux hosts, validating the end-to-end workflow, and then expanding to higher-sensitivity accounts once the run book is stable.

Make host trust explicit

We recommend treating host key verification as a required part of the operating pattern, not an optional hardening step. Wherever possible, pre-populate the host key during onboarding and verify it before the account enters rotation.

Trust on First Use (TOFU) can help bootstrap environments that do not yet have a better distribution path for host keys, but use it as a transitional mechanism rather than the long-term standard. If you rely on TOFU broadly, you weaken one of the most important controls protecting the rotation workflow from connecting to the wrong system.

A good enterprise pattern is:

• Use explicit host key management for stable production hosts.
• Define how teams handle host key rotation before onboarding at scale.
• Require a documented approval path for any TOFU-based onboarding in higher-sensitivity environments.

Design around the real platform dependencies

Local account password rotation succeeds or fails based on platform conditions outside Vault. Before you scale this pattern, we recommend validating the dependencies that most often create operational friction:

• A direct SSH path from Vault to the target host.
• Plugin registration and version alignment as part of the Vault deployment plan.
• The required binaries present in the host path.
• Pseudo-terminal (PTY) support when using self-managed rotation.
• sudo configuration scoped to the exact commands required for parent-managed rotation.
• An explicit password policy so rotated credentials meet complexity requirements consistently across hosts, rather than relying on host or plugin defaults.

This is one reason to keep the first deployment narrow. The feature uses a specific rotation model. If your environment depends on bastion hops, outbound proxies, or inconsistent host hardening standards, fix those dependencies first or explicitly exclude those hosts from the initial operating model.

Separate rotation control from credential consumption

We recommend keeping the number of actors that can read rotated passwords as small as possible. The platform value of this feature comes from consistent rotation and recovery, not from making local account passwords easier to distribute.

Where applications or automation need the credential, prefer a controlled consumption pattern that already aligns with the broader Vault operating model. For legacy consumers, Vault Agent is often the best bridge: it is a credential consumption and delivery pattern, not a rotation mechanism, so it reduces custom integration work while letting the platform team standardize how rotated secrets reach existing systems.

In practice, this means:

• Separate policies for onboarding and rotation from policies that read current credentials.
• Reserve direct credential retrieval for controlled operational use cases, recovery workflows, and approved consumers.
• Avoid normalizing informal password reads by operators when the real need is better automation or templating.

If teams still depend on humans copying passwords out of Vault as a steady-state workflow, the design is not yet mature enough to scale.

Use manual rotation to prove readiness, then automate

We recommend using manual rotation as the readiness gate and scheduled rotation as the steady state.

Manual rotation is the right place to validate:

• The chosen rotation model.
• Connectivity and execution behavior on the host.
• The account’s post-rotation usability.
• The team’s recovery steps if something goes wrong.

Once that works consistently, enable automated rotation with an interval that reflects the sensitivity of the account and the operational tolerance of the workload. Choose rotation cadence with the dependent systems and operating team in mind. Tie it to the time required for dependent systems to absorb a password change and for the platform team to respond when a host drifts out of sync.

Make offboarding a standard workflow

We recommend treating offboarding as part of the managed lifecycle rather than as cleanup after teams finish the real work. When an account leaves managed rotation, turn off automated rotation first, retrieve the current credential for the next approved owner, and then remove the managed account entry. Delete a host entry only after the platform team has confirmed that no remaining managed accounts depend on it.

This sequence keeps ownership clear at the point where drift and access loss are most likely. It also prevents teams from deleting Vault state before they have captured the final known-good credential or confirmed that another workflow now governs the account.

Plan for failure before you expand

This feature manages credentials on a remote system, so recovery planning is part of the design, not an afterthought. We recommend documenting a manual recovery workflow before scaling beyond the pilot:

• How to identify whether Vault or the host has the authoritative password.
• How to use version history and audit data to determine the correct recovery point.
• When to restore a historical version versus when to perform a controlled reset.
• How to offboard an account without losing access or audit continuity.

The key principle is straightforward: do not expand the scope of managed accounts until the platform team can recover from split-brain scenarios confidently and repeatably.

Roll out by account class, not by host count

We recommend sequencing adoption by operational similarity instead of trying to rotate every eligible account at once. A practical deployment sequence looks like this:

1. Pilot: a small supported Red Hat Enterprise Linux (RHEL) cohort with low operational variance.
2. Break-glass accounts: accounts where governance and audit readiness matter most.
3. Management accounts: repair accounts or accounts with sudo access and clearer owner responsibilities.
4. Broader legacy coverage: only after rotation, recovery, and policy boundaries are working consistently.

This order helps the platform team learn where the real failure modes are without spreading the feature faster than the organization can support.

Reference materials

Use the product documentation for feature-specific configuration and API behavior, and use this HVD guidance to shape the operating model around that implementation:

• Vault Agent(opens in new tab)
• OS secrets engine(opens in new tab)
• Vault plugins(opens in new tab)
• SSH secrets engine(opens in new tab)
• Automate Linux password rotation with Vault(opens in new tab)