Retrait MFA SMS Entra ID Passkeys : le calendrier de migration

Retrait MFA SMS Entra ID Passkeys : ce qui change

La migration retrait MFA SMS Entra ID passkeys de Microsoft remplace sa propre méthode de délivrance des codes par SMS et appel vocal pour l'authentification multifacteur (MFA) par les passkeys comme expérience d'authentification par défaut. Ce n'est pas une simple déduction de catalogue — c'est un changement de politique produit daté et publié, documenté directement par Microsoft (Passkeys by default and retirement of Microsoft-provided SMS and voice authentication, Microsoft Learn).

C'est une histoire différente, plus étroite, que le cas général présenté dans Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas — cet article explique que la simple présence du MFA ne suffit pas en soi ; celui-ci porte sur un canal de délivrance précis et phishable (SMS/vocal fourni par Microsoft) désactivé à une date fixe, aux côtés d'autres schémas hérités faibles comme le MFA fatigue / push bombing que des méthodes résistantes au phishing comme les passkeys sont censées éliminer.

Le moteur de ce changement est explicite dans la propre FAQ de Microsoft : les codes SMS et vocaux sont phishables et vulnérables au SIM-swapping, et ne répondent plus au niveau que Microsoft veut imposer par défaut pour l'authentification Entra ID (FAQ for Microsoft-provided SMS and voice retirement, Microsoft Learn).

Le calendrier de retrait

Le retrait s'applique uniquement aux tenants du cloud public (les autres environnements cloud suivent un calendrier ultérieur, annoncé séparément), couvre le SSPR ainsi que le MFA de connexion, et n'affecte pas Azure AD B2C. Microsoft Entra External ID est concerné selon un calendrier distinct et ultérieur, dont l'annonce reste à venir.

Un opt-out temporaire existe pour la fenêtre d'auto-inscription (1er septembre 2026 → 1er février 2027) — pas pour l'application du 1er février elle-même — via la propriété passkeyDynamicMigration de la politique de méthodes d'authentification du tenant :

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
{
   "optOutSettings": {
     "passkeyDynamicMigration": true
   }
}

Détection : qui, dans votre tenant, est encore exposé

Avant que cela ne se déploie automatiquement sur votre tenant, déterminez combien d'utilisateurs dépendent encore réellement du SMS ou de la voix fournis par Microsoft — et si vos paramètres actuels de Conditional Access et de Registration Campaign interagiront proprement avec les changements de Microsoft du 1er septembre. Si vous n'avez pas revu votre base Conditional Access récemment, consultez d'abord Failles d'Accès Conditionnel Azure : Contournement du MFA.

Remédiation

1. Inventoriez d'abord les utilisateurs exposés. Utilisez le script PowerShell officiel pour lister tous les comptes encore activés pour ou utilisant le SMS/vocal. Tout résultat non nul signifie que le tenant est concerné.
2. Faites migrer les utilisateurs vers les passkeys de façon proactive, selon votre propre calendrier. Activez Passkey (FIDO2) comme méthode d'authentification, placez votre population SMS/vocal dans un groupe d'Authentication Methods Policy activé pour les passkeys, et activez vous-même une Registration Campaign (centre d'admin Entra → Authentication methods → Registration campaign → State : Microsoft Managed, ciblée sur votre groupe de sécurité SMS/vocal) — c'est le même mécanisme que Microsoft appliquera automatiquement le 1er septembre 2026, mais vous en contrôlez le message et le calendrier.
3. Si un segment a un besoin réel de conformité ou opérationnel pour le SMS/vocal, documentez la réglementation ou le scénario précis dès maintenant, puis évaluez un fournisseur télécom géré par le client via le Microsoft Security Store à partir du 18 septembre 2026, et configurez-le à partir du 30 octobre 2026 — avant l'échéance du 1er février 2027.
4. N'utilisez l'opt-out passkeyDynamicMigration que comme un pont, pas comme un plan à long terme. Il retarde l'auto-inscription et la pression de la Registration Campaign pendant que vous terminez le travail de migration ; il ne retarde ni n'exempte l'application du 1er février 2027.
5. Communiquez tôt. Microsoft recommande un plan de communication en phases sensibilisation → action → rappel et publie des modèles pour les utilisateurs finaux pour le passage aux passkeys — ciblez la communication sur le groupe de sécurité constitué à l'étape 1 afin que les bons utilisateurs en entendent parler avant le début de l'incitation.
6. Revérifiez le Conditional Access. Un tenant qui bloque déjà l'authentification legacy et applique le MFA largement à tous les utilisateurs, pas seulement aux admins, absorbe ce changement avec bien moins de perturbation qu'un tenant qui s'appuie sur le SMS/vocal comme filet de secours silencieux. Pour un tour d'horizon complet, voir Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique.

Comment EtcSec détecte cela

L'audit Azure/Entra d'EtcSec signale les tenants encore exposés à ce retrait avant qu'il ne devienne une migration subie. AUTH_METHODS_SMS_ENABLED signale quand le SMS est activé comme méthode d'authentification, tout court ; MFA_PHONE_ONLY signale les comptes où les méthodes basées sur le téléphone (SMS, voix) sont la seule option MFA enregistrée — exactement la population qui recevra l'invite bloquante de passkey le 1er février 2027. MFA_NO_PASSWORDLESS et MFA_NO_FIDO2 signalent les tenants qui n'ont pas du tout activé de méthodes sans mot de passe ou FIDO2/passkey, ce qui est l'écart prérequis à combler avant de pouvoir lancer toute migration proactive.