TL;DR: Segregation of duties in accounting splits invoice entry, approval, payroll, and reconciliation so one person cannot control a transaction end to end, reducing fraud, error, and reporting risk, according to SecurEnds. The same control logic now matters across human IAM, NHI governance, and delegated workflows because role boundaries fail when review, approval, and execution collapse into one identity.
At a glance
What this is: This is an explanation of segregation of duties in accounting and its central finding that separating transaction steps reduces fraud, errors, and unreviewed financial activity.
Why it matters: It matters to IAM practitioners because the same role-boundary logic underpins human access control, NHI governance, and delegated approvals where one identity should not own every step.
👉 Read SecurEnds' guide to segregation of duties in accounting
Context
Segregation of duties in accounting means splitting transaction steps so one person cannot create, approve, and reconcile the same activity. The primary security problem is concentrated authority, because the more control a single identity has over a process, the easier it is for errors or fraud to escape detection. That same governance pattern maps directly to human IAM and NHI role design.
In identity programmes, the accounting example is useful because it shows how control failure often begins as a workflow design problem rather than a technology problem. When approval and execution live in the same hands, review becomes ceremonial. The Ultimate Guide to NHIs covers the lifecycle and governance logic that helps teams separate duties across non-human identities as well as people.
Key questions
Q: How should security teams implement segregation of duties in financial workflows?
A: Start by splitting initiation, approval, and reconciliation into separate roles, then enforce those boundaries with access policy rather than manual convention. High-risk actions should require dual authorisation, and access should be reviewed after role rotation to confirm that the same identity cannot complete the full transaction path.
Q: Why does segregation of duties matter for IAM programmes beyond finance?
A: Because the core issue is concentrated authority, not accounting specifically. When one identity can both act and verify its own actions, the control loses independence. That same failure mode shows up in human access approvals, privileged workflows, and NHI governance where a single principal can own the entire process.
Q: What breaks when one person can create and approve the same transaction?
A: Independent review breaks first, followed by auditability and fraud detection. The process may still run, but it no longer provides evidence that a second control point existed. In practice, the organisation now trusts the actor to police itself, which is exactly what segregation of duties is meant to prevent.
Q: Should organisations apply SoD principles to service accounts and automation?
A: Yes, if those identities can initiate business actions with financial or operational impact. Automation does not remove the need for separation. The same identity should not both trigger and approve a sensitive workflow, and the ownership model should make human accountability and system authority clearly distinct.
Technical breakdown
Invoice entry and payment approval as a control boundary
Segregation of duties works when the person who records a transaction cannot also authorise it. In accounting terms, invoice capture, approval, disbursement, and reconciliation are separate control points that create mutual checks. If one identity can perform all four actions, the control becomes self-referential and loses evidentiary value. In IAM language, this is role design with enforced separation, not just documentation. The principle applies cleanly to service accounts and delegated workflows too, because the risk comes from collapsed authority, not the domain itself.
Practical implication: define distinct approval and execution roles and prevent the same identity from satisfying both steps in the same transaction path.
Role rotation, dual authorisation, and review cadence
The article's best-practice section points to three common enforcement patterns: rotating duties, requiring two sign-offs, and using software controls to block self-approval. Rotation reduces familiarity risk, dual authorisation creates an independent challenge, and automated enforcement stops policy from relying on memory. These are governance mechanisms, not accounting-only tactics. In identity terms, they are access review and privilege boundary controls that need consistent enforcement across people, service accounts, and any delegated system used to move money or approve records.
Practical implication: implement enforced dual control for sensitive financial actions and test that rotation actually changes who can act, not just who is assigned on paper.
Why a single identity owning the full ledger path fails
The control failure is not merely a missing check. It is a structural collapse of assurance, because the same identity can generate the event, approve it, and clear it in reconciliation. That removes the independent evidence trail that auditors and controllers depend on. In modern IAM programmes, this is the same failure mode seen when a privileged account or workflow identity can both request and approve access or changes. Once the same principal owns the whole path, accountability becomes internal rather than verifiable.
Practical implication: map every financial workflow to ensure no identity can both initiate and close the same control path.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Segregation of duties is a governance boundary, not just an accounting rule. The article describes a classic control principle: one identity should not be able to create, approve, and reconcile the same transaction. That same principle defines strong human IAM and NHI governance, because assurance disappears when a single principal can both act and validate its own action. Practitioners should treat role separation as a control architecture, not a compliance checklist.
Self-approval is the failure mode that matters most. When the same person or system can enter a record and authorise it, the review function stops being independent. That is not simply weak process hygiene, it is a broken assurance model. The implication is that identity governance must preserve challenge points that are operationally distinct from the actor performing the work.
Role rotation exposes whether separation is real or merely documented. If a programme only works when one named individual stays in one seat, the control is fragile. Rotation forces the organisation to prove that the boundary exists in process and access policy, not in custom or convenience. Practitioners should read this as a test of programme durability, not just staffing flexibility.
Dual authorisation is the closest practical analogue to privilege separation across identities. Requiring one actor to prepare and another to approve mirrors the way strong NHI and privileged access models split capability from authorisation. The lesson is broader than finance. Any workflow that moves value, changes entitlements, or clears exceptions needs independent control points to remain trustworthy.
Named concept: transaction-path concentration. The hidden risk in weak segregation of duties is that one identity accumulates every step needed to complete and conceal a transaction. That concentration makes fraud, error, and audit failure the same governance problem expressed three ways. Practitioners should identify every workflow where one principal can both initiate and close the loop.
From our research:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- That lifecycle gap is why teams should compare role separation against Ultimate Guide to NHIs , Key Challenges and Risks before they treat SoD as a documentation exercise.
What this signals
Segregation of duties should be treated as a reusable identity design pattern, not a finance-only control. As organisations spread approvals across humans, service accounts, and workflow identities, the real question becomes whether one principal can both create and validate the same action. That is the point where governance becomes performative, and the control surface should be redesigned accordingly.
Transaction-path concentration: this is the pattern teams should watch for across financial and operational systems. When one identity can move from request to approval to reconciliation without a separate challenge, the programme has collapsed control boundaries rather than enforced them. Readers building IAM and NHI programmes should use that pattern to locate hidden privilege concentration.
For practitioners
- Map transaction paths end to end Identify every step in invoice, payroll, cash handling, and reconciliation workflows, then mark where the same identity can initiate, approve, and close the loop. Remove any path where one principal can satisfy more than one control point.
- Enforce dual control on sensitive transactions Require two separate approvals for high-value or exception-based actions, and make the second approval technically independent rather than a procedural rubber stamp. Use policy checks that block self-approval.
- Rotate duties and test the boundary Move staff through approval, preparation, and review roles on a scheduled basis, then validate that access follows the role change and not the person. If rotation breaks the process, the control design is too dependent on one operator.
- Apply the same separation logic to non-human identities Review service accounts, automation accounts, and delegated workflow identities to ensure they do not both trigger and approve the same business action. Treat privileged machine accounts as part of SoD design, not as an exception to it.
Key takeaways
- Segregation of duties fails when one identity can initiate, approve, and reconcile the same transaction, because the control no longer has an independent review point.
- The scale of the NHI problem is already structural, with 97% of NHIs carrying excessive privileges, which makes role separation and approval boundaries more than an accounting concern.
- Practitioners should map transaction paths, enforce dual control, and extend the same separation logic to service accounts and automation identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Role separation supports managed access permissions and approval boundaries. |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | SoD depends on continuous authorisation boundaries between initiating and approving actors. |
| NIST SP 800-63 | Useful where human approval and authentication flows underpin financial workflow access. |
Map sensitive financial actions to PR.AC-4 and prevent any single identity from owning the full transaction path.
Key terms
- Segregation of Duties: Segregation of duties is the practice of splitting a process so one identity cannot complete every sensitive step alone. In identity governance, it preserves independent review, reduces fraud opportunity, and creates a verifiable control boundary across people, systems, and non-human identities.
- Dual Authorisation: Dual authorisation requires two separate actors to approve a sensitive action before it proceeds. It is a practical control for preventing self-approval, but it only works when the second approval is independent in both identity and authority, not just a duplicate click in the same workflow.
- Transaction Path: A transaction path is the full sequence of steps needed to create, approve, execute, and reconcile an action. It matters in governance because control failure often comes from one identity owning too many steps, which removes challenge points and makes review effectively meaningless.
Deepen your knowledge
Segregation of duties, privilege separation, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending SoD thinking into service accounts or workflow identities, it is worth exploring.
This post draws on content published by SecurEnds: segregation of duties in accounting. Read the original.
Published by the NHIMG editorial team on 2025-09-12.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org