Calipia : le blog

Il y a des annonces Microsoft qui font naître un enthousiasme poli, et d’autres qui font vraiment lever les yeux au ciel aux architectes IAM en se demandant pourquoi cela a pris autant de temps. La disponibilité générale de l’External MFA dans Microsoft Entra ID appartient, sans conteste, à la seconde catégorie.

Rappelons le contexte. Microsoft Entra ID, anciennement connu sous le nom d’Azure Active Directory, est l’un des systèmes de gestion des identités et des accès (IAM), sans surprise, les plus utilisés dans les environnements d’entreprise. Il prend en charge de nombreuses méthodes d’authentification multifacteur natives, allant de Microsoft Authenticator à Windows Hello for Business en passant par SMS et appels vocaux. Ce qui lui manquait, en revanche, était une intégration propre et standardisée avec les fournisseurs MFA tiers. Une lacune aux conséquences pratiques considérables pour les grandes organisations.

Le problème : l’entreprise réelle n’est pas un tenant monolithique

Microsoft a discrètement supprimé l’une des frictions les plus importantes en matière de gestion d’identité pour les clients enterprise : l’impossibilité d’utiliser proprement des fournisseurs MFA tiers dans Microsoft Entra ID sans sacrifier le contrôle des politiques. 

La réalité des DSI est bien éloignée des schémas d’architecture épurés que Microsoft présente dans ses keynotes. Les grandes entreprises ont des solutions MFA contractuellement engagées avec d’autres fournisseurs, des exigences réglementaires sectorielles qui imposent des outils certifiés spécifiques, et des opérations de fusion-acquisition qui laissent coexister temporairement des référentiels d’identité hétérogènes. La fonctionnalité est particulièrement utile pour les entreprises en cours de fusion ou d’acquisition, où plusieurs systèmes d’identité doivent coexister temporairement, ou pour les organisations qui doivent se conformer à des mandats d’authentification spécifiques à leur secteur d’activité. 

Jusqu’à présent, la réponse de Microsoft à ce besoin s’appelait Custom Controls, un mécanisme introduit en preview en 2020. Et il faut être honnête : c’était une rustine. Cette approche de la MFA tierce avait été jugée trop limitée et a été remplacée par les méthodes d’authentification externes dans Microsoft Entra ID. 

Ce que l’External MFA apporte concrètement

Basé sur le standard OpenID Connect (OIDC), l’External MFA permet d’intégrer le fournisseur MFA de votre choix dans Microsoft Entra ID sans sacrifier la sécurité ni l’application des politiques ( voir pour plus de détail : Microsoft Community Hub). C’est là que réside l’essentiel de la valeur ajoutée par rapport à l’ancienne approche.

Le mécanisme de fonctionnement est élégant dans sa conception. Si la MFA est requise, au lieu de présenter le propre défi MFA de Microsoft, le système redirige l’utilisateur vers le fournisseur MFA externe configuré. Après une authentification réussie, le fournisseur retourne un token OIDC que Microsoft Entra ID valide avant de finaliser la connexion. Autrement dit, Entra ID reste le plan de contrôle, mais délègue le facteur d’authentification secondaire à un tiers de confiance.

Ce point mérite qu’on s’y attarde, car c’est précisément ce que les Custom Controls ne faisaient pas correctement. D’un point de vue technique, toutes les demandes d’authentification, qu’elles utilisent la MFA native ou externe, passent toujours par l’ensemble du pipeline d’évaluation des politiques de Microsoft Entra ID. Cela signifie que le Conditional Access, l’évaluation du risque en temps réel, les contrôles de conformité des appareils et les restrictions géographiques restent pleinement opérationnels même lorsque le challenge MFA est délégué à un fournisseur externe. Pour un architecte Zero Trust, c’est exactement ce qu’on attend d’un tel mécanisme.

La gestion unifiée : le single pane of glass enfin crédible

L’un des arguments de vente souvent avancés par Microsoft pour Entra ID est la centralisation de la gestion des identités. Avec les Custom Controls, cet argument était difficile à tenir face aux équipes sécurité, car les méthodes externes restaient dans une forme de zone grise administrative. Une fois configuré, l’External MFA est géré aux côtés des méthodes d’authentification natives de Microsoft Entra ID, offrant aux administrateurs une interface unifiée pour toutes les méthodes d’authentification. 

Lorsqu’on configure l’External MFA, il apparaît aux côtés des méthodes d’authentification natives de Microsoft dans le centre d’administration. Les événements d’authentification provenant du fournisseur externe apparaissent dans les journaux de connexion d’Entra ID, permettant de surveiller l’activité d’authentification depuis un emplacement unique. Pour les équipes SOC qui en avaient assez de croiser plusieurs consoles pour reconstituer une chaîne d’authentification, c’est un gain opérationnel non négligeable.

Les prérequis techniques à ne pas négliger

