Risk management for identity governance needs stronger SoD controls

At a glance

What this is: This is an EmpowerID blog post arguing that risk management only works when organisations map risky functions, enforce segregation of duties, and fold access risk into recertification.

Why it matters: It matters because IAM, IGA, PAM, and governance teams all rely on the same control logic to stop authorised users or roles from combining actions that create fraud, data exposure, or system damage.

By the numbers:

• In 2008, a rogue trader at Société Générale caused a €4.9 billion loss due to unchecked trading activities.

👉 Read EmpowerID's blog post on risk management and segregation of duties

Context

Risk management is not a single control. It is the discipline of identifying which authorised actions become dangerous when the same identity, role, or workflow can combine them without oversight. In IAM terms, the real problem is not access alone, but access combinations that create fraud, privilege abuse, or unreviewed operational change.

For identity programmes, this is a segregation of duties problem as much as a governance problem. When access requests, role mappings, and recertification are not tied to risk functions, teams end up approving entitlements they cannot actually reason about. That is a common failure mode in mature-looking programmes that still treat risk as a reporting exercise rather than an enforceable control model.

Key questions

Q: How should security teams implement segregation of duties in access governance?

A: Start by defining the risky business functions that must not coexist in one identity, then map those functions to entitlements and roles. Enforce the rules at request time, not only during audits, and keep the mappings updated so reviews reflect current authority rather than stale role names.

Q: Why do role-based reviews miss risk in IAM and GRC programmes?

A: Role names often hide the actual actions a user can perform, especially when inheritance or local permissions expand authority underneath a simple label. Risk appears when one identity can combine sensitive functions, so teams need function-level visibility to assess the real control boundary.

Q: What breaks when segregation of duties is only reviewed periodically?

A: Periodic reviews are too late to stop a toxic combination from being used between certification cycles. If the organisation does not evaluate access at request time and refresh mappings continuously, risky combinations can remain active long enough to cause fraud or operational damage.

Q: Who is accountable when a control failure lets one identity approve and execute the same transaction?

A: Accountability usually sits with the organisation that defined the workflow, the access owners who approved the entitlement, and the control owners who failed to enforce SoD. Governance frameworks expect traceable decisions, so unclear ownership is itself part of the control failure.

Technical breakdown

How risk functions turn identity actions into control logic

Risk functions are the atomic activities a system can recognise, such as resetting an admin password, creating a purchase order, or approving a payment. Once functions are defined, policy engines can detect combinations that should never sit with one identity or role. Global functions capture the general action, while local functions bind it to a system context such as Azure or SAP. That distinction matters because the same action can carry very different risk depending on where it is executed and what downstream permissions it unlocks.

Practical implication: define risk at the function level before you try to govern it at the role level.

Segregation of duties and preventive access checks

Segregation of duties, or SoD, prevents a single identity from completing an entire sensitive business process on its own. In practice, that means checking proposed access during request time, not only after a user is already active in the role. Preventive controls stop toxic combinations before they are granted, while detective controls flag them once they exist. The article also points to fine-grained permissions and role inheritance because coarse role design often hides the exact action path that creates the risk.

Practical implication: use request-time SoD checks for high-risk combinations and back them with detective reporting.

Why recertification only works when risk data is visible

Recertification is supposed to tell approvers whether access still makes sense, but it fails when the review surface is too generic. If managers see role names without risk functions, they cannot tell whether an entitlement enables purchase approval, admin password resets, or other sensitive actions. Risk compilation and regular mapping keep the data current so reviews reflect actual authority rather than stale role labels. That makes recertification a governance decision point instead of a checkbox.

Practical implication: surface risk functions in access reviews so approvers certify actual authority, not role names.

Threat narrative

Attacker objective: The objective is to convert legitimate access into unauthorised financial, operational, or administrative impact by exploiting unsegregated duties.

1. Entry occurs when a user or role gains legitimate access to a process that includes both creation and approval capabilities, or similarly risky combinations.
2. Escalation follows when mapped functions allow the same identity to combine sensitive actions such as approving and executing high-impact changes without a separate control.
3. Impact appears as fraud, unauthorised transactions, or destructive administrative actions that the governance model failed to block in advance.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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

