Authentification multifacteur (MFA) : ce que NIS2 et l'assureur exigent, ce qu'un
attaquant contourne

Le 15 septembre 2022, un prestataire d'Uber reçoit sur son téléphone une demande d'approbation de connexion. Puis une autre. Puis d'autres encore, à répétition. Son mot de passe Uber avait été acheté sur le dark web après l'infection de son appareil personnel par un logiciel malveillant, et la double authentification faisait son travail : elle bloquait. Jusqu'à ce que, d'après le communiqué d'Uber, le prestataire en accepte une. L'attaquant, rattaché par Uber au groupe Lapsus$, obtient ensuite des droits élevés sur G Suite et Slack, lit des conversations internes et accède au tableau de bord HackerOne où les chercheurs déclarent les failles.

L'authentification multifacteur était en place ce soir-là. Elle a cédé quand même, parce que le facteur retenu, une notification à approuver, se contourne par l'usure. Quatre prescripteurs vous demandent aujourd'hui du MFA, de NIS2 à votre assureur cyber, avec des exigences très inégales sur le facteur à retenir. C'est pourtant ce choix qui décide de ce qui se passe le jour où quelqu'un possède déjà votre mot de passe.

Authentification multifacteur : trois familles de facteurs, pas trois codes

La définition officielle est plus stricte que l'usage courant. Le ReCyF de l'ANSSI définit l'authentification multifacteur comme une authentification qui combine des facteurs appartenant à au moins deux des trois catégories : la connaissance (un mot de passe, un code PIN), la possession (une application mobile, une carte à puce, une clé matérielle) et l'inhérence (une empreinte, un visage). Un mot de passe suivi d'une question secrète ne fait donc pas du MFA : ce sont deux facteurs de connaissance. Un code TOTP, lui, prouve la possession d'un secret partagé à l'enrôlement, dérivé en six chiffres toutes les 30 secondes par HMAC selon la RFC 6238.

Ce découpage compte pour la suite, parce que chaque famille a ses attaques. Un facteur de possession se vole (téléphone, SIM, jeton de session) ou se relaie (le code tapé sur un faux site) ; un facteur de connaissance se rejoue depuis une fuite ou se demande au téléphone. Et le point faible le plus courant reste le canal qui les combine : un push approuvé sans regarder, ou un SMS qui transite par un réseau téléphonique conçu dans les années 1980.

Ce que NIS2, le ReCyF, la CNIL et l'assureur exigent

NIS2 : l'article 21, paragraphe 2, point j

La directive NIS2 ne détaille pas de technologie, mais elle nomme le MFA dans sa liste de mesures minimales. L'article 21, paragraphe 2 impose que les mesures de gestion des risques comprennent au moins dix familles, dont le point j : "l'utilisation de solutions d'authentification à plusieurs facteurs ou d'authentification continue, de communications vocales, vidéo et textuelles sécurisées et de systèmes sécurisés de communication d'urgence au sein de l'entité, selon les besoins". Les trois derniers mots font tout le débat. Dans la logique du paragraphe 1 du même article, les mesures doivent être proportionnées au risque en tenant compte de l'état des connaissances, et l'état des connaissances sur les accès distants et l'administration est sans ambiguïté depuis des années.

Côté transposition française, au moment de la rédaction (septembre 2026), le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat le 12 mars 2025, figure toujours en première lecture à l'Assemblée nationale sur le dossier législatif du Sénat, sans trace de promulgation. Si vous lisez ceci plus tard, vérifiez. Le calendrier complet et les seuils d'assujettissement figurent dans l'article de référence de ce blog sur la directive NIS2 et son application en France.

ReCyF : l'objectif 10, et la mesure 8.3 pour les entités essentielles

Ce que la directive laisse ouvert, le référentiel de l'ANSSI le ferme en partie. Le ReCyF version 2.5 du 17 mars 2026, encore estampillé "version de travail", consacre son objectif de sécurité 10 à la gestion des identités et des accès : comptes individuels, comptes partagés tolérés seulement avec traçabilité, revue annuelle des comptes et des droits, changement des secrets par défaut avant mise en service. Sur l'authentification elle-même, la mesure 10.B.1 exige au minimum un élément secret, mono ou multifacteur. Le MFA proprement dit arrive à l'objectif 8, sur les accès distants : la mesure 8.3-EE impose, pour les entités essentielles, un mécanisme "multifacteur et repos[ant] sur au moins un facteur de connaissance", l'exemple donné étant la carte à puce avec code PIN. Une entité importante n'y est pas tenue, et la mesure 8.4-EE prévoit l'exception, compensée, quand le MFA est techniquement impossible. Le référentiel est repris objectif par objectif dans l'article consacré au ReCyF, le référentiel de cybersécurité de l'ANSSI.

