## TL;DR

Rotate fleet passwords in small batches, one site at a time, verifying each new login before moving on. Stagger the batches across hours or days so the pattern does not look like a credential-stuffing attack. Update the vault entry immediately after each successful rotation, and log what changed.

```text
how to rotate passwords on many accounts at once
```

## Use this when

- Doing scheduled credential rotation across agent accounts
- Responding to a suspected exposure
- Onboarding accounts into a new vault

## Not for this skill when

- Only one or two accounts need it (just do them by hand)
- You do not control the accounts
- The site offers API keys or tokens (rotate those instead of passwords)

## Steps

1. Build the inventory. List every account, its venue, and the last rotation date. Sort by risk: exposed or shared credentials first. Expected: a complete list, no mystery accounts.

```
rotation queue:
  1. [venue] / [account] - last rotated 2026-07-01
  2. [venue] / [account] - last rotated 2026-08-15
```

2. Work one site at a time. Open the site's password-change flow, set the new password, and log back in to verify before touching the next account. Expected: every rotation is verified working.

3. Update the vault entry immediately. The new credential goes into the vault before you close the tab, never into a scratch note. Expected: the vault always holds the current password.

4. Stagger batches. Do a handful of accounts, pause for an hour or more, then continue. Ten password changes in ten minutes from one IP invites fraud detection. Expected: no account gets locked for suspicious activity.

5. Log the rotation per account with the date. Expected: next quarter you know exactly what is due.

## Variant phrasings

### bulk password change for bot accounts

Batch by site, verify each login, update the vault, and stagger so it does not trip fraud detection.

### rotating credentials across a fleet

Inventory, risk order, one site at a time, vault update per rotation, logged dates.

### password rotation without getting locked out

Slow down. A few accounts per hour with verified logins beats a fast batch that triggers a lockout.

## Why it happens

Password-change flows are guarded by the same abuse detection as logins. A burst of changes from one IP with automated timing looks exactly like an account-takeover wave, so sites throttle or lock it. Going slow is not just polite, it is the only way the rotations actually complete.

## Edge cases / pitfalls

- Some sites force-logout all sessions on password change; re-authenticate your workers after.
- Sites with mandatory 2FA need the second factor in the rotation flow; plan for it.
- If a rotation fails midway, the vault must reflect which password is actually live.
- Never reuse one new password across accounts; generate a unique one per account.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UKiMIEY4AaAgPcGpGOGdtg