When a Government Email Becomes the Entry Point

The Revolut case reveals a weakness that conventional email security measures alone cannot address: a message can be technically authenticated and still contain an unauthorized request. When sensitive data is requested, companies must check the message origin and independently verify the requester, the underlying case and the authority to disclose. Additional checks need not slow processes down if they are integrated into existing approval procedures based on risk.

Related: Phishing-resistant MFA: CISA, FIDO and USDA · Attackers read GitLab files without a login

On 12 September 2026 it became known that the digital bank Revolut had released sensitive personal data to an unauthorized third party after fraudulent information requests arrived via an email address on the legitimate domain of a government agency. According to reports, around 680 people were affected in total, with the disclosed information including, depending on the person concerned, passport copies, identity verification images as well as account and transaction data. At the same time, Revolut stated that its systems and customer funds had not been compromised.

A few days later, the group “IAmNotAVillain” published a ransom demand worth millions, payable in Monero and threatened to sell the data otherwise. Whether all of the published information really stems from the Revolut incident and how large the dataset is in total has not yet been independently confirmed.

Unlike in conventional ransomware attacks, the leverage here is not an encrypted system but possession of sensitive data and the threat of publishing it or misusing it further. The key point: information such as passport data, verification images or financial records can be abused for impersonation, social engineering or further extortion attempts long after an attack.

Authenticated Does Not Mean Authorized

The incident therefore makes clear how important additional checks are before sensitive data is released. This is where the limits of established email authentication methods become apparent: they can verify whether a message was technically sent via the expected domain and infrastructure, but they cannot verify whether the specific request is actually authorized. These methods include SPF, DKIM and DMARC. SPF checks whether a server is authorized to send on behalf of a domain, DKIM verifies the integrity of the message via a cryptographic signature and DMARC checks alignment between the domains used and defines how failed authentication is handled.

For sensitive data disclosures, companies should therefore check four points separately. They must clarify whether the message was actually sent via the stated domain, whether the authorized person controls the account used and whether the request belongs to a real and authorized case. In addition, they should check whether the scope and type of disclosure demanded are actually necessary. Technical email authentication primarily answers the question of the origin of the message. The remaining questions require additional evidence that is as independent as possible.

The abuse of trusted government accounts for fraudulent information requests is not an isolated occurrence. The FBI warned as early as 2024 about cases in which compromised US and foreign government email accounts were used for fraudulent Emergency Data Requests.

Spreading Trust Across Multiple Systems

Since even a technically authenticated email on its own is not enough to confirm the authority behind a request, companies should apply additional verification criteria that are independent of it. For example, a request can be confirmed via an already established or independently researched contact route. A phone number taken from the incoming email does not serve this purpose, nor does sending a follow-up inquiry to the same mailbox. Instead, use a contact already on file, an official directory or a known contact at the relevant agency.

The case file itself also offers starting points: reference number, issuing agency, legal basis and jurisdiction can be cross-checked via separate systems or known contacts. At the same time, companies should check whether the type and scope of data demanded match the stated purpose. Even a legitimate request does not automatically justify releasing every piece of available information. Companies should therefore transmit only the data that is actually legally required for the specific case.

The records held by the company receiving the request provide another layer of verification. Case management systems show whether the same requester has made contact before, which document formats and transmission routes are usual and what volume of data is typically demanded. Deviations do not automatically indicate an attack, but they can trigger an additional check. A plain email history is less reliable for this, since an attacker with access to a mailbox may also be able to view earlier correspondence.

Finally, special attention should be paid to the destination of the data transfer. If a request suddenly specifies a different transmission route for the data, that should trigger an additional check. This applies, for example, when sensitive information is to be sent to a new email address, a cloud storage service or a previously unknown service instead of the usual government portal. Where possible, government and legal requests should be handled via secure portals protected with phishing-resistant multi-factor authentication. The authority to submit or approve a request should be kept separate from the credentials for the email account.

None of these measures on its own provides complete protection. The goal is therefore to spread the approval decision across several independent anchors of trust rather than to search for the single perfect proof of legitimacy. The more separate systems an attacker has to control at the same time, the harder it becomes to push a fraudulent request through the entire process.

More Verification Without Slowing Operations

Such a chain of checks does not mean that every routine request must be examined fully by hand. Automated checks can help detect deviations from the usual process early and flag unusual requests for further review.

Additional verification steps should kick in when risk is elevated: for example, with a new contact person, a change in the channel used for follow-up communication, unusually extensive demands or particularly sensitive data such as ID copies, biometric material or complete financial histories. Several requests in quick succession, conspicuous sending times, clear deviations from previous behavior or an attempt to bypass regular checks by citing special urgency are also suitable triggers for what is known as step-up verification.

In such cases, confirmation through an independently identified contact can be combined with a second internal approval. In addition, there should be a fast, predefined process for genuine emergencies. Verified contacts available around the clock and clear escalation paths allow companies to respond quickly while maintaining control; if immediate release is necessary, it should initially remain limited to the information actually needed to address the immediate emergency.

Automation can help to build additional controls into the process without unnecessarily slowing it down. Case management systems can compare requests with earlier cases, flag unusual patterns, trigger additional approvals and prevent data from being transmitted to unapproved destinations. Centralized logs also reveal sequences of requests that appear unremarkable individually but, taken together, deviate from the usual pattern.

The Email Is the Beginning of the Review

The Revolut case shows the consequences that arise when the technical authentication of a communication channel is treated as equivalent to the authorization of an action. The goal, however, should not be to distrust legitimate government requests across the board. What matters instead is to design approval processes so that they keep working reliably even when an actually trustworthy communication channel is abused.

Technical email authentication can still form part of the verification process, but it must not become the sole basis for trust. For sensitive data, the release must therefore rest on several independent checks.

Frequently Asked Questions

More from the MBF Media Network

cloudmagazinKubernetes support ends, Amazon charges six times the price

Image source: Acronis

Translated from the German original using artificial intelligence. The German version is authoritative.