Strong IAM reduces login risk, but it usually operates at a coarse access layer. That means a user may appear properly authenticated while still holding combinations of entitlements that create SoD conflicts inside ERP, finance, or procurement systems. The risk comes from what the user can do after login, not just whether they can enter the system. Fine-grained authorization and entitlement governance are needed.
Why IAM alone does not solve SoD inside business applications
Strong IAM usually proves who the user is and whether they can enter the application, but it rarely models every business action that user can perform after login. SoD conflicts often emerge inside ERP, finance, and procurement workflows where one identity can still accumulate incompatible entitlements. The control problem is not access to the system, it is the combination of actions the system allows.
That is why organisations can have clean authentication, MFA, and even role-based access at the perimeter while still carrying toxic combinations such as request plus approve, create plus pay, or vendor setup plus bank detail change. IAM and IGA Basics is useful here because it separates authentication from authorization and shows why entitlement governance sits alongside, not inside, login control.
In practice, this gap appears when the IAM layer assigns broad application roles, but the business application enforces its own object-level and transaction-level rules. If the app is not fed with detailed entitlement data, an apparently valid user can still cross a segregation boundary. Segregation of Duties (SoD) Guide covers the conflict patterns and mitigations that business applications need when role design alone is not enough.
Where SoD risk hides after successful authentication
SoD risk is strongest in systems where work is separated across business steps but access is inherited through roles, groups, or delegated administration. ERP, procurement, treasury, and finance applications are especially sensitive because the same user may be able to create a record, approve it, and release value if entitlements are not assessed as a set. SAP Identity and Access Security Guide is a good example of how authorisation objects, firefighter access, and role design affect SoD outcomes inside a real business platform.
The risk also becomes more subtle when temporary access, emergency access, or privileged business roles are treated as operational exceptions rather than governed controls. Those exceptions may be legitimate, but they still need conflict detection, approval boundaries, and later review. Active Directory and Entra ID Hardening Guide helps on the identity side, but the SoD issue only disappears when the business application itself understands which entitlements should never be combined.
This is why the strongest IAM programme can still leave residual exposure if entitlement review stops at coarse roles. If the organisation cannot answer who can do what, in which order, and under which override path, SoD risk will persist even when account provisioning is otherwise mature.
What closes the gap between IAM and business controls
The fix is fine-grained authorization plus entitlement governance, not just stronger sign-in. Business applications need conflict rules that operate on transactions, objects, approval paths, and exception access, while the IAM or IGA layer needs to continuously recertify those entitlements against job function and process design. Identity Security Programme Guide is relevant because SoD usually fails when ownership of access, process ownership, and governance ownership are split across teams without a single operating model.
For broader governance, the right question is whether the organisation can detect toxic combinations before they are granted, not only after an audit finds them. That means modelling SoD rulesets, mapping entitlements to business capabilities, and treating compensating controls as exceptions that need evidence. Top 10 NHI Issues also reinforces the same governance pattern at scale, because entitlement drift and excessive permissions create the same kind of downstream control failure in non-human access.
Where the application stack is cloud-hosted or integrated with multiple control planes, privilege creep can also arrive through adjacent systems rather than the main business app. Cloud PAM and CIEM Guide shows the value of right-sizing effective permissions, which is the same practical logic SoD needs inside enterprise apps: don’t just grant access, prove that the granted combination is safe.
Risk and Threat Considerations
SoD failures matter because they create a fraud and abuse path that authentication alone does not block. An attacker, insider, or overentitled user does not need to bypass login if the application already allows contradictory powers to coexist, especially in procure-to-pay and payment workflows.
Failure mechanism: The IAM layer confirms identity and grants a role, but the application does not evaluate the full entitlement set for incompatible action combinations, so a user can perform both sides of a controlled process.
Impact: The result can be unauthorized payment release, vendor manipulation, false approvals, concealment of activity, or a control failure that looks like legitimate use until reconciliation or audit review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SoD depends on limiting users to only the business actions they need. |
| IA-2 — Identification and Authentication (Organizational Users) | IAM reduces login risk but does not by itself prevent SoD conflicts. | |
| AC-5 — Separation of Duties | Directly addresses incompatible duties inside enterprise workflows and applications. | |
| Recommendation — Apply AC-6 to restrict users to the minimum entitlements needed for their job. Use IA-2 to authenticate users, then enforce SoD through authorization controls. Implement AC-5 to separate conflicting actions across approval and execution paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | SoD depends on governing accounts, roles, and entitlement changes over time. |
| Recommendation — Review account and entitlement assignments regularly to prevent conflicting access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must extend beyond sign-in into business application authorization. |
| Recommendation — Define and enforce access control rules that cover application actions, not just login. | ||
Practitioner Guidance
What to verify: Check whether your SoD rules are defined at the business-action level, not only at the role level. If your conflict model cannot distinguish create, approve, amend, and release functions, it is too coarse to protect ERP or finance workflows.
Decision rule: If a user can hold two entitlements that become dangerous only when combined, treat the app as the enforcement point and IAM as the feeder, not the final control. If the application cannot enforce the combination, add compensating review, workflow separation, or explicit exception handling before expanding access.
Practitioner takeaway: Strong IAM is necessary, but SoD is a business-logic control problem, so the real test is whether your entitlement model can see incompatible combinations after login, not just whether the user authenticated successfully.
Related resources from NHI Mgmt Group
- Why do strong IAM controls still leave organisations exposed to audit and fraud risk?
- When does a short-lived API key still create material risk?
- How should security teams implement segregation of duties across multiple business applications?
- Why do IAM tools still leave access risk behind after offboarding?