Blue Prism Security: Protecting Digital Workers, Credentials and Server Keys

Every Blue Prism digital worker logs on to Windows and business applications with real credentials, so the way those credentials, encryption keys, roles and runtime resources are configured decides how far an automation estate can be trusted. This guide covers the customer side of SS&C Blue Prism Enterprise security: user authentication and roles, the Credential Manager, encryption schemes and where their keys live, runtime resource start-up options, Login Agent, network encryption between components and the audit log. It is written for RPA platform owners, Blue Prism administrators and the security and identity teams who approve automation. For the identity principles behind bots in general, see the RPA and Bot Identity Security Guide.

This is an independent guide from NHI Mgmt Group, based on SS&C Blue Prism's public documentation as of November 2026. It is not sponsored or reviewed by SS&C Blue Prism. Product features change, so confirm settings against SS&C Blue Prism's current documentation.

Key takeaways

• Make Active Directory the standard sign-on. Blue Prism's guidance is that Active Directory should be the standard authentication option, with native authentication kept for a tightly restricted super administrator used to fix directory issues.
• Grant credentials to Security Roles. Credential Manager access rights by Security Role are the recommended model; the Processes and Resources options are legacy and not recommended.
• Keep encryption keys on the application servers. Store encryption scheme keys in the server key store rather than the database, use AES-256 schemes, and retire Triple DES schemes.
• Run runtime resources privately and encrypted. Start them with /sso rather than /user, avoid /public unless every Blue Prism user should control the resource, and enable /sslcert on the instructional port.
• Watch the audit codes that matter. Credential changes (A001 to A004), role and permission changes (S003, U006, U028), sign-on settings (S004, S006) and encryption scheme changes (K001 to K004) belong in your SIEM.

How identity and access work in Blue Prism

A Blue Prism estate carries three layers of identity, and each needs its own owner:

Blue Prism's infrastructure guidance adds two principles worth adopting as policy: user access is role based and configured independently for each environment, so no single user automatically holds rights across development, test and production; and target application credentials are stored centrally, separate from process definitions, with access restricted to specific runtime resources, processes and users.

Sign-on settings

• Active Directory authentication: enabled by an administrator who is a member of the domain. With Manage role membership in Active Directory selected, AD security groups are added to Blue Prism roles, so joiners and leavers follow directory group changes.
• Authentication Server: the component needed from version 7.0 for the Blue Prism API and browser-based Control Room; when enabled, users sign in with Sign in using Authentication Server.
• Native password rules: where native accounts remain, set a minimum length, character requirements, reuse limits by count and days, and an account lockout after failed attempts (only an administrator can unlock). Turn off Password controls allow pasted passwords only if your policy requires it, since password managers rely on pasting.
• Login screen: keep the default blank username field rather than showing a list of users.

Admin roles and privileged access

Roles are managed in System Manager under Security - User Roles, which itself is a permission to protect. The System Administrator role cannot be edited or deleted, at least one System Administrator must always exist, and only System Administrators can assign it. Role changes apply when the affected user next logs in.

Keep developers out of production credential management, and make production releases go through import by a separate role so no single person both writes and deploys a process that uses a sensitive credential. Treat the Windows administrators of application servers as privileged too: they can reach the server key store. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Credential Manager

Credentials are maintained under System Manager, Security, Credentials, where you can create, edit, delete and use Find References to see which processes use a credential. Types include General, Basic Authentication, OAuth 2.0 (Client Credentials), OAuth 2.0 (JWT Bearer Token), Bearer Token and Data Gateways Credential.

Role-based access does not apply to anonymous public runtime resources, which is a further reason to start resources under a named identity. Follow Blue Prism's account guidance: one target application account per runtime resource that connects concurrently, shared accounts only where unavoidable, and processes that change application passwords on a schedule so no human needs to know them. For OAuth client secrets and bearer tokens, record the issuing system, scopes and expiry outside Blue Prism and rotate at source. The Secrets Management Guide covers rotation patterns.

Runtime resource and service accounts

• Windows accounts: give each digital worker its own domain account, no interactive use by people, and only the rights its target applications need. Blue Prism notes that elevated permissions can change how target applications behave, so match the resource's rights to the target's user context rather than granting local administrator.
• Password resets: Blue Prism can manage runtime resource credentials automatically, including periodic resets that follow complexity and history policies; use it so worker passwords rotate without manual handling.
• Login Agent service: runs under the Login Agent Windows service context; for /sso, configure that service with a service account that has appropriate Blue Prism access. Store the Windows login credential in Credential Manager using the Windows Login: {0} format, where {0} becomes the machine name.
• Configuration files: LoginAgentService.config under C:\ProgramData\Blue Prism Limited\Automate V3 holds start-up arguments. Prefer /sso to /user, and use Windows integrated database authentication rather than setdbpassword, so no password sits in the file; restrict the folder to administrators and the service account.

The general lifecycle for these accounts is in the Service Account Security Guide.