ANSSI et CNIL : privilégier la possession, se méfier du SMS et de la biométrie

Le guide de l'ANSSI Recommandations relatives à l'authentification multifacteur et aux mots de passe, publié le 8 octobre 2021, pose la ligne : partir d'une analyse de risque, déployer le MFA en priorité, et privilégier les facteurs de possession. La CNIL a complété l'angle données personnelles par sa recommandation relative à l'authentification multifacteur (délibération n° 2025-019 du 20 mars 2025) : connaissance plus possession en contexte professionnel, vigilance sur les codes envoyés par SMS, et une alternative obligatoire à tout facteur d'inhérence, la biométrie engageant des données que l'on ne révoque pas.

L'assureur : la case à cocher qui conditionne le contrat

Reste un prescripteur qu'on n'attend pas dans un chapitre réglementaire, et dont l'exigence tombe souvent avant celle du référentiel. Les conditions de souscription d'une assurance cyber demandent si le MFA est déployé et si les accès distants sont sécurisés, à côté de l'EDR et du test régulier des sauvegardes. Un courtier cité par le Journal du Net en septembre 2025 indique qu'une quinzaine de ses 90 dernières demandes de souscription ont été refusées par les assureurs, le niveau de sécurité étant jugé trop faible. Et une case cochée à tort se retourne contre vous au sinistre : le Code des assurances permet d'opposer une déclaration inexacte à l'assuré (art. L.113-8 et L.113-9). Ce que le contrat exige et ce qu'il exclut est passé en revue dans l'article sur l'assurance cyber et ses conditions de souscription.

Ce qu'un attaquant contourne, technique par technique

Toutes les techniques ci-dessous sont documentées par des incidents publics ou par les éditeurs eux-mêmes, et aucune ne casse la cryptographie : elles contournent le facteur, ou récupèrent ce qu'il produit une fois validé.

Push bombing, ou MFA fatigue

C'est le scénario Uber. L'attaquant possède le mot de passe (acheté, fuité, obtenu par credential stuffing) et déclenche des connexions en rafale. Chaque tentative génère une notification "Approuver / Refuser", et la victime finit par approuver, par lassitude ou parce qu'un message la persuade qu'il s'agit du support informatique. La parade a un nom, le number matching : l'écran de connexion affiche un nombre que l'utilisateur doit ressaisir dans l'application. L'attaquant voit le nombre mais n'a pas le téléphone ; la victime a le téléphone mais pas le nombre. Microsoft l'applique désormais à toutes les notifications push de Microsoft Authenticator, sans possibilité de désactivation par l'utilisateur, et la CISA y consacre une fiche. Si votre fournisseur d'identité propose encore un push à deux boutons sans contexte, vous rejouez Uber.

Adversary-in-the-middle : le relais en temps réel

Le push bombing exploite l'humain. L'AiTM exploite l'architecture. Un outil comme Evilginx (framework open source de Kuba Gretzky, aujourd'hui en version 3) se place en reverse proxy entre la victime et le vrai service. La page de connexion que voit la victime est la vraie, servie à travers le proxy ; le mot de passe, puis le code TOTP ou l'approbation push, sont transmis au service légitime qui répond par un cookie de session. Ce cookie transite par le proxy, qui le copie. L'attaquant n'a pas cassé le MFA : il a laissé la victime le passer pour lui, et il garde le résultat.

L'échelle est documentée par Microsoft : en juillet 2022, une seule campagne AiTM avait visé plus de 10 000 organisations depuis septembre 2021, avec un accès aux boîtes mail dans les cinq minutes, des règles de boîte pour masquer les traces et une fraude au virement en bout de chaîne. En juin 2023, l'acteur suivi sous le nom Storm-1167 allait plus loin : après avoir rejoué le cookie, il enregistrait sa propre méthode MFA (un OTP par SMS vers un numéro iranien) pour survivre à un changement de mot de passe, puis envoyait plus de 16 000 e-mails de phishing aux contacts de la victime. Le mécanisme humain de départ, le clic sur un lien crédible, est décrit en détail dans l'article consacré au phishing.

Vol du jeton de session : après le MFA, plus de MFA

