Each RPA bot should have its own account. A shared login makes actions untraceable, forces the account to carry the union of every bot's permissions, and means one leaked password exposes all of them. A bot should never use a named employee's credentials either.
The three common patterns
| Pattern | Traceability | Blast radius | Offboarding |
|---|---|---|---|
| One shared account for all bots | Poor | Large | Hard, retiring one bot touches the rest |
| A person's login reused by a bot | Misleading | Tied to that person's access | Breaks when the person leaves |
| One account per bot | Good | Limited to that bot's task | Clean, disable one account |
The OWASP Non-Human Identities Top 10 for 2025 names identity reuse, human use of non-human identities and overprivileged identities as separate risks. The shared login and the borrowed login patterns hit all three.
Why a borrowed personal login is the worst case
It looks convenient. The builder already has access, so they point the bot at their own account. Then three things happen. The audit trail says a person did work at 3 a.m. The bot inherits every permission that person holds, far more than the task needs. And when the person changes role or leaves, the bot fails, or worse, someone extends the person's account so the bot keeps working.
We cover the same trade-off for connections in personal login or service account for an automation connection.
How to split accounts in practice
Do not make one account per workflow step. A good unit is one account per bot, or per bot family that does the same job against the same systems with the same access.
- Name accounts so the owner and purpose are obvious, for example a prefix for bots plus the process name.
- Record an owner, a backup owner and a review date next to each account.
- Block interactive sign-in for bot accounts where the target application allows it, so people cannot use them by hand.
- Alert if a bot account signs in from an unexpected place or outside its schedule.
- Give accounts that reach sensitive data a shorter review cycle.
What if the target app only supports named users
Some older applications license by person and have no service account type. In that case, create a dedicated account that is clearly marked as a bot, assign it to a team owner rather than an individual, keep its credentials out of workflow files, and document the exception with an owner and a date to revisit. An undocumented exception is a risk. A documented one is a decision.
Common objections
"It costs a licence per bot." Weigh that against what a shared login costs you in an investigation, when you cannot tell which bot touched a record.
"We only have three bots." Three is the right time to set the pattern, before there are thirty.
Where Safeguard fits
Safeguard's asset discovery helps you find the systems and services automation touches, and its compliance and evidence automation can help you keep access review records tidy. It does not issue or manage bot accounts for you.
Quick check
Can two bots that do the same job share an account?
Often yes if they touch the same systems with the same access, as long as the account has an owner and its actions are logged per bot.
Is a service account the same as a bot account?
In practice, yes. Both are non-human identities that should have an owner, minimum access and a review date.
Sources
Last reviewed: 19 October 2026.
