L’authentification multifacteur (MFA) n’est plus un sujet réservé aux équipes sécurité des grands groupes. Son déploiement s’accélère dans des structures de toutes tailles, porté par une pression réglementaire qui ne laisse plus de marge d’interprétation. Nous observons un basculement net : la MFA est passée de bonne pratique à obligation sanctionnable pour les traitements de données sensibles.
Sanctions CNIL et article 32 du RGPD : la MFA comme critère de conformité
Le tournant réglementaire mérite d’être examiné en détail, parce qu’il modifie directement la responsabilité des dirigeants. Depuis 2025-2026, la CNIL qualifie l’absence de MFA sur des systèmes traitant des données sensibles comme un manquement à l’article 32 du RGPD (sécurité des traitements). La nuance est de taille : il ne s’agit plus d’une recommandation ignorée, mais d’un motif direct de sanction documenté par des délibérations récentes.
La CNIL a indiqué qu’environ la moitié de ses contrôles portent désormais sur la sécurité des données. Son rapport annuel 2025 mentionne 83 sanctions pour près de 487 millions d’euros d’amendes. Dans ce contexte, ne pas déployer la MFA sur les accès aux données de santé, aux bases clients massives ou aux systèmes RH revient à s’exposer volontairement à une procédure.
Pour les responsables de traitement, la conséquence opérationnelle est claire : tout audit de conformité RGPD doit maintenant inclure une vérification du périmètre MFA. Les traitements concernés ne se limitent pas aux données de santé. Toute base contenant des données personnelles à grande échelle entre dans le radar.
Facteurs d’authentification MFA : hiérarchie de robustesse en entreprise
Toutes les méthodes MFA ne se valent pas, et le choix du second facteur conditionne le niveau réel de protection. Nous recommandons de raisonner en termes de résistance au phishing plutôt qu’en termes de facilité de déploiement.
SMS et codes OTP par email
Le SMS reste le facteur le plus répandu, mais aussi le plus vulnérable. Les attaques par SIM swapping et l’interception de codes OTP par des kits de phishing en temps réel rendent ce canal peu fiable pour protéger des accès critiques. Son seul avantage : la compatibilité universelle avec les terminaux des utilisateurs.
Applications TOTP et notifications push
Les applications génératrices de codes temporels (TOTP) offrent un niveau supérieur. Le code est généré localement sur l’appareil de l’utilisateur, ce qui élimine le risque d’interception réseau. Les notifications push ajoutent une couche de vérification contextuelle (localisation, appareil connu), mais restent exposées aux attaques de type « MFA fatigue » où l’attaquant bombarde l’utilisateur de demandes jusqu’à obtenir une validation accidentelle.
Clés de sécurité matérielles et passkeys
Les clés FIDO2 restent le facteur le plus résistant au phishing. Elles reposent sur un échange cryptographique lié au domaine exact du service, ce qui rend toute tentative de redirection vers un faux site inopérante. Les passkeys, qui reprennent ce principe en le stockant sur l’appareil de l’utilisateur, commencent à être proposées par les principaux fournisseurs d’identité.
- SMS/OTP email : déploiement simple, résistance au phishing faible, adapté aux comptes à faible criticité
- Applications TOTP/push : bon compromis pour les accès courants, vigilance nécessaire sur la fatigue MFA
- Clés FIDO2/passkeys : protection maximale contre le phishing, à réserver aux accès administrateurs et données sensibles
Périmètre de déploiement MFA : quels comptes protéger en priorité
La question du périmètre est celle qui génère le plus de friction en interne. Déployer la MFA sur tous les comptes d’une organisation d’un coup provoque de la résistance utilisateur et surcharge le support informatique. Nous observons que les déploiements réussis suivent une logique de priorisation stricte.
Les comptes à privilèges élevés doivent être couverts en premier : administrateurs systèmes, accès aux consoles cloud, comptes de service avec droits d’écriture sur les bases de données. Selon le rapport Verizon DBIR, la majorité des fuites de données découlent d’un vol d’identifiants ou d’une attaque de phishing. Protéger ces comptes réduit la surface d’attaque de manière disproportionnée par rapport à l’effort déployé.
Viennent ensuite les accès aux applications métier contenant des données personnelles (CRM, SIRH, outils de facturation), puis les comptes de messagerie, vecteur principal des attaques par hameçonnage. Les comptes utilisateurs standard sur des applications internes sans données sensibles peuvent être traités dans une phase ultérieure.
- Phase 1 : comptes administrateurs, accès cloud et bases de données (clés FIDO2 ou TOTP)
- Phase 2 : applications métier traitant des données personnelles (TOTP ou push)
- Phase 3 : messagerie et outils collaboratifs (TOTP minimum)
- Phase 4 : comptes utilisateurs courants sur systèmes internes (SMS acceptable en dernier recours)
MFA et architecture zero trust : convergence technique
La MFA ne fonctionne pas en isolation. Son efficacité dépend de son intégration dans une politique de gestion des identités et des accès (IAM) cohérente. Dans une architecture zero trust, chaque connexion est vérifiée indépendamment du réseau d’origine. La MFA devient alors un composant d’une chaîne de vérification continue, pas un simple portail d’entrée.
Concrètement, cela signifie coupler la MFA à des règles d’accès conditionnel : exiger un facteur fort lorsque la connexion provient d’un appareil non enregistré, d’une géolocalisation inhabituelle ou en dehors des horaires de travail. Cette approche adaptative réduit la friction pour l’utilisateur en situation normale tout en renforçant le contrôle sur les scénarios à risque.
Le piège fréquent consiste à considérer la MFA comme une mesure suffisante. Un facteur MFA compromis sans politique d’accès conditionnel laisse le système aussi exposé qu’un mot de passe seul. La combinaison MFA, segmentation réseau et surveillance des sessions constitue le socle technique minimal pour une posture de sécurité défendable face à un contrôle CNIL ou à un incident.
L’authentification multifacteur n’est plus un projet technique optionnel. C’est une brique réglementaire dont l’absence est désormais sanctionnée, et une composante structurelle de toute politique de sécurité des systèmes d’information. Les sociétés qui repoussent encore son déploiement s’exposent autant juridiquement que techniquement.