Security and compliance SoD software: what buyers need to evaluate

At a glance

What this is: This buyer's guide explains how Segregation of Duties software should detect conflicting access across applications, identities, and policy states.

Why it matters: It matters because IAM, IGA, and audit teams need evidence-grade SoD controls that survive cross-app sprawl, exceptions, and remediation without relying on spreadsheets.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Zluri's buyer's guide to Security and Compliance SoD software

Context

Segregation of Duties software exists to stop one identity from holding conflicting permissions that should never coexist in the same business process. In a SaaS-heavy environment, those conflicts are rarely confined to a single application, which is why spreadsheet-based reviews miss the real risk surface.

This article is really about what happens when SoD governance collides with scale, distributed entitlements, and incomplete visibility across identity systems. The core issue is not whether conflicts exist, but whether a programme can detect and prove them consistently enough for audit and remediation.

For teams evaluating controls through a broader identity lens, the key shift is from periodic review to continuous conflict detection. That aligns SoD more closely with IGA, access lifecycle governance, and evidence quality than with point-in-time certification alone.

Key questions

Q: How should security teams evaluate SoD software for cross-application conflicts?

A: Start by testing whether the platform can detect one toxic combination split across different applications and still surface it as a single violation. If the tool needs manual cross-referencing to spot the conflict, it is not giving you true SoD coverage. Use real ERP, finance, and SaaS examples from your own environment.

Q: Why do spreadsheet-based SoD reviews fail at scale?

A: They fail because access changes continuously while a spreadsheet captures only a snapshot. Once conflicting entitlements live in different systems, the manual reconciliation workload grows faster than the review process can keep up. The result is stale evidence, missed conflicts, and controls that are hard to defend in audit.

Q: What do teams get wrong about SoD exemptions?

A: They often treat exemptions as a convenience instead of a governed exception. A valid exemption needs a reason, a clear expiry, and a process that forces re-review. Without those boundaries, temporary exceptions turn into permanent control gaps that nobody owns.

Q: Who is accountable when SoD violations are not remediated?

A: Accountability should sit with the business owner or control owner who can approve, revoke, or justify the exception, not with the tool itself. The platform can detect and document violations, but the organisation remains responsible for remediation, evidence retention, and follow-up when exceptions expire.

Technical breakdown

Why spreadsheet-based SoD reviews fail across SaaS applications

Manual SoD processes depend on a static snapshot, usually a spreadsheet cross-checked against exported access reports. That model breaks when the conflicting entitlements live in different systems, because each admin console only sees its own application. Once access changes faster than the review cadence, the conflict matrix becomes stale before it is used. The problem is not just scale. It is fragmentation across cloud, ERP, finance, and identity platforms, where no single tool has native visibility into the full toxic combination.

Practical implication: replace spreadsheet reconciliation with cross-application conflict detection tied to the live identity record.

Identity-centric violation detection versus account-centric reporting

Account-centric SoD logic flags conflicts per login or per system account, which can split one person's risk into several disconnected findings. Identity-centric detection consolidates all linked accounts into a single violation so the programme can see the person, the conflicting entitlements, and the supporting systems together. That distinction matters in environments with multiple roles, multiple directories, and multiple application identities, because compliance evidence needs to map back to one accountable subject rather than a pile of account-level alerts.

Practical implication: normalise SoD findings to the person or primary identity before you judge remediation priority.

Why simulation, exemptions, and audit snapshots matter for control assurance

SoD controls are only defensible when teams can test them before enforcement, justify exceptions with expiry dates, and reconstruct what the policy looked like at a prior point in time. Simulation shows whether a rule will explode into noise or catch real conflicts. Exemptions prevent business interruptions, but only if they expire and are re-evaluated. Versioned audit snapshots turn the control into evidence, which is what auditors need when they ask not just what the rule is today, but what it was when the decision was made.

Practical implication: require pre-enforcement simulation, time-bound exemptions, and immutable policy version history as baseline control features.

Threat narrative

Attacker objective: The objective is to exploit conflicting access to approve or move business value without an effective control challenge.

1. Entry occurs when conflicting entitlement paths are spread across multiple applications and a manual review misses the toxic combination.
2. Escalation follows when a single identity retains mutually incompatible access long enough to approve, create, or move value through the process.
3. Impact is realised when the organisation cannot demonstrate effective SoD enforcement, leaving fraud, error, or audit failure uncontained.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Cross-application conflict detection is the real SoD test, not report generation. A tool that only inspects one system at a time simply cannot see the toxic pair when one entitlement lives in ERP and the other in finance, cloud, or CI/CD. That makes the control logically incomplete, not merely operationally weak. Practitioners should treat cross-application visibility as the minimum threshold for credible SoD governance.

Identity-centric SoD is stronger than account-centric SoD because accountability lives at the person level. If a programme fragments the same individual across multiple accounts, it also fragments the violation, the remediation path, and the audit trail. The result is weaker evidence and slower containment. SoD should be tied to the identity that exercises the privilege, not to whichever account happened to trigger the alert.

