Dual control is not dual when both approvers are behind the same phishing kit.

Two approvers on every large payment is the oldest control in finance and one of the best. It works because the two approvals are independent events. Session theft quietly removed the independence about four years ago, and most treasury teams have not noticed, because the audit log still shows two names.

The invitation arrives at 9:14 on a Thursday and looks like a scheduling nuisance rather than an attack. It is a Teams meeting for a quarterly supplier review, forwarded from a genuine address inside a genuine supplier organisation, with a link to a shared document that needs a quick sign in. The treasury analyst clicks it while eating a sandwich, authenticates against her company's real single sign on page, satisfies the number matching prompt on her phone, sees a slightly dull spreadsheet, and forgets about it entirely.

Forty minutes later the assistant treasurer clicks the same forwarded invitation, because he was copied on the same thread and the same document needs the same review. He authenticates. He number matches. He sees the same dull spreadsheet.

Nine days later, a payment of one million four hundred thousand dollars is initiated in the treasury management system under the analyst's account, to a supplier in the vendor master file whose bank details were updated on the same day. Sixteen minutes after that, it is approved under the assistant treasurer's account. The system enforced its dual control policy correctly. It refused to release on a single approval. It required a second, distinct, named user, and it got one.

When the recall attempt fails on Monday and the incident review starts on Tuesday, the first artifact anybody opens is the approval log. It shows two approvals, two different user identifiers, two different timestamps sixteen minutes apart, both with valid authenticated sessions, both with multi factor authentication satisfied earlier that morning. There is nothing anomalous in it at all. The company's controls performed exactly as documented, and the money is gone, and the reason those two facts sit comfortably together is the subject of this lesson.

What does dual control actually assume?

Segregation of duties is an unusually good control, and it is worth understanding why before understanding how it breaks.

The premise is probabilistic. If the chance that any one approver is compromised or corrupt in a given period is small, call it p, then the chance that two of them are compromised simultaneously is p squared. If a single approver has a one in a thousand chance of being a problem, two approvers give you one in a million. That is an enormous improvement for a very cheap organisational change, which is why the two person rule shows up everywhere from nuclear weapons handling to pharmacy dispensing to the release of a wire.

But look closely at that multiplication, because everything depends on it. Multiplying the probabilities is only valid if the two events are independent. The moment the two failures share a common cause, the arithmetic is not merely less favourable, it is wrong. It stops being p squared and becomes something much closer to p, because a single event now takes out both.

The fuel tank

Here is the analogy worth keeping. A twin engine aircraft is safer than a single engine aircraft because the chance of both engines failing on the same flight is the product of two small numbers. That reasoning is sound, and it is why the second engine exists.

Now suppose both engines draw from the same fuel tank, and the tank is contaminated. You have not halved your risk. You have paid for a second engine and received nothing, because the redundancy was never real. The two engines look independent on the diagram. They are not independent in the failure mode that actually occurs.

Every serious engineering discipline has learned this lesson expensively, and has a name for it: common mode failure, or common cause failure. Aviation, nuclear power, and structural engineering all design explicitly against it, on the understanding that redundancy without independence is decoration.

Financial controls, for the most part, have not had that conversation. Dual approval is drawn on the control diagram as two independent boxes. In almost every implementation shipped in the last decade, both boxes are fed from the same tank, and the tank is the browser session.

How does one phishing kit collect two approvers?

Adversary in the middle phishing is the mechanism, and it is worth being precise about how it works, because the precision is what makes the conclusion unavoidable.

A traditional phishing page is a copy of a login screen. It captures a password and, historically, that was enough. Multi factor authentication broke that model, because a captured password is useless without a second factor, and second factors are time limited.

An adversary in the middle kit does something structurally different. It is not a copy of the login page. It is a reverse proxy sitting between the victim and the genuine identity provider. The victim's browser talks to the kit; the kit talks to the real Microsoft or Okta endpoint and relays every byte in both directions. The page the victim sees is not an imitation, because it is being served through from the real thing, complete with the correct tenant branding, the correct behaviour, and the correct certificate on the attacker's own domain.

The victim types a password. The kit forwards it. The real identity provider issues a real multi factor challenge. The victim's phone buzzes with a genuine prompt from a genuine service, because it is genuine. The victim number matches, confirms with a fingerprint, and authenticates successfully against the real provider.

At that moment the identity provider does what it is supposed to do: it issues a session cookie. That cookie travels back through the proxy, and the kit keeps a copy. The victim is forwarded to whatever innocuous document the lure promised and notices nothing, because nothing went wrong from their perspective. Authentication succeeded. It was supposed to.

The attacker now holds a bearer token. Not a password to try, not a code that expires in thirty seconds, but the artifact that the whole authentication ceremony existed to produce. They can replay it into their own browser and be that user, without a password, without a prompt, and without generating a sign in event, until the session expires. We walked through this attack in detail in your MFA worked perfectly, the attacker was already inside the session.

