8 min de lecture<\/p>\n
En 2026, l\u2019MFA adaptative rel\u00e8ve moins d\u2019un d\u00e9fi technologique que d\u2019une question de preuve. Depuis l\u2019entr\u00e9e en vigueur sans p\u00e9riode de transition de la loi allemande transposant NIS2, les \u00e9quipes de s\u00e9curit\u00e9 doivent non seulement d\u00e9montrer qu\u2019elles disposent d\u2019une authentification multifacteur. Elles doivent prouver qu\u2019elles savent quels risques elles att\u00e9nuent ainsi. Cela implique que les seuils de d\u00e9cision soient document\u00e9s. Entra Conditional Access, Okta Adaptive MFA, Duo Risk-Based et Ping Identity offrent ces fonctionnalit\u00e9s. Pourtant, le d\u00e9ploiement \u00e9choue souvent en raison du foss\u00e9 entre la fonctionnalit\u00e9 et la preuve.<\/strong><\/p>\n L’essentiel en bref<\/p>\n En lien<\/span>Infostealer 2026 : comment les cookies de session contournent l\u2019MFA<\/a> \/<\/span> Prolif\u00e9ration des identit\u00e9s dans les PME : AD et configurations cloud<\/a><\/p>\n La loi allemande transposant NIS2 est en vigueur depuis le 6 d\u00e9cembre 2025, sans p\u00e9riode de transition. L\u2019enregistrement aupr\u00e8s du BSI \u00e9tait obligatoire jusqu\u2019au 6 mars 2026. L\u2019article 21 de la directive \u00e9num\u00e8re dix domaines dans lesquels les entreprises doivent justifier de leurs mesures, notamment les politiques d\u2019acc\u00e8s, la s\u00e9curit\u00e9 de la cha\u00eene d\u2019approvisionnement et explicitement l\u2019authentification multifacteur. La formulation de la directive est volontairement ouverte : l\u2019MFA doit \u00eatre mise en \u0153uvre \u00ab de mani\u00e8re appropri\u00e9e \u00bb, sans que l\u2019UE ou le BSI ne d\u00e9finissent de seuils minimaux concrets.<\/p>\n Cette ouverture devient un probl\u00e8me lors des audits, lorsque les entreprises d\u00e9clarent avoir activ\u00e9 l\u2019MFA, mais ne disposent d\u2019aucune documentation sur la logique des seuils. Un auditeur ne demande pas si l\u2019MFA est activ\u00e9e. Il demande dans quelles conditions un second facteur est exig\u00e9, quelles exceptions sont configur\u00e9es, comment les acc\u00e8s d\u2019urgence sont s\u00e9curis\u00e9s et quels protocoles permettent de retracer la d\u00e9cision d\u2019une politique de Conditional Access. Les \u00e9quipes de s\u00e9curit\u00e9 qui ont trait\u00e9 l\u2019MFA comme une simple case \u00e0 cocher se retrouvent sur la d\u00e9fensive \u00e0 ce stade.<\/p>\n Microsoft Entra Conditional Access s\u2019impose comme une solution \u00e9vidente pour les organisations utilisant Microsoft 365, car le moteur de politiques est directement int\u00e9gr\u00e9 \u00e0 la pile d\u2019identit\u00e9 et exploite des signaux tels que le risque de connexion, le risque utilisateur et la conformit\u00e9 des appareils via Microsoft Defender for Identity. Les seuils peuvent \u00eatre d\u00e9finis de mani\u00e8re granulaire par groupe et par application. L\u2019effort r\u00e9side dans l\u2019affectation pr\u00e9cise des politiques aux groupes d\u2019utilisateurs et dans la documentation de la logique d\u00e9cisionnelle. Sans une bonne hygi\u00e8ne des politiques, on se retrouve apr\u00e8s deux ans avec un fatras de cent r\u00e8gles qui se chevauchent, sans que personne ne sache plus lesquelles s\u2019appliquent.<\/p>\n Okta Adaptive MFA se positionne comme une plateforme multi-IdP et excelle lorsque plusieurs sources d\u2019identit\u00e9 convergent (Active Directory, G Suite, syst\u00e8mes RH). Son moteur de scoring des risques utilise l\u2019empreinte des appareils, la r\u00e9putation du r\u00e9seau et les sch\u00e9mas comportementaux. Pour les entreprises peu ancr\u00e9es dans l\u2019\u00e9cosyst\u00e8me Microsoft, Okta est souvent le premier choix. Son prix est sup\u00e9rieur \u00e0 celui d\u2019Entra, mais sa flexibilit\u00e9 est plus grande.<\/p>\n Duo Security, d\u00e9sormais int\u00e9gr\u00e9 \u00e0 Cisco, est largement r\u00e9pandu dans les PME et les entreprises dot\u00e9es d\u2019une infrastructure Cisco. Ses fonctionnalit\u00e9s bas\u00e9es sur les risques sont matures, et son int\u00e9gration avec Cisco ISE et Umbrella permet d\u2019\u00e9conomiser temps et argent en cas d\u2019investissements pr\u00e9alables. Ping Identity joue un r\u00f4le plus marqu\u00e9 dans le segment des grandes entreprises, avec des int\u00e9grations B2B complexes, le Customer Identity Access Management et les identit\u00e9s f\u00e9d\u00e9r\u00e9es, plut\u00f4t que dans le middle market classique. Les quatre plateformes se recoupent sur les fonctionnalit\u00e9s de base, mais se distinguent nettement par la profondeur de leur int\u00e9gration dans les stacks existants.<\/p>\n En pratique, le choix repose souvent moins sur la matrice des fonctionnalit\u00e9s que sur le support des applications legacy. De nombreuses PME allemandes utilisent des applications qui ne prennent en charge ni SAML ni OpenID Connect. L\u2019authentification bas\u00e9e sur les en-t\u00eates, le proxy RADIUS ou les acc\u00e8s SSH avec certificats sont monnaie courante dans ce contexte. Duo et Ping offrent une plus grande profondeur dans ce domaine, tandis qu\u2019Entra a combl\u00e9 son retard ces 18 derniers mois gr\u00e2ce \u00e0 Entra Application Proxy et Entra ID Governance. Okta couvre ce champ via son Access Gateway. L\u2019\u00e9valuation de ces niches doit faire partie de la phase de s\u00e9lection, sous peine de voir le d\u00e9ploiement \u00e9chouer si le syst\u00e8me ERP central ou une application m\u00e9tier ne peut \u00eatre int\u00e9gr\u00e9.<\/p>\n La licence constitue le deuxi\u00e8me point variable dans la comparaison. Microsoft Entra Conditional Access est inclus dans Entra ID P1 et P2, P2 d\u00e9bloquant les politiques de risque avec Identity Protection. Okta facture par utilisateur avec diff\u00e9rents packages pour la MFA, l\u2019Adaptive MFA et la gestion du cycle de vie. Duo propose un mod\u00e8le clair \u00e0 plusieurs niveaux avec Duo Essentials, Advantage et Premier. Ping, souvent plus cher dans le segment entreprise, offre en contrepartie des options de personnalisation plus pouss\u00e9es. Pour obtenir un prix de r\u00e9f\u00e9rence, il faut toujours comparer la configuration concr\u00e8te, et non les tarifs publics par utilisateur.<\/p>\n Le succ\u00e8s d\u2019un d\u00e9ploiement d\u2019Adaptive MFA ne d\u00e9pend pas de la puissance du moteur de politiques, mais de l\u2019exp\u00e9rience utilisateur. En 2025, les attaques par \u00ab push-bombing \u00bb, o\u00f9 les attaquants d\u00e9clenchent de mani\u00e8re r\u00e9p\u00e9t\u00e9e des demandes MFA jusqu\u2019\u00e0 ce que l\u2019utilisateur accepte par habitude, sont devenues une m\u00e9thode standard. En r\u00e9ponse, les \u00e9diteurs ont mis en place l\u2019authentification par correspondance de chiffres, o\u00f9 l\u2019utilisateur doit saisir un num\u00e9ro affich\u00e9 dans l\u2019application d\u2019authentification. Microsoft l\u2019a activ\u00e9e par d\u00e9faut, tandis que Duo et Okta proposent des variantes. Tout fournisseur qui n\u2019impose pas cette m\u00e9thode laisse la porte ouverte.<\/p>\n Ce qui provoque la fatigue MFA<\/p>\n Ce qui r\u00e9duit les attaques par fatigue<\/p>\n Le r\u00e9glage des seuils est le deuxi\u00e8me point critique. Si un syst\u00e8me Adaptive MFA exige un second facteur \u00e0 chaque deuxi\u00e8me connexion, cela g\u00e9n\u00e8re une lassitude face aux demandes et pousse \u00e0 des contournements. S\u2019il demande trop rarement, il perd son efficacit\u00e9 en mati\u00e8re de s\u00e9curit\u00e9. L\u2019approche pragmatique consiste \u00e0 d\u00e9marrer les trois premiers mois avec des politiques conservatrices, puis \u00e0 s\u2019appuyer sur la t\u00e9l\u00e9m\u00e9trie pour identifier quels sch\u00e9mas de connexion sont r\u00e9ellement suspects. Entra, Okta et Duo proposent des tableaux de bord permettant de visualiser la fr\u00e9quence des demandes par utilisateur et par niveau de risque.<\/p>\n Un aspect souvent n\u00e9glig\u00e9 concerne la gestion des comptes de service et des acc\u00e8s API. L\u2019Adaptive MFA est optimis\u00e9 pour les connexions interactives d\u2019utilisateurs. Pour les automatisations, il faut privil\u00e9gier l\u2019authentification par certificat ou l\u2019usage de jetons temporaires avec rotation. Laisser des comptes de service avec des mots de passe persistants et sans MFA constitue une br\u00e8che que les attaquants cibleront sp\u00e9cifiquement en 2026. La documentation de la politique relative aux comptes de service fait partie des preuves exig\u00e9es par la directive NIS2, au m\u00eame titre que l\u2019authentification MFA des utilisateurs.<\/p>\n Une troisi\u00e8me composante soumise aux audits est la gestion des utilisateurs externes. Fournisseurs, prestataires et partenaires obtiennent r\u00e9guli\u00e8rement un acc\u00e8s \u00e0 des syst\u00e8mes internes sans \u00eatre int\u00e9gr\u00e9s au processus standard de gestion des identit\u00e9s. Entra B2B Collaboration, Okta External Identities et Ping DaVinci proposent des fonctionnalit\u00e9s permettant d\u2019offrir aux utilisateurs externes un parcours MFA s\u00e9curis\u00e9. Forcer ces utilisateurs dans des comptes internes expose non seulement \u00e0 un risque de non-conformit\u00e9, mais aussi \u00e0 une surface d\u2019attaque exploit\u00e9e \u00e0 plusieurs reprises en 2025 dans le cadre d\u2019attaques par cha\u00eene d\u2019approvisionnement.<\/p>\n Un d\u00e9ploiement r\u00e9aliste se d\u00e9roule en quatre phases, s’\u00e9talant sur dix \u00e0 vingt semaines selon la taille de l’organisation. La premi\u00e8re phase consiste en un \u00e9tat des lieux, la derni\u00e8re en une pr\u00e9paration \u00e0 l’audit.<\/p>\n Le point faible le plus fr\u00e9quent lors d’un d\u00e9ploiement est l’absence de lien avec la r\u00e9ponse aux incidents. Si le SIEM d\u00e9tecte des sch\u00e9mas de connexion suspects mais que l’\u00e9quipe IAM ne sait pas comment placer rapidement les comptes en quarantaine, la MFA adaptative pr\u00e9sente un angle mort. L’int\u00e9gration entre Entra ou Okta et le pipeline SOC doit \u00eatre r\u00e9alis\u00e9e d\u00e8s la premi\u00e8re phase, et non \u00e0 la fin. Concr\u00e8tement, cela signifie que Splunk, Sentinel ou Elastic ont besoin des journaux de connexion, des \u00e9v\u00e9nements de risque et des \u00e9v\u00e9nements de modification de politique dans un r\u00e9f\u00e9rentiel centralis\u00e9, avec des alertes sur des sch\u00e9mas comme dix \u00e9checs de connexion en cinq minutes ou une demande de validation provenant d’un pays inhabituel. Les formats de journaux diff\u00e8rent entre Entra et Okta, et la normalisation est une t\u00e2che qui ne peut \u00eatre d\u00e9l\u00e9gu\u00e9e au fournisseur du SIEM.<\/p>\n Enfin, le point le plus important : la MFA adaptative n’est pas un projet avec une fin, mais un fonctionnement continu. Les seuils \u00e9voluent car les attaquants utilisent de nouvelles techniques. De nouvelles applications sont int\u00e9gr\u00e9es, les groupes d’utilisateurs changent. Celui qui planifie le d\u00e9ploiement comme un projet ponctuel se retrouve apr\u00e8s dix-huit mois avec une pile IAM qui ne refl\u00e8te plus la derni\u00e8re menace. Un r\u00f4le d\u00e9di\u00e9 \u00e0 l’exploitation IAM et des revues trimestrielles des politiques font de la MFA adaptative une preuve productive.<\/p>\n Un exemple concret issu du terrain : un constructeur de machines en Sauerland a lanc\u00e9 fin 2025 le d\u00e9ploiement d’Entra Conditional Access. La phase pilote s’est d\u00e9roul\u00e9e sur deux semaines avec un groupe IT, incluant des politiques volontairement conservatrices. Lors des trois premiers jours, 140 demandes MFA par utilisateur et par jour ont \u00e9t\u00e9 enregistr\u00e9es, car un d\u00e9clencheur de politique r\u00e9agissait \u00e0 chaque bascule entre le VPN et le LAN du bureau. Apr\u00e8s un calibrage utilisant le statut d’appareil conforme comme signal, le nombre de demandes est tomb\u00e9 \u00e0 12-18 par jour, ce que les utilisateurs ont accept\u00e9. La le\u00e7on : la t\u00e9l\u00e9m\u00e9trie en phase pilote n’est pas une fonctionnalit\u00e9 optionnelle, mais l’outil qui d\u00e9termine l’acceptation.<\/p>\n Un autre point qui revient r\u00e9guli\u00e8rement lors des audits : la s\u00e9paration entre authentification et autorisation. La MFA d\u00e9termine si quelqu’un peut se connecter en toute s\u00e9curit\u00e9. Ce qu’il peut faire ensuite est r\u00e9gi par l’autorisation via le *Role-Based Access Control*, le *Privileged Access Management* ou l’acc\u00e8s *Just-in-Time*. De nombreuses entreprises m\u00e9langent ces concepts, ce qui conduit \u00e0 la conclusion erron\u00e9e qu’une MFA forte compense une configuration de r\u00f4les faible. Ce n’est pas le cas. La NIS2 exige explicitement dans l’article 21 des politiques d’acc\u00e8s. Ces politiques doivent reposer sur une architecture de r\u00f4les solide, et non uniquement sur la demande MFA.<\/p>\n La directive impose une MFA \u00ab\u00a0appropri\u00e9e\u00a0\u00bb sans pr\u00e9ciser de param\u00e8tres exacts. Si vous utilisez une MFA classique avec un second facteur robuste, vous remplissez cette obligation, \u00e0 condition que la documentation soit irr\u00e9prochable. La MFA adaptative n’est pas une obligation, mais elle devient en pratique un standard de facto pour les organisations expos\u00e9es \u00e0 des risques, car elle permet de justifier clairement les seuils et exceptions.<\/p>\n G\u00e9n\u00e9ralement en parall\u00e8le, sans bascule brutale. Conditional Access s’applique d’abord aux applications Microsoft, tandis que Duo reste en place pour les syst\u00e8mes Cisco et les applications legacy. Apr\u00e8s six \u00e0 neuf mois, il est g\u00e9n\u00e9ralement clair si une migration compl\u00e8te est judicieuse ou si une configuration hybride reste pertinente sur le long terme.<\/p>\n Un point de d\u00e9part typique consiste \u00e0 d\u00e9clencher une demande de MFA lors d’une connexion depuis un nouvel appareil, une IP r\u00e9seau inconnue, en dehors des horaires de travail ou lors de l’acc\u00e8s \u00e0 des applications sensibles. Apr\u00e8s trois mois, les seuils sont ajust\u00e9s en fonction des donn\u00e9es de t\u00e9l\u00e9m\u00e9trie, aboutissant souvent \u00e0 un durcissement de certaines conditions et \u00e0 un assouplissement d’autres.<\/p>\n Les comptes de service b\u00e9n\u00e9ficient d’une authentification bas\u00e9e sur des certificats ou des identit\u00e9s manag\u00e9es, combin\u00e9e \u00e0 des tokens \u00e0 dur\u00e9e de vie limit\u00e9e et \u00e0 une rotation des secrets dans un vault. Le niveau de protection n’est pas une MFA, mais il est \u00e9quivalent. La documentation de cette d\u00e9cision est cruciale pour que l’auditeur comprenne la politique mise en place.<\/p>\n Le BSI recommande le number-matching ou des proc\u00e9dures \u00e9quivalentes dans ses derni\u00e8res lignes directrices, sans l’imposer explicitement. Microsoft a configur\u00e9 le number-matching comme param\u00e8tre par d\u00e9faut pour Entra Authenticator, tandis que Duo et Okta le pr\u00e9conisent fortement et le mettent en avant dans leurs derni\u00e8res versions des consoles d’administration. Si vous utilisez des notifications push sans matching, vous devez justifier ce choix dans votre analyse des risques et le consigner dans votre documentation NIS2.<\/p>\n\n
L\u2019article 21 de NIS2 comme cadre pour l\u2019MFA adaptative<\/h2>\n
Les quatre grandes plateformes IAM dans la comparaison Adaptive MFA<\/h2>\n
Pourquoi la fatigue MFA est le principal risque lors d\u2019un d\u00e9ploiement<\/h2>\n
\n
\n
Comment les \u00e9quipes de s\u00e9curit\u00e9 structurent un d\u00e9ploiement sans faille<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
La directive NIS2 exige-t-elle explicitement une MFA adaptative ou une MFA classique suffit-elle ?<\/h3>\n
Comment se d\u00e9roule la transition de Duo vers Entra Conditional Access dans les environnements Microsoft 365 ?<\/h3>\n
Quels seuils sont un bon point de d\u00e9part pour la MFA adaptative ?<\/h3>\n
Comment g\u00e9rer les comptes de service qui ne supportent pas la MFA interactive ?<\/h3>\n
Que dit le BSI concernant le number-matching comme param\u00e8tre par d\u00e9faut ?<\/h3>\n
Plus d’articles du r\u00e9seau MBF Media<\/h2>\n