A real mailbox, a fake request
On 12 September 2026 Revolut confirmed that it had handed customer data to someone who had no right to it. The Financial Times put the number of customers at around 680, mostly in Switzerland and France. What went out was the kind of data a bank collects at onboarding: identity documents, addresses, phone numbers and, according to reports, verification selfies and transaction histories.
Nobody broke into Revolut, and Revolut says its systems and customer funds were not affected. The requests came from the genuine certified mailbox (PEC) of an Italian government agency. Threat-intel firm Hudson Rock says the credentials came from infostealer logs of a government employee, most likely bought rather than harvested by the attacker, and that the requests went on for around five months. They looked routine and were answered. Only later messages raised doubts, and when Revolut contacted the agency, the agency said it had never sent them. Italy’s Polizia Postale is now investigating for unauthorised access and computer fraud.
Revolut called it “a sophisticated external impersonation scam”. I don’t think it was. If Hudson Rock is right, the attacker didn’t phish anyone or write any malware: someone else’s infostealer had already done that part, and the credentials were for sale. After that, the attack was an email. It needed no zero-day and no deepfake. It needed a password that leaked from one side, and someone on the other side who trusted the mailbox more than the request inside it.
A public body is expected to train its staff on exactly this. Italian public employees owe 40 hours of training a year since 2025 (though cybersecurity isn’t among the mandatory topics), and bodies under NIS2 must have a documented cybersecurity training plan in place by 31 October 2026, seven weeks after Revolut went public. Whether that training happened here, we don’t know. What we do know is that stolen credentials were enough to send legally binding email in a government agency’s name — so either the training didn’t stick, or the risk was never taken seriously enough to put anything behind the password. On the other side, the same pattern: a process that released customer data because the envelope looked right.
What a PEC actually proves
If you don’t work in Italy, you have probably never heard of PEC (Posta Elettronica Certificata). It is certified email with legal value, the digital version of a registered letter with proof of delivery. Companies, professionals and public bodies are required to have one, and courts, tax offices and ministries use it for anything that has to stand up legally.
The mechanics are simple. The sender’s provider wraps the message in a signed envelope and certifies that it left a given mailbox at a given time; between two PEC mailboxes, the recipient’s provider also certifies delivery. The content can’t be altered on the way, and the sender can’t later deny having sent it. Even when a PEC lands in an ordinary inbox, it arrives inside that signed envelope, and the recipient’s mail client shows signatures and certificates that look official.
What a PEC does not prove is who was logged into the mailbox when the message was sent, or whether the request inside it is legitimate. The seal certifies the mailbox. It says nothing about the person using it or what they’re asking for.
This is how email security in general works, and anyone who has set up SPF, DKIM or DMARC knows it: authentication tells you the message came from where it claims, not that it’s honest. The difference with PEC is how people read it. A normal email from a government domain still makes some people pause. A PEC from a government domain, with every seal valid, reads as settled. The attacker didn’t have to fake any trust signal, because every one of them was real.
Failure one: the shared mailbox
We don’t know how the agency’s mailbox was run. I do know how office PEC mailboxes are run in more than one organisation I’ve supported, and it isn’t reassuring.
A PEC address usually belongs to the office, not to a person. Legal, accounting and administration all need to read it, sometimes because internal policy says so, often because there aren’t enough people to give each department its own. So the password gets shared. It ends up in an email, a chat, a spreadsheet, sometimes on a post-it. Multi-factor authentication is usually off, because it would tie the mailbox to one phone, and the phone belongs to one person.
Then there’s IMAP. People prefer their mail client to the provider’s webmail, so the PEC gets configured in Outlook or Thunderbird on several laptops. At that point the perimeter of a legally binding mailbox is every laptop it’s configured on, and those laptops are also the ones where infostealers look for saved credentials.
The rules to prevent this exist. ACN, Italy’s national cybersecurity agency, publishes guidelines, and public bodies are supposed to follow them. They get skipped for the usual reason: they slow down the normal work, and nothing bad has happened yet.
Two details make this worse than it looks:
- MFA doesn’t cover IMAP. The move from PEC to REM, the European standard for registered email, will make two-factor authentication mandatory. The deadline has slipped more than once and still isn’t fixed, so today it’s opt-in. And once you turn it on, mail clients don’t go through it: one of the largest Italian providers issues a separate “password for mail programs”, valid for three months, that works without the second factor. An infostealer that grabs that password gets the mailbox, MFA or not.
- No IP restrictions. Italian PEC providers generally don’t let the owner restrict access to company IPs or a VPN. I used to assume the law required access from anywhere. It doesn’t: I went through the decree and AgID’s technical guidelines, and nothing in them forbids it. It’s a product choice, which means it’s also something you can ask your provider for.
Failure two: trusting the seal
The second failure is on the receiving side, and it’s the one I find more interesting, because it comes from what people have been taught.
In Italy, PEC is presented as the safe channel. It has legal value, it has seals, it has certificates. Companies train their staff to treat PEC differently from ordinary email, and they’re right to, for the purpose PEC was designed for: proving that a message was sent and delivered. The problem is that the reasoning quietly extends one step further. “A PEC came from this address, so the sender is genuine, so the request is legitimate.”
The first step is true, the second is an assumption, the third is the attack. A phone call to the agency, on a number found independently and not taken from the email, would have stopped it on the first request. That’s exactly what eventually happened: when Revolut contacted the agency, the scheme was over. It just happened months later than it could have.
The second check gets skipped precisely because the channel looks so trustworthy. Nobody calls back to confirm a registered letter on official letterhead. The attacker didn’t have to beat the seals. They only had to make sure nobody looked past them.
When training does work
I’m not arguing that training is useless. I’ve seen it work.
A workstation I was looking after had its endpoint protection temporarily disabled: there was a known issue on that machine, and the fix was in progress. During that window a PEC arrived with an attachment called something like urgent_supply_invoice_<plausible number>.pdf.xlsx. The user was about to download it, stopped, and called me: “The PEC looks fine, but this file looks suspicious. What do you think?”
The machine wasn’t infected. No technical control stopped it, because the technical control was off. What stopped it was a person who had been trained often enough that the double extension triggered a reflex, even inside a message that “looked fine”.
Notice the wording, though: the PEC looked fine. Even there, the channel got a pass, and it was the attachment that raised the alarm. With a clean request and no attachment, like the ones Revolut received, there would have been nothing to trip over.
That’s the honest place for training. It’s the last line, the thing that’s left when the controls fail, and it works when it’s constant rather than a yearly slideshow. But it’s one person in one moment. You can’t build a process on the assumption that the person will always stop and think.
What CISOs and ISMS managers have to enforce anyway
Everything below slows someone down. That’s the point, and it’s why the CISO and the ISMS manager have to monitor it and enforce it even when people grumble. Prevention is tiring. Cleaning up afterwards is much worse.
On the mailbox side:
- Pick a provider that supports multiple named users on a single PEC mailbox, with MFA mandatory for each of them. Turn MFA on now; don’t wait for the REM deadline.
- If your provider doesn’t support multiple users, treat the credentials like a bank card PIN. Nobody keeps their PIN on a post-it in their wallet, of course. Store them in a shared password vault, or in encrypted files on a private company drive, or on an intranet that requires proper verification to reach.
- The MFA factor is tied to a single channel, so it becomes the real key. Never share it with anyone who isn’t authorised, and pass a code on only after you’re certain who is asking: in person, or by calling them back after a request arrives by email, SMS or WhatsApp.
- If the PEC runs over IMAP, the laptops are part of the perimeter. Endpoint protection that stays on, patching, disk encryption, and no PEC password saved in the browser.
- Ask your provider for IP or VPN restrictions. Nothing in the rules prevents them from offering it.
On the receiving side:
- Any request for customer or personal data gets an out-of-band check, on a contact you found yourself, whatever channel it came in on.
- A valid seal is evidence of the sender’s mailbox, not of the request. Write that into the procedure, so nobody has to remember it.
Takeaways
- A PEC seal certifies the mailbox, not the person using it or the request inside it.
- A shared PEC password without MFA is a legally binding mailbox protected by a post-it.
- With IMAP on, MFA stops at the webmail: the laptops are the perimeter.
- Verify every data request out of band, on a number you found yourself.
- Train constantly, but design the process for the day the training doesn’t work.