Treat both as non-human identities with named owners, scoped privileges, rotation requirements, and offboarding triggers. The practical test is whether the credential behind the automation can be reviewed and revoked independently of the business process it supports. If not, the organisation has automation without governance, which is a control gap rather than an efficiency gain.
Why This Matters for Security Teams
RPA bots and workflow connectors are often treated as plumbing, but they function as non-human identities with the power to read data, trigger transactions, and chain into downstream systems. That makes them governance objects, not just automation assets. The control question is whether each bot or connector has a named owner, a reviewable entitlement set, and a revocation path that does not depend on the business process staying alive.
This matters because automation usually spreads faster than identity governance. Once a connector is embedded in a ticketing flow, finance approval chain, or customer onboarding workflow, teams tend to leave credentials untouched to avoid disruption. NHI Management Group notes in Ultimate Guide to NHIs that only 20% of organisations have formal offboarding and revocation processes for API keys, and 71% of NHIs are not rotated within recommended time frames. The same pattern shows up in broader governance gaps in the Top 10 NHI Issues.
In practice, many security teams discover a forgotten bot account only after an audit finding, a credential leak, or an automation failure has already exposed the gap.
How It Works in Practice
The practical model is to govern bots and connectors like any other non-human identity, but with tighter lifecycle controls. Start by inventorying every automation account, service principal, API token, and integration credential, then map each one to a business owner and a technical custodian. That ownership should include approval authority, expected use, rotation cadence, logging requirements, and a hard offboarding trigger when the workflow is retired or the vendor relationship changes.
Security teams should prefer short-lived access where the platform allows it. For example, a workflow connector that supports OAuth, workload identity, or ephemeral token exchange is easier to govern than one built on a shared static password. When static secrets are unavoidable, they should live in a secrets manager, not in code, config files, or CI/CD variables. The broader problem is visibility: NHI Management Group’s Regulatory and Audit Perspectives guidance highlights how incomplete inventory and weak revocation make audits fail even when the automation still “works.”
Use the same control logic already established in NIST Cybersecurity Framework 2.0: identify the identity, protect the credential, detect abnormal use, and respond quickly when the workflow changes. The operational test is simple: if a bot can be paused, rotated, or revoked without breaking unrelated business processes, governance is probably in place.
- Assign a named owner and backup owner for every bot and connector.
- Separate process ownership from credential ownership.
- Rotate secrets on a defined schedule and after any vendor, code, or permission change.
- Log every action with enough context to distinguish normal workflow activity from misuse.
- Revoke access automatically when the business use case ends.
These controls tend to break down in legacy RPA platforms and tightly coupled ERP integrations because one shared credential often supports multiple workflows that cannot be individually revoked.
Common Variations and Edge Cases
Tighter bot governance often increases operational overhead, so organisations have to balance speed of automation against revocation and review discipline. That tradeoff is most visible when one connector serves many departments, or when an external SaaS integration is owned by the business but administered by IT.
Current guidance suggests separate identities for separate business functions, but there is no universal standard for how granular that separation must be. In low-risk internal automations, a shared service account may be acceptable if the account is tightly scoped, heavily monitored, and rotated reliably. In customer-facing or finance-adjacent workflows, best practice is evolving toward more granular workload identities, JIT access, and policy-based approval at runtime rather than standing permissions.
Another edge case is attended RPA, where a bot acts under a human session. Even there, the bot’s technical identity still needs governance because it can outlive the user session or retain elevated permissions. External vendors can add further complexity, especially when connector credentials are managed outside the enterprise boundary. In those cases, security teams should require documented ownership, evidence of rotation, and a clean offboarding path before approving the integration.
Where organisations lose control is when automation is treated as a process exception instead of an identity class, especially in environments with shared credentials and no independent revocation path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers credential rotation and lifecycle control for bot and connector identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and entitlement review fit bot governance directly. |
| NIST AI RMF | Governance of autonomous workflow behavior aligns with AI risk management accountability. |
Assign clear accountability for automation outcomes and monitor identity-driven risk throughout the lifecycle.
