Dual authorisation requires two separate actors to approve a sensitive action before it proceeds. It is a practical control for preventing self-approval, but it only works when the second approval is independent in both identity and authority, not just a duplicate click in the same workflow.
Expanded Definition
Dual authorisation is a control pattern where two distinct approvers must independently approve a sensitive action before execution. In NHI security, it is used for changes that can materially alter trust boundaries, such as privilege grants, secret rotation exceptions, key deletion, or production workflow approvals.
Definitions vary across vendors on how much independence is required, but NHI Management Group treats true dual authorisation as more than two clicks in one system. The second approver must have a separate identity, separate authority, and a meaningful ability to refuse the request. If the same operator can initiate, route, and indirectly force approval, the control degrades into a procedural checkpoint rather than a real safeguard.
This distinction aligns with the intent of the NIST Cybersecurity Framework 2.0, which emphasises governance and control enforcement over symbolic approval chains. In NHI environments, dual authorisation is often applied to reduce the risk of self-approval by the same team that administers service accounts, API keys, or agent permissions. The most common misapplication is treating a routed notification or shared-workspace reaction as dual authorisation, which occurs when the second approval lacks independent identity or authority.
Examples and Use Cases
Implementing dual authorisation rigorously often introduces latency and operational friction, requiring organisations to weigh stronger control over privileged actions against slower incident response and change throughput.
- Requiring two separate approvers before a high-privilege NHI can be granted access to a production secrets manager, especially where credential exposure would affect downstream systems. See the Ultimate Guide to NHIs for why overprivileged NHIs remain a dominant risk.
- Requiring one operator to request a service-account key rotation and another operator to approve the timing when the rotation could disrupt live integrations. This helps separate change intent from change validation.
- Using dual authorisation for emergency break-glass access so an on-call engineer cannot both request and self-confirm elevated access without oversight.
- Requiring two approvers before deleting an API key or certificate, because irreversible removal can break production agents and obscure forensic evidence.
- Applying approval gates to agent tool permissions when an AI agent is being allowed to invoke a sensitive workflow, especially where policy definitions are still evolving. For broader governance context, NIST Cybersecurity Framework 2.0 provides a useful control-management baseline.
Why It Matters in NHI Security
Dual authorisation matters because NHI compromise usually becomes damaging when a single account, pipeline, or operator can both request and approve privilege. That failure mode is especially dangerous in environments where service accounts outnumber human identities by 25x to 50x and where 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs by NHI Mgmt Group.
When dual authorisation is poorly implemented, attackers can exploit workflow shortcuts, shared admin roles, or delegated approvals to make sensitive changes appear legitimate. This weakens both prevention and accountability, because audit logs may show two events while the underlying decision still came from one authority. Strong dual authorisation complements least privilege, separation of duties, and Zero Trust practices, but it does not replace them.
Practitioners should also distinguish between approval and enforcement. A workflow that records two approvals but allows a later override by the original requester is not a durable control. Organisations typically encounter the need for dual authorisation only after a privileged change causes outage, secret exposure, or unauthorised access, at which point the control 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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Dual approval helps prevent self-approved privilege and secret changes in NHI workflows. |
| NIST CSF 2.0 | PR.AC-4 | Access control governance supports separation of duties and approval enforcement. |
| NIST Zero Trust (SP 800-207) | CA-7 | Zero Trust emphasises continuous verification, including trusted approval pathways for privileged actions. |
Treat approvals as policy checks that must be independently verified before privileged execution proceeds.
Related resources from NHI Mgmt Group
- What is MCP Step-Up Authorisation and how does it implement least privilege for agents?
- What are MCP Authorisation Extensions and why do they matter for enterprise governance?
- What is the difference between agent authentication and agent authorisation?
- How should security teams design API authorisation for decentralized identity?
