MFA adaptatif dans Entra, Okta et Duo : comment les équipes sécurité peuvent aligner leur déploiement 2026 sur la NIS2

Q: La directive NIS2 exige-t-elle explicitement une MFA adaptative ou une MFA classique suffit-elle ?

La directive impose une MFA "appropriée" sans préciser de paramètres exacts. Si vous utilisez une MFA classique avec un second facteur robuste, vous remplissez cette obligation, à condition que la documentation soit irréprochable. La MFA adaptative n'est pas une obligation, mais elle devient en pratique un standard de facto pour les organisations exposées à des risques, car elle permet de justifier clairement les seuils et exceptions.

8 min de lecture

En 2026, l’MFA adaptative relève moins d’un défi technologique que d’une question de preuve. Depuis l’entrée en vigueur sans période de transition de la loi allemande transposant NIS2, les équipes de sécurité doivent non seulement démontrer qu’elles disposent d’une authentification multifacteur. Elles doivent prouver qu’elles savent quels risques elles atténuent ainsi. Cela implique que les seuils de décision soient documentés. Entra Conditional Access, Okta Adaptive MFA, Duo Risk-Based et Ping Identity offrent ces fonctionnalités. Pourtant, le déploiement échoue souvent en raison du fossé entre la fonctionnalité et la preuve.

L’essentiel en bref

NIS2 impose l’MFA, mais sans préciser de paramètres. L’article 21 exige une authentification multifacteur, laissant aux entreprises le soin de définir les seuils et les exceptions. L’obligation de documentation est concrète, le cadre technique volontairement large.
Le choix entre Entra, Okta, Duo et Ping dépend de la stack. Ceux qui utilisent déjà Microsoft 365 en profondeur optent généralement pour Entra Conditional Access. Pour les environnements multi-IdP, Okta reste la plateforme la plus flexible, Duo s’impose dans le contexte Cisco, et Ping Identity se positionne sur le segment entreprise.
La fatigue MFA est le problème opérationnel central. Les attaques par push-bombing et number-matching augmentent. Sans calibration des seuils et formation des utilisateurs, l’MFA adaptative perd l’effet escompté.

En lienInfostealer 2026 : comment les cookies de session contournent l’MFA / Prolifération des identités dans les PME : AD et configurations cloud

L’article 21 de NIS2 comme cadre pour l’MFA adaptative

La loi allemande transposant NIS2 est en vigueur depuis le 6 décembre 2025, sans période de transition. L’enregistrement auprès du BSI était obligatoire jusqu’au 6 mars 2026. L’article 21 de la directive énumère dix domaines dans lesquels les entreprises doivent justifier de leurs mesures, notamment les politiques d’accès, la sécurité de la chaîne d’approvisionnement et explicitement l’authentification multifacteur. La formulation de la directive est volontairement ouverte : l’MFA doit être mise en œuvre « de manière appropriée », sans que l’UE ou le BSI ne définissent de seuils minimaux concrets.

Cette ouverture devient un problème lors des audits, lorsque les entreprises déclarent avoir activé l’MFA, mais ne disposent d’aucune documentation sur la logique des seuils. Un auditeur ne demande pas si l’MFA est activée. Il demande dans quelles conditions un second facteur est exigé, quelles exceptions sont configurées, comment les accès d’urgence sont sécurisés et quels protocoles permettent de retracer la décision d’une politique de Conditional Access. Les équipes de sécurité qui ont traité l’MFA comme une simple case à cocher se retrouvent sur la défensive à ce stade.

6 mars 2026

Délai d’enregistrement auprès du BSI dans le cadre de NIS2. Ceux qui n’étaient pas enregistrés à cette date travaillent désormais sous le risque de sanctions et perdent toute marge de manœuvre dans la discussion sur les preuves.

Source : BSI, loi transposant NIS2, en vigueur depuis le 6 décembre 2025.

Les quatre grandes plateformes IAM dans la comparaison Adaptive MFA