Simulation plus expiry-based exemptions define whether SoD is a control or a paperwork exercise. Without pre-enforcement testing, teams discover policy noise only after rollout. Without expiry, exceptions become permanent holes in the control surface. The control standard is not detection alone, but detection with bounded deviation and reproducible proof.

Audit-grade SoD now sits inside broader identity governance, not beside it. The article shows why remediation, entitlement mapping, and evidence capture all need to share the same governance substrate. When SoD is isolated, organisations duplicate integration work and weaken lineage. Practitioners should evaluate SoD as part of the full identity lifecycle and control evidence chain.

Named concept: policy drift between review cycles. SoD programmes built on periodic checks assume the underlying access graph stays stable long enough to be reviewed, certified, and remediated. That assumption fails when entitlements change continuously across multiple applications and exemptions can outlive the policy intent. The implication is that governance must be measured against live state, not historical review cadence.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• For a broader control baseline, see NHI Lifecycle Management Guide for how lifecycle governance and revocation discipline support evidence-quality access control.

What this signals

Policy drift between review cycles: SoD programmes that still rely on periodic export-and-reconcile workflows will keep missing conflicts that emerge and disappear between reviews. The practical shift is toward live entitlement evaluation, because the evidence trail must reflect current access state rather than a past snapshot. Teams that still run manual reconciliation should expect audit pressure to rise as application sprawl increases.

The strongest programmes will treat SoD as part of the identity lifecycle, not as a separate compliance island. That means policy authoring, exemption governance, remediation, and audit evidence all need one shared control model. For teams already modernising access governance, this is also where [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) becomes useful as a structure for governance, protection, detection, and response mapping.

Cross-application SoD also exposes how poorly many identity stacks describe accountability across systems. If the control cannot say who owns the conflict, who approved the exception, and what version of the rule was active, it will not scale well through audit or incident review. That is why SoD maturity is now a governance question, not just a feature comparison.

For practitioners

• Test cross-application detection before shortlisting any SoD tool Build three or four real toxic combinations that span separate applications, then verify the tool can identify them as one violation in the live identity record. A single-app demo is not enough. Use at least one conflict that crosses ERP, finance, and a cloud or SaaS system to expose visibility gaps.
• Require identity-centric violations in your evaluation criteria Check whether the platform consolidates all linked accounts into one finding tied to the person or primary identity. If it only reports by account, remediation and audit evidence will fragment. Ask for a sample violation output that shows the identity plus all offending accounts together.
• Validate monitor mode and full-scope simulation Run new policies in monitor mode first, then compare a quick single-identity check with a full-scope dry run before enabling enforcement. This helps you see false positives, rule overlap, and alert volume before the control starts revoking access.
• Make exemptions time-bound and reviewable Require every exemption to carry a documented reason, an expiry date, and an owner who must re-evaluate it before renewal. If the system cannot reopen the violation automatically when the exemption ends, the exception process is too weak for audit use.
• Demand versioned policy snapshots for audit evidence Confirm the platform stores a full configuration snapshot each time a policy is published, not just a timestamp or change log. Auditors need to see exactly what the rule looked like on the day the decision was made.

Key takeaways

• SoD software is only credible when it can detect toxic access combinations across applications, not just inside one system.
• Identity-centric violations, time-bound exemptions, and policy snapshots are the difference between usable control evidence and fragmented reporting.
• The governance model is shifting from spreadsheet review to live, lifecycle-linked conflict management across the identity stack.

Key terms

• Segregation of Duties: Segregation of Duties is an access control principle that prevents one identity from holding conflicting permissions that could enable fraud, error, or unapproved change. In practice, it requires organisations to define incompatible entitlements, detect overlaps across systems, and prove that exceptions are bounded and reviewed.
• Identity-centric violation: An identity-centric violation is a SoD finding tied to the person or primary identity rather than to one isolated account. This matters because many users hold multiple accounts across applications, and only identity-level consolidation shows the full conflict set, the accountable subject, and the remediation path clearly.
• Policy simulation: Policy simulation is a pre-enforcement test that runs an SoD rule against live or representative access data before the rule is turned on. It helps teams estimate violation volume, spot false positives, and tune the policy before it disrupts operations or creates unusable alert noise.
• Time-bound exemption: A time-bound exemption is a documented exception to an access control rule that expires automatically unless it is renewed through review. It keeps temporary business allowances from becoming permanent control gaps and gives auditors a clear boundary for why the conflict was tolerated.

What's in the full article

Zluri's full guide covers the operational detail this post intentionally leaves for the source:

• Side-by-side vendor comparison table with the specific SoD capabilities buyers are likely to test in demos
• Platform-specific implementation notes on cross-application detection, exemptions, and remediation modes
• Pricing and total cost of ownership guidance for enterprise IGA and SaaS-native buyers
• Examples of how Zluri structures SoD policies, simulations, and enforcement workflows

👉 Zluri's full guide covers the vendor comparison, implementation details, and pricing considerations in more depth.

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.