The bot is built. UAT has passed. The process owner wants it live on Monday. Then the information security team asks a simple question: how does the bot log in? If the honest answer is a password in a configuration file, a developer's own account, or a one-time code typed in by whoever is at their desk, the go-live date just moved by a quarter. The security review is the gate automation programmes hit hardest, and nearly every finding could have been designed out in week one.
What the reviewer is looking for.
An unattended bot is a non-human identity with the access of a clerk, and often more. A reviewer wants four answers. Who is this identity. Where do its secrets live. Who can read them. What happens when they change. A bot without those answers is treated as a shared password with a scheduler attached, because that is what it is.
| Finding | What the reviewer sees | What to build instead |
|---|---|---|
| Human account reused | A developer's login running production batches at 02:00. | One named service account per bot, per environment. |
| Secret in code or config | A password in a project file, a screenshot, a wiki page. | Credential asset in the orchestrator, backed by an enterprise vault. |
| MFA bypassed | A spreadsheet of backup codes, or MFA switched off for the account. | A policy exemption for the runner, or an authentication method built for machines. |
| No rotation | A password last changed when the bot was built. | Rotation on a schedule, with the bot reading the current value at run time. |
Service accounts: one bot, one identity.
Every bot gets its own account in every system it touches, named so a log entry identifies it at a glance. Request it through the same joiner process a person would go through, with the automation lead as owner. Scope its access to the transactions the process definition document names. A bot that posts supplier invoices does not need to create vendors.
- Separate accounts per environment. The development account must not reach production data, and the reverse holds too.
- A documented exemption, if any. Password-expiry policies written for people will lock the bot out at the worst possible time. Agree the exemption in the review and compensate with vault-driven rotation.
- Attended bots use the person's own identity. The human is present, the session is theirs, and the audit trail should say so. Service accounts are for unattended work.
Credential vaults: the bot never holds the secret.
Every major platform stores credentials centrally: credential assets in UiPath Orchestrator, the credential vault in Automation Anywhere Control Room, credential objects in SS&C Blue Prism Control Room, connections in Power Platform environments. Use it. Better still, integrate it with the organisation's enterprise secrets manager so the orchestrator fetches the value at run time and holds no secret of its own.
- The identity team creates the secret in the vault. No developer ever sees it.
- The bot refers to the secret by name only. No password sits in the project, the config or the repository.
- At run time the orchestrator retrieves the value and hands it to the robot session. Nothing is written to disk.
- Rotation happens in the vault on a schedule. The bot reads the new value on its next run. No redeployment, no change ticket.
- Every retrieval is logged, so the reviewer can see which bot read which secret and when.
Two habits undo all of this. A bot that traces the values it read has copied the secret to the log server, so mask credentials at the logging layer. And if a production credential also works from a developer's laptop, the vault has become decoration. Bind production secrets to the production runners.
MFA without workarounds.
Multi-factor authentication exists to stop exactly what an unattended bot does: log in from a machine with no person present. Programmes that fight it collect the worst findings of all, so settle it with the security team early. Three routes pass, in order of preference.
- Stop using the screen. If the target system has an API, authenticate with a client certificate, an OAuth client credential or a token issued to the service account. Interactive MFA policies no longer apply.
- Conditional exemption. Most identity platforms can exempt a named account from MFA when the login comes from a known runner, a managed device or a fixed network range. The runner itself becomes the second factor, and the exemption is recorded policy.
- Vault-held TOTP seed. Where interactive login with a one-time code is unavoidable, store the authenticator seed in the vault and generate the code at run time. This is legitimate only if the security team enrols the seed, owns it and can revoke it.
What never passes: switching MFA off for the account, keeping backup codes in a file, routing codes through a shared mailbox or a colleague's phone, or having a bot read the authenticator app on a logged-in workstation.
Walking into the review prepared.
The review goes quickly when the answers are already in the pack. For each bot, bring the service accounts and the systems each one reaches, the access matrix against the process definition document, the vault in use and who administers it, the rotation schedule, the MFA route agreed for each system, the masking rules, and the runner inventory with its network position. Make the pack a CoE template. By the tenth bot the review is a checklist.
A bot is a user the security team did not hire. Introduce it properly and it will be trusted like one.
If a bot is waiting on a security sign-off, or you want the pattern settled before the next one is built, we are glad to review the authentication design and help write the pack.