Password Policy for Privileged Accounts

Password policy for privileged accounts diverges from user policy, because the constraints are different once no human has to remember the value.

When the vault holds it

Length can be maximal, up to what the target system accepts.

Complexity is free, since nobody types it.

Rotation can be frequent, limited only by dependencies.

Uniqueness is absolute — no reuse anywhere.

Memorability is irrelevant, which removes the constraint that shapes all user password guidance.

Generate the longest random value the target supports and rotate on the tightest schedule dependencies allow. There is no argument for anything less.

When a human must know it

Break-glass accounts, some appliances, some emergency paths.

Long passphrases rather than complex short strings.

Written down and stored physically is acceptable and frequently correct for break-glass, provided the storage is controlled.

Split across two holders where the consequence justifies it.

Rotated after every use.

Expiry

For vaulted accounts: rotate on a schedule and on check-in, and disable platform-level expiry, which otherwise causes unexpected lockouts.

For human accounts: forced periodic expiry is now widely discouraged for ordinary users. For privileged human accounts it remains defensible where compromise detection is weak, and it is a weaker control than multi-factor authentication and session brokering.

Prefer detection and rotation on suspicion to routine expiry.

Multi-factor authentication

Required for every privileged human authentication, without exception for convenience.

Phishing-resistant methods where available, since the accounts most worth attacking are the ones most likely to be targeted by sophisticated phishing.

At the vault, and at the target where possible, so that a compromised vault session does not automatically grant everything.

Break-glass accounts need a second factor too, with a fallback that works when the primary system is unavailable — which is the design problem.

Account lockout

A trade-off, not a straightforward control.

Lockout protects against guessing and creates a denial-of-service path against administrative accounts.

For break-glass accounts, lockout is dangerous: an attacker who locks them out has removed the recovery path.

Prefer monitoring and rate limiting over hard lockout on emergency accounts, and alert on failed attempts.

The things that matter more

Password policy attracts disproportionate attention. These do more.

Reducing how many accounts exist.

Removing standing rights.

Brokering sessions so credentials never reach endpoints.

Multi-factor authentication.

Monitoring for use.

An organisation with a strict password policy and standing domain administrative rights for forty people has optimised the wrong variable.

What to write down

Per tier: length, generation method, rotation interval, storage location, authentication requirements, and what happens on suspected exposure.

Short, and matched to what the tooling actually enforces.

Reviewed when the tooling changes, because policies outlive the systems they were written for and become fiction.

Where the policy meets reality

Written policy and enforced configuration diverge, and the gap is where the exposure sits.

Compare the policy against what the platform actually enforces, per system class.

Compare against what the vault generates, which may be shorter than the policy allows if the target has a limit.

Find the systems with a maximum length below your policy, which exist and are usually old.

Record each as an exception with the actual configuration.

Review when systems change, because policies outlive the platforms they were written for and become fiction that an auditor will identify.

Multi-factor at the target

Authentication at the broker is necessary and not always sufficient.

A compromised broker session grants everything the broker can reach, if the target requires nothing further.

Step-up authentication at the target for the highest tiers limits that.

Not practical everywhere, since many systems cannot require it.

Apply at tier zero, where the population is small and the consequence is total.

Accept broker-only authentication elsewhere, and record the decision rather than leaving it implicit.