Microsoft Entra Conditional Access s’impose comme une solution évidente pour les organisations utilisant Microsoft 365, car le moteur de politiques est directement intégré à la pile d’identité et exploite des signaux tels que le risque de connexion, le risque utilisateur et la conformité des appareils via Microsoft Defender for Identity. Les seuils peuvent être définis de manière granulaire par groupe et par application. L’effort réside dans l’affectation précise des politiques aux groupes d’utilisateurs et dans la documentation de la logique décisionnelle. Sans une bonne hygiène des politiques, on se retrouve après deux ans avec un fatras de cent règles qui se chevauchent, sans que personne ne sache plus lesquelles s’appliquent.

Okta Adaptive MFA se positionne comme une plateforme multi-IdP et excelle lorsque plusieurs sources d’identité convergent (Active Directory, G Suite, systèmes RH). Son moteur de scoring des risques utilise l’empreinte des appareils, la réputation du réseau et les schémas comportementaux. Pour les entreprises peu ancrées dans l’écosystème Microsoft, Okta est souvent le premier choix. Son prix est supérieur à celui d’Entra, mais sa flexibilité est plus grande.

Duo Security, désormais intégré à Cisco, est largement répandu dans les PME et les entreprises dotées d’une infrastructure Cisco. Ses fonctionnalités basées sur les risques sont matures, et son intégration avec Cisco ISE et Umbrella permet d’économiser temps et argent en cas d’investissements préalables. Ping Identity joue un rôle plus marqué dans le segment des grandes entreprises, avec des intégrations B2B complexes, le Customer Identity Access Management et les identités fédérées, plutôt que dans le middle market classique. Les quatre plateformes se recoupent sur les fonctionnalités de base, mais se distinguent nettement par la profondeur de leur intégration dans les stacks existants.

En pratique, le choix repose souvent moins sur la matrice des fonctionnalités 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’authentification basée sur les en-têtes, le proxy RADIUS ou les accès SSH avec certificats sont monnaie courante dans ce contexte. Duo et Ping offrent une plus grande profondeur dans ce domaine, tandis qu’Entra a comblé son retard ces 18 derniers mois grâce à Entra Application Proxy et Entra ID Governance. Okta couvre ce champ via son Access Gateway. L’évaluation de ces niches doit faire partie de la phase de sélection, sous peine de voir le déploiement échouer si le système ERP central ou une application métier ne peut être intégré.

La licence constitue le deuxième point variable dans la comparaison. Microsoft Entra Conditional Access est inclus dans Entra ID P1 et P2, P2 débloquant les politiques de risque avec Identity Protection. Okta facture par utilisateur avec différents packages pour la MFA, l’Adaptive MFA et la gestion du cycle de vie. Duo propose un modèle clair à 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ées. Pour obtenir un prix de référence, il faut toujours comparer la configuration concrète, et non les tarifs publics par utilisateur.

Pourquoi la fatigue MFA est le principal risque lors d’un déploiement

Le succès d’un déploiement d’Adaptive MFA ne dépend pas de la puissance du moteur de politiques, mais de l’expérience utilisateur. En 2025, les attaques par « push-bombing », où les attaquants déclenchent de manière répétée des demandes MFA jusqu’à ce que l’utilisateur accepte par habitude, sont devenues une méthode standard. En réponse, les éditeurs ont mis en place l’authentification par correspondance de chiffres, où l’utilisateur doit saisir un numéro affiché dans l’application d’authentification. Microsoft l’a activée par défaut, tandis que Duo et Okta proposent des variantes. Tout fournisseur qui n’impose pas cette méthode laisse la porte ouverte.

Ce qui provoque la fatigue MFA

Des notifications push sans contexte (pas de nom d’application, pas de géolocalisation)
Des seuils trop bas déclenchant une demande à chaque connexion
Un manque de sensibilisation des utilisateurs aux tentatives de phishing
Un outil de signalement absent pour les notifications suspectes

Ce qui réduit les attaques par fatigue

L’authentification par correspondance de chiffres activée par défaut pour tous les utilisateurs
Des politiques basées sur le risque, allégeant les appareils de confiance
Un bouton d’auto-signalement dans l’authentificateur
Une intégration SIEM pour détecter les schémas de push-bombing

