RPA and Bot Identity Security Guide: UiPath and Power Automate

RPA bots log in to business applications with real accounts and passwords, often with more access than any single employee, and they are rarely owned, reviewed or offboarded like the identities they are. A robotic process automation (RPA) bot copies invoices from email into SAP, reconciles bank statements or moves records between a legacy green-screen system and a CRM. To do that it needs a Windows logon, application credentials and sometimes privileged rights, all of which sit outside the joiner-mover-leaver process. This guide covers how UiPath and Microsoft Power Automate desktop flows authenticate bots, where credentials should live, how to scope and review bot access, and what to monitor. It is written for IAM, PAM and automation centre of excellence (CoE) teams who need to bring bot accounts under the same controls as other non-human identities.

Key takeaways

• Every bot is at least two identities. There is the machine or robot identity that connects to the orchestrator, and the Windows and application accounts the bot uses to do the work. Inventory and govern both.
• Attended and unattended bots need different account models. Attended bots act as the signed-in person and should use that person's own access; unattended bots need dedicated robot accounts with no human user.
• Move off non-expiring keys. UiPath recommends OAuth client credentials with expiring tokens for unattended robots and interactive sign-in for attended ones, over legacy machine keys.
• Credentials belong in a vault, not in workflows. Both platforms integrate with external stores such as Azure Key Vault and CyberArk, and the vault should own rotation.
• Review bot access like privileged access. A bot that touches finance or HR data needs a named business owner, a technical owner and a periodic access review that covers its application roles, not just its orchestrator role.

Why RPA bots are an identity problem

RPA automates work through the user interface the way a person would. The classic case is swivel-chair work, where someone reads from one screen and types into another because the two systems have no integration. Because the bot drives the same screens, it usually needs a normal interactive user account in each target application, rather than an API credential designed for software. That creates a set of identity problems that API integrations largely avoid:

• Interactive logons for non-humans: unattended bots must open a real Windows session to drive the UI, so the bot account typically has interactive or Remote Desktop logon rights that service accounts are normally denied.
• Passwords instead of tokens: target applications such as SAP GUI, mainframe emulators or web portals are signed in to with a username and password typed by the bot, which means stored, reusable secrets.
• MFA gaps: an unattended bot cannot respond to a push prompt, so bot accounts end up excluded from MFA or Conditional Access policies. See the Conditional Access Guide.
• Aggregated access: one bot often spans several applications in one process, so its combined entitlements can break segregation of duties rules that would block a single employee, for example raising and approving a payment.
• Weak ownership: bots are often built by a business team or a contractor, and when the developer leaves the bot keeps running with its accounts. See the NHI Ownership Guide.

These traits put bot accounts in the same class as service accounts, with the added risk of interactive logon. See the Service Account Security Guide and Human vs Non-Human Identity.

Attended, unattended and browser-based bots

In UiPath, unattended robots run as a Service Mode Robot under Local System, and need machine login credentials only for foreground processes that interact with the UI. From robot version 2021.10, background processes run in Session 0 as NT AUTHORITY\LOCAL SERVICE and need no Windows credentials, which is a simple way to remove a stored password where the process does not need a screen.

In Power Automate, unattended desktop flows require the Power Automate Process plan. The service signs in through the desktop flow connection by creating an RDP session for each run, keeps the screen locked and signs out when the flow ends. The connection's account must be able to open a remote desktop session, normally through the Remote Desktop Users group, and unattended flows cannot run elevated. Browser automation and the wider governance of low-code makers are covered in the Low-Code Agent Platforms Guide and the Enterprise Browser and Browser Security Guide.

How UiPath robots authenticate

A UiPath robot has a connection identity to Orchestrator and, separately, the accounts it uses at runtime.

