Le cas Revolut montre qu’un message peut \u00eatre techniquement authentifi\u00e9 et contenir une demande non autoris\u00e9e, faille que les m\u00e9canismes classiques de s\u00e9curit\u00e9 des e-mails ne suffisent pas, \u00e0 eux seuls, \u00e0 combler. Avant de transmettre des donn\u00e9es sensibles, les entreprises doivent donc v\u00e9rifier l’origine du message, mais aussi confirmer de mani\u00e8re ind\u00e9pendante l’identit\u00e9 du demandeur, la r\u00e9alit\u00e9 du dossier concern\u00e9 et l’autorisation de transmettre les donn\u00e9es. Ces contr\u00f4les suppl\u00e9mentaires ne ralentissent pas n\u00e9cessairement les processus lorsqu’ils sont int\u00e9gr\u00e9s aux proc\u00e9dures de validation existantes en fonction des risques.<\/strong><\/p>\n L’essentiel en bref<\/p>\n \u00c0 lire aussi :<\/strong> MFA r\u00e9sistante au phishing : CISA, FIDO et USDA \u00b7 Des attaquants lisent des fichiers GitLab sans s’authentifier<\/p>\n Le 12 septembre 2026, on apprenait que la banque num\u00e9rique Revolut avait communiqu\u00e9 des donn\u00e9es personnelles sensibles \u00e0 un tiers non autoris\u00e9, apr\u00e8s avoir re\u00e7u des demandes de renseignements frauduleuses envoy\u00e9es depuis une adresse e-mail relevant du domaine l\u00e9gitime d’un organisme gouvernemental<\/a>. Selon les rapports, environ 680 personnes<\/a> ont \u00e9t\u00e9 touch\u00e9es au total, les informations divulgu\u00e9es comprenant, selon la personne concern\u00e9e, notamment des copies de passeport, des images de v\u00e9rification d’identit\u00e9 ainsi que des donn\u00e9es de compte et de transaction. Dans le m\u00eame temps, Revolut d\u00e9clarait que ses syst\u00e8mes et les fonds de ses clients n’avaient pas \u00e9t\u00e9 compromis<\/a>.<\/p>\n Quelques jours plus tard, le groupe \u00ab IAmNotAVillain \u00bb a publi\u00e9 une demande de ran\u00e7on \u00e0 hauteur de plusieurs millions, payable en Monero<\/a>, et a menac\u00e9, \u00e0 d\u00e9faut, de vendre les donn\u00e9es. On ne peut pas confirmer \u00e0 ce jour, de mani\u00e8re ind\u00e9pendante, si toutes les informations publi\u00e9es proviennent r\u00e9ellement de l’incident Revolut et quelle est l’\u00e9tendue totale du jeu de donn\u00e9es.<\/p>\n Contrairement aux attaques classiques par ran\u00e7ongiciel, le levier de pression n’est pas ici un syst\u00e8me chiffr\u00e9, mais la possession de donn\u00e9es sensibles et la menace de leur publication ou d’un usage abusif suppl\u00e9mentaire. Or, des informations telles que des donn\u00e9es de passeport, des images de v\u00e9rification ou des donn\u00e9es financi\u00e8res peuvent, longtemps apr\u00e8s une attaque, servir \u00e0 l’usurpation d’identit\u00e9, au social engineering ou \u00e0 de nouvelles tentatives de chantage.<\/p>\n L’incident montre ainsi \u00e0 quel point des contr\u00f4les suppl\u00e9mentaires s’imposent avant de remettre des donn\u00e9es sensibles. C’est pr\u00e9cis\u00e9ment l\u00e0 qu’appara\u00eet la limite des proc\u00e9d\u00e9s \u00e9tablis d’authentification e-mail : ils peuvent v\u00e9rifier qu’un message a bien \u00e9t\u00e9 envoy\u00e9 techniquement via le domaine et l’infrastructure attendus, mais non que la demande concr\u00e8te est r\u00e9ellement autoris\u00e9e. Ces proc\u00e9d\u00e9s incluent SPF, DKIM et DMARC. SPF v\u00e9rifie si un serveur est autoris\u00e9 \u00e0 envoyer au nom d’un domaine, DKIM contr\u00f4le l’int\u00e9grit\u00e9 du message au moyen d’une signature cryptographique et DMARC recoupe les domaines utilis\u00e9s et d\u00e9finit le traitement des authentifications \u00e9chou\u00e9es.<\/p>\n Pour les divulgations de donn\u00e9es sensibles, les entreprises devraient donc examiner quatre points s\u00e9par\u00e9ment. Elles doivent \u00e9tablir si le message a r\u00e9ellement \u00e9t\u00e9 envoy\u00e9 via le domaine indiqu\u00e9, si la personne habilit\u00e9e contr\u00f4le le compte utilis\u00e9 et si la demande se rapporte \u00e0 un dossier r\u00e9el et autoris\u00e9. Elles devraient en outre v\u00e9rifier si l’\u00e9tendue et la nature de la divulgation exig\u00e9e sont r\u00e9ellement n\u00e9cessaires. L\u2019authentification technique des e-mails r\u00e9pond avant tout \u00e0 la question de l\u2019origine du message. Pour le reste, il faut des preuves suppl\u00e9mentaires, aussi ind\u00e9pendantes que possible les unes des autres.<\/p>\n D\u00e9finition \u00b7 Authentification e-mail<\/p>\n Qu’est-ce que l’authentification e-mail ?<\/strong> L\u2019authentification technique des e-mails r\u00e9pond avant tout \u00e0 la question de l\u2019origine du message. Pour tout le reste, il faut des preuves suppl\u00e9mentaires, aussi ind\u00e9pendantes que possible.<\/p>\n<\/div>\n L\u2019utilisation abusive de comptes de messagerie d\u2019autorit\u00e9s jug\u00e9s fiables pour adresser des demandes de renseignements frauduleuses n\u2019est pas un ph\u00e9nom\u00e8ne isol\u00e9. Le FBI alertait d\u00e9j\u00e0 en 2024<\/a> sur des cas o\u00f9 des comptes e-mail gouvernementaux am\u00e9ricains et \u00e9trangers compromis servaient \u00e0 des Emergency Data Requests frauduleuses.<\/p>\n Comme un e-mail techniquement authentifi\u00e9 ne suffit pas, \u00e0 lui seul, \u00e0 confirmer qu’une demande est autoris\u00e9e, les entreprises devraient mobiliser des crit\u00e8res de contr\u00f4le suppl\u00e9mentaires et ind\u00e9pendants de cette authentification. La demande peut par exemple \u00eatre confirm\u00e9e par un canal de contact d\u00e9j\u00e0 \u00e9tabli ou d\u00e9termin\u00e9 de mani\u00e8re ind\u00e9pendante. Un num\u00e9ro de t\u00e9l\u00e9phone figurant dans l’e-mail re\u00e7u ne sert pas \u00e0 cet effet, pas plus qu’une demande de confirmation envoy\u00e9e \u00e0 la m\u00eame adresse e-mail. En revanche, un interlocuteur d\u00e9j\u00e0 enregistr\u00e9, un annuaire officiel ou un contact connu de l’autorit\u00e9 comp\u00e9tente conviennent.<\/p>\n Le dossier lui-m\u00eame offre des points d’appui : la r\u00e9f\u00e9rence du dossier, l’autorit\u00e9 \u00e9mettrice, la base juridique et la comp\u00e9tence peuvent \u00eatre recoup\u00e9es via des syst\u00e8mes distincts ou des contacts connus. Il convient en parall\u00e8le de v\u00e9rifier si la nature et l’\u00e9tendue des donn\u00e9es exig\u00e9es correspondent au but indiqu\u00e9. M\u00eame une demande l\u00e9gitime ne justifie pas automatiquement la remise de toutes les informations disponibles. Les entreprises ne devraient donc transmettre que les donn\u00e9es r\u00e9ellement n\u00e9cessaires en droit pour le cas concern\u00e9.<\/p>\n L’historique des demandes re\u00e7ues par l’entreprise sollicit\u00e9e constitue un autre niveau de contr\u00f4le. Les syst\u00e8mes de gestion des dossiers montrent si le m\u00eame demandeur a d\u00e9j\u00e0 pris contact auparavant, quels formats de documents et canaux de transmission sont usuels et quel volume de donn\u00e9es est habituellement demand\u00e9. Des \u00e9carts ne signalent pas n\u00e9cessairement une attaque, mais peuvent d\u00e9clencher un contr\u00f4le suppl\u00e9mentaire. Le simple historique e-mail est moins fiable \u00e0 cette fin, car un attaquant ayant acc\u00e8s \u00e0 une bo\u00eete mail peut aussi consulter les correspondances ant\u00e9rieures.<\/p>\n\n
Authentifi\u00e9 ne veut pas dire autoris\u00e9<\/h2>\n
R\u00e9partir la confiance sur plusieurs syst\u00e8mes<\/h2>\n
![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/11\/net-kubernetes-patches-enden-amazon-rechnet-61691164.jpg\")
<\/span>