Usage-aware segregation of duties closes the audit-to-risk gap

At a glance

What this is: This is an analysis of why traditional segregation of duties controls often miss real risk and how usage-aware detection changes that model.

Why it matters: It matters because IAM, IGA, and PAM teams need controls that reflect how access is actually exercised, not just how it was provisioned.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.

👉 Read Oleria Security's analysis of usage-aware segregation of duties

Context

Segregation of duties is supposed to prevent one person from controlling both sides of a risky business process, but most programmes still rely on static entitlement checks that do not reflect how access is used in practice. In an IAM and IGA context, that creates a gap between policy compliance and real control effectiveness, especially when responsibilities shift over time and access accumulates across systems.

The article uses finance workflow examples to show why access reviews alone are not enough. If a user can create vendors in one workflow and approve payments in another, the issue is not just the permission set but whether those permissions are exercised together in a way that creates fraud risk. That is typical of mature enterprises with layered SaaS and legacy estates.

Key questions

Q: How should security teams detect segregation of duties conflicts that matter in practice?

A: They should correlate assigned entitlements with actual activity across systems, not just rely on role definitions. The most useful SoD control distinguishes a theoretical conflict from a conflict that is being exercised in a real workflow. That requires unified visibility, event telemetry, and risk thresholds tied to business processes, not abstract policy tables.

Q: Why do static SoD policies fail when business processes change?

A: Static policies age quickly because permissions, applications, and approval chains evolve faster than the policy matrix. A control written for last year’s workflow can miss a current risk or flag harmless access as a violation. The result is either blind spots or alert fatigue, neither of which protects the business.

Q: What do organisations get wrong about SoD and compliance?

A: They often treat a certified access review as proof that the risk is controlled. In reality, SoD is only effective when the organisation can show that incompatible access is not being used together in live transactions. Compliance evidence matters, but operational evidence is what prevents fraud.

Q: What should teams do when a user has both create and approve access?

A: They should assess whether both permissions are actually needed in the same role, then remove or split the conflicting access where possible. If the permissions are legitimate, they should require documented exceptions, enhanced monitoring, and clear evidence of business need. The goal is to reduce the person’s ability to complete and conceal a transaction alone.

Technical breakdown

Why entitlement-based SoD checks miss real risk

Traditional segregation of duties tools inspect assigned roles and permissions, then flag combinations that appear incompatible. That is a useful compliance control, but it is not the same as detecting operational abuse. In practice, business roles change, applications proliferate, and a conflicting entitlement can exist for months without ever being used. The result is a programme that knows what access exists but not whether the dangerous combination is active. This is why static SoD often produces noise instead of evidence.

Practical implication: teams need activity-aware control logic, not only periodic entitlement certification.

How usage-aware SoD changes the detection model

Usage-aware SoD correlates actual events across connected systems, including frequency, recency, and context of access. That matters because a permission that is never exercised is a different risk from one used repeatedly in close sequence with another conflicting entitlement. By tying identity data to observed behaviour, the control can separate theoretical exposure from active exposure. It also supports cross-application visibility, which is essential when one half of a conflict lives in finance and the other in a separate ERP or workflow system.

Practical implication: connect activity telemetry to identity records before expecting SoD alerts to be actionable.

Why continuous monitoring is the real control shift

Periodic review cycles create long blind spots because a conflicting role can be granted, retained, and exploited between audits. Continuous monitoring compresses the detection window from months to near real time and gives investigators concrete evidence about what was used, when, and how often. That changes remediation from a manual evidence-gathering exercise into a targeted response. It also gives compliance teams stronger audit artefacts because the control is based on observed behaviour rather than a point-in-time declaration.

Practical implication: retire review-only detection as the primary SoD control and use it as a backstop.

Threat narrative

Attacker objective: The attacker objective is to execute fraud by combining permissions that should never be held or used together.

1. Entry occurs when a legitimate employee accumulates two incompatible permissions through ordinary role change, not through compromise.
2. Escalation happens when the conflicting permissions are used together in a way that enables unauthorised vendor creation or approval of fraudulent payment activity.
3. Impact is the ability to complete and conceal a fraudulent transaction without a second independent control intervening.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Usage-aware segregation of duties is a control maturity issue, not just a compliance refinement. Traditional SoD programmes prove that conflicting permissions were identified at provisioning or certification time, but that does not prove the conflict was ever operationally meaningful. Once access patterns are measured in use, not just assignment, the programme becomes a risk signal instead of a paperwork exercise. Practitioners should treat SoD as a live identity control surface, not a quarterly audit artifact.