Now run it twice

Here is the part that specifically dismantles dual control, and it requires no additional cleverness at all.

The kit does not care how many people click the link. It is a proxy. If one person clicks it, it harvests one session. If both approvers click it, and they will, because the lure was forwarded into a thread they are both on and it concerns work they both do, then it harvests two sessions. The marginal cost to the attacker of collecting the second approver is one additional click by someone else. There is no second attack to mount. There is one attack, and it collects everyone who touches it.

This is not a theoretical capability. Phishing as a service made it routine. The Tycoon 2FA platform, active since 2023, is reported to have affected more than 96,000 victims and was running on 330 domains that were seized when Microsoft, Europol and industry partners disrupted it in an action reported in March 2026 (Microsoft Security). Sekoia's threat research team identified eleven distinct adversary in the middle kits in active commercial operation in the first four months of 2025, with Tycoon the most prevalent. Barracuda reported in April 2026 that after the takedown the model scattered rather than died. Business email compromise, the loss category these kits feed, accounted for $3.05 billion in reported United States losses across 24,768 complaints in 2025 (FBI IC3 2025 Internet Crime Report).

The attacker running the kit does not need to know your approval matrix, your payment limits, or which two people your policy requires. They collect sessions indiscriminately and read your organisational chart afterwards, from your own mailboxes.

Why does the audit log look perfectly clean?

This is the part that makes incident reviews so disorienting, and it deserves its own section because the answer is uncomfortable.

The audit log is not lying. It is not incomplete. It accurately records what happened: two approvals arrived, associated with two distinct user identifiers, from two authenticated sessions, at two different times. Every one of those statements is true.

The problem is what the log is a record of. It records what the sessions did. It was interpreted, by everyone reading it, as a record of what the humans decided. Those were the same thing back when the only way to have a session was to be the person, and they quietly stopped being the same thing when sessions became stealable at scale.

So the log tells you that two sessions approved a payment. It cannot tell you that two humans approved a payment, because it never contained that information. Nobody removed it. It was never captured. An auditor sampling this control will find two approvals and tick the box, because the evidence the control produces is exactly the evidence the auditor was told to look for, and neither the evidence nor the auditor is equipped to distinguish two people from one attacker with two cookies.

That gap has downstream consequences beyond the loss itself. Crime and cyber insurance policies frequently price on the presence of dual authorisation. A company that discovers its dual control was defeated by relayed sessions is in the awkward position of having genuinely operated the control it attested to, while the control provided none of the protection the premium was calculated against.

What does a payload bound approval look like?

The fix follows directly from the diagnosis. If the problem is that approvals inherit their authority from a session, then the approval must carry its own authority, and it must be inseparable from the thing being approved.

Concretely, an approval stops being an HTTP request that arrives inside an authenticated session, and becomes a cryptographic assertion produced on a device that was enrolled to a specific human, over a digest of the payment payload itself.

Start with the canonical payload. Both the approver's device and the verifying server must agree byte for byte on what is being approved, so the encoding is fixed: sorted keys, explicit types, integer minor units rather than floating point, an absolute timestamp, and a nonce.

{
  "act": "payment.approve",
  "payment_id": "PMT-2026-09-118842",
  "beneficiary": "Halvorsen Industrial AS",
  "iban_sha256": "4c8b...e910",
  "amount_minor": 140000000,
  "currency": "USD",
  "value_date": "2026-09-08",
  "initiated_by": "u_4471",
  "nonce": "7c1d9a02f5be4431"
}

Each approver's device receives that payload, renders the beneficiary, the amount and the value date on its own screen, and asks for a fingerprint. What it returns is a WebAuthn assertion whose challenge is the SHA-256 of the canonical payload. Not a random challenge. The payload digest.

That distinction is the whole control. A signature over a random challenge proves a key was present. A signature over the payload digest proves a key was present and that whoever held it was confirming these specific values. You cannot lift such a signature onto a different beneficiary or a different amount, because the digest would change and the signature would fail.

The server side verification of a two approver quorum is short enough to read in one sitting:

digest = sha256(canonical_json(payment))
valid  = []

for a in submitted_assertions:
    assert a.challenge == digest                   # signed THIS payment
    assert a.credential_id in enrolled_keys()      # a key we enrolled
    assert verify_signature(a, pubkey_for(a.credential_id))
    assert now - a.signed_at < 180                 # fresh, not replayed
    valid.append(subject_of(a.credential_id))

assert len(set(valid)) >= 2                        # two DISTINCT humans
assert initiator_id not in valid                   # approver != initiator

release(payment, receipts=submitted_assertions)    # keep both receipts

