Some administrative actions are dangerous for a reason that ordinary role-based access control does not fully address: one authorized identity can cause an unusually large or difficult-to-reverse effect.

Consider an administrator who can disable organization-wide authentication controls, replace a production signing key, or permanently delete a large body of security-relevant data. Strong authentication and least privilege reduce who can reach that action. They do not help enough if the one account that is legitimately allowed to perform it is compromised, or if its operator makes a serious mistake.

For selected high-impact actions, independent approval can reduce this risk. The requester prepares a specific change, but a different authorized person must approve that same change before the system executes it. This pattern is often called dual control or a two-person rule.

The important part is not simply adding an approval button. The approval must represent a second, independent authorization decision over the exact operation that will occur. This article explains that mental model, where it helps, how to implement it without creating a false sense of protection, and when a simpler control is enough.

One powerful identity can still be a single point of failure

Least privilege asks whether an identity has only the permissions it needs. Independent approval asks a different question:

Should one identity be sufficient to exercise this particular authority by itself?

Suppose a service has an organization_admin role. An administrator requests a destructive operation:

requester:  admin-17
operation:  delete archived audit records
scope:      organization-42
before:     2025-01-01

A conventional authorization check might verify that admin-17 has permission to delete those records. If so, the operation runs immediately.

With independent approval, authorization has another condition:

authorized requester
        +
valid approval from a different authorized identity
        +
approval matches this exact operation
        =
operation may execute

The additional decision changes the failure model. Compromising one administrator account is no longer sufficient under the assumptions of the design. A single mistaken requester also has an opportunity to be corrected before execution.

This control does not make the operation harmless. Two compromised accounts, collusion between authorized people, a flaw that bypasses the approval path, or compromise of the execution service can still defeat it. Independent approval narrows a particular risk: unilateral use of sensitive authority.

Reserve dual control for actions with exceptional impact

Requiring two people for every administrative operation creates delay and encourages rubber-stamping. The control is most useful when the consequence of a wrong decision is large enough to justify the extra coordination.

Good candidates tend to share one or more properties:

  • the action can affect many users or systems at once;
  • recovery is slow, uncertain, or impossible;
  • the action weakens controls that protect other privileged operations;
  • the action changes a root of trust, such as a highly privileged credential or signing authority;
  • ordinary detection would discover misuse only after significant damage.

The exact boundary depends on the system. Deleting one user’s recoverable draft may need only ordinary authorization and a confirmation step. Deleting an organization’s retained security logs may justify independent approval because the scope is larger and the loss can damage later investigation.

Do not confuse approval with user-interface confirmation. Asking the requester to click Confirm protects mainly against accidental activation. Asking the same person to enter a password again can establish fresh authentication. Neither creates an independent authorization decision because the same identity still controls both steps.

Bind approval to the exact requested change

The most important implementation property is request binding. An approver should approve a concrete, immutable description of the operation, not a vague permission to perform something later.

Imagine this unsafe flow:

1. requester asks for approval to "delete old records"
2. approver approves request ID 731
3. requester changes the cutoff date on request 731
4. system executes the modified request

The system technically recorded an approval, but the approver did not authorize the operation that actually ran.

A stronger design treats the proposed action as fixed once it enters approval. Store the security-relevant parameters with the request:

approval_request:
  id: 731
  action: delete_archived_audit_records
  organization: organization-42
  before: 2025-01-01
  requested_by: admin-17
  status: pending

If the requester needs to change organization, before, or another parameter that affects authority or impact, create a new approval request or invalidate existing approvals. The approver must see enough of those parameters to understand what will happen.

This is the same general principle used when binding a security decision to context: approval of one statement must not silently authorize a different statement.

Enforce independence in the authorization layer

A workflow is not dual control if the requester can approve their own request through another screen or API path.

Enforce separation on the server side. A simplified decision might be:

allow execution only if:
  requester is authorized for the action
  approver is authorized to approve the action
  approver != requester
  request is still pending and unmodified
  approval is still valid

The exact identity model matters. Comparing display names or email text is not enough if those values can change. Use the stable identity identifiers on which your authorization system relies.

Also decide what “independent” means in your threat model. Two accounts controlled by the same automation, two credentials issued to the same human, or an administrator and a service account that administrator can freely impersonate may not provide meaningful independence. For particularly sensitive operations, organizational separation can matter too: for example, the approver may need to belong to a different privileged role or operational function.

That stronger separation adds operational cost. It is justified only when the risk calls for it.

Recheck authority at execution time

Approval workflows introduce time between request and execution. Authorization can change during that interval.

Suppose an administrator requests a sensitive operation on Monday, another administrator approves it, and the request executes on Tuesday. During that time, either person’s privileged role may have been revoked, the target resource may have changed ownership, or a security incident may have caused the operation to be suspended.

Do not assume that authorization at request time remains valid forever. At execution, verify the conditions that must still hold for the action to be legitimate. Depending on the system, that can include:

  • the requester still has the required authority;
  • the approval came from an eligible approver;
  • the request has not expired, been cancelled, or already executed;
  • the target and security-relevant parameters still represent the approved operation;
  • current policy still permits the action.

