A governance pattern that requires two independent authorised people to approve a sensitive action before it is released. In finance, it reduces the chance that a single compromised identity can move money or alter payment instructions on its own.
What dual control is for and why it matters
Dual control is a governance pattern for high-consequence actions, where release requires two independent authorised people rather than one. That separation reduces single-person misuse, makes collusion harder, and creates a practical checkpoint for actions that can move funds, change instructions, destroy evidence, or alter security state.
Its value is not in adding delay for its own sake. It is in forcing a second human decision at the point where a compromised account, a rushed approval, or an insider error could otherwise turn a routine request into an irreversible event.
In security operations, dual control is often paired with approval workflows, segregation of duties, and a clear rule that the approver must not also be the requester. In mature programmes, the control is treated as part of the action design, not a manual review bolted on after the fact.
Where dual control is used
Dual control is most common where a single mistake or compromise would have outsized impact. Financial transfers, payment instruction changes, privileged account changes, key ceremonies, backup restore approvals, and destructive administrative actions are all typical examples.
The pattern also appears in privileged access environments when the action itself is sensitive rather than the session alone. For example, a privileged operation may require one person to request it and another to approve it, or a system may require two custodians to unlock a secret or approve a release step.
In cloud and platform operations, the same idea may be applied to emergency access, infrastructure deletion, or production changes. The exact tooling varies, but the control objective stays the same, no single actor should be able to complete a high-risk action unaided.
How dual control differs from related safeguards
Dual control is often confused with simple approval logging or after-the-fact review. Logging records what happened; dual control prevents unilateral execution by requiring a second authorised decision before the action proceeds.
It is also different from broad role assignment. A role can grant the ability to request or approve, but dual control is about the transaction rule itself, the action remains blocked until the second approval is present and independent.
Used well, it complements separation of duties, maker-checker workflows, and least-privilege design. Used poorly, it becomes a checkbox, for example when approvers are too closely related, when one person can both create and approve the request, or when emergency bypasses are too broad.
What makes dual control effective in practice
Dual control works only when the two approvals are genuinely independent and the approval path is hard to circumvent. The control should define which actions are in scope, who may approve, how exceptions are handled, and how evidence is retained for audit and incident review.
It is strongest when backed by technical enforcement rather than social expectation. A workflow should prevent self-approval, preserve an immutable trail, and ensure the second approval is not just a symbolic sign-off after the fact.
For sensitive operations, the control should also be consistent across normal and emergency paths. If an emergency process can bypass the second approval too easily, dual control stops being a meaningful safeguard and becomes paperwork.
Risk and Threat Considerations
Dual control exists because single-actor compromise, insider abuse, and rushed operational decisions can cause irreversible damage. The main risk is false confidence: organisations believe they have two-person oversight, but the workflow still allows one person to steer, submit, and effectively release the action.
Failure mechanism: The control fails when approvals are not independent, when privileged users can approve their own requests through a related account or exception path, or when an attacker compromises both sides of the workflow.
Impact: A successful bypass can enable fraudulent payment changes, unauthorised privilege changes, destructive admin actions, or release of sensitive cryptographic material, with consequences that are often immediate and hard to reverse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Dual control enforces who may release a sensitive action. |
| AC-6 — Least Privilege | Dual control limits any one person from completing a high-impact action alone. | |
| SC-12 — Cryptographic Key Establishment and Management | Key ceremonies often require dual control for protected cryptographic actions. | |
| Recommendation — Enforce two-person approval rules for high-risk actions. Restrict approval and execution rights to separate roles. Require dual custody for sensitive key-management operations. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of duties | Dual control is a direct segregation-of-duties pattern for sensitive actions. |
| A.8.24 — Use of cryptography | Cryptographic operations often need witnessed, dual-approved handling. | |
| Recommendation — Separate initiation and approval duties for critical operations. Apply dual approval to high-consequence cryptographic procedures. | ||
Practitioner Guidance
Why practitioners should care: Dual control is only meaningful when the second approver can actually stop the action. Treat the control as a design requirement for the transaction, not a ceremonial step after the system has already decided to proceed.
Governance implication: Define exactly which actions require two independent approvals, who may act as approver, and what constitutes independence. If the same operational team can both initiate and approve without real separation, the control is weakened.
Practitioner takeaway: The control should be easiest to use for the right path and hardest to bypass on the exception path.
Related resources from NHI Mgmt Group
- Guide: Dual control and four-eyes approval for privileged and agent actions
- How should security teams implement dual control for high-risk identity actions?
- Who should be accountable when a dual-control request is approved or denied?
- Should organisations treat cryptographic people verification as a replacement for dual control?
- How do teams know when step-up approval is enough and dual control is required?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org