Static SoD rules create compliance theatre when business processes evolve faster than policy maps. Roles, applications, and approval chains change continuously, while SoD matrices are often frozen for long periods. That mismatch means organisations can remain technically compliant while operationally exposed. The practical conclusion is that SoD policy lifecycle management must keep pace with business change, or the control loses credibility.

Cross-system SoD conflicts are the real governance blind spot. The dangerous combination often spans multiple platforms, so a tool that only sees one application at a time will miss the control failure entirely. This is where identity governance has to move from local entitlements to enterprise process correlation. Practitioners should expect the hardest SoD cases to emerge where finance, ERP, HR, and cloud workflows intersect.

Identity blast radius is the right way to think about SoD risk. A single person with both create and approve capabilities can expand the blast radius of a routine workflow into a fraud-enabling control failure. That concept is useful because it shifts the conversation from entitlement counts to the business impact of combined access. Teams should prioritise the smallest set of permissions that can trigger the largest unreviewed transaction path.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader lifecycle lens, read Ultimate Guide to NHIs , Key Challenges and Risks for the governance patterns that keep identity controls from drifting into noise.

What this signals

Identity governance teams should expect SoD programmes to be judged on evidence quality, not policy completeness. As organisations mature, auditors and internal stakeholders will care less about whether a conflict exists on paper and more about whether the control can prove active misuse was detected quickly. The practical shift is toward telemetry-backed governance that supports both fraud prevention and audit defensibility.

Usage-aware controls will increasingly define the boundary between IGA and actual identity security. Static certification can document access, but it does not prove that conflicting access was harmless. That is why teams should align SoD telemetry with the broader identity lifecycle, especially where role changes create latent risk that review cycles miss.

With 72% of organisations already reporting or suspecting a breach of non-human identities, per the 2024 ESG Report: Managing Non-Human Identities, identity teams should assume that access drift is already normal and build controls that catch it in motion, not after the fact.

For practitioners

• Map high-risk SoD pairs across business systems Start with finance, HR, admin, and deployment workflows where a single actor could complete both sides of a critical transaction. Build the list from real process paths, not only role names, so cross-application conflicts are visible in one control model.
• Correlate permission assignment with actual usage Feed activity logs into your identity governance process so you can distinguish a theoretical conflict from a conflict that is actively exercised. Prioritise alerts where both permissions are used in the same operational window or transaction chain.
• Shorten the time between access change and review Move away from quarterly-only SoD validation for the most sensitive workflows. Use continuous monitoring for high-risk roles and reserve periodic review for lower-risk residuals, so conflicts do not persist unnoticed for months.
• Automate revocation for unused conflicting permissions If a conflicting entitlement has not been exercised for 60 to 90 days, treat it as a candidate for removal unless there is a documented business exception. That reduces review noise and removes latent exposure without harming operations.
• Retain evidence for audit and investigation Store who used the conflicting permissions, when they were used, and which business process they touched. That evidence supports both compliance reporting and incident investigation without forcing analysts to rebuild the case from scratch.

Key takeaways

• Traditional SoD checks often prove that conflicting access exists, not that it is being abused.
• Usage-aware detection turns SoD into an evidence-based control that can reduce false positives and shorten detection windows.
• The deciding factor is whether identity governance can correlate access, activity, and business process in time to stop fraud.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Usage-aware SoD: Usage-aware SoD is an identity control that evaluates whether conflicting permissions are actually used in combination, not merely assigned on paper. It reduces false positives by tying access entitlements to observed behaviour across systems, which makes the control more accurate for modern enterprises with changing roles and distributed applications.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Oleria Security's full article covers the operational detail this post intentionally leaves for the source:

• A step-by-step explanation of how usage-aware SoD detection distinguishes theoretical conflicts from active ones.
• Practical guidance on mapping cross-application SoD conflicts across ERP, finance, HR, and cloud systems.
• Implementation detail on continuous monitoring, evidence capture, and automated revocation workflows.
• Examples of how remediation decisions change when usage context is available.

👉 The full Oleria Security article covers the detection model, remediation flow, and operational trade-offs in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.