Whether the approver must still hold the approving role at execution time is a policy choice. For some workflows, approval is a durable decision made while the approver was authorized. For higher-risk workflows, revocation should invalidate pending approvals. Choose deliberately and test the behavior rather than inheriting it accidentally from the data model.

Make execution single-use and race resistant

An approved request should normally authorize one intended execution, not become a reusable capability.

A common failure is to implement approval as a boolean flag:

approved = true

If several workers observe that flag simultaneously, or if a retry occurs after an ambiguous failure, the operation may execute more than once.

Model the workflow as a state transition instead:

pending -> approved -> executing -> completed
                   \-> cancelled

Use the transaction, locking, compare-and-set, idempotency, or queue guarantees appropriate to your platform so that only one worker can claim an approved request for execution. If execution can partially succeed, define how retries determine what already happened.

This is not unique to security approval, but high-impact actions make duplicate execution especially costly. The approval record should answer both “was this authorized?” and “has this authority already been consumed?”

Expire approvals when their context becomes stale

An approval that remains usable indefinitely becomes detached from the circumstances in which it was reviewed.

Set a validity period based on how quickly relevant conditions can change. There is no universal duration. A short-lived emergency infrastructure change may justify minutes or hours; a planned administrative workflow may reasonably remain pending longer.

Expiration reduces the chance that an old approval is unexpectedly exercised after staff, policy, target state, or operational intent has changed. It does not replace execution-time authorization checks, because important conditions can change before the expiry time.

Cancellation should also be explicit. Requesters or designated operators may need to withdraw a pending action, and incident responders may need a way to invalidate outstanding approvals during an account compromise.

Give the approver enough information to make a real decision

Dual control fails socially when approval becomes a reflex.

An approval interface should present the facts that determine impact: the action, target, scope, important parameters, requester, and relevant reason or change reference when your process uses one. Avoid requiring the approver to reconstruct those facts from an opaque identifier.

At the same time, do not expose secrets merely to make the screen look complete. If an operation rotates a secret, for example, the approver may need to know which credential will change and which systems depend on it, not the secret value itself.

For machine-facing approval APIs, the same principle applies. The approval client should receive a stable representation of the operation it is authorizing, and the server should reject approval if the request is no longer in an approvable state.

Log the decision chain, not just the final action

When a high-impact change is investigated later, a log entry saying operation completed is not enough.

Record the important decision events separately: request creation, approval or rejection, cancellation, expiry, execution attempt, and final result. Include stable identities, the request identifier, the relevant target and action, and timestamps. Protect these logs according to their sensitivity and retention needs.

Logging does not stop misuse. It helps operators detect unusual approval behavior, understand whether the control worked as designed, and reconstruct responsibility after an incident.

Useful verification tests follow directly from the threat model. Confirm that a requester cannot self-approve, changing a security-relevant parameter invalidates prior approval, revoked or expired requests behave according to policy, concurrent execution attempts do not duplicate the action, and alternate APIs cannot bypass the approval requirement.

Plan for emergencies without creating a permanent bypass

A two-person dependency can become an availability problem. An urgent security response may occur when only one qualified operator is reachable.

There are two valid approaches, depending on the system’s risk. Some environments should simply require two people and accept the delay. Others need an emergency path, often called break-glass access.

If you provide such a path, treat it as a different, tightly controlled risk decision rather than a hidden shortcut. Restrict who can invoke it, require strong authentication, make its use conspicuous in monitoring, log the reason and resulting actions, and review use afterward. Temporary emergency authority should be removed when the emergency ends.

The goal is not to preserve the appearance of dual control while leaving an easy single-person bypass. It is to make the exceptional path explicit enough that its additional risk can be managed.

Know what independent approval does not solve

Independent approval assumes that the second decision is meaningfully independent and that the system enforcing the workflow is trustworthy enough to apply the rule.

It does not address every route to the protected effect. If an administrator cannot delete audit data through the application but can directly delete the underlying storage, the application approval workflow protects only one path. High-impact effects should be mapped to their real enforcement boundaries.

It also does not replace strong authentication, least privilege, reauthentication for sensitive actions, secure recovery, or monitoring. Those controls address different failure modes. Dual control is defense in depth when the remaining risk of one authorized identity acting alone is still too high.

For lower-impact actions, simpler controls are usually better. Ordinary authorization, clear confirmation, reversible changes, backups, and useful audit logs may provide enough protection without adding another human dependency.

Conclusion

Independent approval is useful when the security problem is not merely “who may perform this action?” but “should any one identity be able to perform this action alone?”

Design the approval as a real authorization decision. Bind it to an immutable operation, require a genuinely separate approver, recheck relevant authority when execution occurs, consume the approval once, expire stale requests, and log the complete decision chain. Then test the alternate paths and failure cases that could bypass those guarantees.

Used selectively, dual control reduces the chance that one compromised account or one serious mistake can trigger an exceptional-impact change. Used everywhere, it becomes friction. The defensive decision is to identify the small set of operations where eliminating a single point of human or credential failure is worth that cost.

Cybersecurity Access Control Least Privilege Authorization