L'AiTM vole le cookie au moment où il naît. Un infostealer le vole plus tard, dans le navigateur, avec tous les autres. Le cas Okta d'octobre 2023 le montre sans phishing : d'après le rapport de cause racine d'Okta, un employé s'était connecté à son compte Google personnel dans le Chrome de son poste géré par Okta, où le mot de passe d'un compte de service du support avait été enregistré. Avec ce compte, l'attaquant a récupéré, du 28 septembre au 17 octobre 2023, des fichiers HAR déposés par les clients pour du dépannage, qui contenaient des jetons de session valides. 134 clients touchés, cinq détournements de session réussis, et le MFA de ces clients jamais sollicité, puisque la session était déjà ouverte. Okta a répondu en liant le jeton à l'emplacement réseau.

SIM swap et OTP bots : le SMS attaqué des deux côtés

Le code par SMS a deux points faibles. Le premier est l'opérateur : par ingénierie sociale ou complicité interne, l'attaquant fait transférer le numéro de la victime sur une SIM qu'il contrôle. Le FBI a comptabilisé 1 611 plaintes pour SIM swap en 2021 aux États-Unis, pour plus de 68 millions de dollars de pertes, contre 320 plaintes sur les trois années précédentes réunies. Le second point faible est la victime. Dès 2021, des bots vendus sur Telegram sous les noms SMSRanger ou SMS Buster automatisaient un appel vocal au nom de la banque, demandaient le code reçu et le renvoyaient au client du bot, avec un taux de réussite annoncé de 80 % quand la victime décrochait, d'après Brian Krebs. Un code TOTP d'application y passe aussi bien qu'un SMS : tout ce que l'utilisateur peut lire se dicte au téléphone, ressort que détaille l'article sur l'ingénierie sociale et les limites de la sensibilisation.

La hiérarchie des facteurs, du plus faible au plus solide

Une fois les attaques posées, le classement s'écrit tout seul. La CISA a publié en octobre 2022 un tableau des formes de MFA du plus fort au plus faible, et le NIST, dans la révision 4 de SP 800-63B (août 2025), range les codes envoyés par le réseau téléphonique parmi les authentifiants restreints et réserve son niveau AAL3 aux authentifiants cryptographiques résistants au phishing, à clé privée non exportable. Le tableau ci-dessous croise les deux avec les attaques vues plus haut.

Aucune forme de MFA n'est inutile : même le SMS arrête le rejeu direct d'un mot de passe fuité, qui reste l'attaque la plus fréquente. Mais dès que le compte donne accès à l'administration, à la messagerie d'un dirigeant ou à une console cloud, la seule ligne qui tient face à un kit de phishing est la dernière. Le vol de session ne figure pas dans le tableau parce qu'il contourne toutes les lignes : sa réponse est dans la durée de vie des sessions, leur liaison à l'appareil et la surveillance des connexions.

FIDO2, WebAuthn et passkeys : pourquoi le phishing ne prend pas

Ce qui met FIDO2 hors de portée d'un kit de phishing tient en deux mots, liaison à l'origine. La solidité du secret compte beaucoup moins qu'on ne l'imagine : un TOTP à six chiffres ne résiste à la force brute que parce que le serveur limite les tentatives, ce que la RFC 4226 impose en section 7.3. À l'enregistrement, l'authentificateur crée une paire de clés rattachée à un identifiant de partie utilisatrice, le RP ID, qui est le domaine du service. La spécification WebAuthn Level 3 du W3C est explicite : seule la partie utilisatrice identifiée par ce RP ID peut employer la clé. Et à chaque authentification, le navigateur inclut l'origine réelle de la page dans les données signées (clientDataJSON). Un site Evilginx sur login-microsoftonline.co ne verra donc jamais la clé de login.microsoftonline.com, et une signature produite pour le mauvais domaine sera refusée par le service légitime.

Les passkeys sont la version grand public de ce mécanisme. La FIDO Alliance distingue les passkeys synchronisées, répliquées entre les appareils par un service cloud chiffré de bout en bout, et les passkeys liées à un appareil, qui ne le quittent jamais, notamment celles stockées sur une clé de sécurité matérielle. Pour un administrateur, la seconde catégorie s'impose : une passkey synchronisée fait reposer l'accès à votre tenant sur la sécurité d'un compte Apple ou Google personnel, et seule une clé non exportable satisfait le critère du NIST pour AAL3.

Vérifier sa couverture MFA : partir de ce qui est exposé

L'écart entre "nous avons le MFA" et "chaque accès est couvert" se mesure, en commençant à l'extérieur. Un attaquant ne consulte pas votre politique, il énumère votre surface d'attaque : portails VPN, passerelles RDP, webmails, consoles d'administration d'équipements réseau, interfaces de sauvegarde, et tout ce que le shadow IT a laissé traîner. Chaque interface a sa propre politique d'authentification, et c'est là qu'on trouve le RDP en 3389 ouvert pour un prestataire en 2021, ou le VPN SSL dont l'intégration MFA n'a jamais été terminée. La procédure suivante est celle que je déroule, dans cet ordre.