L’intégration repose intégralement sur OIDC. Une Discovery URL correspond au point de terminaison de découverte OIDC du fournisseur d’authentification externe. Il faut s’assurer que la propriété kid (Key ID) est encodée en base64 dans l’en-tête JWT du token d’identité ainsi que dans le JWKS récupéré depuis le jwks_uri du fournisseur. Cet alignement d’encodage est essentiel pour la validation des signatures de token lors des processus d’authentification. Un détail technique qui peut surprendre lors des premiers tests d’intégration si l’on n’y prête pas attention.

Il faut également noter que la fonctionnalité nécessite un abonnement Microsoft Entra ID P1 ou P2. Les organisations sur des licences plus légères devront en tenir compte dans leur plan de migration. Par ailleurs, les organisations doivent accorder un consentement administratif pour que le fournisseur externe puisse accéder aux informations utilisateur requises lors de l’authentification. 

Un avertissement de Microsoft à prendre au sérieux : la fatigue MFA

Microsoft ne se contente pas d’annoncer la fonctionnalité, il glisse dans sa documentation un rappel que les équipes sécurité auraient tort d’ignorer. Microsoft avertit qu’imposer la MFA trop fréquemment peut dégrader l’expérience utilisateur et augmenter le risque de phishing en conditionnant les utilisateurs à approuver les invites sans examen attentif.

C’est le paradoxe bien connu du MFA fatigue attack : une politique de reauthentification trop agressive finit par entraîner une forme d’automatisme chez les utilisateurs, qui valident les demandes sans les analyser. Les administrateurs devront donc calibrer avec soin les politiques de fréquence de connexion au sein du Conditional Access pour trouver l’équilibre entre sécurité et productivité réelle.

La fin annoncée des Custom Controls : le compte à rebours est lancé

La nouvelle fonctionnalité s’accompagne d’une échéance que les équipes IT ne peuvent pas se permettre d’ignorer. Le nouveau cadre External MFA remplace entièrement l’ancienne fonctionnalité Custom Controls au sein de Microsoft Entra ID. Microsoft a planifié la dépréciation formelle des Custom Controls pour le 30 septembre 2026. 

Cette échéance est importante car les projets d’identité ont tendance à stagner jusqu’à ce que la date limite devienne impossible à ignorer. Microsoft semble conscient de cette tendance, c’est pourquoi sa documentation décrit déjà comment l’External MFA et les Custom Controls peuvent fonctionner en parallèle pendant la période de migration.Le message est clair : utilisez la fenêtre de chevauchement pour valider le nouveau modèle plutôt que d’attendre que l’ancien défaille sous la pression.

Le processus de migration implique plusieurs étapes clés. Les organisations doivent d’abord configurer leur fournisseur MFA externe pour prendre en charge l’intégration OIDC avec Microsoft Entra ID, puis créer des politiques d’authentification dans Entra ID qui référencent ce fournisseur externe. Les organisations utilisant des implémentations simples avec des fournisseurs MFA majeurs trouveront probablement un chemin de migration direct. En revanche, celles qui utilisent des solutions MFA développées sur mesure ou des outils de niche devront prévoir un travail d’adaptation plus conséquent.

Des implications financières existent également. Bien que Microsoft ne facture pas de supplément pour la fonctionnalité External MFA elle-même, les organisations peuvent supporter des coûts de licence additionnels de la part de leurs fournisseurs MFA. Certains prestataires facturent en fonction du volume d’authentifications, et acheminer davantage d’authentifications via leurs systèmes pourrait augmenter les coûts. Un point budgétaire à anticiper dans les plans de migration.

Ce que cela dit de la stratégie de Microsoft

Au-delà de la fonctionnalité elle-même, cette annonce est révélatrice d’une évolution de posture chez Microsoft. La dépréciation des Custom Controls nous dit quelque chose de plus large sur la direction de Microsoft. Les Custom Controls ont toujours été une approche plus sur-mesure, et les mécanismes bespoke ne scalent pas aussi proprement que les standards ouverts. En passant à l’External MFA, Microsoft consolide la stratégie d’identité autour d’un modèle d’intégration plus prévisible, ce qui devrait bénéficier à l’ingénierie, au support et à la gouvernance simultanément.

C’est un signal fort : Microsoft accepte que son écosystème ne soit pas le seul à exister dans les entreprises, et préfère jouer le rôle de plan de contrôle universel plutôt que d’imposer une MFA propriétaire à tout prix. Pour les DSI qui avaient du mal à justifier Entra ID comme hub central face à des équipes attachées à leurs solutions Duo, RSA ou autres, ce positionnement clarifie considérablement le discours.

En conclusion

L’External MFA dans Microsoft Entra ID n’est pas une révolution conceptuelle, c’est une correction structurelle que le marché attendait depuis que les Custom Controls avaient montré leurs limites. L’approche basée sur OIDC est solide, l’intégration avec le Conditional Access est ce qu’elle devrait être, et la gestion unifiée représente un gain opérationnel réel. Ce qui reste à surveiller : la qualité de la documentation de migration que Microsoft a promis de publier avant septembre 2026, et la compatibilité effective avec les fournisseurs MFA moins mainstream. Les architectes IAM ont tout intérêt à enclencher dès maintenant une revue de leur configuration Custom Controls existante, le délai de 18 mois paraît confortable sur le papier mais fond rapidement face aux cycles de projet réels.