The four-eyes principle is a control concept that requires at least two independent people to approve a significant decision. In access governance, it reduces the chance that one mistaken or biased reviewer can authorise access alone. The goal is independent scrutiny, not a second signature from someone who simply repeats the first decision.
Expanded Definition
The four-eyes principle is a governance control that requires two independent approvers for a high-impact action, such as granting privileged access, approving a standing secret, or authorising an exception. In NHI security, the control is valuable because service accounts, API keys, and automation credentials can move quickly once approved, so the first reviewer should not be able to complete the decision alone. That distinguishes it from simple peer review, where the second person only confirms the first person’s judgement instead of exercising genuine independence. The principle aligns well with separation of duties, but no single standard governs its exact implementation across platforms, so organisations should define what counts as independence, what evidence must be reviewed, and which actions require dual approval. It is also consistent with the governance expectations expressed in the NIST Cybersecurity Framework 2.0, especially where access decisions must be traceable and accountable. The most common misapplication is treating a second click from the same operational team as four-eyes control, which occurs when approvers are not actually independent or lack authority to reject the request.
Examples and Use Cases
Implementing the four-eyes principle rigorously often introduces approval latency, requiring organisations to weigh faster delivery against stronger assurance and reduced insider risk.
- A platform team requests production access for a new AI agent, and one approver from engineering plus one from security must both validate the business need, tool scope, and expiry.
- A change to a privileged service account requires a manager and an IAM reviewer to approve before the credential can be issued or rotated, consistent with the lifecycle controls discussed in Ultimate Guide to NHIs.
- A temporary exception to Zero Standing Privilege is granted only after separate approvers confirm the exception owner, duration, and rollback plan.
- An API key for a third-party integration is approved by the application owner and a governance reviewer to prevent one person from creating and authorising uncontrolled access.
- A release pipeline change that adds a new secret store integration is reviewed by both the DevOps owner and the security function before deployment.
These workflows are strongest when the second approver has real context, not just permission to rubber-stamp the request. That is especially important for automated identities because the control must address who can initiate access, who can validate it, and who can revoke it later. The Ultimate Guide to NHIs provides broader context for how approval controls fit into NHI governance, while NIST Cybersecurity Framework 2.0 frames the need for accountable access decisions.
Why It Matters in NHI Security
Four-eyes controls matter because many NHI failures begin with a single overconfident approval that expands privilege faster than teams can monitor it. When applied to service accounts, secrets, and automation paths, the control helps slow down risky grants, expose mismatched justification, and reduce the chance that one administrator can both request and approve access. This is particularly relevant in environments where NHIs outnumber human identities by 25x to 50x, because the volume of approvals can make weak oversight feel normal if teams do not enforce independence. NHI Mgmt Group also reports that 97% of NHIs carry excessive privileges, which makes approval discipline more than a paperwork exercise. The governance value is not just prevention; it is also auditability, because dual approval creates a clearer record of who challenged the decision and why. Organisations typically encounter the need for four-eyes control only after a privileged misuse, secret exposure, or access abuse incident, at which point dual approval becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Dual approval helps prevent improper access and secret handling. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed with accountable, least-privilege reviews. |
| NIST Zero Trust (SP 800-207) | AC-5 | Zero Trust limits implicit trust, supporting verified access decisions for NHIs. |
| NIST SP 800-63 | IAL2 | Identity assurance guidance supports stronger validation before privileged access approval. |
| CSA MAESTRO | Agent governance emphasizes controlled authorization of autonomous actions and tool access. |
Require independent approvals before issuing or expanding NHI access and secrets.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