Read the assertion on the second to last line carefully. It is not checking for two approvals. It is checking for two distinct credential identifiers, each mapped to a different enrolled human, each having signed this exact payment digest within the last three minutes. Two stolen session cookies satisfy none of those conditions. They do not produce assertions at all, because the private keys never left the secure elements of two phones that are in two different pockets.

What comes out the other end

The two assertions are retained as receipts. Each verifies offline against a published Ed25519 key, with no callback to any vendor, which means the bank, the auditor, and the insurer can each check independently, years later, that this specific payment payload was confirmed by two specific enrolled humans. The control now produces evidence about people rather than evidence about sessions, and that is the difference the incident review on Tuesday morning needed.

How does this restore independence?

Return to the fuel tank. The failure of dual control was not that there was only one approver. It was that both approvers drew authority from the same contaminated source. Fixing it means giving each approval its own source.

A device bound signature does exactly that. Approver A's authority comes from a private key in the secure element of A's phone. Approver B's comes from a different key in a different secure element in a different phone. There is no shared artifact between them that an attacker can steal in one operation. Compromising both now requires compromising two physical devices held by two people, which is the threat model dual control was designed for and was silently no longer providing.

Notice that the first five rows are not useless. Device compliance and conditional access genuinely raise attacker cost, and you should keep them. The point of the table is narrower and sharper: none of the first five rows produces an artifact that is bound to the payment, and therefore none of them can distinguish two humans from one attacker holding two cookies.

What do SOX, PCI DSS and NIST actually require?

You will need to make this argument to people who think in frameworks, so here are the hooks, stated carefully.

Sarbanes Oxley. Dual authorisation over payments is commonly designated a key control in the internal control over financial reporting programme, tested annually by both internal and external audit. The framework requires that the control operate effectively. It does not specify a cryptographic standard, which means the burden falls on the organisation to justify that its implementation still achieves segregation of duties under current threat conditions. The relayed session scenario is the question your auditor has probably not asked yet and increasingly will.

PCI DSS version 4. Requirement 8 addresses authentication, and version 4 pushes toward phishing resistant mechanisms for access to cardholder data environments (see the PCI Security Standards Council document library). The relevant observation for finance teams is directional rather than literal: the standards bodies have accepted that phishing resistance is now a requirement rather than an aspiration. Once you accept that for login, the obvious follow up question is what phishing resistant approval means, and the standard does not yet answer it.

NIST SP 800-63B. The digital identity guidelines define authenticator assurance levels and, importantly for this argument, discuss verifier impersonation resistance, which is precisely the property that defeats a relay. A control that depends on a bearer session cookie inherits none of that resistance for actions taken after the login. The guidelines are about authentication rather than transaction authorisation, and that boundary is exactly where the gap lives.

PSD2 dynamic linking. The most useful precedent is European. The regulatory technical standards on strong customer authentication require that authentication codes for payments be dynamically linked to the specific amount and payee, so that a code cannot be reused for a different transaction (European Banking Authority). That is payload binding, mandated, and it exists because regulators concluded that authenticating the person without binding the transaction was insufficient. The mechanism described in this article is that same principle applied to internal approvals rather than to consumer payments.

Honest limits

Being precise about what this does not do is how you deploy it against the right problem.

It binds intent, not judgment. If both approvers are separately socially engineered, look at a beneficiary name that seems plausible, and consciously approve, you will get two perfectly valid signatures. They meant it. They were wrong. This control removes the class of attack where approvals are forged; it removes none of the class where approvals are elicited. That is why it belongs alongside, not instead of, callback discipline on supplier bank detail changes and a signature on the payee add itself, which is where most of that deception is actually staged.

Collusion is out of scope. Two humans who agree to defraud their employer will produce two valid signatures with clean receipts. Dual control never addressed collusion either; it addressed unilateral action and unilateral compromise. The receipt does at least make the collusion undeniable afterwards, which is a real if grim benefit.

Threshold signing is not the same thing, and we have not shipped it. What is described here is N independent signatures, collected and verified together. It is not an M of N threshold scheme where a single combined signature is produced from partial shares. Threshold signing is on our roadmap and is not available today. For the treasury use case the practical difference is small, but the words matter and you should not buy one believing you are getting the other.

Device enrollment is the trust bottleneck. Everything rests on the claim that each enrolled key belongs to the approver it is mapped to. Enrollment deserves more ceremony than any approval that follows it, and every approver needs a second enrolled authenticator so that a lost phone does not become a policy exception at the worst possible moment.

Somebody will be on a plane. Payment windows are unforgiving and approvers travel. If you do not design a constrained fallback deliberately, the organisation will improvise one under deadline pressure, and the improvised path will become the attack surface. Design it, log it, cap it by amount, and review every use.

It does not protect the payment file after release. A signature on the approval does not defend the integrity of the file in transit to the bank, or the bank's own processing. Those need their own controls.

What to do this week

