Retrait des contrôles personnalisés Entra ID : guide de migration vers External MFA avant septembre 2026

Retrait des contrôles personnalisés Entra ID et méthodes d'authentification externes : ce qui change et pourquoi

Le retrait des contrôles personnalisés Entra ID — les Custom Controls de Conditional Access — au profit des méthodes d'authentification externes a désormais une échéance fixée par Microsoft. Selon la documentation Conditional Access de Microsoft Learn elle-même, il ne sera plus possible de créer de nouveaux contrôles personnalisés ni de modifier ceux qui existent à partir de septembre 2026, le retrait complet étant prévu pour début 2027. Un avis du Message Center Microsoft 365, MC1422061 (« Microsoft Entra ID : retrait des contrôles personnalisés dans Conditional Access et migration vers External MFA »), confirme le même gel de septembre 2026 et fixe le retrait complet à mai 2027, date à laquelle les contrôles personnalisés cesseront d'être pris en charge. Les méthodes d'authentification externes (External Authentication Methods) — la capacité standardisée que Microsoft commercialise désormais sous le nom External MFA — sont le seul remplacement pris en charge.

Les contrôles personnalisés n'ont jamais été une fonctionnalité Conditional Access grand public en disponibilité générale — Microsoft Learn les décrit depuis toujours comme « une fonctionnalité en préversion ». Lorsqu'une stratégie en utilisait un, le navigateur de l'utilisateur connecté était redirigé vers un service tiers approuvé, l'authentification s'y déroulait, puis l'utilisateur était redirigé vers Entra ID, qui vérifiait la réponse avant de poursuivre le flux de connexion. C'est exactement cette indirection qui est retirée : le même résultat — une MFA tierce appliquée au sein de Conditional Access — passe désormais par une méthode d'authentification native, en disponibilité générale, au lieu d'un aller-retour de redirection-vérification.

Comment fonctionnent les contrôles personnalisés — et pourquoi External MFA les remplace

Ce retrait n'est pas cosmétique. Les recommandations de migration de Microsoft listent des lacunes fonctionnelles concrètes que les contrôles personnalisés ont toujours eues, des lacunes qu'External MFA comble :

Source : Microsoft Learn, « Migrate from custom controls to external MFA in Conditional Access ».

La documentation Microsoft Learn sur les contrôles personnalisés liste la même lacune, vue depuis l'autre angle : les contrôles personnalisés ne peuvent explicitement pas être utilisés pour satisfaire l'exigence de MFA automatisée d'Identity Protection, la réinitialisation de mot de passe en libre-service de Microsoft Entra, les exigences de revendication MFA, les contrôles de fréquence de connexion, l'activation de rôle PIM, l'inscription d'appareils Intune, la relation d'approbation inter-locataires, ou la jonction d'appareil. Un locataire qui s'appuie sur un contrôle personnalisé pour « faire de la MFA » a, en pratique, fait tourner un sosie que plusieurs autres fonctionnalités Entra ne reconnaissent pas du tout comme de la MFA — un écart significatif face aux méthodes natives que nous couvrons dans notre analyse des changements d'inscription MFA sans mot de passe.

Autre subtilité de nommage à signaler pour éviter toute confusion en cours de migration : le remplacement est sorti en préversion sous le nom « external authentication methods », puis a atteint la disponibilité générale sous le nom External MFA (External Multifactor Authentication), selon l'annonce de disponibilité générale de Microsoft sur le blog Entra. Microsoft Learn, l'interface du centre d'administration et les objets de l'API Graph (externalAuthenticationMethodConfiguration) continuent d'utiliser en interne la terminologie « external authentication method » — attendez-vous donc à voir les deux noms selon l'endroit où vous regardez.

Détection : repérer chaque stratégie Conditional Access utilisant des contrôles personnalisés

Avant de toucher à quoi que ce soit, faites l'inventaire des stratégies Conditional Access qui utilisent réellement un contrôle personnalisé aujourd'hui. Pour un panorama plus large des mauvaises configurations Conditional Access au-delà des contrôles personnalisés, voir notre guide sur les failles d'accès conditionnel Entra ID. Selon les recommandations de migration de Microsoft, cela peut se faire de deux façons :

Portail : connectez-vous au centre d'administration Microsoft Entra avec au minimum le rôle Administrateur de la stratégie d'authentification, accédez à Protection > Conditional Access > Stratégies, et examinez les contrôles d'octroi de chaque stratégie à la recherche d'une référence à un contrôle personnalisé. Pour chaque correspondance, notez le nom et l'ID de la stratégie, les utilisateurs/groupes et applications cloud ciblés, le fournisseur du contrôle personnalisé référencé, et les conditions éventuelles (emplacements, plateformes d'appareil).

