Some actions in a control system are consequential enough that no single person should be able to carry them out unchecked - committing new PLC logic, changing a safety-related setpoint, deleting historical records. Separation of duties is the principle that splits such a sensitive action across two people so that one cannot both make and approve the change. This guide explains what separation of duties means in a SCADA context, how the four-eyes or maker-checker pattern works on critical changes, and how the principle maps into the roles a system already defines.
Separation of Duties in one line: Separation of duties is a control that divides a sensitive action between two or more people so that no single individual can complete it alone - typically, one person makes a change and a different person must review and approve it before it takes effect. In SCADA this applies to high-consequence actions like editing and committing control logic or altering a critical setpoint. Its purpose is to guard against both malicious insider action and honest mistakes by requiring a second, independent set of eyes.
Separation of duties, sometimes called segregation of duties, rests on a simple idea: the person who initiates a high-consequence change should not also be the person who authorizes it. The action is deliberately broken into at least two steps assigned to different people. One engineer might draft and edit a change to a controller's logic; a second, independent engineer must review and commit it before it reaches the live system. Because completing the action requires two distinct individuals to act, no one person holds the full power to push a dangerous change through on their own.
This is a different kind of control from the ones that decide what a single account may do. Access control and least privilege bound one person's individual authority - what screens they see, what commands they may issue. Separation of duties instead governs the relationship between people: even a fully authorized engineer with every permission their role allows still cannot single-handedly enact certain changes, because the design requires a second, independent party to concur. It is, at its heart, an anti-collusion and anti-error principle, aimed squarely at the actions where the cost of a single bad decision - deliberate or accidental - is too high to leave in one pair of hands.
The everyday form of separation of duties is the four-eyes principle, also known as maker-checker or dual control: one person makes, another checks. Applied to SCADA, the maker prepares a change - a new setpoint, a modified alarm limit, an update to control logic - and the change is staged rather than applied immediately. It then sits pending until a different, qualified person, the checker, reviews it and approves. Only on that second approval does the change take effect. For the most critical operations, the checker's approval is not a formality but a genuine independent verification that the change is correct and intended.
The pattern earns its keep on exactly the changes where mistakes and misuse are most damaging. A mistyped setpoint on a pressure controller, a logic edit that removes a safety interlock, or a bulk deletion of historical data can all cause real harm, and each becomes far less likely to slip through when a second person must consciously agree before it is committed. Dual control also reshapes the calculus for a malicious insider: a lone bad actor can no longer quietly enact a harmful change, because doing so now requires a co-conspirator, and requiring collusion raises both the difficulty and the risk of being caught. The same review step doubles as an error filter for the far more common case of an honest engineer simply getting a value wrong.
Separation of duties has to be enforced by the system, not merely encouraged in a procedure, and the natural place to enforce it is the role and permission model the SCADA platform already uses. Rather than relying on people to remember to ask a colleague, the roles are arranged so that the ability to make a change and the ability to approve it are held by different roles and never combined in one account. A maker role can stage a change but not commit it; a separate approver role can commit but is expected to be a different person. Building the split into roles turns a policy anyone could bypass under pressure into a rule the software enforces every time.
In distributed operations this becomes especially valuable, because changes are often requested remotely and the temptation to let one person handle everything is strongest when staffing is thin. A cloud SCADA platform such as Merobix can support the pattern by requiring that consequential changes be staged and approved by a distinct authenticated user before they take effect, and by keeping an attributable record of who made and who approved each one. That record matters as much as the control itself: it demonstrates to auditors and investigators that critical changes genuinely passed through two independent people, and it turns the anti-collusion principle from an honor system into an enforced, evidenced part of how the field is operated.
The four-eyes principle, also called maker-checker or dual control, requires that a sensitive change be prepared by one person and reviewed and approved by a different, qualified person before it takes effect. In SCADA it is applied to high-consequence actions like committing control logic or changing a critical setpoint. The staged change stays pending until a second individual consciously approves it, which catches both mistakes and malicious edits.
Least privilege limits what a single account is allowed to do, bounding one person's individual authority. Separation of duties governs the relationship between people, requiring that a sensitive action be split so that no one individual can both make and approve it - even someone with every permission their role allows. Least privilege narrows each person's power, while separation of duties ensures certain actions need two independent people to complete.
Because a single person can no longer enact a harmful change alone, a malicious insider would need a co-conspirator to complete it, which requires collusion and greatly increases the chance of being detected. The same second-approval step also filters honest mistakes, since an independent reviewer must consciously agree before the change is committed. Requiring two people to act turns a lone bad decision into a much harder and riskier undertaking.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.