Who should be accountable when a dual-control request is approved or denied?

Why This Matters for Security Teams

Dual-control is meant to prevent one person or one system from making a high-risk change alone, but accountability becomes unclear when approvals are distributed across policy, operations, and platform teams. That gap matters because the decision is only as defensible as the evidence behind it. NHI Management Group notes that 97% of NHIs carry excessive privileges, which makes approval governance a real attack-surface control, not just a process check. The NIST Cybersecurity Framework 2.0 treats access governance as a core operational discipline, not an afterthought.

For NHI programs, the question is not just who clicked approve or deny. It is who defined the risk threshold, who had authority to judge the request, and who ensured the workflow was bound to the right identity, context, and audit trail. The practical risk is that teams assume the platform will absorb accountability, while approvers assume the policy team owns the outcome. In practice, many security teams encounter blame after a privileged request is approved without clear ownership, rather than through intentional governance design.

How It Works in Practice

Accountability should be shared, but not blurred. The policy owner is accountable for defining the conditions under which dual control is required, including what counts as elevated risk, which identities are in scope, and when a second approver is mandatory. Approvers are accountable for making a reasoned decision based on the request context, not for rubber-stamping a ticket. The IAM or PAM platform team is accountable for how the control is implemented, including cryptographic request binding, immutable logging, and enforcement of quorum rules.

Practitioners usually separate responsibility into three layers:

• Policy accountability: define the rule, risk tier, and escalation path.
• Decision accountability: approve or deny based on evidence, justification, and timing.
• Platform accountability: ensure the workflow is enforceable, traceable, and resistant to tampering.

This is where evidence matters. A defensible dual-control process should preserve the request payload, approver identity, timestamps, and the exact policy version used at decision time. That is consistent with the governance approach described in the Ultimate Guide to NHIs — Standards, which emphasizes auditable controls across the NHI lifecycle. It is also aligned with NIST guidance on access control and accountability, where enforcement is expected to be measurable and reviewable, not implied by process. Where possible, organisations should bind the request to the target workload identity or credential object so approvals cannot be replayed or redirected.

For high-risk NHI actions, the approval record should show who owned the policy, who participated in quorum, what context was reviewed, and whether any compensating controls were active, such as JIT expiry or step-up validation. These controls tend to break down when the approval process is embedded in ticketing tools with weak identity binding and no authoritative policy versioning, because reviewers cannot prove what they approved against.

Common Variations and Edge Cases

Tighter dual-control often increases operational overhead, requiring organisations to balance faster response against stronger separation of duties. That tradeoff becomes more visible during incidents, maintenance windows, and emergency access events. Best practice is evolving, but current guidance suggests that emergency bypasses should be explicitly time-boxed, separately logged, and reviewed after the fact rather than folded into standard approval logic.

There are a few common edge cases. If the policy owner and approver are the same person, the control is usually weakened unless a separate independent reviewer exists. If an automated workflow denies a request, accountability shifts to whether the policy was correctly defined and whether the platform enforced it consistently. If a request is approved using stale context, such as an outdated incident designation or expired business justification, the approver still owns the decision, but the platform team may also be accountable for failing to surface the right data.

For organisations moving toward zero standing privilege, dual control should be treated as one layer in a broader governance model alongside JIT access, approval logging, and periodic review. The core question is not whether approval occurred, but whether the right people could explain and defend it later. That is the standard that matters when auditors, incident responders, or legal teams reconstruct a privileged change after the fact.

Related resources from NHI Mgmt Group

• Dual Control
• Who is accountable when an access request is approved through a ticket but later turns out to be inappropriate?
• Who is accountable when a fraudulent request is approved through a trusted channel?
• What breaks when discovery, lifecycle, and audit are forced into one control plane?