The control breaks when one non-human identity can perform both sides of a transaction that should be separated. That collapses segregation of duties, makes exceptions harder to see and turns access into direct financial exposure. Finance, IAM and audit teams should review whether the identity path matches the business approval path.
When a Machine Identity Can Do Both Sides of the Transaction
The break is not just technical access, it is control design. If one machine identity can onboard a vendor and release payment, the same non-human actor is sitting inside both a request path and an approval path. That removes the friction that segregation of duties is meant to create, so a compromise, misuse, or bad automation rule can turn directly into financial action.
That matters because the control boundary is no longer between systems, it is inside a single identity’s effective authority. In practice, the question is whether the identity can only prepare work, or whether it can also finalise it. When those powers collapse into one account, the process can still run, but the assurance model behind it is already broken.
Why Segregation of Duties Fails Even When the Workflow Still Works
Segregation of duties is often described as a finance control, but the failure here is identity-centric. A machine identity that can both create vendors and release payments can bypass the intended separation between master data management, approval, and disbursement. That creates a control path where the same actor can introduce the payee and authorise the payout, which is exactly the combination that review and reconciliation are supposed to prevent.
This is especially dangerous in systems where automation masks the underlying authority. A workflow can look compliant because individual steps exist, but if the same credential, token, or service principal can traverse both steps, the process is effectively self-approving. The issue is not whether a human was watching the screen at the time, it is whether the identity model preserves an independent check on financial authority.
In NHI terms, the control failure is amplified when service accounts, application identities, or workload identities are reused across functions. NHIMG’s Service Account Security Guide is relevant because least privilege and ownership discipline are what stop an identity from quietly accumulating both operational and financial power. The same pattern is visible in broader NHI governance, where key NHI security challenges include overprivilege and unmanaged credentials.
What Good Control Design Looks Like for Vendor and Payment Automation
Good design separates initiation from release, even when both steps are automated. The identity that creates or updates a vendor record should not also be able to approve or transmit payment instructions. Where automation is necessary, the safer model is narrow-scoped identities with distinct permissions, explicit approval checkpoints, and clear ownership for the account that can move money.
That separation is easier to maintain when teams treat the machine identity as a governed asset rather than a background implementation detail. The identity path should mirror the business approval path: one role or service can create the vendor, another can release payment, and exceptions should be visible, reviewable, and time-bound. If the process requires a shared identity to make it work, the process is probably carrying hidden risk rather than useful efficiency.
For practitioners, the question is not only “can this automation do the job?” but “what is the smallest authority needed for each step?” NHIMG’s Human vs Non-Human Identity explainer is useful here because it highlights where human approval and machine execution should remain distinct. When the same machine identity spans both, the business process loses its independent challenge point.
Risk and Threat Considerations
When a single machine identity can both add a vendor and pay that vendor, the main risk is abuse that looks like routine automation. A compromised token, stale service account, or overprivileged workflow can create a fraudulent payee and move funds before ordinary review catches the change. The danger is not limited to external attackers, because accidental misconfiguration or internal misuse can produce the same financial exposure.
Failure mechanism: The identity has end-to-end authority across vendor setup and payment release, so there is no independent control to stop an illegitimate payee from being created and paid in the same trust chain.
Impact: Organisations can lose money, weaken audit evidence, and miss the exception because the transaction appears to have been performed by an authorised system rather than a single overextended identity.
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 SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The identity can do both vendor creation and payment release, which is overprivilege. |
| NHI-09 — NHI Reuse | A reused machine identity across finance steps collapses intended separation. | |
| Recommendation — Split the identity’s permissions so vendor setup and payment release require separate authorities. Avoid reusing one NHI across master-data and payment functions. | ||
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | The question is about one identity performing incompatible financial duties. |
| IA-5 — Authenticator Management | Machine identities rely on managed secrets or tokens that can enable dual-use access. | |
| Recommendation — Enforce separate roles for vendor maintenance and payment authorisation. Rotate and govern the credential so dual-use access cannot persist unnoticed. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of duties | The control break is the collapse of approval and execution into one identity. |
| Recommendation — Design financial workflows so setup and release remain independently controlled. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | This is an access scope problem where one identity has too much authority. |
| Recommendation — Review and reduce the identity’s access so it cannot both create and pay vendors. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Identity and access controls determine whether the machine can cross both transaction steps. |
| Recommendation — Align access decisions to the business approval path and remove excess privilege. | ||
Practitioner Guidance
What to verify: Confirm that vendor master changes and payment release are controlled by different identities, different entitlements, or different approval paths. If one machine identity can reach both, treat that as a design defect, not a convenience.
Decision rule: If the identity can create payees, it should not be able to authorise disbursement. If automation must touch both steps, require a separate approval identity or a compensating control with independent logging and review.
What practitioners underestimate: The most dangerous cases are often the ones that appear “fully automated” and therefore low touch. Automation does not reduce the need for segregation of duties, it makes the hidden authority of the identity more important to test.
Practitioner takeaway: The real test is whether the machine identity can complete a financial event without an independent control boundary. If it can, the workflow is efficient but the control is not.