Dual authorization requires two distinct identities to confirm one action before it takes effect. Neither one can complete the action alone, and the second confirmation is a decision about that specific action, not a standing permission. In older security writing the same arrangement is called two-person control, the two-man rule or, by auditors, four-eyes approval. In the NIST catalogue it is one control with one identifier: AC-3(2), Dual Authorization (NIST SP 800-53 Rev. 5).
What does "distinct" have to mean?
Two confirmations are one confirmation unless three things hold.
- Distinct identities, cryptographically. The check is on the identity that signed, not on a name in a message and not on two sessions in one browser.
- The proposer is excluded. The party that asked cannot be one of the parties that agree. An agent approving its own proposal is a single actor with two roles.
- One action, named exactly. Both identities confirm the same operation, on the same target, with the same arguments. If either could have confirmed a summary, the summary is the thing that was approved.
Saltzer and Schroeder stated the principle before the control existed: "a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key" (Saltzer and Schroeder, section I.A). Their reason was that no single accident and no single compromise is enough.
Is this the same as segregation of duties?
They are related and they are not interchangeable. Segregation of duties splits a process across roles so that no one role can run it end to end. Dual authorization puts two identities on one step. A payment process can have clean segregation of duties and still let a single administrator release a payment, and a process with weak role design can still require two signatures at the moment of release.
Both appear in the standards. ISO/IEC 27001:2022 Annex A carries A.5.3, Segregation of duties (ISO/IEC 27001:2022; the control text itself is not free to reproduce). The DORA technical standard is more specific about the failure it is aimed at, requiring "the segregation of duties designed to prevent ... the allocation of combinations of access rights that may be used to circumvent controls" (Commission Delegated Regulation (EU) 2024/1774, Article 21(b)). The same article requires user accountability, "limiting ... generic and shared user accounts and ensuring that users are identifiable for the actions performed" at all times (Article 21(c)).
What the regulations do not say
Two claims circulate in agent security marketing and neither survives the primary text.
DORA has no dual-authorization article. Regulation (EU) 2022/2554 does not require two-person approval of anything. The nearest binding text is the delegated regulation above, and it is written as segregation of duties and user accountability, not as a signature count.
The AI Act's two-person rule is not general. Article 14(5) requires that "no action or decision is taken ... unless that identification has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority", and it binds only the systems in Annex III point 1(a), remote biometric identification. It is disapplied for certain law enforcement, migration, border control and asylum uses (Regulation (EU) 2024/1689). An agent deleting a production database is not covered by Article 14(5). The clause by clause position is set out in agent controls mapped to DORA, the AI Act, NIS2 and ISO 27001.
How is it built for an agent?
- Name the approvers in advance. In policy, as identities, rather than as whoever holds a role that day.
- Bind the approval to the action. The signature covers the bytes of the action. A signature over a request identifier lets the request change underneath it.
- Use n-of-m for availability. Two of five named approvers survives holidays. Two of two does not.
- Enforce at the point of effect. The count is checked where the credential is used. A count checked in the interface that collected the clicks is a display, not a control.
- Make the two channels independent. If both approvals arrive over the path the agent can write to, one compromise produces both.
- Keep the approver's key off the agent's machine. The key that confirms must not be reachable by the thing being confirmed.
- Expire, and expire toward nothing. An unmet quorum ends with no action.
Where does dual authorization fail?
- Two identities, one person. The commonest defeat, and it is an identity lifecycle problem rather than a cryptographic one.
- A shared service account. Accountability collapses, which is exactly what Article 21(c) above is written against.
- Binding failure. The approvals are checked, then a different object runs. This is a substitution attack, not a policy question.
- Replay. A valid pair of signatures reused for a second action. The approval needs a nonce and a single-use claim.
- Break-glass. An emergency path with one approver, used routinely, is the real control.
- Volume. Put every action behind two humans and the control is switched off within a month. The failure modes of human gates are covered in human-in-the-loop for AI agents.
- No record. Two people agreeing without evidence is a memory, not a control. See the AI agent audit trail.
How does ZIFFER implement it?
ZIFFER calls the arrangement a quorum, and holds an action at or above its policy floor until the required number of distinct signing identities have signed the exact bytes that will run. Two confirmations from one approver count as one approver, the check is on the signing identity rather than the name in the message, the quorum is verified at the executor before your credential is used, and a quorum that does not form ends with nothing run. The approvers are named in the signed policy bundle, so the set cannot be widened without a new signature and a higher epoch. The exact definitions, including what a quorum is not, are in the concepts page.