Toxic Combinations, Handled: Enforcing Segregation of Duties Across Systems with MidPoint

This article was written by our Gold implementation partner, AMI Praha, as part of our MidPoint in Practice series, where partners share real-world implementation stories highlighting how they solve identity governance challenges with midPoint.

What Is Segregation of Duties (SoD)?

Segregation of Duties (SoD) is one of the most important controls in identity governance and administration (IGA). It prevents users from accumulating combinations of permissions that could enable fraud or abuse of power, and it’s a core component of any effective risk management strategy.

Certain powerful capabilities must never rest in the same pair of hands – being able to create a vendor and approve a payment, or to post a journal entry and approve it – these two examples are classic fraud risks. These “toxic combinations” are common audit findings and are addressed directly by compliance frameworks such as ISO/IEC 27001 (Control 5.3).

Many enterprise applications can enforce SoD within their own environment. But today’s organizations run on multiple interconnected systems, and a user may pick up one sensitive entitlement in one application and another in a line-of-business system, creating a risky combination that no single application can detect on its own.

This is where identity governance becomes essential. Because midPoint serves as a central identity governance and administration platform, it has a complete view of a user’s assignments and can enforce cross-system SoD policies before risky access is granted.

In this implementation story, AMI Praha explains how a regulated financial institution in Central Europe used midPoint to move from manual, detective controls to automated, preventive access governance.

The Challenge: Enforcing Segregation of Duties Across Multiple Systems

The organization uses midPoint as its central IGA platform, granting access through a role model (a structure where access rights are bundled into named roles, then assigned to users, rather than granted permission-by-permission) that spans several connected systems – an SAP ABAP back end, Active Directory, an LDAP directory, and a core line-of-business application – all fed from an authoritative HR source.

Although SoD was already being checked within individual systems, most notably inside SAP, the organization faced a common identity governance challenge: no single application had visibility into a user’s complete access profile. As a result, toxic combinations spanning multiple systems could slip through undetected.

At the same time, enforcement relied heavily on manual spreadsheets and periodic audits. Violations were discovered only after access had already been granted, rather than prevented at the point of request – creating real exposure windows, repetitive analyst effort, and audit findings that were expensive to remediate after the fact.

To complicate matters further, years of accumulated role assignments meant SoD conflicts already existed throughout the environment. A “just turn it on” approach wasn’t an option: enabling strict enforcement overnight would have disrupted business operations and generated a flood of errors. The organization needed a solution that strengthened governance and compliance without interrupting day-to-day work.

How MidPoint Enforced Cross-System Segregation of Duties

AMI Praha implemented SoD natively in midPoint using policy rules with exclusion constraints, and, critically, rolled it out gradually. A few properties of midPoint’s model made this approach clean to implement:

• Exclusion is declarative and bi-directional. Administrators state, on one role, that it excludes another via a targetRef. MidPoint treats the exclusion as mutual regardless of which role is assigned first or second, so each conflicting pair is defined once, not twice, which keeps the policy set simpler to maintain long-term.

• The enforcement action is separate from the constraint. The same exclusion can be attached to different policy actions depending on how strict the situation calls for:
  • enforcement – a hard block; the conflicting assignment is rejected with an error.
  • approval – the request is routed to a designated approver, who can grant a documented, auditable exception.
  • record – the conflict is marked but not blocked, so it can be reported without disrupting anyone.

• Metaroles let SoD scale. Instead of wiring together hundreds of individual role pairs, the team expressed “exclusion classes”, for example, all executive roles versus all controlling roles through metaroles (roles that apply their rules to a whole category of other roles at once), so newly added roles inherit the correct exclusions automatically.
• It’s a cross-system by construction. Because midPoint evaluates a user’s complete assignment set, a violation split across SAP and another application is caught just as reliably as one contained entirely inside SAP – something a single-system control cannot do.

A Gradual Rollout That Minimized Risk

The rollout followed midPoint’s gradual-enforcement pattern, which turned out to be the single most important decision in the project:

1. Model the conflicts. Working with business and compliance owners, AMI Praha translated the organization’s SoD matrix into exclusion constraints on the relevant roles, using metaroles for the broad “class versus class” rules.
2. Start in record mode. Every rule went live initially with the record action. Nothing was blocked; conflicts were simply marked.
3. Report and remediate. The team produced a violation report from those marks, surfacing the true state of pre-existing conflicts. The business then worked through the backlog – removing access, splitting duties, or formally accepting a documented exception – until it was clean.
4. Switch to prevention. Only then did the actions change to enforcement for the strict rules and approval for the cases where legitimate, controlled exceptions are a business reality. From that point on, midPoint prevents new violations at the moment of request.

Pairing enforcement and approval per rule was key to making this work: the truly forbidden combinations became simply impossible, while the “normally not allowed, but sometimes justified” combinations generate an approval request that leaves a full audit trail of who requested, who approved, and why.

From Detective Controls to Preventive Identity Governance

The most significant shift was in timing: SoD moved from detective to preventive. Conflicting access is now stopped at the moment of request, closing the exposure window that periodic reviews used to leave open. Instead of discovering a violation weeks or months after the fact, the system simply refuses to create it.

Coverage also became cross-system. Because midPoint evaluates a user’s complete assignment set, it catches combinations that no individual application (SAP included) could have seen on its own, closing the blind spot that motivated the project in the first place.

That shift changed what audit preparation looks like day to day. Rather than assembling evidence after the fact, the organization can now present it directly: the policy rules serve as the documented control, the marks left by earlier record-mode runs serve as historical evidence, and every approved exception carries its own audit trail of who requested it, who approved it, and why. Analyst time that used to go into manually hunting for violations has been redirected toward remediation and ongoing policy refinement instead.

Key Lessons for Implementing Segregation of Duties

Gradual enforcement isn’t optional at scale. Going straight to hard blocking in an established role model breaks legitimate work. The record → report → remediate → enforce sequence is what actually makes SoD deployable in a live environment rather than a theoretical policy that never gets switched on.

It’s also worth defining each conflicting pair only once. Because exclusion in midPoint is bi-directional, mirroring a rule on both roles creates maintenance noise down the line. For the same reason, metaroles are worth adopting early rather than late: pair-by-pair modeling doesn’t scale and tends to rot as new roles are added, while class-level rules keep the policy maintainable over time.

Enforcement and approval should be combined deliberately rather than applied uniformly. Not every conflict is absolute, therefore reserving hard enforcement for the genuinely forbidden combinations, and routing the rest through an approval workflow, keeps the control both strict where it needs to be and workable where legitimate exceptions exist.

Finally, it’s worth remembering that SoD is a business artifact, not a technical one. The exclusion matrix has to be owned and signed off by compliance and the business. MidPoint enforces the policy faithfully, but only the business can decide what the policy actually is.

Frequently Asked Questions

+ What are the benefits of Segregation of Duties?

SoD minimizes operational risk by preventing any single individual from executing high-risk processes unchecked. It dramatically reduces exposure to internal fraud, errors, and privilege abuse across the organization. Additionally, SoD simplifies alignment with major compliance frameworks like ISO/IEC 27001 and SOX.

+ How does midPoint enforce Segregation of Duties?

MidPoint enforces SoD using policy rules defined within role configurations, specifically through role exclusions. A role can declare via a policy constraint that it cannot be assigned alongside another specific role or category. Administrators can utilize metaroles to apply these bidirectional exclusion rules across entire classes of roles simultaneously. Because midPoint evaluates a user’s global assignment set across all connected target systems, it effectively catches cross-system conflicts.

+ What happens when a Segregation of Duties conflict is detected?

When a SoD conflict is detected, midPoint’s response depends entirely on the policy action attached to the exclusion rule. With strict enforcement, the system hard-blocks the request and rejects any conflicting assignment outright. Alternatively, with an approval workflow, the request is automatically routed to a designated authority who can review the context and grant a documented exception. The system can also be configured to simply record or log the conflict for visibility without blocking, which is ideal during initial policy rollouts.