1. Ask your treasury platform one question in writing. Is approval a session action or a signed action? Specifically: if an attacker held a valid session cookie for an approver, could they approve a payment? Most vendors have never been asked and the answer is instructive.
2. Run the cookie test in a controlled way. With authorisation and in a test tenant, export an authenticated session for an approver account, load it in a clean browser profile, and attempt an approval. This takes an afternoon and ends every remaining debate.
3. Check whether your two approvers can be reached by one lure. Look at whether they sit on the same distribution lists, threads and calendars. If a single forwarded invitation lands in front of both, your two controls have one shared input.
4. Look at your last four large payment approvals in the log. Ask what evidence exists that a human, rather than a session, made each one. If the honest answer is none, that is the finding to bring to your next control review.
5. Read your crime and cyber policy language on dual authorisation. Understand what you have attested to and whether your implementation supports the attestation under a session theft scenario.
6. Pick one payload bound approval to pilot. Choose payments above a threshold where the volume is low and the value is high. This is the easiest possible internal sell, because nobody argues that a seven figure wire deserves a fingerprint.
7. Retain the receipts where audit can reach them. Evidence that verifies offline is only useful if the auditor can find it. Store the receipts with the payment record, not in a security tool nobody outside the security team can query.

If you want to see a step up signature on a privileged action before designing around it, there is a working demonstration at the privileged action lab, and the API reference is in the documentation. The same pattern applied to a single high value release is covered in the deepfake got on the video call, it still could not sign the wire.

Frequently asked questions

Does dual approval still stop wire fraud when MFA is bypassed? No. Dual control works because two approvals are independent events, and that independence disappears when both approvals are clicks inside browser sessions that one adversary in the middle kit has relayed. The attacker holds two cookies and approves as two people. Only approvals that are device bound signatures over the payment payload remain independent under session theft.

What is adversary in the middle phishing? It is a phishing technique that proxies the genuine login page rather than imitating it. The victim authenticates against the real identity provider, multi factor and all, and the proxy captures the session cookie that authentication produces. Because the login genuinely succeeded, nothing looks wrong to the victim and no failed sign in event is generated.

Is number matching phishing resistant? Number matching defeats prompt bombing, where an attacker spams push notifications hoping for an accidental approval, and it is worth enabling. It does not defeat a relay, because in a relay the user is deliberately completing a legitimate challenge. It hardens the login and leaves everything after the login untouched.

Would conditional access or device compliance have stopped this? They raise the cost meaningfully and you should keep them. They constrain where a session can be used rather than binding an approval to a payment, so a sufficiently determined relay operating from a compliant context still yields approvals that carry no proof of who made them.

What counts as a phishing resistant approval for payments? The standards define phishing resistance for authentication rather than for approval, which is the gap. In practice an approval is phishing resistant when it is a fresh assertion from a registered authenticator whose challenge is derived from the transaction payload, so the approval cannot be replayed against different details. The European dynamic linking requirement under PSD2 is the closest regulatory precedent.

Do we still need two approvers if approvals are signed? Yes. Signing fixes the independence of the two approvals, it does not remove the reason for having two. The second approver exists to catch error, unilateral action and coercion, and those reasons are unaffected by cryptography.

How does an auditor test this control? They sample payments and verify the retained receipts against the published key, confirming that each approval matches the payment payload and maps to a distinct enrolled human. That is a materially stronger test than reading a list of usernames in a log, and it can be performed without trusting the application that produced it.

Sources

1. Microsoft Threat Intelligence, analysis of the Tycoon 2FA adversary in the middle phishing kit and the disruption action reported in March 2026, including victim and domain figures. microsoft.com/security/blog
2. Proofpoint threat insight on the disruption of Tycoon 2FA as a phishing as a service platform. proofpoint.com threat insight
3. Sekoia Threat Detection and Research, census of adversary in the middle phishing kits in commercial operation during 2025. blog.sekoia.io
4. Barracuda threat spotlight on the fragmentation of the Tycoon 2FA model following the takedown, April 2026. blog.barracuda.com
5. FBI Internet Crime Complaint Center, 2025 Internet Crime Report, for business email compromise loss and complaint totals. ic3.gov annual reports
6. NIST Special Publication 800-63B, Digital Identity Guidelines, on authenticator assurance levels and verifier impersonation resistance. pages.nist.gov/800-63-3/sp800-63b.html
7. PCI Security Standards Council document library, for PCI DSS version 4 authentication requirements. pcisecuritystandards.org
8. European Banking Authority, regulatory technical standards on strong customer authentication, including the dynamic linking requirement. eba.europa.eu
9. W3C Web Authentication (WebAuthn) Level 3 specification, for assertion and challenge mechanics. w3.org/TR/webauthn-3

Two approvers behind one phishing kit are not two approvers. They are one attacker with better paperwork.