Microsoft Graph PowerShell (plus rapide pour les grands locataires — les recommandations de Microsoft notent que certains environnements comptent des dizaines, voire des centaines de stratégies Conditional Access à vérifier) :

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.GrantControls -and (
        @($_.GrantControls.CustomAuthenticationFactors) |
        Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }
    ).Count -gt 0
} | Select-Object Id, DisplayName, State, @{
    N = "CustomAuthFactors"
    E = { ($_.GrantControls.CustomAuthenticationFactors | Where-Object { $_ -is [string] -and $_.Trim().Length -gt 0 }) -join "," }
}

Source : Microsoft Learn, « Migrate from custom controls to external MFA in Conditional Access ».

Exportez les résultats avant de commencer la migration. Si une stratégie ne référence aucun contrôle personnalisé, selon les recommandations mêmes de Microsoft aucune action n'est nécessaire dessus — n'y consacrez pas d'effort de migration inutile.

Remédiation : migrer vers les méthodes d'authentification externes avant l'échéance

Une fois l'inventaire réalisé, les recommandations de migration de Microsoft détaillent une trajectoire par phases. Prérequis d'abord : une licence Microsoft Entra ID P1 ou P2, le rôle Administrateur de la stratégie d'authentification (Administrateur général fonctionne aussi), le rôle Administrateur de rôle privilégié pour accorder le consentement administrateur à l'application du fournisseur, ainsi que les métadonnées de votre fournisseur External MFA — son Application ID, son Client ID et son URL de découverte OIDC.

1. Enregistrer le fournisseur External MFA. Dans le centre d'administration, accédez à Protection > Méthodes d'authentification > Stratégies > Ajouter une méthode externe, renseignez le nom d'affichage (non modifiable après création), le Client ID, l'App ID et le point de terminaison de découverte, puis accordez le consentement administrateur à l'application du fournisseur. La même configuration est disponible via l'API Graph (POST /policies/authenticationMethodsPolicy/authenticationMethodConfigurations avec @odata.type: "#microsoft.graph.externalAuthenticationMethodConfiguration") ou via la commande PowerShell New-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration, pour les équipes qui automatisent le déploiement.
2. Cibler uniquement un groupe de test — pas l'ensemble des utilisateurs — lors de l'activation de la méthode, et inscrire ces utilisateurs de test à la méthode d'authentification externe avant d'aller plus loin.
3. Créer une nouvelle stratégie Conditional Access en mode Rapport seul (Report-only) qui utilise le contrôle d'octroi standard Exiger l'authentification multifacteur (pas le contrôle personnalisé), avec le même périmètre d'applications cloud et de conditions que la stratégie héritée, ciblant le groupe de test, et excluant les comptes d'accès d'urgence break-glass.

🚨 Danger : les recommandations de Microsoft sont explicites — External MFA n'est pas encore compatible avec « Exiger un niveau de sécurité d'authentification » — seul le contrôle d'octroi standard « Exiger l'authentification multifacteur » le satisfait. Construire la stratégie de test sur une exigence de niveau de sécurité d'authentification échouera silencieusement à fonctionner comme prévu.

4. Vérifier d'abord en mode Rapport seul via l'onglet Conditional Access des journaux de connexion, confirmer que la stratégie s'évalue comme attendu et que la méthode MFA s'affiche bien comme votre fournisseur externe, puis basculer la stratégie sur Activé.
5. Exclure le groupe de test de la stratégie héritée basée sur le contrôle personnalisé et confirmer avec l'outil Que se passerait-il si (What If) que seule la nouvelle stratégie s'applique à eux, et que les connexions de test sont bien contestées par le fournisseur externe et non par le contrôle personnalisé.
6. Déployer par phases — groupe de test, puis IT/utilisateurs pilotes, puis service par service, puis l'ensemble des utilisateurs — en élargissant à chaque étape à la fois le groupe cible de la méthode External MFA et le périmètre de la nouvelle stratégie Conditional Access.
7. Retirer la stratégie héritée en dernier, pas en premier. Désactivez (sans supprimer) l'ancienne stratégie basée sur le contrôle personnalisé et surveillez les journaux de connexion pendant une à deux semaines avant de la supprimer et de retirer la définition du contrôle personnalisé, en conservant une voie de retour arrière en cas de régression.

Comment EtcSec détecte cela

Les contrôles Conditional Access d'EtcSec signalent la faille que ce retrait met à nu : CA_NO_MFA_REQUIREMENT fait remonter les applications cloud et les périmètres d'utilisateurs pour lesquels aucune stratégie Conditional Access n'exige réellement la MFA — exactement l'état dans lequel se retrouve un locataire si une stratégie basée sur un contrôle personnalisé cesse discrètement de fonctionner sans être remplacée. MFA_NOT_ENFORCED_ADMINS et MFA_NO_STRONG_METHOD repèrent les comptes privilégiés et les configurations à méthode faible qu'un contrôle personnalisé cassé ou non migré peut masquer, puisque les contrôles personnalisés n'ont jamais été reflétés comme une revendication MFA native. CA_POLICY_REPORT_ONLY signale les stratégies — y compris la stratégie de test en Rapport seul recommandée par cette migration — qui n'ont jamais été basculées en mode appliqué, afin qu'une migration en pause ne passe pas inaperçue.