They create risk because the policy decision and the actual identity change are separated by tickets, scripts or browser automation, which makes fulfilment failure and delayed reconciliation more likely. That gap weakens evidence quality and leaves programmes dependent on people or bots behaving consistently.
Why the governance problem is not the automation itself, but the handoff gap
Manual fulfilment and RPA both split the governance event into two separate moments: a policy decision is made first, then some later action changes the identity or access state. That split creates room for delay, missed execution, inconsistent evidence, and exceptions that are hard to reconcile after the fact. The risk grows when approvals, scripts, and browser steps are treated as equivalent to a controlled fulfilment system.
When the fulfilment path is not directly coupled to the control decision, teams lose a clean line of sight from request to change. The result is weaker auditability, more reliance on human follow-through, and a higher chance that access remains active longer than intended or is granted in a different form than was approved.
RPA can improve throughput, but it does not remove the governance burden. It only relocates it to script ownership, credential handling, exception handling, and reconciliation. NIST Cybersecurity Framework 2.0 is relevant here because the control question is not whether work gets done, but whether the change is governed, observable, and recoverable.
Where manual fulfilment and RPA fail operationally
Manual fulfilment usually fails at consistency. Different operators interpret the same ticket differently, apply steps in the wrong order, or miss a required approval, and the evidence trail becomes fragmented across emails, tickets, screenshots, and spreadsheets. RPA fails differently: it can be consistent while the underlying target system changes, the bot credential expires, a page layout shifts, or an exception path is not covered.
The common failure mode is delayed reconciliation. The request may be approved, but the actual change is not verified immediately, so the organisation cannot reliably tell whether the access state matches the intent state. That is why fulfilment quality depends as much on post-change validation as on the initial decision.
Both approaches also concentrate operational knowledge in a few people or bots. If the process owner leaves, the bot breaks, or the fallback manual path is undocumented, the organisation inherits hidden dependency risk rather than control maturity.
NIST SP 800-53 Rev. 5 Security and Privacy Controls fits this problem because fulfilment needs both access control discipline and audit evidence, not just task completion. OWASP Non-Human Identities Top 10 is also relevant where the bot itself uses credentials, because the fulfilment mechanism then becomes part of the identity and privilege model.
What good governance looks like when change is executed by people or bots
Good governance keeps the approval, execution, and verification steps close together. The approver should know what state change is expected, the fulfiller should have a bounded method to make that change, and the verifier should be able to confirm the result without relying on informal reassurance. When a process uses RPA, the bot should be owned like any other privileged operational actor: its credentials, scope, exceptions, and logs must be governed explicitly.
The practical test is simple: can you prove who decided, what was supposed to change, what actually changed, and when the system was reconciled? If that answer depends on hunting through screenshots or ticket notes, the governance model is too loose for the risk being carried.
For programmes with recurring access or entitlement changes, the stronger pattern is to standardise fulfilment around controlled workflows and verification points, then reserve manual intervention for exceptions only. That reduces the number of places where human inconsistency or bot fragility can create a gap between policy and reality.
Risk and Threat Considerations
Manual fulfilment and RPA create a security exposure because they often leave a window where the organisation believes a control has been executed even though the underlying identity state has not been updated, or has not been validated. That gap is especially dangerous for access changes, removals, and time-bound exceptions, where stale access can persist unnoticed.
Failure mechanism: The request, the execution, and the evidence are separated, so reconciliation becomes a later administrative activity instead of an immediate control check. In RPA, the same weakness appears when a script depends on stable screens, static credentials, or unmonitored exceptions.
Impact: Delayed deprovisioning, incorrect entitlement states, weak audit evidence, and greater exposure to misuse of standing access or abandoned exceptions. Over time, the organisation also becomes dependent on individuals or bots whose failure can silently break governance.
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 addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Manual and RPA fulfilment must fit the organisation's governance and control model. |
| GV.OV-01 — Oversight | The question is about governance risk from weak oversight of execution and reconciliation. | |
| Recommendation — Define fulfilment ownership and control boundaries before allowing manual or automated identity changes. Require oversight that proves approved changes were actually completed and reconciled. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Evidence quality and traceability are central to fulfilment governance risk. |
| AC-6 — Least Privilege | RPA and manual fulfils often use privileged access that should be tightly scoped. | |
| Recommendation — Log fulfilment actions and reconciliation checks so execution can be independently verified. Limit fulfilment actors to the minimum access needed for the change they execute. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | RPA bots commonly operate as non-human actors with excessive access. |
| NHI-07 — Long-Lived Secrets | RPA workflows often depend on stored credentials that increase governance exposure. | |
| Recommendation — Reduce bot privilege to the smallest scope needed for fulfilment and review it regularly. Rotate and shorten credential lifetime for automated fulfilment paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Fulfilment changes account state, so account governance is directly implicated. |
| Recommendation — Centralise account change handling and verify that approved changes were applied as intended. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is governed access change execution and verification. |
| Recommendation — Apply controlled access-change procedures with clear approval and verification steps. | ||
Practitioner Guidance
What to prioritise: Treat fulfilment latency and reconciliation lag as governance metrics, not just operational inconvenience. If approval and change are separated, the control objective should be immediate verification that the target state matches the approved state.
What to verify: For every manual or automated fulfilment path, verify ownership of the fulfiller, the rollback path, the evidence produced, and the control that detects missed execution. For RPA, also verify credential scope and expiry handling.
Common mistake: Assuming that automation equals control. A bot that completes steps reliably but cannot prove the final state has improved throughput, not governance.
Practitioner takeaway: The key decision is whether the fulfilment process can prove completion and reconcile quickly; if it cannot, you are managing operational convenience rather than governed identity change.