Encryption schemes and keys

Encryption schemes, under System, Security, Encryption Schemes, set the algorithm and key location for sensitive data written to the database: credentials (always encrypted), resource screen captures (default scheme) and work queues configured with a key.

Rotating and retiring keys

Data is always read with the scheme that wrote it, and a change applies only to new data. To change keys, create a new scheme, point the Credential Manager and queues at it, then retire the old one: confirm it is not the default or assigned to a queue, deselect Available, run the re-encrypt command line option to confirm nothing still uses it, delete it, and remove the key from every server key store. Watch for schemes marked Unresolved Key, which means a server cannot find the key. Back up the server key stores securely, because losing them makes encrypted data unreadable. See the Encryption Key Compromise Playbook for response steps if a key is exposed.

Network encryption between components

Use the same /port on all resources unless there is a reason not to, and firewall the instructional port so only application servers and controllers can reach it. Use /local for resources that should be controllable only from the machine itself.

Logging and detection

The audit log, viewed and exported from System, Audit - Audit Logs, codes each event by area. Session logs are exported from System, Audit - Process Logs. Export or forward both on a schedule so investigations do not depend on the Blue Prism database alone.

Correlate these with Windows logon events for runtime resource accounts and with the target applications' own logs, since a digital worker's activity is spread across all three. Detection patterns for bot accounts are in the RPA and Bot Identity Security Guide.

Metrics to track: percentage of credentials using Security Role access rights; number of schemes with database-held keys or Triple DES; percentage of runtime resources started with /sslcert and /sso; native Blue Prism accounts other than break glass; days since last rotation for each target application credential; and audit events from the table above reviewed within one business day.

Hardening baseline

1. Inventory. List environments, users and roles, System Administrators, credentials with their access rights and Find References results, encryption schemes and key locations, runtime resources with start-up parameters, and Login Agent configurations.
2. Move sign-on to Active Directory. Enable AD authentication, map AD groups to roles per environment, and keep one native super administrator in a vault. Pilot with a development environment first.
3. Re-scope credentials. Create Security Roles for credential access, move each credential off the legacy Processes and Resources options, and confirm processes still run in test before changing production.
4. Fix encryption. Create AES-256 schemes with keys on the application servers, point credentials and queues to them, re-encrypt, then retire old schemes using the documented steps. Back up the server key stores.
5. Harden runtime resources. Use dedicated Windows accounts, /sso, /sslcert, a consistent /port, firewall rules and /local where appropriate; remove /public unless it is a deliberate decision.
6. Secure Login Agent. Run it under a service account, store Windows Login credentials in Credential Manager, enable sslcert after testing, and remove passwords from the configuration file.
7. Forward the audit log. Export or stream audit and session logs to the SIEM and alert on the codes above.
8. Maintain. Apply SS&C Blue Prism releases and security updates promptly, and review roles, credentials and schemes quarterly. Roll back a change by restoring the previous role, credential access rights or start-up parameters recorded during inventory.

Framework mapping

Common misconfigurations

• Credentials scoped to processes or resources. The legacy models are harder to review; move access rights to Security Roles.
• Keys stored in the database. A database backup then carries both ciphertext and key. Hold keys in the application server key store.
• Triple DES schemes left in use. Re-encrypt to an AES-256 scheme and retire the old one.
• Public runtime resources by habit. /public lets every Blue Prism user control the resource and sits outside role-based credential checks. Use named resources.
• Passwords in start-up arguments. /user and setdbpassword values in shortcuts or LoginAgentService.config can be read by anyone with file access. Use /sso and integrated authentication.
• One account for many digital workers. Shared accounts block rotation and attribution; give each concurrent worker its own account, as Blue Prism's guidance describes.

Practitioner checklist

• Make Active Directory the standard sign-on and keep one vaulted native super administrator.
• Configure roles per environment and limit System Administrator to named owners.
• Set every credential's access rights to Security Roles and review Find References quarterly.
• Use AES-256 encryption schemes with keys on the application servers and back up the key stores.
• Encrypt work queues that hold personal or financial data.
• Give each runtime resource its own Windows account without local administrator rights.
• Start runtime resources with /sso and /sslcert, and avoid /public unless deliberately approved.
• Run Login Agent under a service account with no passwords in its configuration file.
• Forward audit and session logs to the SIEM and alert on credential, role, sign-on and key events.
• Apply Blue Prism updates promptly and rotate target application credentials on a schedule.

Standards and references

• SS&C Blue Prism: User accounts, remote access, and security
• SS&C Blue Prism: Credential manager
• SS&C Blue Prism: Encryption schemes
• SS&C Blue Prism: Blue Prism roles
• SS&C Blue Prism: Sign-on settings
• SS&C Blue Prism: Command line options
• SS&C Blue Prism: Audit actions and events
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: RPA and Bot Identity Security Guide · Service Account Security Guide · Secrets Management Guide · Privileged Access Management Guide