• Client secret handling: UiPath shows the client secret only once at provisioning. A machine object can hold several secrets, each with a Secret ID, so rotation is add new, redeploy, delete old. Deleting a secret disconnects every robot using it and halts running jobs, so schedule it.
• Robot accounts vs user accounts: UiPath advises user accounts for attended robots, because they act as real people, and robot accounts for unattended robots. Both must be added to an Orchestrator folder and granted permissions for the processes they run, which makes folders the natural boundary for least privilege.
• Machine logon credentials: the Windows username and password for unattended foreground runs are held in a credential store and sent to the robot during heartbeats. UiPath also lists HSM-backed options (Luna Credential System and nShield Key Storage Provider).
• Assets: application credentials used inside a process are stored as Credential assets (AES 256 encrypted, with values that can be hidden from RPA developers). Values can be set per account or per account-machine pair, which lets one process use a different application account per robot. Secret assets for API keys currently work with coded agents only.

How Power Automate desktop flows authenticate

• Connection types: a desktop flow connection either uses a username and password (selected from a stored credential, or typed) or uses connect with sign-in, which creates an Entra token scoped to running desktop flows. Connect with sign-in supports attended runs only; unattended runs with it fail.
• Accepted accounts: local (MACHINENAME\User), domain (DOMAIN\User) or Microsoft Entra ([email protected]). Entra certificate-based authentication with Network Level Authentication requires admin consent for the Remote Desktop app ID a4a365df-50f1-4397-bc59-1a1564b8bb9c, otherwise runs fail with MSEntraRemoteDesktopAppConsentRequired.
• Credentials feature: stored credentials can keep their secret in Azure Key Vault or, in preview, CyberArk, so the password is not held in the connection itself.
• Sharing: desktop flow connections can only be shared with service principal users, with Can use or Can edit permissions, and only when a run owner identity is set. The run owner's permissions are checked at execution and shown in run history, which gives the audit trail an accountable identity.
• Machine groups: a group password protects who can add machines; it cannot be recovered and should itself be vaulted. Group keys are protected in an AES256 PFX file; Windows Server 2016 needs the legacy 3DES setting UseLegacyPasswordProtectionForGroupKey, which Microsoft does not recommend. Where machines use local accounts, every machine in the group needs the same local account and password, which is a strong reason to use domain or Entra accounts instead.
• Who can register machines: by default, users with the Environment Maker role can register machines. Restrict this with the Desktop Flows Machine Owner, Desktop Flows Machine User and Desktop Flows Machine User Can Share roles.

Credential storage and rotation

The goal is that no human knows a production bot's password and that the vault, not the CoE, rotates it. See the Secrets Management Guide and the Privileged Access Management Guide.

• Vault authentication: the orchestrator's own credential to the vault becomes the most powerful secret in the estate. UiPath lists AppRole as the recommended method for HashiCorp Vault; for Azure Key Vault prefer a service principal or managed identity with read access to the RPA vault only.
• Default stores: in UiPath, the default credential store is set per tenant for robots and for assets, and changing it does not move existing items. Migrating to a vault means moving each robot and asset deliberately, and confirming none remain in the database store.
• Rotation without outages: bots fail at the next login if a password changes mid-run. Rotate between runs, use maintenance mode on Power Automate machine groups (new runs queue, running runs finish) and test the next scheduled run.

Scoping access and segregation of duties

• One robot account per process or process family: a single shared "rpa_svc" account used by fifty processes makes access reviews impossible and blast radius total.
• Least privilege in each application: give the bot the transaction codes or roles the process needs, not a copy of the business analyst's profile. Check combined entitlements across all target applications against SoD rules.
• Folder and environment boundaries: in UiPath, place each business area's processes, robot accounts and assets in their own folder; in Power Platform, separate development, test and production environments and restrict machine registration in production.
• Logon restrictions: limit the bot account to its RPA hosts (for example with Active Directory workstation restrictions or Conditional Access location and device conditions where the platform supports them), and deny it logon everywhere else.
• Action controls: Power Platform data loss prevention (DLP) policies classify desktop flow action groups as business, non-business or blocked, and endpoint filtering restricts which URLs browser automation and HTTP actions may reach and which processes UI automation may drive. Violating flows are suspended. Microsoft notes flows called through the Run desktop flow action are not evaluated, so test that path.
• Developer separation: RPA developers should not see production Credential asset values or hold production robot passwords. Hide asset values and give developers non-production runtimes (UiPath NonProduction or Testing).

RPA access review

An RPA access review should answer four questions per bot: is the process still running, who owns it, are its accounts and entitlements still the minimum, and are its secrets in the vault and rotated. See the Access Reviews Guide.

