Rotate RPA credentials by keeping them in a central store that bots read at run time, so a change in one place reaches every bot. Then rotate in a planned sequence: create the new secret, update the store, run a test, revoke the old secret. Stagger the work so a failure hits one bot, not all.
Why rotation matters
The OWASP Secrets Management Cheat Sheet advises regular rotation so that any stolen credentials work only for a short time, and says secrets should expire after a defined time where possible. Long-lived secrets are also a named risk in the OWASP Non-Human Identities Top 10 for 2025.
The problem is that bots break when a password changes, so teams avoid rotating. The answer is design, not avoidance.
What makes rotation easy or hard
| Setup | Rotation effort |
|---|---|
| Password typed into each workflow | High, must edit every bot |
| One shared password across bots | High and risky, one change breaks all |
| Dedicated account, secret in a store, bot reads it at run time | Low, update one entry |
| Short-lived credentials issued per run | Lowest, rotation is automatic |
The sequence
- Confirm which bots use the secret. If you cannot tell, that is the first problem to fix.
- Create the new credential on the target system while the old one still works, if the system allows two at once.
- Store the new value in the secret store. Do not paste it into chat or a ticket.
- Run one low risk bot against it and check the log for success.
- Release the change to the remaining bots in small groups.
- Revoke the old credential once everything has switched. The cheat sheet says revoked secrets must be removed from the exposed system immediately.
- Record the date, the person and the result.
When the system allows only one password
Some older systems keep one active password per account. Pick a quiet window, pause the schedules of the bots that use it, change the password and the stored value together, run a test, then resume. Write the window down so a failure at 2 a.m. has an owner.
Plan for failure
Keep the previous value available for a short time, as the rollback. Know who can reach the target system's admin to unlock an account if a bot locks it with the wrong password. Alert when a bot fails to sign in, since repeated failures can lock the account and stop other bots too.
Set the cadence
Rotate on a schedule you can meet, and rotate immediately after any suspected exposure or when a person with knowledge of the secret leaves. A lower frequency that happens beats a monthly plan that does not.
Make it a drill
Once or twice a year, rotate on purpose in a test environment and time it. The result tells you whether your design supports rotation or only your policy does.
Where Safeguard fits
Safeguard does not store or rotate secrets and does not offer secret scanning. It supports the code and dependency side of your automation estate.
Quick check
Can two credentials be valid at once?
On some systems yes, which makes rotation smoother. If not, schedule a short quiet window.
What if we do not know which bots use a secret?
Treat that as a finding. Build the inventory first, then rotate, so nothing breaks unseen.
Sources
Last reviewed: 19 October 2026.