Le réglage des seuils est le deuxième point critique. Si un système Adaptive MFA exige un second facteur à chaque deuxième connexion, cela génère une lassitude face aux demandes et pousse à des contournements. S’il demande trop rarement, il perd son efficacité en matière de sécurité. L’approche pragmatique consiste à démarrer les trois premiers mois avec des politiques conservatrices, puis à s’appuyer sur la télémétrie pour identifier quels schémas de connexion sont réellement suspects. Entra, Okta et Duo proposent des tableaux de bord permettant de visualiser la fréquence des demandes par utilisateur et par niveau de risque.

Un aspect souvent négligé concerne la gestion des comptes de service et des accès API. L’Adaptive MFA est optimisé pour les connexions interactives d’utilisateurs. Pour les automatisations, il faut privilégier l’authentification par certificat ou l’usage de jetons temporaires avec rotation. Laisser des comptes de service avec des mots de passe persistants et sans MFA constitue une brèche que les attaquants cibleront spécifiquement en 2026. La documentation de la politique relative aux comptes de service fait partie des preuves exigées par la directive NIS2, au même titre que l’authentification MFA des utilisateurs.

Une troisième composante soumise aux audits est la gestion des utilisateurs externes. Fournisseurs, prestataires et partenaires obtiennent régulièrement un accès à des systèmes internes sans être intégrés au processus standard de gestion des identités. Entra B2B Collaboration, Okta External Identities et Ping DaVinci proposent des fonctionnalités permettant d’offrir aux utilisateurs externes un parcours MFA sécurisé. Forcer ces utilisateurs dans des comptes internes expose non seulement à un risque de non-conformité, mais aussi à une surface d’attaque exploitée à plusieurs reprises en 2025 dans le cadre d’attaques par chaîne d’approvisionnement.

Comment les équipes de sécurité structurent un déploiement sans faille

Un déploiement réaliste se déroule en quatre phases, s’étalant sur dix à vingt semaines selon la taille de l’organisation. La première phase consiste en un état des lieux, la dernière en une préparation à l’audit.

Déploiement d’une MFA adaptative en quatre phases

Phase 1 (Sem. 1-4)

État des lieux : inventorier toutes les sources IAM, segmenter les groupes d’utilisateurs par classes de risque, lister séparément les comptes de service. Sans inventaire précis, les politiques deviennent arbitraires.

Phase 2 (Sem. 4-10)

Conception des politiques : définir des règles d’accès conditionnel ou basées sur le risque, par groupe d’utilisateurs et application. Le *number-matching* comme paramètre par défaut. Documenter le chemin d’urgence pour les comptes *break-glass*.

Phase 3 (Sem. 10-16)

Pilote : sélectionner un groupe d’utilisateurs pour le pilote, observer pendant deux semaines, analyser la télémétrie, ajuster les seuils. Rédiger un *playbook* de support pour les blocages MFA et les enregistrements d’appareils.

Phase 4 (Sem. 16+)

Préparation à l’audit : archiver la documentation des politiques dans le système de gouvernance IT, conserver les preuves des décisions sur les seuils, planifier des revues trimestrielles avec le RSSI et le DPO.

Le point faible le plus fréquent lors d’un déploiement est l’absence de lien avec la réponse aux incidents. Si le SIEM détecte des schémas de connexion suspects mais que l’équipe IAM ne sait pas comment placer rapidement les comptes en quarantaine, la MFA adaptative présente un angle mort. L’intégration entre Entra ou Okta et le pipeline SOC doit être réalisée dès la première phase, et non à la fin. Concrètement, cela signifie que Splunk, Sentinel ou Elastic ont besoin des journaux de connexion, des événements de risque et des événements de modification de politique dans un référentiel centralisé, avec des alertes sur des schémas comme dix échecs de connexion en cinq minutes ou une demande de validation provenant d’un pays inhabituel. Les formats de journaux diffèrent entre Entra et Okta, et la normalisation est une tâche qui ne peut être déléguée au fournisseur du SIEM.

