What breaks when approval workflows only count the number of reviewers?

A two-approver rule collapses if one actor can create multiple believable identities. Counting approvals without verifying distinct people or devices turns consensus into a cosmetic control. The result is that privileged actions, code merges, payouts, and escalations can be rubber-stamped by a single adversary using sockpuppet accounts.

Why This Matters for Security Teams

Approval counts are a weak proxy for trust when the workflow cannot prove who the reviewers are, whether they are independent, or whether one person is operating several accounts. That failure shows up fast in identity-heavy environments, especially where NIST Cybersecurity Framework 2.0 style governance is expected but the control is implemented as a checkbox. It is also a recurring pattern in NHI abuse, where compromised or over-issued identities are used to manufacture false consensus. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which means reviewer integrity is often assumed rather than verified. The same problem appears in supply chain events such as the GitHub Action tj-actions Supply Chain Attack, where trust in automated actors and credentials mattered more than the number of approvals on paper.

Counting approvals without binding them to unique identities, devices, or risk signals creates a false sense of separation of duties. In practice, many security teams encounter this only after a single adversary has already used sockpuppet accounts or delegated access paths to make a broken workflow look compliant.

How It Works in Practice

The control needs to verify reviewer uniqueness, not just reviewer quantity. A sound approval workflow should bind each approval to a distinct identity, a trusted device or workload identity, and a real-time policy decision about the request being approved. That is why current guidance increasingly favours context-aware authorisation and strong identity proofing over static count-based rules.

For human reviewers, the system should confirm that the approver is a different person, authenticated through a strong method, and not acting through a shared admin account. For non-human approvals, such as CI/CD gates, release pipelines, or agentic automation, the workflow should require workload identity and short-lived credentials rather than reusable static secrets. The practical goal is to prove that each approval came from an independent actor with its own cryptographic identity, not from a cloned account or a delegated token.

• Require unique identity binding for each approver, including MFA where appropriate.
• Reject shared accounts, delegated aliases, and reused session tokens for high-risk approvals.
• Check device posture or workload identity before accepting an approval.
• Use policy-as-code to evaluate risk at request time, not after the fact.
• Record the approval chain with immutable audit detail so reviewers cannot be retrofitted later.

This aligns with NHI Mgmt Group guidance on lifecycle visibility and excessive privilege, because approval integrity collapses when identities are opaque or broadly over-entitled. It also maps well to emerging models described in the NIST Cybersecurity Framework 2.0, where governance and access control are expected to be measurable, not implied. These controls tend to break down in organisations that still treat a workflow engine as the source of truth while identity proofing, session binding, and separation checks are spread across disconnected tools.

Common Variations and Edge Cases

Tighter approval controls often increase operational friction, requiring organisations to balance stronger assurance against speed and usability. That tradeoff is real, especially in engineering, finance, and cloud operations where urgent changes cannot wait for a long manual chain.

There is no universal standard for this yet, but best practice is evolving toward risk-based approval requirements rather than fixed headcount thresholds. A low-risk documentation change may tolerate a simple review count, while a production privilege grant, payment release, or secret rotation should demand stronger evidence of independent approvers. In multi-team environments, the edge case is not just collusion. It is identity duplication across systems, where the same person appears under different accounts, or a service account can trigger or satisfy approval logic without being a real reviewer.

Agentic workflows make this even harder. If an AI agent can open tickets, request access, and route approvals, then the control must verify that the agent is operating within a bounded workload identity and not amplifying a human attacker’s reach. The safest pattern is to combine distinct-human verification, workload identity checks, and short-lived authorisation for each sensitive step. Approval count alone is useful only as one signal, not as the control itself.

Related resources from NHI Mgmt Group

• What breaks when AI governance relies only on approval workflows?
• What breaks when insurance approval workflows still depend on paper handling?
• What breaks when agent approval workflows are the only control on autonomous actions?
• What breaks when approval workflows are built outside the gateway?