Everyone’s talking about the Italian government agency whose compromised inbox helped attackers gain sensensitive data on Revolut customers. The postmortems focus on the phishing, the credential theft, the technical breach. Wrong focus.
The actual vulnerability was structural, and it’s sitting in almost every business’s outbound communication right now: one person can authorize a request, and nobody else has to see it before it goes out.
That’s not a security failure. That’s how email is designed to work.
The single point of failure nobody talks about
Think about how a payment instruction, a contract change, or a wire transfer request actually leaves an organization. Someone drafts an email. They pick who to send it to. Maybe they CC a colleague – maybe they don’t. There’s no structural requirement for a second set of eyes. The system trusts one inbox, one login, one moment of judgment.
When that inbox is compromised, there’s no internal checkpoint to catch it. The attacker doesn’t need to fool an organization. They need to fool – or simply take over – one account.
And the receiving side is just as blind. Revolut had no way to know whether the request they received had been reviewed by anyone on the sending team at all. They saw an email from a known contact. That was the entire trust model.
Two failures, not one
Strip it down and there are two separate gaps here:
- No internal quorum. A single compromised identity can originate an irreversible instruction with zero peer review.
- No external visibility. The counterparty receiving the instruction has no way to verify that anyone else checked it.
Fix only one of these and you’ve still got a hole. Add peer review internally but give the counterparty no way to see it happened, and you’ve made your process safer without making your counterparty any more confident. Give the counterparty a fancy “verified” badge with nothing real behind it, and you’ve built theater, not security.
What an actual fix looks like
The fix isn’t more security awareness training. It’s structural. A request shouldn’t leave a business until:
- It’s visible to everyone on the sending team who has a stake in it, not just the person who drafted it
- A minimum number of people – not one – have actively signed off on it, with their sign-off tied to a real, verifiable identity
- Those approvals are tied to verified identities
- The request remains invisible to the recipient until the required approval threshold is met
- The recipient can see the approval chain and verify who approved it
- The communication, documents and data are encrypted
- The audit trail is tamper-evident and independently verifiable
- Responses and documents are returned through the same secure channel, keeping the entire transaction together
This is dual control, the same principle banks have used internally for payment authorization for decades, applied to the communication channel itself instead of bolted on as a separate internal process that the outside world never sees.
The idea is simple:
Don’t trust the inbox. Trust the organisation’s approval.
A request is created by one person.
Their team sees it.
The required people approve it.
Only then is it released through a secure channel.
And the receiving organisation can see the full approval trail.
Not just:
“This came from someone at your organisation.”
But:
“This request was created by X, reviewed by Y, approved by Z, and released according to your organisation’s approval policy.”
That’s a fundamentally different trust model.
The interesting shift is the third point. Internal dual control is old news. What’s new – and what actually would have changed the outcome in the Revolut case – is a counterparty being able to see the review happened at all. Right now, that information exists nowhere. Not in the email header, not in the signature block, not anywhere the receiving side can inspect.
Why this matters more than the next phishing headline
Every quarter there’s a new version of this story with a different organization name attached. The lesson people take from it is “train your staff to spot phishing better.” That’s necessary but insufficient – attackers only need to win once, and training doesn’t scale to zero.
The lesson that doesn’t get written often enough: if a single compromised identity can move money or authorize sensitive actions with no structural checkpoint, the process was broken before the phishing email ever arrived. The attacker didn’t create the vulnerability. They found one that was already there.
Fixing that isn’t about better vigilance. It’s about not building single points of failure into how your business communicates in the first place.
