separation of duties
termgovernance & risksecurityops culture
The control that no single person should hold enough privilege to misuse a system alone, so that completing a sensitive action requires two people, or two roles that the same person cannot hold.
NIST's glossary, citing SP 800-192, defines separation of duty as "the principle that no user should be given enough privileges to misuse the system on their own", with the classic example: "the person authorizing a paycheck should not also be the one who can prepare them". It "can be enforced either statically (by defining conflicting roles, i.e., roles which cannot be executed by the same user) or dynamically (by enforcing the control at access time)", which is the static and dynamic separation that the RBAC model expresses as constraints on roles. The control catalogue's AC-5 requires organisations to identify and document the duties to be separated and to "define system access authorizations to support separation of duties", and explains that the control "addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion", with the example that "security personnel who administer access control functions do not also administer audit functions". The principle is Saltzer and Schroeder's separation of privilege of 1974 in organisational form: "a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key".
Separation of duties is the control that refuses to trust any one person completely, and it is older than computing: the bookkeeper who records the payments does not sign the cheques. NIST's glossary, citing Special Publication 800-192, defines it as "the principle that no user should be given enough privileges to misuse the system on their own", gives the canonical example, "the person authorizing a paycheck should not also be the one who can prepare them", and names the two ways of enforcing it: "either statically (by defining conflicting roles, i.e., roles which cannot be executed by the same user) or dynamically (by enforcing the control at access time)". Static separation says the two roles may never both be assigned to one person; dynamic separation allows the assignment but forbids both being active in the same session, so that the person who can both prepare and approve cannot do both to the same transaction.
The principle's computing ancestor is the one Saltzer and Schroeder listed just before least privilege. Their separation of privilege reads: "Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key." They credit Needham in 1973 with pointing out its relevance to computer systems, and the reasoning is the organisational one: once the two keys are held by different programs, organisations or people, no single accident, deception or breach of trust is sufficient to compromise what they protect.
The control catalogue turns it into a requirement. AC-5, Separation of Duties, asks organisations to identify and document the duties that must be separated and to "define system access authorizations to support separation of duties". Its discussion explains the aim, that the control "addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion": a control that one person can defeat alone is defeated by one dishonest or one compromised person, while a control that needs two makes them conspire, which is harder, rarer and more often detected. The examples the catalogue gives are the ones infrastructure teams recognise: "dividing mission or business functions and support functions among different individuals or roles, conducting system support functions with different individuals, and ensuring that security personnel who administer access control functions do not also administer audit functions". The last is the one most often missed in small teams, where the administrator of the systems is also the administrator of the log server that would record their actions.
In the access models, separation of duties is a constraint. The RBAC model expresses it as mutually exclusive roles, static or dynamic, and an attribute-based policy can express it as a rule that the approver of a record may not be its author. In operations it is a change process in which the engineer who writes a configuration change is not the one who approves it, a deployment pipeline in which the person who can merge code cannot alone promote it to production, a key ceremony that needs two custodians, and an accounting design in which the people who administer the network devices cannot alter the TACACS+ and syslog records of what they did. Privilege creep is its slow enemy: a person who accumulates roles across transfers eventually holds both halves of a separated duty without anyone having decided it, which is why the catalogue says separation "is enforced through the account management activities" of AC-2 and why access reviews check conflicting combinations as well as excess.
The entries beside this one complete the picture: least privilege for the principle that each person should hold the minimum, RBAC and ABAC for the models that express the constraints, privilege creep for the drift that erodes them, and accounting for the records that let a reviewer see whether the separation held.
Also known as: segregation of duties, sod, separation of duty, two-person rule, four-eyes principle, dual control
Sources
- NIST CSRC glossary, separation of duty (from NIST SP 800-192): no user given enough privileges to misuse the system alone, the paycheck example, static enforcement by conflicting roles and dynamic enforcement at access time (read 2026-10-06)
- NIST SP 800-53 Rev. 5 control catalogue, OSCAL edition 5.2.0: AC-5 Separation of Duties, abuse of authorized privileges and malevolent activity without collusion, dividing functions, access control and audit administered by different people, enforcement through AC-2 account management (read 2026-10-06)
- Saltzer and Schroeder, The Protection of Information in Computer Systems (Communications of the ACM 17(7), July 1974, per the web edition read): design principle (e), separation of privilege, the mechanism that requires two keys, credited to Needham 1973 (read 2026-10-06)