Le MFA (Multi-Factor Authentication, authentification multifacteur) est un mécanisme de sécurité qui exige au moins deux facteurs d'identification distincts pour valider l'accès à une ressource. Les facteurs se répartissent en quatre familles historiques : connaissance (mot de passe, PIN), possession (clé FIDO2, smartphone TOTP), inhérence (biométrie), et contexte (localisation, device trust). Son objectif : rendre la compromission d'un compte significativement plus coûteuse en forçant un attaquant à réunir plusieurs facteurs simultanément. En 2026, le MFA est obligatoire dans la majorité des contextes régulés (NIS2 depuis octobre 2024, DORA depuis janvier 2025, PCI DSS v4.0 depuis mars 2024), mais pas tous les MFA se valent : les méthodes phishing-resistant (Passkeys, FIDO2, WebAuthn, PKI) résistent aux attaques modernes AiTM (Adversary in the Middle), alors que SMS, TOTP et Push restent vulnérables. CISA et ENISA classent uniquement FIDO/WebAuthn et PKI comme phishing-resistant. Cet article détaille les 4 facteurs, les méthodes par famille, les attaques documentées (MFA fatigue, SIM swap, AiTM), le positionnement des Passkeys, les obligations 2026 et les plans de déploiement.
Les 4 facteurs d'authentification
Un MFA vrai exige au moins deux facteurs de familles différentes. Réutiliser deux mots de passe n'est pas du MFA.
| Facteur | Nom technique | Exemples |
|---|---|---|
| Ce qu'on sait | Knowledge | Mot de passe, PIN, question secrète |
| Ce qu'on possède | Possession | YubiKey, smartphone avec Authenticator app, carte à puce |
| Ce qu'on est | Inherence | Empreinte digitale, reconnaissance faciale, iris |
| Où/quand/comment on est | Context | Localisation GPS, réseau entreprise, device enregistré, horaire |
Le quatrième facteur (context) est plus récent et sous-tend les approches Zero Trust modernes via Conditional Access (Entra ID), Risk-Based Authentication (Okta) ou Adaptive MFA (Cisco Duo).
Définitions précises 2FA / MFA / SCA
2FA (Two-Factor Authentication)
Exactement 2 facteurs, souvent mot de passe + un deuxième
Terme historique et populaire
MFA (Multi-Factor Authentication)
Au moins 2 facteurs, souvent 2 en pratique
Terme générique couvrant 2FA et plus
SCA (Strong Customer Authentication)
Terme réglementaire PSD2 (paiement européen)
Exige 2 facteurs indépendants avec isolation cryptographique
Obligatoire pour paiements en ligne depuis 2020Les méthodes MFA en 2026 : comparatif
TOTP (Time-based One-Time Password)
Standard RFC 6238. Un secret partagé entre le serveur et l'application authentificateur génère un code à 6 chiffres qui change toutes les 30 secondes. Implémentations : Google Authenticator, Microsoft Authenticator, Authy, Aegis (OSS Android), 1Password, Bitwarden.
Forces :
Standard ouvert, gratuit, fonctionne offline
Offre réduite d'attaque par rapport au SMS
Faiblesses :
Vulnérable au phishing classique + AiTM (l'utilisateur tape le code
sur un site proxy, l'attaquant le rejoue en temps réel sur le vrai site)
Secret initial (QR code) à protéger : si stocké dans le cloud non-E2E,
il peut fuiterSMS OTP
Code envoyé par SMS. Simple, universel, mais vulnérable.
Vecteurs d'attaque documentés :
SIM swap : attaquant convainc l'opérateur de migrer le numéro
SS7 interception : exploitation de la signalisation télécom
SMS phishing : l'utilisateur saisit le code sur un site fake
Smishing redirect : faux SMS pour réorienter vers un proxy
NIST SP 800-63B (Rev 4, 2024) déconseille explicitement le SMS
pour les contextes à risque modéré ou élevé.Push notifications (Duo, Okta Verify, Microsoft Authenticator)
Le serveur envoie une notification push sur le smartphone enregistré. L'utilisateur tape « approuver ».
Vulnérabilité principale : MFA fatigue / push bombing
L'attaquant ayant déjà le mot de passe envoie des dizaines
de push jusqu'à ce que l'utilisateur en accepte une par lassitude
Mitigation 2026 :
Number matching (afficher un nombre à saisir, pas juste Approve/Deny)
Géo-matching (afficher la localisation de la demande)
Rate limiting (3 pushes max par période)
Contextualisation (afficher l'app cible, l'IP source)Clés matérielles FIDO2 / WebAuthn
Clés USB-A, USB-C ou NFC qui implémentent le standard FIDO2 (CTAP2 + WebAuthn). La clé génère une paire asymétrique unique par domaine, la clé privée ne quitte jamais le device, et l'assertion de signature inclut le domaine cible.
Matériels de référence 2026 :
YubiKey 5 Series (Yubico) : standard du marché
YubiKey Bio : biométrie empreinte intégrée
Google Titan Security Key : alternative Google
Feitian, Kensington, Thetis : alternatives économiques
Solokey (open source)
Support natif :
Microsoft Entra ID (Passwordless + FIDO2)
Google Workspace (Advanced Protection Program)
Apple (Passkeys iOS 16+)
GitHub, GitLab, 1Password, AWS IAM Identity CenterPasskeys (FIDO Alliance, 2022)
Généralisation des Passkeys par FIDO Alliance en 2022-2023, adoption massive 2024-2026. Une Passkey est une clé FIDO2 synchronisée dans un trousseau cloud (iCloud Keychain, Google Password Manager, Microsoft Authenticator, 1Password, Bitwarden).
Avantages vs YubiKey :
Pas de hardware à acheter et transporter
Synchronisation cross-device (smartphone, laptop, tablette)
UX fluide via Face ID, Touch ID, Windows Hello
Phishing-resistant identique aux clés hardware
Limitations :
Trousseau cloud = point de défaillance (si compte Apple/Google compromis)
Pas adapté pour contextes secret défense (où hardware dédié requis)
Attestation level souvent plus faible que hardware key enterpriseBiométrie (Face ID, Touch ID, Windows Hello)
Rarement utilisée seule, souvent en combinaison avec une Passkey ou pour débloquer un authentificateur mobile. Windows Hello for Business et macOS Secure Enclave stockent les credentials en TPM ou Secure Enclave.
Carte à puce PKI
Historique dans le secteur gouvernemental et militaire. Exemple : CAC card US DoD, MSFPKI France. Phishing-resistant, mais déploiement lourd. CISA reconnaît PKI et FIDO/WebAuthn comme les deux seules méthodes phishing-resistant approuvées.
Tableau comparatif des méthodes
| Méthode | Phishing-resistant | UX | Coût déploiement | Risque SIM swap | Recommandation 2026 |
|---|---|---|---|---|---|
| SMS OTP | Non | Bonne | Nul | Élevé | À éviter sauf grand public |
| Email OTP | Non | Bonne | Nul | Moyen | À éviter sauf backup |
| TOTP (apps) | Non | Moyenne | Faible | Nul | Acceptable fallback |
| Push notifications | Non (MFA fatigue) | Très bonne | Moyen | Nul | Avec number matching obligatoire |
| Passkeys (FIDO2 sync) | Oui | Très bonne | Faible | Nul | Recommandé par défaut 2026 |
| Clé hardware FIDO2 | Oui | Bonne | 50-60 USD/clé | Nul | Comptes à privilège |
| PKI smart card | Oui | Moyenne | Élevé (infra PKI) | Nul | Secteur gouvernemental |
| Biométrie seule | Non (sans second facteur) | Excellente | Moyen | Nul | Avec Passkey ou hardware |
Attaques modernes contre MFA
MFA fatigue (push bombing)
Popularisé par Lapsus$ en 2022 (Uber, Rockstar, Okta customers).
Attack chain :
1. Attaquant obtient le mot de passe (fuite, phishing, credential stuffing)
2. Déclenche login sur la cible MFA push-based
3. Envoie 20, 50, 100 push notifications sur le smartphone victime
4. L'utilisateur accepte par lassitude, erreur, ou pense que c'est
un bug de l'app - donne accès à l'attaquant
Mitigations :
Number matching (obligatoire en Entra ID depuis février 2023)
Limitation rate / day par compte
Migration Passkeys (pas de push, pas de fatigue possible)Adversary in the Middle (AiTM)
Proxies de phishing modernes : Evilginx2, Modlishka, EvilProxy (SaaS for criminals).
Attack chain :
1. Victime reçoit un email de phishing avec lien vers proxy attaquant
2. Proxy imite le site légitime (ex. login.microsoftonline.com)
3. Victime saisit credentials + MFA TOTP/SMS/Push
4. Proxy relaie tout en temps réel au vrai site
5. Site renvoie cookie de session au proxy, qui le récupère
6. Attaquant a maintenant un cookie de session valide (pas besoin
de re-MFA à chaque requête)
Mitigations :
Phishing-resistant MFA (FIDO2, WebAuthn, Passkeys)
La signature FIDO2 inclut le domaine origin, donc le proxy
ne peut pas forwarder un échange valide vers le vrai site
Conditional Access avec device compliance obligatoire
Detection post-compromise : alertes sur session cookie anormaleSIM swap
L'attaquant convainc l'opérateur télécom de migrer le numéro victime sur une carte SIM attaquant, souvent par social engineering.
Cas médiatisés :
Jack Dorsey (Twitter CEO) 2019
Michael Terpin (crypto investor) : perte 24 M USD en cryptomonnaies
Nombreux comptes crypto Twitter et Discord 2020-2023
Protections côté utilisateur :
Activer la PIN de SIM chez l'opérateur
Migrer tout MFA SMS vers TOTP ou Passkeys
Ne jamais utiliser le numéro perso comme recovery sur services critiquesSession hijacking post-MFA
L'attaquant vole le cookie de session après un MFA réussi (via XSS, proxy AiTM, malware sur le poste).
Mitigations :
Cookies Secure, HttpOnly, SameSite=Strict
Session courte (30 min - 4 h) avec re-MFA sur actions sensibles
Token binding (RFC 8471, peu déployé 2026)
Continuous access evaluation (Entra ID, Google Risk Engine)Obligations réglementaires 2026
NIS2 (France, applicable depuis octobre 2024)
La directive NIS2 transposée en droit français par la loi 2024-1062 impose aux entités essentielles et importantes :
- MFA obligatoire sur tous les accès privilégiés (admins, comptes de service à impact).
- MFA obligatoire sur les systèmes d'information sensibles.
- ENISA Implementing Guidelines 2025 recommandent explicitement le phishing-resistant MFA.
Amendes possibles jusqu'à 10 M€ ou 2 % du CA mondial pour les entités essentielles.
DORA (financier, applicable janvier 2025)
Article 9 sur la gestion des identités et des accès. MFA obligatoire sur tout accès aux systèmes critiques des acteurs financiers européens et de leurs prestataires TIC critiques.
PCI DSS v4.0 (paiement, depuis mars 2024)
Exigence 8.4 : MFA obligatoire pour tout accès au CDE (Cardholder Data Environment), y compris les accès non-administratifs depuis mars 2025.
Cyberscore France (loi 2022-2020, applicable janvier 2024)
Les plateformes grand public doivent afficher un cyberscore incluant le niveau de MFA proposé. Pression indirecte sur le déploiement.
Autres cadres
HDS (santé France) : MFA recommandé, souvent exigé en audit
RGS (secteur public France) : MFA pour niveaux *** et élevé
US Executive Order 14028 (2021) : phishing-resistant MFA sur tous les
systèmes fédéraux avant fin 2024
Google Advanced Protection Program : FIDO2 obligatoire pour cibles
à haut risque (journalistes, activistes)Implémentation : exemples pratiques
Microsoft Entra ID Conditional Access
Politique type 2026 :
Scope : tous les administrateurs globaux, application admins
Condition :
- Authentification depuis n'importe quelle location
- Device non compliant ou non managé
Contrôle :
- Require phishing-resistant MFA (FIDO2 ou Passkey)
- Require compliant device
Sans ces éléments, le login est bloqué.AWS IAM Identity Center (ex-AWS SSO)
Configuration type :
Activer MFA enforcement pour tout utilisateur
Privilégier WebAuthn/FIDO2
TOTP en fallback uniquement pour recovery
Désactiver SMS OTP explicitement
Associer à IAM Identity Provider (Entra ID, Okta, Google Workspace)GitHub Organization
Depuis janvier 2024, GitHub exige MFA pour tous les contributeurs aux repos publics. Recommandation enterprise 2026 :
- MFA obligatoire pour tous les membres de l'org.
- FIDO2 / Passkey fortement recommandé.
- SSH keys signées via SSO (Signed Commits + SSO required).
Implémentation côté applicatif (développeur)
Pour un développeur qui ajoute MFA à son application web :
Bibliothèques 2026 recommandées :
JavaScript/TypeScript :
simplewebauthn : WebAuthn côté client et serveur
passport-webauthn : intégration Passport.js
Python :
webauthn-lib : package officiel Duo
fido2 : Yubico
Java :
WebAuthn4J : bibliothèque de référence
Go :
go-webauthn : maintenu activement
Ruby :
webauthn-ruby : officiel
Backend services managés alternative :
Auth0 (Okta) : MFA clés en main
Clerk : dev-friendly, Passkeys natif
Supabase Auth : Passkeys supportées
AWS Cognito : FIDO2 + TOTP + SMS
Firebase Auth : intégration mobile fortePlan de déploiement entreprise 6-18 mois
Mois 1-2 : Inventaire et priorisation
Cartographier tous les points d'authentification (SSO, SaaS, VPN, admin)
Classer par criticité (privileged, standard, external)
Choisir la stack MFA cible (Entra, Okta, Auth0, Duo)
Mois 2-4 : Pilote sur comptes à privilège
Distribution clés hardware FIDO2 aux admins (YubiKey, Titan)
Activation Passkeys sur smartphones corporates
Conditional Access sur applications critiques
Mois 4-12 : Rollout utilisateurs standard
Campagne de communication et formation
Enrollment guidé avec support dédié
Fallback TOTP pour utilisateurs sans smartphone compatible
Mois 12-18 : Enforcement et phishing-resistant
Activer le blocking en Conditional Access
Migrer des TOTP vers Passkeys progressivement
Métriques : % users avec MFA phishing-resistant
Continu : Gouvernance
Revue trimestrielle des exceptions
Rotation clés hardware compromises
Formation anti-phishingPièges fréquents
- Recovery SMS sur MFA Passkey : un utilisateur qui perd sa Passkey redescend au niveau SMS, qui devient la faiblesse maillon faible. Utiliser recovery codes papier ou deuxième Passkey.
- MFA sur le login mais pas sur les actions sensibles : re-MFA nécessaire pour sudo, admin actions, transactions financières.
- Exclusions mal gérées : les comptes de service technique doivent utiliser OIDC Workload Identity plutôt qu'une exception MFA.
- TOTP secret stocké en cloud non E2E : un Google Authenticator synchronisé dans le cloud sans E2E expose les secrets en cas de compromission du compte Google.
- MFA activé mais bypass possible via legacy protocols : IMAP, SMTP basic auth sur Entra ID, POP3 - désactiver explicitement.
- Absence de logging MFA : sans logs authN détaillés, impossible d'investiguer un MFA fatigue attack en post-mortem.
Points clés à retenir
- MFA = au moins 2 facteurs d'authentification parmi 4 familles (knowledge, possession, inherence, context). 2FA est un cas particulier de MFA.
- Hiérarchie 2026 par résistance phishing : Passkeys / FIDO2 (gold standard CISA, ENISA) > TOTP > Push avec number matching > SMS OTP (à éviter).
- Attaques modernes à connaître : MFA fatigue (Lapsus$ 2022), AiTM via Evilginx2/Modlishka/EvilProxy, SIM swap, session hijacking post-MFA.
- CISA et ENISA reconnaissent uniquement FIDO/WebAuthn et PKI comme phishing-resistant MFA. Migrer vers Passkeys dès que possible.
- Obligations 2026 France : NIS2 (octobre 2024), DORA (janvier 2025), PCI DSS v4.0 (mars 2024), Cyberscore (janvier 2024), HDS santé, RGS public.
- Implémentation : Entra Conditional Access, AWS IAM Identity Center, GitHub org-level enforcement. Côté dev : simplewebauthn (JS), webauthn-lib (Python), WebAuthn4J (Java), go-webauthn (Go).
- Déploiement entreprise type : 6-18 mois, priorité aux comptes à privilège, rollout standard progressif, enforcement puis migration phishing-resistant.
Pour approfondir la gestion des permissions cloud côté IAM, voir CIEM : définition, fonctions et outils 2026. Pour les bases IAM sur un cloud provider typique, lire GCP Security pour débutant. Pour comprendre pourquoi l'authentification seule ne suffit pas (autorisation est aussi critique), voir Broken Access Control : explication, exemples et prévention.
