Introduction : fin de vie des Custom Controls Entra ID
Si votre organisation s'appuie sur les Custom Controls Microsoft Entra ID pour intégrer des fournisseurs MFA tiers tels que Duo Security, RSA SecurID ou Ping Identity, il est impératif d'initier dès maintenant votre planification de migration. Microsoft a officialisé la dépréciation de cette fonctionnalité avec une date de retrait fixée au 30 septembre 2026, et une fin de vie complète en mai 2027.
Cette décision n'est pas anodine : elle reflète une refonte architecturale profonde de la plateforme d'identité Microsoft Entra, en faveur de protocoles standards et d'une intégration native dans le moteur Conditional Access. Le remplacement désigné est la fonctionnalité External MFA, construite sur OpenID Connect (OIDC) et conçue pour combler toutes les lacunes techniques des Custom Controls.
Échéance critique
Les Custom Controls seront retirés le 30 septembre 2026 et atteindront leur fin de vie en mai 2027. Toute organisation n'ayant pas migré vers External MFA avant cette date risque des interruptions de service sur ses flux d'authentification critiques.
Anatomie des Custom Controls : comprendre les limites architecturales
Les Custom Controls ont été introduits comme une solution de contournement permettant d'injecter des fournisseurs MFA externes dans le processus d'authentification Entra ID. Leur fonctionnement reposait sur un mécanisme de redirection HTTP : après une première évaluation partielle par Entra ID, l'utilisateur était redirigé vers un service d'authentification tiers, qui renvoyait ensuite un jeton de validation vers Microsoft.
Flux d'authentification avec Custom Controls (architecture legacy)
Le flux typique d'un Custom Control se décomposait ainsi :
- L'utilisateur initie une connexion à une application protégée par Conditional Access
- Entra ID évalue les politiques Conditional Access et détecte la condition Custom Control
- L'utilisateur est redirigé vers le fournisseur MFA tiers (ex. : portail Duo)
- Le fournisseur tiers complète la vérification et retourne un claim JSON signé à Entra ID
- Entra ID valide le claim et accorde (ou refuse) l'accès
Ce modèle introduisait plusieurs problèmes structurels critiques :
- Évaluation hors pipeline : les politiques Conditional Access n'étaient pas réévaluées après le retour du fournisseur tiers, créant une fenêtre d'opacité dans l'application des contrôles de sécurité
- Absence de signal de risque en temps réel : Microsoft Entra ID Protection ne pouvait pas corréler les signaux de risque (sign-in risk, user risk) avec la session en cours pendant la phase de redirection
- Incompatibilité avec les Continuous Access Evaluation (CAE) : les sessions basées sur Custom Controls ne bénéficiaient pas de la révocation de token en temps réel
- Complexité opérationnelle : chaque provider tiers implémentait sa propre logique de claim, rendant la standardisation et l'audit difficiles
Limitation de sécurité majeure
Les Custom Controls opèrent en dehors du pipeline d'évaluation Conditional Access. Cela signifie que des contrôles critiques comme les exigences d'Authentication Strength, les session controls ou les sign-in risk policies ne sont pas garantis d'être appliqués après le retour du provider MFA tiers.
External MFA : architecture OIDC et intégration native
External MFA représente une refonte complète de l'intégration des fournisseurs MFA tiers dans Microsoft Entra ID. Contrairement aux Custom Controls, External MFA s'appuie sur le protocole OpenID Connect (OIDC) et s'intègre directement dans le moteur d'évaluation Conditional Access, en tant que composant natif de la plateforme.
Flux d'authentification avec External MFA (architecture moderne)
Avec External MFA, le flux devient :
- L'utilisateur initie une connexion
- Entra ID évalue l'ensemble des politiques Conditional Access, y compris les exigences External MFA
- Entra ID initie une session OIDC avec le fournisseur MFA externe enregistré
- Le fournisseur tiers complète la vérification et retourne un id_token OIDC signé
- Entra ID intègre le résultat dans son évaluation continue, applique les session controls et accorde l'accès
Cette architecture garantit que l'ensemble de la chaîne d'évaluation Conditional Access reste active pendant et après l'interaction avec le fournisseur tiers.
Avantages techniques d'External MFA
- Participation native au pipeline Conditional Access : les sign-in risk policies, authentication strength requirements et session controls sont évalués de manière cohérente, indépendamment du provider MFA utilisé
- Protocole OIDC standardisé : remplacement des intégrations propriétaires par un standard industriel largement supporté, simplifiant la maintenance et l'audit de conformité
- Gestion centralisée dans le portail Entra : les méthodes d'authentification externes sont configurées et administrées au même endroit que les méthodes natives Microsoft, dans le panneau Authentication Methods
- Expérience utilisateur améliorée : réduction des redirections superflues, parcours d'authentification plus fluide, diminution des tickets help desk liés aux échecs de connexion
- Compatibilité avec Continuous Access Evaluation : les sessions authentifiées via External MFA peuvent bénéficier de la révocation de token en temps réel
Compatibilité des providers tiers
Les principaux fournisseurs MFA comme Duo Security, RSA SecurID et Ping Identity ont annoncé ou sont en cours de développement de leur support pour External MFA via OIDC. Vérifiez la roadmap de votre fournisseur avant d'initier la migration.
Comparaison technique : Custom Controls vs External MFA
| Critère | Custom Controls (legacy) | External MFA (moderne) |
|---|---|---|
| Protocole | Propriétaire / Redirect HTTP | OpenID Connect (OIDC) |
| Intégration Conditional Access | Hors pipeline (post-évaluation) | Native, dans le pipeline |
| Sign-in Risk Evaluation | Non garantie | Complète et continue |
| Authentication Strength | Non supportée | Supportée nativement |
| Continuous Access Evaluation | Non compatible | Compatible |
| Gestion centralisée | Configuration séparée | Portail Entra unifié |
| Date de retrait | 30 septembre 2026 | Fonctionnalité active |
Configuration d'External MFA dans Microsoft Entra ID
Voici les étapes techniques pour configurer External MFA avec un fournisseur tiers compatible OIDC.
Prérequis
- Tenant Microsoft Entra ID avec licences P1 ou P2
- Fournisseur MFA tiers supportant External MFA via OIDC (consulter la documentation du vendor)
- Accès Global Administrator ou Authentication Policy Administrator
- Enregistrement de l'application OIDC du fournisseur dans votre tenant
Déploiement via le portail Entra
Enregistrer le fournisseur MFA externe
Naviguez vers Entra ID > Protection > Authentication methods > External authentication methods. Cliquez sur + Add et renseignez les métadonnées OIDC fournies par votre vendor (Client ID, Client Secret, Discovery URL).
Configurer les politiques Conditional Access
Dans Entra ID > Protection > Conditional Access, créez ou modifiez une politique existante. Dans la section Grant, sélectionnez Require authentication strength puis choisissez ou créez une Custom Authentication Strength incluant votre External MFA provider.
Valider la configuration via Microsoft Graph API
Utilisez Microsoft Graph pour vérifier que le provider est correctement enregistré :
1# Connexion avec les permissions requises2Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"3 4# Lister les fournisseurs External MFA configurés5$externalProviders = Invoke-MgGraphRequest -Method GET `6 -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations"7 8$externalProviders.value | Where-Object { $_."@odata.type" -like "*ExternalAuthentication*" } | 9 Select-Object id, state, displayNameAuditer les Custom Controls existants via PowerShell
Avant de migrer, identifiez toutes les politiques Conditional Access qui référencent encore des Custom Controls :
1# Installation du module si nécessaire2Install-Module Microsoft.Graph -Scope CurrentUser -Force3 4Connect-MgGraph -Scopes "Policy.Read.All"5 6# Récupération de toutes les politiques CA7$policies = Get-MgIdentityConditionalAccessPolicy -All8 9# Filtrage des politiques avec Custom Controls10$policiesWithCustomControls = $policies | Where-Object {11 $_.GrantControls.CustomAuthenticationFactors.Count -gt 012}13 14foreach ($policy in $policiesWithCustomControls) {15 Write-Host "Politique : $($policy.DisplayName)" -ForegroundColor Yellow16 Write-Host " ID : $($policy.Id)"17 Write-Host " Custom Controls : $($policy.GrantControls.CustomAuthenticationFactors -join ', ')"18 Write-Host " Etat : $($policy.State)"19 Write-Host ""20}Tester en environnement pilote
Déployez la nouvelle configuration sur un groupe pilote restreint (10-20 utilisateurs) en créant une politique Conditional Access ciblant ce groupe. Supervisez les logs de connexion dans Entra ID > Monitoring > Sign-in logs en filtrant sur authenticationRequirement = multiFactorAuthentication et externalAuthenticationProvider.
1# Récupération des logs de connexion pour auditer les External MFA2Connect-MgGraph -Scopes "AuditLog.Read.All"3 4$signInLogs = Get-MgAuditLogSignIn -Filter `5 "authenticationRequirement eq 'multiFactorAuthentication'" `6 -Top 1007 8$signInLogs | Select-Object UserDisplayName, AppDisplayName, `9 @{N='MFA Detail'; E={$_.AuthenticationDetails.AuthenticationMethod}} | 10 Format-Table -AutoSizeAstuce de migration progressive
Utilisez la fonctionnalité Report-only mode des politiques Conditional Access pour simuler l'impact de vos nouvelles politiques External MFA sur la population utilisateur, avant de les basculer en mode Enabled. Cela permet d'identifier les cas limites sans impact sur la production.
Plan de migration : checklist technique complète
Voici un plan de migration structuré pour les administrateurs système et ingénieurs cloud en charge de cette transition.
Phase 1 — Inventaire et évaluation (J-12 mois)
- Exécuter le script d'audit PowerShell pour identifier toutes les politiques Conditional Access référençant des Custom Controls
- Cartographier les applications et les flux d'authentification dépendants de providers MFA tiers
- Documenter les Custom Control IDs et leurs configurations associées
- Vérifier la roadmap External MFA de chaque fournisseur tiers utilisé dans votre organisation
- Évaluer les licences requises (Entra ID P1/P2) pour l'ensemble de la population cible
Phase 2 — Conception et préparation (J-9 mois)
- Enregistrer les applications OIDC des fournisseurs MFA tiers dans le tenant Entra ID
- Concevoir la nouvelle architecture de politiques Conditional Access avec Authentication Strength
- Définir les Custom Authentication Strength adaptées à vos exigences de sécurité
- Préparer les procédures de rollback en cas d'échec du déploiement pilote
Phase 3 — Pilote et validation (J-6 mois)
- Déployer External MFA sur un groupe pilote représentatif (différents OS, applications, localisations)
- Valider les scénarios d'authentification critiques : navigateur web, clients natifs, applications legacy
- Analyser les logs de connexion pour détecter les erreurs ou les comportements inattendus
- Recueillir les retours utilisateurs et ajuster la configuration
Phase 4 — Déploiement production et désactivation (J-3 mois)
- Déployer progressivement External MFA sur la totalité des utilisateurs (par vagues ou par département)
- Désactiver les politiques Conditional Access basées sur les Custom Controls après validation
- Supprimer les Custom Controls du tenant une fois la migration complète
- Documenter la nouvelle architecture et mettre à jour les runbooks opérationnels
Ne pas attendre la date limite
Tenter une migration en urgence en septembre 2026 laissera peu de marge pour les tests, le troubleshooting et la gestion des cas limites. Une migration précipitée sur des flux d'authentification critiques peut entraîner des lockouts utilisateurs et des interruptions de service majeures.
Implications pour la gouvernance et la conformité
La migration vers External MFA offre également des opportunités d'amélioration de la posture de sécurité et de la conformité réglementaire :
- Alignement NIST SP 800-63B : External MFA via OIDC s'aligne mieux avec les recommandations du NIST sur les protocoles d'authentification standards
- Auditabilité renforcée : les événements d'authentification External MFA sont intégralement tracés dans les Entra ID Sign-in Logs et exportables vers Microsoft Sentinel ou votre SIEM
- Compatibilité Zero Trust : l'intégration native dans Conditional Access renforce l'architecture Zero Trust en garantissant une évaluation continue des politiques à chaque accès
- Rapports de conformité : la centralisation de la gestion des méthodes d'authentification dans le portail Entra simplifie la génération de rapports pour les audits (ISO 27001, SOC 2, NIS2)
Conclusion
La dépréciation des Custom Controls Entra ID marque une étape structurante dans l'évolution de la plateforme d'identité Microsoft. La migration vers External MFA n'est pas une simple substitution fonctionnelle : c'est une opportunité de moderniser l'architecture d'authentification de votre organisation, d'éliminer des dette technique et d'aligner votre posture de sécurité avec les standards industriels contemporains.
Les équipes IT disposent de deux ans pour planifier et exécuter cette transition. Commencer dès maintenant l'inventaire, l'évaluation des providers et la conception de la nouvelle architecture est la décision la plus prudente pour éviter toute disruption à l'approche de l'échéance de septembre 2026.
