Rotating Credentials Without Breaking Things

Every PAM programme commits to rotation and most stall on the same obstacle: nobody knows what will break.

Why it matters

A static credential is valuable indefinitely to whoever obtains it.

Exposure is undetectable. A credential copied years ago leaves no trace.

Leavers retain knowledge of shared credentials until rotation.

Compromise recovery requires it, and an organisation that cannot rotate cannot recover.

The easy cases

Human accounts brokered through the vault. Rotate on check-in, and nothing depends on the value.

Accounts with no automation dependency.

Cloud access keys, where the platform supports two active keys and a clean cutover.

Do these first, and report the coverage, because they are a real reduction and they build momentum.

The hard case

Service accounts with unknown dependencies, which is most of them.

The method:

Enable authentication logging for the account.

Run for a full quarter, to catch monthly and quarterly jobs.

Collect authenticating hosts and processes.

Build the dependency list, and assume it is incomplete.

Notify the owners of each dependency.

Rotate in a maintenance window with a rollback ready.

Watch authentication failures for the following weeks.

There is no shortcut, and no product removes the mapping work.

Reducing the need

Better than rotating faster.

Managed accounts where the platform handles the password automatically.

Workload identity in cloud, which issues short-lived credentials to a running workload with no stored secret.

Certificates rather than passwords, with a short validity and an issuance path.

Dynamic secrets from a secrets manager, created per use and expired shortly after.

Each removes the static credential entirely, which is a better outcome than a rotation schedule.

Setting intervals

Match to tier and to consequence, not to a single policy number.

Tier zero human accounts: on check-in.

Tier zero service accounts: as often as dependency mapping allows, and prioritise migrating them off static credentials.

Lower tiers: a defined interval, with the interval documented and justified rather than inherited from a standard.

On any suspected exposure: immediately, which requires the process to be practised.

Verifying it worked

Confirm the new credential authenticates.

Confirm the old one does not.

Watch failure logs for dependencies you missed.

Record the rotation with a timestamp, which is the audit evidence.

A silent rotation failure is the worst outcome, because everyone believes the credential changed and it did not.

The emergency rotation drill

Worth practising before it is needed.

Pick a tier one service account.

Rotate it under time pressure, as though responding to a compromise.

Measure how long it took and what broke.

Fix what the drill revealed.

Repeat annually. An organisation that has never rotated under pressure will discover during an incident that it cannot, which is the point at which it matters most.

Verifying the old credential fails

A rotation is not complete until the previous value has been confirmed to stop working.

Attempt authentication with the old credential after rotation.

Check that it fails, rather than assuming.

Check every authentication path, since some systems cache credentials and a stale value may work for a period.

Check replicas and secondaries, where replication lag can leave the old value valid.

Record the verification with a timestamp, which is the audit evidence.

A silent rotation failure is the worst outcome, because everyone believes the credential changed and the exposure continues unmeasured.

Rotating under compromise

Different from scheduled rotation, and it needs deciding in advance.

Order by tier, starting with anything that could grant the others.

Rotate the vault's own credentials first, if it may be affected.

Do not use possibly-compromised credentials to perform the rotation, which requires a clean administrative path established first.

Accept breakage. Dependency mapping is a luxury here; things will fail and that is preferable to leaving credentials valid.

Have the order written down before the incident, because deciding it under pressure costs the first day.