1. Build the inventory: export robots, machines, robot accounts and assets from Orchestrator, and machines, machine groups, connections and run owners from Power Automate. Join them to the directory accounts and application accounts each process uses. The Service Account Inventory Template works for this.
2. Attach owners: a business owner for the process outcome and a technical owner for the bot, both active employees.
3. Review entitlements in the target applications, not just the orchestrator roles, with the business owner certifying each one.
4. Retire dormant bots: processes with no successful run in 90 days, robot accounts with no logon, and connections whose creator has left.
5. Record evidence: UiPath keeps audit events searchable for at least six months and archived to 24 months, exportable as CSV; export them with the review.

How to implement

1. Discover: inventory every orchestrator tenant, Power Platform environment and RPA host, including bots run from personal desktops.
2. Set the authentication baseline: switch UiPath tenants to Interactive Sign-in for attended and Client Credentials for unattended. Use Hybrid only during migration and track remaining machine keys to zero.
3. Connect a vault in read-only mode first: point new robots and assets at the external store, migrate existing ones in batches, and confirm each batch runs before moving on.
4. Split shared accounts: create dedicated robot accounts per process family, pilot with one low-risk process, then the rest by risk tier.
5. Apply DLP and endpoint filtering in a non-production environment, then production, watching for suspended flows.
6. Enable rotation in the vault on a schedule aligned with run windows.
7. Rollback: keep the old account disabled, not deleted, for one review cycle, and keep the previous client secret until the new one is confirmed on every robot.

Detection and measurement

• Directory and host logs: bot account logons from hosts other than registered RPA machines; interactive logons to RPA hosts by humans using bot accounts; password reads from the vault outside run windows.
• Orchestrator logs: new robots, machines, credential stores or assets; changes to robot security settings; jobs started by unexpected users; Power Automate connections shared or edited.
• Application logs: bot accounts performing transactions outside their process (for example approving what they normally only create).

Common failure patterns

• Humans know the bot's password: a developer keeps the robot password to troubleshoot, or it is saved in a browser. The Okta support system breach began with a service account password saved in an employee's personal Chrome profile; a bot password handled the same way carries the same risk.
• One super-bot account: every process uses the same domain account with local admin on every RPA host and broad application roles, so compromise of one workflow exposes them all.
• Permanent MFA exclusions: bot accounts excluded from Conditional Access without compensating location or device restrictions become the easiest password-spray target in the tenant.
• Credentials in workflow files: passwords placed in config files, Excel inputs or Text assets instead of Credential assets, and copied into source control.
• Orphaned bots: the citizen developer leaves, the flow keeps running under their connection, and nobody can say what it does.
• Cloned RPA hosts: VMs cloned after installing the runtime, which Microsoft warns against for machine groups, or copied images carrying cached bot credentials.

Framework mapping

Practitioner checklist

• Inventory every bot with its orchestrator identity, Windows account and application accounts.
• Assign a business owner and a technical owner to each bot, and re-certify them every review cycle.
• Use the person's own interactive sign-in for attended bots and dedicated robot accounts for unattended bots.
• Move UiPath unattended robots to Client Credentials and retire machine keys.
• Store all bot passwords and Credential assets in an external vault that owns rotation.
• Give each process family its own robot account with least privilege in every target application.
• Restrict bot accounts to RPA hosts and compensate for any MFA exclusion with device or location conditions.
• Apply Power Platform DLP and endpoint filtering to desktop flows, and restrict who can register machines.
• Alert on bot logons from other hosts and on vault reads outside run windows.
• Disable dormant bots and connections whose creator has left.

Standards and references

• UiPath: Robot Authentication
• UiPath: Managing Credential Stores
• UiPath: About Robots
• Microsoft Learn: Desktop flow connections
• Microsoft Learn: Run unattended desktop flows
• Microsoft Learn: Manage machine groups
• Microsoft Learn: Data loss prevention for desktop flows
• OWASP: Top 10 Low-Code/No-Code Security Risks

Related NHI Mgmt Group resources: Service Account Security Guide · Low-Code Agent Platforms Guide · Secrets Management Guide · Access Reviews Guide · NHI Ownership Guide