Notifications
Clear all
Topic starter
09/07/2026 3:24 pm
TL;DR: Spreadsheet-based Segregation of Duties reviews break down when access changes continuously across multiple applications, and cross-application conflicts can remain invisible unless a tool consolidates identities, rules, exemptions, and audit history, according to Zluri. Manual review models assume access is stable long enough to reconcile, which no longer holds in SaaS-heavy environments.
NHIMG editorial — based on content published by Zluri: Security & Compliance SoD Software, a buyer's guide and vendor comparison
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.
Questions worth separating out
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.
Q: Why do spreadsheet-based SoD reviews fail at scale?
A: They fail because access changes continuously while a spreadsheet captures only a snapshot.
Q: What do teams get wrong about SoD exemptions?
A: They often treat exemptions as a convenience instead of a governed exception.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Zluri's buyer's guide to Security and Compliance SoD software →
SoD software and access conflicts: what should teams test first?
Explore further
09/07/2026 3:43 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Security and compliance SoD software: what buyers need to evaluate
