Cartographie des niveaux d’authentification : ce que les référentiels imposent
Les compromissions de compte par vol de credentials représentent encore plus de 80 % des incidents de sécurité liés aux accès, selon les données Microsoft Entra compilées sur des milliards de connexions. L’activation du MFA (Multi-Factor Authentication) réduit ce risque de 99 % dans les scénarios de credential stuffing et de phishing classique. Pourtant, de nombreuses organisations déploient encore un MFA de premier niveau - SMS ou TOTP - qui reste contournable, ou peinent à étendre la couverture au-delà des comptes administrateurs par crainte de la friction.
Le NIST SP 800-63B définit trois niveaux d’assurance d’authentification (AAL1, AAL2, AAL3). Pour les systèmes d’information traitant des données sensibles, AAL2 est le minimum : il exige un second facteur cryptographique ou un OTP. AAL3 impose une clé matérielle résistante au phishing (FIDO2, PIV/CAC).
L’ANSSI aligne ses recommandations sur le cadre eIDAS : le niveau « substantiel » correspond approximativement à AAL2 avec un facteur hors SMS, et le niveau « élevé » à AAL3. Pour les OIV (Opérateurs d’Importance Vitale) et les OSE (Opérateurs de Services Essentiels), l’ANSSI exclut le SMS comme unique second facteur dans ses guides publiés depuis 2021.
| Méthode MFA | Résistance au phishing | Niveau NIST | Niveau eIDAS approx. | Friction utilisateur |
|---|---|---|---|---|
| SMS / OTP vocal | Faible (SIM swap, SS7) | AAL2 restreint* | Faible | Faible |
| TOTP logiciel (Google Auth, Aegis) | Moyenne (vulnérable AiTM) | AAL2 partiel | Substantiel partiel | Faible |
| Push notification (Duo, Entra) | Moyenne (MFA fatigue) | AAL2 | Substantiel | Faible |
| Push avec correspondance de nombre | Moyenne-haute | AAL2 renforcé | Substantiel | Faible |
| FIDO2 / WebAuthn (clé hardware) | Haute (phishing-resistant) | AAL3 | Élevé | Moyenne |
| Passkeys (device-bound ou synced) | Haute | AAL2-AAL3 | Élevé partiel | Très faible |
| Certificat client (PKI/smartcard) | Haute | AAL3 | Élevé | Moyenne-haute |
*Le SMS est un « restricted authenticator » selon NIST 800-63B : toléré en AAL2 mais soumis à surveillance active des risques et notification obligatoire des utilisateurs sur les alternatives disponibles.
La colonne « friction utilisateur » est délibérément contextuelle : un technicien terrain avec des gants ne peut pas utiliser la biométrie par empreinte digitale ; un analyste SOC sur poste fixe ne verra aucune friction avec une clé FIDO2 laissée en permanence dans le port USB.
Les attaques que votre MFA actuel ne bloque pas
Le MITRE ATT&CK recense plusieurs techniques ciblant le MFA, notamment T1111 (MFA Interception) et T1621 (MFA Request Generation). Deux familles d’attaques méritent une attention particulière en environnement B2B.
AiTM (Adversary-in-the-Middle) : des frameworks comme Evilginx2 ou Modlishka agissent en proxy transparent entre l’utilisateur et le fournisseur d’identité. L’utilisateur saisit son TOTP sur le faux portail, l’attaquant le relaie en temps réel et capture le cookie de session. Cette technique est documentée dans les campagnes APT ciblant les environnements Microsoft 365 depuis 2022. Le TOTP est contourné en quelques secondes, sans que l’utilisateur perçoive la moindre anomalie.
MFA Fatigue (ou Push Bombing) : l’attaquant envoie en rafale des demandes push à l’utilisateur, espérant une validation par erreur ou par exaspération. La compromission documentée de Cisco en août 2022 illustre ce vecteur : l’attaquant a combiné vishing et push bombing pour obtenir l’approbation d’un compte VPN. La mitigation passe par l’activation du « number matching » (correspondance de nombre) disponible dans Microsoft Entra et Okta, qui force l’utilisateur à saisir dans l’application mobile un code affiché sur l’écran de connexion.
Seules les solutions basées sur FIDO2/WebAuthn éliminent structurellement ces deux vecteurs : le protocole lie cryptographiquement la réponse d’authentification à l’origine DNS du site (RP ID). Un proxy ne peut pas forger cette liaison sans posséder la clé privée stockée dans l’enclave sécurisée du périphérique.
FIDO2 et passkeys : le standard à déployer en priorité
FIDO2 est le standard ouvert défini par la FIDO Alliance, composé de WebAuthn (API W3C côté navigateur/application) et de CTAP2 (protocole entre l’authenticator et la plateforme). Il est nativement supporté depuis Chrome 67, Firefox 60, Safari 14 et Edge 79 (version Chromium). Côté IdP, Microsoft Entra ID, Okta, Ping Identity et Keycloak supportent FIDO2 en production.
Les passkeys sont une implémentation conviviale de FIDO2 promue conjointement par Apple, Google et Microsoft. Elles existent en deux variantes :
- Device-bound passkeys : la clé privée ne quitte jamais le TPM ou l’enclave sécurisée du terminal. Sécurité maximale, mais la perte du terminal implique la perte du facteur sans procédure de récupération préalable.
- Synced passkeys : la clé est synchronisée chiffrée dans le trousseau cloud (iCloud Keychain, Google Password Manager, 1Password). Confort maximal, mais le niveau de confiance dépend de la posture sécurité du compte cloud associé.
Pour les environnements entreprise, la recommandation est d’utiliser des clés hardware FIDO2 (Yubikey, Feitian, GoTrust) sur les comptes à privilèges, et des synced passkeys gérées via un gestionnaire d’entreprise (1Password Business, Dashlane Business, Microsoft Entra) pour les comptes standards. Cette distinction est compatible avec une politique Zero Trust : les accès aux ressources critiques exigent un facteur device-bound, les accès aux outils de productivité acceptent les passkeys synchronisées.
La mise en oeuvre d’une architecture Zero Trust doit traiter le MFA comme une brique parmi d’autres, couplée à l’évaluation continue de la posture du terminal et au contrôle conditionnel des accès.
Déploiement sans friction : les trois leviers organisationnels
Step-up authentication contextuelle
L’approche binaire « MFA ou pas MFA » est contre-productive. Une politique d’accès conditionnel (Conditional Access dans Entra, Adaptive MFA dans Okta) déclenche un facteur supplémentaire uniquement quand le risque détecté le justifie : accès depuis un pays inhabituel, terminal non conforme, heure atypique, ressource sensible. Cette approche réduit les frictions de 60 à 70 % sur les flux courants tout en maintenant le contrôle sur les scénarios à risque.
Les signaux de confiance utilisables incluent : conformité Intune/MDM, score de risque de l’identité (Identity Protection dans Entra), géolocalisation IP, présence d’un certificat client, appartenance réseau (ZTNA). L’infrastructure sous-jacente doit être intégrée dès la conception de l’IAM, avec une attention particulière aux enjeux d’infrastructure IT.
SSO fédéré pour réduire le nombre de prompts
Chaque application avec sa propre authentification multiplie les frictions et les surfaces d’attaque. La consolidation via un IdP fédéré (SAML 2.0, OIDC/OAuth 2.0) ramène le MFA à une seule friction par session de travail. Le SSO ne réduit pas la sécurité si l’IdP central est correctement protégé : MFA phishing-resistant obligatoire sur le compte IdP, journalisation exhaustive, révocation de session en temps réel.
Pour les environnements hybrides (on-premise + cloud), les architectures de type broker d’identité (Microsoft Entra Hybrid Join, Ping Federate, Keycloak avec LDAP sync) permettent d’étendre le SSO sans refondre les annuaires existants. Cette démarche s’inscrit dans la sécurisation des environnements cloud enterprise au sens large.
Politique d’exceptions documentée et auditée
Il existe toujours des cas légitimes où le MFA standard est inapplicable : comptes de service, applications legacy sans support OIDC, terminaux industriels. La tentation est d’exclure silencieusement ces cas. L’approche rigoureuse impose une procédure formelle : ticket d’exception daté, validation RSSI, revue trimestrielle, compensation par d’autres contrôles (segmentation réseau, monitoring comportemental, rotation automatique des secrets via vault). NIS2 et DORA imposent des pistes d’audit des contrôles d’accès : une exception non documentée devient une non-conformité.
Intégration dans la stratégie globale de gestion des identités
Le MFA n’est qu’une couche du cadre IAM (Identity and Access Management). Il doit s’articuler avec le cycle de vie des identités (JML : Joiners, Movers, Leavers), la gestion des accès à privilèges (PAM) et la gouvernance des identités (IGA). En pratique, les RSSI constatent que les comptes orphelins et les droits résiduels représentent un risque supérieur à l’absence de MFA : un compte désactivé sans MFA ne peut pas être utilisé, mais un compte actif sur-privilégié avec MFA contournable reste une surface d’attaque majeure.
Un point souvent négligé concerne les identités non-humaines : comptes de service applicatifs, pipelines CI/CD, clés API et tokens de déploiement. Ces identités prolifèrent dans les architectures cloud-native et échappent fréquemment aux politiques MFA. La réponse n’est pas d’imposer un facteur interactif inexistant, mais d’appliquer des contrôles équivalents : certificats à courte durée de vie, rotation automatisée via un vault (HashiCorp Vault, Azure Key Vault), principe du moindre privilège et monitoring des appels anormaux.
Les enjeux de cybersécurité entreprise couvrent cette dimension systémique : l’authentification forte est nécessaire mais pas suffisante sans une gouvernance des identités robuste. De même, les cas d’usage de l’IA dans les systèmes IT introduisent de nouveaux comptes de service et API keys dont le cycle de vie doit être intégré dans le même cadre IAM.
Pour les terminologies et définitions de référence (AAL, RP ID, CTAP, WebAuthn, ZTNA), le glossaire complète les notions abordées dans cet article.
Mesurer et améliorer en continu
Un déploiement MFA sans tableau de bord est un déploiement aveugle. Les métriques clés à suivre :
- Taux de couverture MFA : pourcentage de comptes actifs avec MFA activé, segmenté par criticité (admin, standard, service accounts).
- Taux de méthodes phishing-resistant : proportion des authentifications via FIDO2/passkeys versus OTP/push.
- Taux de MFA bypass : exceptions actives / total comptes, avec tendance mensuelle.
- Temps moyen d’authentification : indicateur de friction, à monitorer par cohorte d’utilisateurs après chaque changement de politique.
- Alertes MFA fatigue : volume de push rejeté ou ignoré, indicateur d’attaque en cours ou de mauvaise expérience utilisateur.
- Couverture identités non-humaines : ratio comptes de service avec rotation automatisée de secrets versus secrets statiques à longue durée de vie.
Ces métriques alimentent la revue trimestrielle de la politique d’accès et servent de preuves dans les audits NIS2/DORA. La roadmap cible pour la plupart des organisations est d’atteindre 100 % de couverture MFA sur les comptes humains et 80 % de méthodes phishing-resistant sur les accès aux ressources sensibles, conformément aux objectifs publiés par la CISA dans son guide « More Than a Password ».