Can identity security enforce separation of duties across sensitive systems?

Yes, but effective separation of duties depends on more than assigning different permissions. Identity security can prevent conflicting access rights from being granted to one identity, require independent approval for high-risk actions and preserve evidence of who performed each step. The applications and business processes involved must also support distinct roles and approval states; an identity platform cannot compensate for a system that allows one unrestricted administrator to bypass its own controls.

The control is normally designed around conflicting duties. For example, a user who creates a new supplier should not also be able to approve that supplier and release payment. In an IT environment, the person who requests a privileged configuration change may need to be separate from the person who approves it, while implementation and validation are assigned to different identities. The exact conflicts should be defined by the organisation’s processes, regulatory obligations and risk assessment rather than copied from a generic role template.

Role design is the foundation. Access should be separated into narrowly defined business or technical roles instead of giving users broad permissions based on job titles alone. A role model can identify incompatible combinations, such as:

• creating and approving financial transactions;
• developing code and authorising its release into a production environment;
• requesting access and approving the same request;
• administering security settings and independently certifying that those settings are correct; and
• managing a user account and approving that user’s privileged access.

These restrictions should apply during access requests, account changes and role assignments. A joiner, mover or leaver process should not simply add a new role without checking whether it creates a prohibited combination. Where access is inherited through groups, nested groups or application mappings, the effective permissions need to be evaluated rather than reviewing only the permissions visible in an individual request.

Identity governance tools can support this by testing requests against rules before they are approved. A request that would create a conflict can be blocked, routed to an appropriate independent authority or allowed only with a documented exception. The approver should have enough context to understand the proposed access, its business purpose and any existing permissions that make it sensitive. Approval by the person requesting the access, or by someone who benefits directly from it, does not provide meaningful separation.

Preventive controls are strongest when combined with workflow controls. A sensitive operation may require the requester, approver and executor to be different identities, with each action recorded as a separate event. The application should enforce the sequence, prevent an approval from being reused for another transaction and ensure that a user cannot approve their own request. Where an identity platform provides the access decision but the application performs the transaction, the integration should pass the relevant identity, role and approval context reliably.

Privileged access needs particular care because administrators can often change permissions, alter audit settings or create alternative accounts. Separation of duties may therefore require administrative roles to be divided by function, such as identity administration, server administration and security monitoring. Highly privileged actions can also be subject to an independent approval or a controlled elevation process, with the reason, scope and resulting activity recorded. A standing administrator account that can override every other control represents a significant limitation, even if ordinary user roles are separated correctly.

Technical identities and service accounts require a different approach. They may need to perform automated tasks without human approval for every transaction, but their permissions should still be limited to the systems and actions required by the service. Where a service account can both alter data and approve the resulting change, compensating controls may include a separate validation process, immutable activity records and alerts for unusual use. The account’s owner should not be able to alter its permissions without independent authorisation.

Separation of duties is not always absolute. Smaller organisations may not have enough staff to assign every step to a different person. In that situation, the risk should be documented rather than concealed by creating nominal roles that the same individual can access. Possible compensating measures include dual approval for defined actions, independent review of transaction evidence, restricted administrative paths and monitoring by someone outside the operational process. These measures reduce risk but should not be described as equivalent to complete segregation.

Exceptions should have a defined reason, owner, scope and end date. Permanent exceptions tend to become unreviewed access, particularly when employees change roles or systems are replaced. An exception process should identify which conflicting permissions are being accepted, who authorised the decision and what additional control is expected to detect misuse. The exception should be withdrawn when the business need ends.

Testing should cover both intended and unintended access paths. Useful checks include attempting to request a conflicting role, testing whether inherited group membership bypasses a restriction, confirming that self-approval is rejected and verifying that a user cannot complete a transaction through a second account. Reviews should also consider emergency access, shared credentials, application-specific administrator permissions and accounts created directly in a target system rather than through the central identity process.

Evidence that the control is operating can include denied access requests, approval records, role-conflict reports, privileged activity logs, exception registers and records showing that access was removed after a role change. The evidence should connect the identity to the request, decision and action, and should be protected from alteration by the people whose activity it records. This makes it possible to distinguish a control that exists in policy from one that is actually preventing conflicting activity.

For UK businesses, the practical objective is to map sensitive processes, identify incompatible duties, implement the restrictions in the relevant identity and application systems, and test the resulting access paths. Identity security can enforce that model effectively when ownership, workflow integration, privileged access and exception handling are addressed together. It is not a substitute for sound process design, but it provides the control layer that makes separation of duties consistent and auditable across connected systems.