A single compromised or careless administrator can wipe a device fleet, delete backups or push malicious code to production, because most platforms let one identity do it alone. Dual control, also called the four-eyes principle or two-person control, requires a second, independent person to approve or take part before such an action completes. It is cheap to switch on in many platforms and easy to undermine with self-approval, rubber-stamping, admin bypasses and agents that act without a gate. This guide covers which actions deserve dual control, how the major platforms implement it, how to keep approvers independent, how it applies to AI agents and automation, and how to measure it. It is for identity, PAM, cloud and platform engineering teams.
Key takeaways
- Reserve it for destructive and irreversible actions. Fleet wipes, backup deletion, role assignment at the top tier, production deployment and key operations are the core list; NIST SP 800-53 has dual authorisation enhancements for exactly these.
- Independence is the whole control. The approver must be a different person, outside the requester's chain of compromise; prevent self-approval and admin bypass explicitly, because some platforms allow both by default.
- Put the approval gate where the attacker cannot reach it. Azure Backup's Resource Guard and AWS Backup multi-party approval both recommend placing approvers in a separate subscription, tenant or organisation.
- Agents and automation need the same gate. An AI agent or pipeline service account that can perform a destructive action without human approval is a single point of failure with no fatigue and no judgement.
- Approval quality decays. Measure approval latency, rejection rates and bypasses; an approver who approves everything in seconds is not a second pair of eyes.
Dual control, four-eyes and related controls
| Term | Meaning | Example |
|---|---|---|
| Dual authorisation (two-person control) | Two authorised individuals must approve before an action executes; NIST AC-3(2) | A device wipe request held until a second admin approves |
| Four-eyes principle | Common name for the same idea: maker and checker | A payment raised by one person and released by another |
| Dual control in execution | Both people take part in carrying out the action | Two key custodians present at an HSM ceremony |
| Split knowledge | No single person holds the whole secret | Key components held by different custodians |
| Separation of duties | Conflicting functions assigned to different people; NIST AC-5 | Developers cannot approve their own production releases |
| Quorum (M of N) | A threshold of approvers from a group | Two of five recovery approvers to restore a vault |
NIST SP 800-53 describes dual authorisation as reducing insider risk and advises rotating dual authorisation duties to reduce the risk of collusion, while considering the risk where an immediate response is needed for public and environmental safety. For separation of duties more broadly, see the Segregation of Duties Guide.
Which actions need dual control
| Action | Why | ATT&CK v20 | NIST SP 800-53 |
|---|---|---|---|
| Mass device wipe, retire or delete | One action can destroy the fleet | T1072 Software Deployment Tools, T1485 Data Destruction | AC-3(2) |
| Backup deletion, retention reduction, disabling soft delete or immutability | Removes recovery before ransomware or destruction | T1490 Inhibit System Recovery | CP-9(7) |
| Top-tier role assignment (Global Administrator, organisation owner, cloud root-level roles) | Persistence and full takeover | T1098 Account Manipulation, T1098.003 Additional Cloud Roles | AC-3(2), AC-6(1) |
| Production deployment and changes to critical configuration | Malicious or faulty code reaches customers | T1072 | CM-5(4) |
| Changes to or deletion of audit logs and their configuration | Hides the attacker | Not applicable | AU-9(5) |
| Key generation, export, destruction; signing key access | Forged tokens and code signatures | Not applicable | AC-3(2) |
| Disabling accounts at scale or removing access | Locks out responders | T1531 Account Access Removal | AC-3(2) |
The Stryker Intune wiper attack in 2026 is the reference case: a compromised administrator account issued legitimate Intune wipe commands to tens of thousands of devices, and the page's lessons include requiring multi admin approval for destructive actions.
How the platforms implement it
| Platform feature | What it gates | Self-approval | Points to watch |
|---|---|---|---|
| Microsoft Intune Multi Admin Approval | Access policies for app deployments, compliance and settings catalog policies, device wipe, retire and delete, RBAC changes, scripts and device categories | Not allowed, including for Global and Intune Administrators | No notifications, so tell approvers directly; approved requests expire if not completed in 3 days; protecting the Role policy type can deadlock RBAC if set up first |
| Microsoft Entra Privileged Identity Management approval | Activation of eligible roles | Configure approvers who are not the requesters | The first approver to respond decides; requests lapse after 24 hours (not configurable); Microsoft recommends two or more approvers per role |
| Azure Backup multi-user authorisation (Resource Guard) | Mandatory: disabling soft delete or security features, removing MUA; optional: deleting protection, reducing retention, encryption changes, disabling immutability and more | Separated by design: backup admin must have no rights on the Resource Guard | Place Resource Guard in another subscription or tenant; grant only the Backup MUA Operator role, just in time |
| AWS Backup multi-party approval | Access to logically air-gapped vaults from a recovery account | Threshold of approvers from an approval team | Approval team sits in a separate recovery organisation using IAM Identity Center |
| Google Cloud Privileged Access Manager | Temporary role grants through entitlements | Approvers defined per entitlement, with optional approver justification | Multi-level approvals (preview) allow two sequential levels of up to five approvals each; ungranted requests expire after 24 hours |
| GitHub environment protection rules | Deployment jobs to an environment | Optional "prevent self-review" setting; off unless enabled | Up to six reviewers, only one needs to approve; administrators can bypass by default unless bypass is disallowed |
The pattern across platforms is consistent: the feature exists, but the safe settings (no self-review, no admin bypass, approvers outside the blast radius) often need to be turned on deliberately. See the Privileged Identity Management (PIM) Guide and the JIT Access Guide.
Making approvers independent
- Different identity, different device: the approver must sign in with their own account on their own device, with phishing-resistant MFA. An approval clicked from the requester's session is not dual control.
- Outside the blast radius: approvers for backup and recovery actions should sit in a separate tenant, subscription or organisation, as Microsoft and AWS recommend, so one compromised administrator cannot also approve.
- No self-review and no bypass: enable "prevent self-review" and disallow administrator bypass where the platform offers them, and check that top-tier roles are not exempt.
- Rotate and limit: NIST suggests rotating dual authorisation duties to reduce collusion. Keep approver groups small, named and reviewed in access certifications.
- Real context: the approval request must show what will happen (device count, environment, role, retention change) and the requester's justification, so the approver can judge it.
Agents and automation
Dual control was designed for people, but most destructive actions in modern estates can be triggered by a service account, a pipeline or an AI agent. An agent that holds an Intune, backup or cloud admin permission can perform a wipe or deletion without the fatigue or hesitation a human might show, and in some platforms an app-authenticated API call is a separate path. Intune's Multi Admin Approval applies to application-authenticated Microsoft Graph calls against protected resources, with optional exclusions for named enterprise applications; use those exclusions sparingly because they bypass approval for that resource type.
- Agents request, humans approve: give the agent rights to submit a request, not to complete a destructive action. The approval is bound to the exact action, parameters and target. See the AI Agent Action Approvals and Spending Limits Guide.
- No agent as both requester and approver: Google Cloud PAM now lets service accounts and agent identities be approvers (preview). Never let the same agent, or two agents sharing an owner, satisfy both sides of a dual control.
- Pipelines: production deployment by a CI/CD service account should require an environment approval by a human who did not author the change.
- Scope first: dual control on top of an over-privileged NHI is a weak backstop. Remove destructive permissions from automation that does not need them. See the Human-in-the-Loop for AI Agents Guide.
Emergency and break-glass access
Dual control can delay incident response, and NIST acknowledges cases where immediate action is needed for safety. Plan the exception rather than weakening the control: keep break-glass accounts that can act alone, protect them heavily, alert on every use and review each use within one business day. Make sure the dual control configuration cannot lock you out: Intune warns that protecting the Role policy type before other policies and RBAC are correct can create a deadlock. See the Break-Glass Account Guide.
How to implement
- List destructive actions per platform using the table above, and record which identities (human and non-human) can perform each today.
- Remove standing rights first where possible, using just-in-time elevation, so fewer identities can even request.
- Design approver groups for each action: named, small, independent of requesters, with phishing-resistant MFA, and for recovery actions outside the main tenant or organisation.
- Pilot in audit mode or on low-impact scope: apply the policy to one action type (for example device wipe) and a test group, measure approval times for two weeks and confirm break-glass still works.
- Turn on the safe settings: self-review prevention, no admin bypass, approver justification where offered.
- Extend to backups, top-tier roles, production deployments and key operations.
- Roll back safely: keep a documented procedure and an account able to remove an access policy if it blocks operations, and test it.
- Review quarterly: approver membership, bypass events and the list of excluded applications.
Small organisations with one or two administrators can still use dual control for backups and wipes by naming a second approver outside IT, such as a director with a separate admin account, or by using a managed service provider as the approver. Large organisations should add multi-level approvals for the highest-impact actions and integrate requests with change management.
Detection and measurement
- Coverage: percentage of listed destructive actions that are gated by dual control on each platform.
- Self-approval and bypass events: count of administrator bypasses, emergency overrides and excluded-application actions, each reviewed (target: every one explained).
- Approval latency: median time to approve; very short times suggest rubber-stamping, very long times push people to bypass.
- Rejection rate: a rate of zero over many months is a warning sign that approvers are not reviewing.
- Ungated destructive actions: alerts on wipes, backup policy changes or top-tier role assignments that did not go through an approval record (AU-10 non-repudiation evidence).
- Approver hygiene: percentage of approvers with phishing-resistant MFA and no requester role on the same action.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Dual authorisation for privileged commands | AC-3(2) Dual Authorization | PR.AA-05 |
| Separation of duties | AC-5 Separation of Duties | PR.AA-05, GV.RR-02 |
| Changes to production and critical configuration | CM-5(4) Dual Authorization, CM-3 Configuration Change Control | PR.PS-01 |
| Backup protection | CP-9(7) Dual Authorization for Deletion or Destruction | PR.DS-11 |
| Audit log protection | AU-9(5) Dual Authorization | PR.PS-04 |
| Evidence of who approved | AU-10 Non-repudiation | DE.CM-03 |
Common failure patterns
- Self-approval left on: the deployment or role activation is approved by the person who requested it because the platform did not block it by default.
- Admin bypass: repository or environment administrators skip the gate, and attackers target exactly those accounts.
- Approvers inside the blast radius: the approver is in the same tenant and the same admin group, so one compromise satisfies both sides.
- Rubber-stamping: approvals arrive in seconds with no rejections, and the second pair of eyes is never really looking.
- Automation path ungated: humans need approval but a service account or agent with the same permission can act alone, or is on the exclusion list.
- Lockout by design: dual control applied to role management or break-glass accounts without a tested recovery path stops responders during an incident.
Practitioner checklist
- List destructive and irreversible actions on each platform and who or what can perform them.
- Enable Intune Multi Admin Approval for device wipe, retire and delete, scripts and RBAC changes.
- Protect backup vaults with Resource Guard or multi-party approval, with approvers in a separate tenant or organisation.
- Require approval for top-tier role activation in PIM or PAM, with at least two named approvers.
- Require environment approval with "prevent self-review" and no admin bypass for production deployments.
- Give agents and pipelines request rights only, never completion rights, for destructive actions.
- Keep and test break-glass accounts and a rollback path for every approval policy.
- Alert on bypasses, exclusions and destructive actions without an approval record.
- Review approver membership, latency and rejection rates quarterly.
Standards and references
- NIST: SP 800-53 Rev. 5 (AC-3(2), AC-5, CM-5(4), AU-9(5), CP-9(7))
- Microsoft Learn: Use Multi Admin Approval in Intune
- Microsoft Learn: Approve or deny requests for Azure resource roles in PIM
- Microsoft Learn: Multi-user authorization using Resource Guard
- AWS: Multi-party approval for logically air-gapped vaults
- Google Cloud: Privileged Access Manager overview
- GitHub Docs: Deployments and environments
- MITRE ATT&CK: Inhibit System Recovery
Related NHI Mgmt Group resources: Privileged Access Management Guide · Segregation of Duties Guide · Human-in-the-Loop for AI Agents Guide · Break-Glass Account Guide · JIT Access Guide