You have heard the theory about Separation of Duties by now. SoD appears in audit reports, the principle has been explained, and its necessity is not in dispute. The question that follows is a lot more concrete: how does the software that is supposed to enforce this (Identity Governance & Administration, or IGA) actually enforce SoD?
A principle is one thing. A product that gives it hands and feet is something else entirely. And between IGA vendors there are far greater differences than most organisations realise.
One vendor sees SoD as a central role-conflict matrix maintained by a compliance team. Another sees it as an operational safeguard that should be woven into every access request. That choice strongly determines what a product can do, and what it demands from your organisation.
What is the relationship between IGA and SoD?
IGA software manages who has access to which systems, ensures that access aligns with policy and regulations, and makes it demonstrable that the right people have the right rights. Think of assigning and revoking access rights, periodically reviewing access, and recording who could do what and when.
Separation of duties is not a standalone function within IGA, but a governance requirement. The answer to the question: are the access rights we have granted also distributed safely? An organisation that only tracks who has access, but does not check whether that combination of rights is dangerous, has a blind spot in its governance.
IGA products implement SoD in fundamentally different ways. That choice has major consequences for how you manage separation of duties, who is responsible for it, and how demonstrable the result is.
First, a step back: where does SoD come from?
Separation of Duties is not an IT invention. The principle originates in accounting, where it has applied for centuries: the same person may not both receive, record and verify money. In the twentieth century this was formalised in the COSO framework. After the accounting scandals surrounding Enron and WorldCom, the Sarbanes-Oxley Act of 2002 forced listed companies to demonstrably implement SoD, including in IT. Since then it has been part of ISO 27001, NIST and countless sector-specific standards.
The core idea is always the same: no single actor (human or system) may be able to complete a critical process entirely alone. For the broader context and the discussion about preventive versus detective controls, we refer to the article: What does Separation of Duties mean and why does it so often fail?
Four variants of SoD in the market
Many IGA products combine several approaches, but almost every product has a clear centre of gravity. That choice is rarely coincidental: it reflects a vision of who is responsible for governance and how strictly that is enforced.
Variant 1: The central role-conflict matrix
This is the classic and most visible approach. A compliance team defines in advance which roles or permissions are incompatible with each other. A user who holds role A cannot simply be assigned role B. The system monitors this centrally and treats a request that would create a conflict either as a hard block or as a policy violation requiring remediation.
An important detail: in matrix products, policy is often configurable. An organisation can set a SoD policy to be preventive (block at the point of request) or detective (allow, but flag as a violation on a dashboard with remediation as the next step). In practice, both modes are used in combination, sometimes even within a single installation.
What the matrix delivers: a centrally demonstrable policy that is easy to explain in audits. What it costs: significant modelling effort, a compliance function that keeps the matrix current, and a high degree of centralisation. In organisations with strong decentralised ownership, this approach often feels alienating, because the people who know the processes are not always the ones managing the matrix.
Variant 2: Detective SoD via access certification
A second group of products takes a fundamentally different route: not preventive blocking, but periodic recertification. Access may be granted first, but is then reviewed at regular intervals by a manager or owner. Conflicts are detected after the fact, not prevented upfront.
What this delivers: less rigid modelling upfront, room for legitimate exceptions, and good visibility after the fact. What it costs: reactivity. Between the emergence of a conflict and the next certification cycle, a user can sit in a toxic combination of rights for months. For heavily regulated environments, that is rarely sufficient.
Variant 3: Workflow segregation and the four-eyes principle
The third variant shifts the focus to the moment of the request. A requester cannot approve their own request, and the approver cannot activate the access themselves. SoD is therefore not modelled as a role conflict, but enforced in the chain of actions. This is the variant that comes closest to the original four-eyes principle from accounting.
Most IGA products support this layer out of the box, often as a supplement to variant 1 or 2. In some products, workflow segregation is even the primary SoD layer, and no separate conflict matrix is maintained.
What this delivers: an operational safeguard at exactly the moment it matters, and an implementation that works even without a heavy compliance function. What it costs: without additional mechanisms, a user can still accumulate two incompatible rights in their portfolio.
Variant 4: Just-in-Time as a complement
JIT is not an alternative to the three variants above, but a valuable additional layer. Instead of permanent rights, permissions only become active when someone needs them, for exactly the duration of the task. After that, they are automatically revoked.
This reduces the attack surface: conflicting permissions are never combined permanently. But it does not fully solve the SoD problem. An approver in a JIT workflow does not automatically see what other rights a user holds at that moment. Without additional controls, someone can still build up a dangerous combination of rights through separate requests, temporary but real.
JIT enriches the audit trail (a reason and expiry time are recorded) and works well for privileged access, emergency situations and project-based access. As a complement to one of the three variants, not as a replacement.
KeyHub's choice: decentralised authorisation strictly enforced
KeyHub follows the principle of central authentication and decentralised authorisation. Who grants access to what is the responsibility of the people who know the work, not a central compliance team. That choice sounds operational, but it flows through to how SoD is implemented.
Where a matrix product says "these two roles may never be held by the same person, regardless of where in the organisation", KeyHub says: it is up to group owners to decide where separation of duties is needed. Once they have set that separation, KeyHub enforces it strictly.
That principle takes shape through five building blocks:
Building block 1: Groups as the foundation
Access in KeyHub runs via groups. Each group grants access to a specific combination of accounts, systems or passwords, and has a group owner who manages membership. Group owners work close to the work and know the risks in their own domain.
Building block 2: Group exclusions as the primary SoD layer
A mutual exclusion can be set between two groups. A user who is a member of group A cannot simply become a member of group B, and vice versa. No conflict arises that needs to be resolved later: enforcement is strict. A request that would cause a conflict is rejected, whether the work is done via the UI or via the API, and regardless of whether the assignment is manual or runs via an access profile. When setting an exclusion, it is explicitly specified from which group conflicting members must be removed. The feature has recently been added and is already running in production at a large public-sector client.
Building block 3: Four-eyes principle, including towards a third party
KeyHub has nine distinct approval moments where the four-eyes principle is enforced, from group admission and vault access to activation requests, membership changes and audit reviews. For each of those moments, a separate authorising group can be configured. This makes three parties possible in a single chain: the requester, the approver and, if an authorising group is configured, an additional check above that. The authorising group can differ per action within the same group. A group manager may, for example, approve day-to-day membership changes, while the audit of that same group is signed off by a different team.
Building block 4: Just-in-Time activation (optional)
For groups where permanent access is undesirable, such as privileged access, KeyHub can activate membership on a time-limited basis. The user activates access for as long as they need it, with a reason and an expiry time. After that, access is automatically revoked. For low and medium privileged access this is generally not desirable: nobody wants to go through an activation step just to reach a shared team folder. JIT in KeyHub is therefore not a mandatory pattern, but a targeted instrument for groups where the risk justifies it.
Building block 5: Audit and classification as a governance layer
Groups can be classified, and per classification an organisation can centrally impose minimum requirements: maximum audit interval, required audit month, audit trail logging, and which approvals are required at which moment. On the roadmap is the ability to impose SoD requirements via classifications as well, in the same way this already works for authorising flows. This allows an organisation to centrally mandate that certain group types must have exclusions, without giving up the decentralised management of those exclusions.
What KeyHub does differently, and why
KeyHub has no central role-conflict matrix. That is a deliberate choice: the people who know the processes are better placed to determine where separation of duties is needed than a central compliance team. Exclusions are configured decentrally, and KeyHub then enforces them strictly. For organisations that receive SOX audits in a specific matrix format, this is something to factor into your implementation.
Exceptions to exclusions are not a configuration option, but an explicit design decision. Anyone who wants to configure an exception does so via a separate group with JIT activation and an authorising group above it. Visible, traceable and approved. Not silently permitted.
Which SoD fits your organisation?
Separation of Duties has many faces in the IGA market. A matrix approach works for organisations that prioritise central compliance and are willing to carry the modelling discipline that requires. A certification approach works for those who prefer to start flexibly and clean up afterwards. A workflow approach works for those who see the four-eyes principle as their primary safeguard. A JIT approach works for those who want to reduce the permanent attack surface where risk is highest.
KeyHub combines workflow seperation and targeted JIT with an explicit SoD layer in the form of group exclusions, and places all of that within a classification-based governance layer. That fits the philosophy on which the entire product is built: central authentication, decentralised authorisation. The people who know the processes can enforce separation of duties where it is needed. And once that is set, it is strict.
No matrix, no checkbox. Just working mechanisms.