Enfin, le point le plus important : la MFA adaptative n’est pas un projet avec une fin, mais un fonctionnement continu. Les seuils évoluent car les attaquants utilisent de nouvelles techniques. De nouvelles applications sont intégrées, les groupes d’utilisateurs changent. Celui qui planifie le déploiement comme un projet ponctuel se retrouve après dix-huit mois avec une pile IAM qui ne reflète plus la dernière menace. Un rôle dédié à l’exploitation IAM et des revues trimestrielles des politiques font de la MFA adaptative une preuve productive.

Un exemple concret issu du terrain : un constructeur de machines en Sauerland a lancé fin 2025 le déploiement d’Entra Conditional Access. La phase pilote s’est déroulée 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 été enregistrées, car un déclencheur de politique réagissait à chaque bascule entre le VPN et le LAN du bureau. Après un calibrage utilisant le statut d’appareil conforme comme signal, le nombre de demandes est tombé à 12-18 par jour, ce que les utilisateurs ont accepté. La leçon : la télémétrie en phase pilote n’est pas une fonctionnalité optionnelle, mais l’outil qui détermine l’acceptation.

Un autre point qui revient régulièrement lors des audits : la séparation entre authentification et autorisation. La MFA détermine si quelqu’un peut se connecter en toute sécurité. Ce qu’il peut faire ensuite est régi par l’autorisation via le *Role-Based Access Control*, le *Privileged Access Management* ou l’accès *Just-in-Time*. De nombreuses entreprises mélangent ces concepts, ce qui conduit à la conclusion erronée qu’une MFA forte compense une configuration de rôles faible. Ce n’est pas le cas. La NIS2 exige explicitement dans l’article 21 des politiques d’accès. Ces politiques doivent reposer sur une architecture de rôles solide, et non uniquement sur la demande MFA.

Questions fréquentes

La directive NIS2 exige-t-elle explicitement une MFA adaptative ou une MFA classique suffit-elle ?

La directive impose une MFA « appropriée » sans préciser de paramètres exacts. Si vous utilisez une MFA classique avec un second facteur robuste, vous remplissez cette obligation, à condition que la documentation soit irréprochable. La MFA adaptative n’est pas une obligation, mais elle devient en pratique un standard de facto pour les organisations exposées à des risques, car elle permet de justifier clairement les seuils et exceptions.

Comment se déroule la transition de Duo vers Entra Conditional Access dans les environnements Microsoft 365 ?

Généralement en parallèle, sans bascule brutale. Conditional Access s’applique d’abord aux applications Microsoft, tandis que Duo reste en place pour les systèmes Cisco et les applications legacy. Après six à neuf mois, il est généralement clair si une migration complète est judicieuse ou si une configuration hybride reste pertinente sur le long terme.

Quels seuils sont un bon point de départ pour la MFA adaptative ?

Un point de départ typique consiste à déclencher une demande de MFA lors d’une connexion depuis un nouvel appareil, une IP réseau inconnue, en dehors des horaires de travail ou lors de l’accès à des applications sensibles. Après trois mois, les seuils sont ajustés en fonction des données de télémétrie, aboutissant souvent à un durcissement de certaines conditions et à un assouplissement d’autres.

Comment gérer les comptes de service qui ne supportent pas la MFA interactive ?

Les comptes de service bénéficient d’une authentification basée sur des certificats ou des identités managées, combinée à des tokens à durée de vie limitée et à une rotation des secrets dans un vault. Le niveau de protection n’est pas une MFA, mais il est équivalent. La documentation de cette décision est cruciale pour que l’auditeur comprenne la politique mise en place.

Que dit le BSI concernant le number-matching comme paramètre par défaut ?

Le BSI recommande le number-matching ou des procédures équivalentes dans ses dernières lignes directrices, sans l’imposer explicitement. Microsoft a configuré le number-matching comme paramètre par défaut pour Entra Authenticator, tandis que Duo et Okta le préconisent fortement et le mettent en avant dans leurs dernières 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.