NHI Mgmt Group analysis

Segregation of duties is still the decisive control, but only when it is expressed as machine-enforceable function policy. Risk language without mapped functions becomes a reporting layer, not a control layer. The article is right to separate risk functions from risk policies, because governance only works when the policy engine understands which action combinations are toxic. Practitioners should treat SoD as an execution control, not a quarterly audit artefact.

Identity risk is often mismanaged as role review when the real issue is action combination review. A user can hold a benign-looking role and still be able to create and approve the same transaction path. That is why role inheritance and fine-grained permissions matter: the dangerous condition is usually hidden below the role label. Practitioners should model risk at the function level, then map it back to access governance.

Recertification without risk context produces false confidence. Reviewers can only reject or approve what they can understand, and role names rarely explain the business impact of the entitlement. The stronger model is to recertify against mapped functions, mitigating controls, and known SoD conflicts. Practitioners should push review decisions toward actual authority, not inherited access terminology.

Traditional GRC risk still depends on identity governance data quality. Finance-style control logic fails if the organisation cannot keep mappings current across cloud, ERP, and directory systems. The article’s emphasis on compilation and regular updates reflects a broader truth: stale entitlement data turns every downstream risk decision into guesswork. Practitioners should treat mapping freshness as a control requirement, not an administrative task.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For the control model behind these failures, see NHI Lifecycle Management Guide for how lifecycle governance reduces standing exposure across identities.

What this signals

Risk governance is becoming an identity-data problem, not just a policy problem. If entitlement mappings are stale, SoD rules cannot reliably tell you which combinations are toxic. That is why continuous compilation and review hygiene matter as much as the policy definitions themselves.

With 72% of organisations reporting or suspecting NHI breaches, the control lesson is broader than one process or platform. Identity governance has to span human access, service accounts, and workload permissions because the same governance blind spots show up in each layer. Practitioners should expect risk tooling to move closer to live entitlement state, not quarterly snapshots.

The next maturity step is less about adding more rules and more about making risk visible where decisions happen. Programmes that can surface function-level exposure inside access requests and recertification workflows will be better placed to reduce fraud, privilege creep, and operational misuse.

For practitioners

• Map risky functions before defining policies Catalogue the specific actions that create risk in each major system, then express them as policy objects that SoD engines can evaluate. Separate global functions from system-specific variants so the same control logic can be reused across Azure, SAP, and other platforms.
• Block toxic combinations at request time Evaluate access requests before granting entitlements that let one identity both initiate and approve a sensitive process. Use preventive checks for high-impact combinations and reserve detective alerts for residual exceptions that cannot be denied outright.
• Expose function-level risk in recertification Present reviewers with the actual risky functions attached to an entitlement, not just the role name or group label. That gives managers enough context to certify, reduce, or revoke access based on real authority and business impact.
• Keep entitlement mapping current across systems Refresh mappings on a regular cadence so new roles, inherited permissions, and changed workflows are reflected before the next review cycle. Stale data undermines both preventive SoD checks and detective reporting.

Key takeaways

• The post shows that risk management fails when organisations cannot see which access combinations create real business harm.
• The clearest evidence is the €4.9 billion Société Générale loss, which demonstrates how unchecked authorised activity can become catastrophic.
• The practical response is to govern risky functions directly, enforce segregation of duties at request time, and keep recertification tied to current entitlement mappings.

Key terms

• Segregation Of Duties: Segregation of duties is a control model that prevents one identity from completing a sensitive process end to end. It reduces fraud and misuse by separating the actions that create, approve, and execute high-risk transactions or administrative changes.
• Risk Function: A risk function is a specific action or task that can create exposure when combined with another action. In identity governance, functions are the unit used to detect toxic combinations across roles, applications, and workflows.
• Risk Policy: A risk policy defines which combinations of functions, roles, or entitlements are unacceptable. It turns governance intent into an enforceable rule set that access management and recertification workflows can evaluate before or after access is granted.
• Recertification: Recertification is the periodic review of existing access to confirm that it is still needed and still safe. Its value depends on whether reviewers can see the actual functions behind an entitlement rather than only a role name or group label.

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by EmpowerID: a blog post on risk management, segregation of duties, and access governance. Read the original.