Sur Microsoft Entra ID, la seconde passe tient en une requête Graph. L'API userRegistrationDetails expose pour chaque utilisateur les méthodes enregistrées et deux booléens, isMfaRegistered et isMfaCapable, avec la permission AuditLog.Read.All ou le rôle Lecteur de rapports :

# Comptes sans aucune methode MFA enregistree (Microsoft Graph v1.0)
# Prerequis : jeton avec AuditLog.Read.All, ou role Reports Reader
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?\$filter=isMfaRegistered%20eq%20false" \
  | jq -r '.value[] | [.userPrincipalName, .userType, (.isAdmin|tostring), (.methodsRegistered|join(","))] | @tsv'

# Comptes admin dont la methode enregistree inclut le SMS ou la voix : a migrer en priorite
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails" \
  | jq -r '.value[] | select(.isAdmin and (.methodsRegistered | index("mobilePhone"))) | .userPrincipalName'

La première passe, celle de l'extérieur, demande de regarder votre périmètre comme un inconnu, sous-domaines et plages IP compris, et de recommencer à chaque changement. C'est le rôle d'une plateforme EASM, et en particulier du module de surveillance de surface d'attaque qui remonte les interfaces d'administration et d'accès distant visibles depuis Internet, avec le service et la version derrière. L'état du MFA sur chaque portail, lui, se vérifie à la main, portail par portail. L'outillage sert à obtenir la liste, celle que je trouve rarement à jour quand je démarre un test.

Là où le MFA s'arrête, et ce qui prend le relais

Il faut le dire pour ne pas survendre : un MFA bien choisi protège l'ouverture de session. Il ne dit rien de ce qui se passe après, ni de l'état de l'appareil depuis lequel elle a été ouverte. Un poste infecté par un infostealer livre des sessions déjà validées, sans qu'aucune page de connexion ne soit affichée. Les réponses sont d'un autre ordre : sessions courtes et liées à l'appareil, accès conditionnel réévalué à chaque requête plutôt qu'au seul login, détection des règles de boîte mail créées à distance, et une politique qui suppose que le mot de passe est déjà compromis. Cette bascule, où l'authentification initiale ne vaut plus blanc-seing, porte un nom et fait l'objet d'un article à part : le zero trust appliqué sans tout refaire. Côté gouvernance, le MFA se place dans une analyse de risque et se justifie par rapport aux autres mesures, logique décrite dans l'article sur la GRC en cybersécurité.

À retenir

• NIS2 nomme le MFA à l'article 21, paragraphe 2, point j, "selon les besoins" ; le ReCyF v2.5 (version de travail du 17 mars 2026) l'impose sur les accès distants des entités essentielles, avec un facteur de connaissance (mesure 8.3-EE). L'assureur cyber le demande au questionnaire de souscription, avec les accès distants sécurisés, l'EDR et le test régulier des sauvegardes.
• Le push simple se contourne par l'usure (Uber, septembre 2022) ; le number matching y répond. SMS et TOTP se relaient par un proxy AiTM ou se dictent à un bot vocal ; le SMS subit en plus le SIM swap.
• Seul FIDO2 / WebAuthn résiste au phishing, par liaison de la clé au domaine et de la signature à l'origine. Sur les comptes à privilèges, n'accepter que lui, en passkey liée à l'appareil ou clé matérielle.
• Le vol de jeton de session contourne tout MFA (Okta, 2023) : la réponse tient dans la durée de vie des sessions et leur liaison à l'appareil, plus que dans un facteur supplémentaire.
• La couverture se vérifie en deux passes : l'inventaire des interfaces exposées depuis Internet, puis l'export des comptes sans MFA, comptes de service et exclusions compris.

Deux chantiers se lancent sans budget : restreindre les méthodes acceptées sur la dizaine de comptes qui ouvrent le SI, et savoir combien de portails d'authentification votre organisation expose sur Internet. Le second est ce que fait la plateforme EASM own2pwn à partir de votre nom de domaine, en self-service. Quant à ce qu'un attaquant obtient une fois le formulaire passé, avec un mot de passe volé et un kit AiTM en main, ça se mesure en conditions réelles, sur un périmètre défini : c'est l'objet d'un pentest web en boîte noire, avec une réponse sous 24 heures.

Questions fréquentes sur l'authentification multifacteur