Some administrative actions are too consequential to depend on one account making one decision. An administrator might be compromised, might misunderstand the target, or might simply select the wrong option. If that one identity can immediately disable a critical control, grant powerful access, or approve a destructive change, ordinary authentication cannot distinguish a legitimate decision from a costly mistake.
Independent approval changes that failure mode. One authorized person proposes the action, and a different authorized person must approve the same action before it can execute. The control is sometimes called two-person approval or a four-eyes rule. Its useful security property is narrower than those names suggest: a single administrator’s authority is insufficient for a defined class of high-risk operations.
This article explains when that control is worth the friction, how to bind approval to the exact operation being reviewed, and where implementations often weaken the separation they intended to create.
Start with the failure you want to contain
Normal role-based access control might say:
administrator -> may rotate production signing keyThat policy assumes one administrator is an acceptable unit of trust. For many routine operations, that is sensible. Adding another person to every change would slow work without reducing enough risk to justify the cost.
Now consider an operation whose failure could affect every customer or remove an important recovery path. The trust decision may deserve a different shape:
requester authorized to propose
+
different approver authorized to approve
+
approval matches exact pending action
|
v
executeThe threat model is not “two people can never be compromised.” Independent approval mainly reduces risks caused by one compromised privileged account, one malicious insider acting alone, and some classes of operator error. It provides less protection when the requester and approver collude, both accounts are compromised, the approval interface lies about what will execute, or the underlying system can bypass the workflow.
That boundary matters. Two-person approval is a way to reduce concentrated authority, not a substitute for strong authentication, least privilege, logging, backups, or incident response.
Choose actions by impact, not by administrator status
A common mistake is to require approval for everything an administrator does. That creates queues of low-value approvals and encourages reviewers to click through them mechanically.
Instead, identify operations where one mistaken or compromised decision would have an unusually large consequence. The exact list depends on the system. It might include disabling an organization-wide security control, granting a highly privileged role, changing a root trust configuration, or permanently deleting a large protected resource.
The important question is not whether the screen is labelled “admin.” Ask what authority the operation creates or destroys, how broad its effect is, and how difficult recovery would be.
A useful policy can be expressed in terms of the operation itself:
action: change root trust configuration
requester permission: trust_change_propose
approver permission: trust_change_approve
self-approval: forbidden
approval lifetime: boundedSeparate propose and approve permissions when the organization needs different populations for those roles. In a smaller system, the same administrative role may hold both permissions while still prohibiting a person from approving their own request. The stronger separation is useful when the threat model justifies the operational complexity.
Approval must cover the exact action that will execute
The most important implementation property is binding. The approver should review the same security-relevant details that execution will use.
Suppose an administrator proposes granting a privileged role:
request id: 7312
subject: user-184
role: billing-admin
scope: organization-27The approval must refer to that immutable proposal, not merely to request 7312 while the subject, role, or scope can still change.
Otherwise the workflow can produce a dangerous sequence:
review harmless proposal
|
approve
|
proposal changes
|
execute different operationA sound design freezes the security-relevant fields once review begins. If any of those fields need to change, invalidate the previous approval and require review of the new proposal.
This is the same reason an approval screen should show meaningful details rather than a generic message such as “Approve pending change?” A reviewer cannot make a useful decision without knowing the target and consequence of what they are authorizing.
For structured operations, store the proposal server-side and give it an immutable identifier or version. The execution path should load that approved representation directly. Do not rebuild the operation later from mutable client input.
Enforce independence with stable identities
Checking that two requests came from different sessions is not enough. One person can have several sessions. Checking that display names differ is also weak because names may change or collide.
Use the application’s stable principal identifier for the separation rule:
if approver_principal_id == requester_principal_id:
reject approvalThis simplified pseudocode demonstrates the identity comparison, not a complete authorization flow. The server must also verify that both principals currently hold the required permissions.
If administrators can act through shared accounts, the system cannot reliably establish individual independence from those account identities. High-risk approval workflows therefore work better with individually attributable administrative identities. Shared emergency access may still be necessary in some environments, but it should be treated as an explicit exception with its own controls rather than quietly satisfying the two-person rule.
Independence can also require more than different user IDs. An organization may decide that certain actions need approval from a separate team or authority domain. That is a policy choice. Encode it explicitly if it matters; do not assume that two accounts automatically represent independent judgment.
Re-check authority when approval and execution happen
Permissions can change while a request waits for review. An administrator might leave the team, an account may be suspended, or the approver’s role may be revoked.
A practical workflow therefore makes several decisions at different times:
proposal time: requester may propose this action
approval time: approver may approve this action
execution time: required approvals remain validDo not treat a week-old approval as permanent authority unless that is genuinely the policy. Give pending approvals an appropriate lifetime, and expire or invalidate them when relevant security state changes.
The execution path should also verify the proposal state atomically enough for the system’s concurrency model. A request that is approved once should not accidentally execute twice because two workers observe the same pending state. Record a transition such as approved -> executing -> completed, or use another transactional mechanism appropriate to the data store and operation.
This is not primarily about preventing an attacker from racing the system. It also prevents retries and operational failures from turning one approved action into several effects.
Do not let alternate paths bypass the approval boundary
An approval requirement is only as strong as the least protected route to the same capability.
If the web console requires two people but an older API endpoint lets one administrator perform the operation directly, the organization still trusts one administrator. The interface has changed; the security boundary has not.
Enforce the policy in a shared server-side authorization layer or at the sensitive capability itself. Include automation, administrative APIs, background jobs, support tools, and emergency workflows in the design review.
Some systems genuinely need a break-glass path for urgent recovery. That can be reasonable when waiting for a second person would create a larger safety or availability problem. Treat it as a separate, deliberately stronger-risk path: tightly restrict who can use it, require strong authentication, record the reason and actor, alert appropriate responders, and review its use afterward. A hidden “skip approval” flag available to ordinary administrators defeats the purpose of the control.
Make approval understandable to the reviewer
Security can fail even when the software enforces two distinct identities. A reviewer who cannot understand the request is not providing meaningful independent judgment.
Show the fields that determine consequence: who or what is affected, the privilege or configuration being changed, the scope, and whether the action is reversible. For a replacement operation, showing both the current and proposed values can make the decision clearer.
Avoid forcing reviewers to reconstruct context from opaque IDs when the system can safely present human-readable names alongside stable identifiers. At the same time, do not let display labels become the values that execution trusts. Human-readable context is for review; stable internal identifiers should continue to drive the operation.
Notifications should lead reviewers to the legitimate approval interface rather than embedding a one-click approval that lacks enough context. For especially consequential actions, requiring recent authentication before approval can reduce the chance that an unattended approver session is enough. That is a complementary control, not part of the two-person property itself.
Preserve evidence without treating logs as authorization
Record enough information to reconstruct the decision: the immutable proposal or its trustworthy reference, requester identity, approver identity, relevant timestamps, outcome, and any cancellation or expiry. Keep secrets and unnecessary personal data out of those records.
Audit logs help incident response and accountability, but logging an unapproved action does not make the action acceptable. The approval check must happen before execution.
Likewise, a cryptographic hash of a proposal can help detect representation changes only if the surrounding system protects how that hash is created and used. Most applications do not need to invent a signing protocol for ordinary internal approvals. A server-side immutable proposal with sound access control and transactional state changes is often simpler and easier to verify.
Test the security property directly
A useful test suite tries to violate the separation rather than only exercising the happy path.
Verify that a requester cannot approve their own proposal through another session, an unauthorized user cannot approve, modifying a security-relevant field invalidates prior approval, expired approval cannot execute, and an approved proposal executes at most as many times as the operation permits. Test alternate APIs that expose the same capability.
Also test permission changes between stages. If the approver loses the required role before execution, decide whether existing approval remains valid or must be rejected, then encode that policy consistently. There is no universal answer because some systems treat approval as a durable signed decision while others require current authority at execution time. The choice should be explicit.
Operational tests matter too. Make sure a stuck approval can be cancelled, a failed execution has a defined retry policy, and incident responders can tell whether the action executed, partially executed, or never started.
Use two-person approval where concentrated authority is the problem
Independent approval adds delay and coordination cost. That cost is justified when the main risk is that one privileged identity can cause an effect too large to entrust to one decision.
For ordinary administrative work, least privilege, strong authentication, clear interfaces, and reliable audit logs may be sufficient. Adding a second reviewer to low-impact changes can make the important approvals harder to notice.
For the smaller set of high-risk operations, design the control around a precise invariant: the requester cannot be the approver, both identities must have the required authority, and the approval must be bound to the exact action that executes. Then make sure there is no easier route around that boundary.
That turns “someone else clicked approve” into a defensible security property: one compromised or mistaken administrator is no longer enough to perform the operation under the assumptions the workflow was designed to enforce.