Entra ID Inscription MFA Sans Mot de Passe : ce qui change
Pendant des années, Microsoft Entra ID a imposé aux nouveaux utilisateurs un parcours d'intégration « méthode la plus faible en premier » : avant de pouvoir enregistrer une passkey, une clé de sécurité FIDO2, Windows Hello for Business, macOS Platform SSO, ou la connexion sans mot de passe de Microsoft Authenticator, il fallait d'abord configurer une méthode MFA de base — généralement le SMS ou l'appel vocal. Cet ordre faisait des méthodes phishables et vulnérables au SIM-swapping le point d'entrée par défaut de chaque nouvelle identité, même dans les tenants qui voulaient des passkeys partout. Le changement Entra ID inscription MFA sans mot de passe que Microsoft déploie désormais supprime cette exigence.
Selon le suivi du Microsoft 365 message center (MC1450133, résumé par PUPUWEB et OurCloudNetwork, et repris cette semaine dans les discussions communautaires sur r/AZURE et r/entra), les utilisateurs éligibles pourront enregistrer une passkey synchronisée, une passkey Microsoft Entra sur Windows, ou une clé de sécurité FIDO2 comme toute première méthode d'authentification — sans détour obligatoire par le SMS ou la voix.
ℹ️ Remarque : Ceci est distinct du retrait du MFA SMS/vocal fourni par Microsoft, qui supprime une méthode faible existante. Ce changement porte sur l'ordre d'inscription pour les utilisateurs nouveaux ou sous-inscrits — il fait du sans mot de passe le chemin le plus simple à l'entrée, pas seulement une destination éventuelle.
Selon les mêmes sources de suivi, le déploiement se fait en phases :
- Phase 1 — passkeys synchronisées, passkeys Microsoft Entra sur Windows, et clés de sécurité FIDO2 — commence à être déployée dans le monde entier et dans les tenants GCC mi-octobre 2026, avec un achèvement prévu pour mi-novembre 2026.
- Phase 2 — extension de l'inscription sans mot de passe en premier facteur à Windows Hello for Business, macOS Platform SSO, et la connexion sans mot de passe par téléphone de Microsoft Authenticator — suit ensuite.
⚠️ Avertissement : Le texte du message center de Microsoft pour la Phase 2 est incohérent en interne — il indique un début « début janvier 2026 » (avant le début de la Phase 1 en octobre 2026) se terminant « fin février 2027 ». Chaque tracker que nous avons vérifié (PUPUWEB, OurCloudNetwork, M365 Admin) reproduit exactement ce même texte, ce n'est donc pas un désaccord entre trackers — cela ressemble à une coquille dans le billet original de Microsoft (très probablement janvier 2027, pas 2026). Considérez la fenêtre de la Phase 1 ci-dessus comme le chiffre fiable, et confirmez la date exacte de la Phase 2 dans votre propre message center Microsoft 365 (MC1450133) avant de communiquer en interne. Notez que MC1450134 est un message distinct, mais lié — Windows Hello for Business et macOS Platform SSO devenant des facteurs MFA autonomes, disponibilité générale début octobre-fin novembre 2026 — ce n'est pas une source de calendrier pour la Phase 2 de ce changement-ci.
Les administrateurs ne perdent pas le contrôle : la politique de méthodes d'authentification existante et le Conditional Access continuent de déterminer quelles méthodes sont réellement disponibles et pour qui. Le changement réduit la friction d'inscription, il n'active pas silencieusement les passkeys pour les tenants qui n'ont pas activé la méthode.
Comment ça fonctionne
L'inscription sans mot de passe en premier s'appuie sur une infrastructure qui existe déjà dans Entra ID : la politique de méthodes d'authentification (quelles méthodes d'authentification sont activées à l'échelle du tenant, y compris FIDO2/passkey avec Allow self-service setup) et la fonctionnalité registration campaign, qui incite les utilisateurs connectés vers une méthode cible après avoir complété le MFA.
Selon la documentation Microsoft Learn sur la registration campaign, la campagne se configure via le bloc registrationEnforcement.authenticationMethodsRegistrationCampaign de la politique de méthodes d'authentification (lisible/modifiable via Microsoft Graph à GET/PATCH https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy), avec ces propriétés :
| Propriété | Valeurs | Ce qu'elle contrôle |
|---|---|---|
state | enabled / disabled / default | Si la campagne incite les utilisateurs ou non |
includeTargets[].targetedAuthenticationMethod | fido2 / microsoftAuthenticator | Vers quelle méthode les utilisateurs sont poussés — une campagne ne peut cibler qu'une seule méthode à la fois |
snoozeDurationInDays | 0–14 (par défaut 1) | Délai avant qu'une incitation ignorée ne réapparaisse |
enforceRegistrationAfterAllowedSnoozes | true / false | Si l'inscription devient obligatoire après 3 reports |
Lorsque l'état Microsoft managed est utilisé, Microsoft fait déjà évoluer progressivement la cible d'Authenticator vers fido2 (passkeys) et fait passer l'intervalle de report à 1 jour — mais désactive aussi la limite d'inscription forcée après 3 reports, si bien que les incitations deviennent plus fréquentes tandis que l'inscription forcée reste désactivée pour les tenants qui n'ont pas défini de valeurs explicites — un point à connaître avant de supposer que la cible de votre campagne actuelle est toujours celle que vous avez configurée il y a plusieurs mois.
Détection : que vérifier dans votre tenant
Avant l'arrivée de la Phase 1, confirmez ce que votre tenant est réellement configuré pour autoriser, et qui s'inscrit réellement :
| Vérification | Où | Ce que vous recherchez |
|---|---|---|
| État de la méthode FIDO2 / passkey | Centre d'admin Entra → Authentication methods → Policies → Passkey (FIDO2) | La méthode est-elle Enabled, et Allow self-service setup est-il activé ? |
| Cible de la registration campaign | Centre d'admin Entra → Authentication methods → Registration campaign, ou GET /policies/authenticationmethodspolicy | state est-il enabled/Microsoft managed, et quel est targetedAuthenticationMethod ? |
| Couverture d'inscription de référence | Rapport d'activité des méthodes d'authentification (Centre d'admin Entra → Authentication methods → Activity, onglet Registration) | Quelle part des utilisateurs a actuellement une méthode sans mot de passe enregistrée, par rapport au téléphone uniquement |
| Événements d'inscription | Journal d'audit Entra ID, filtrer la catégorie d'activité « Authentication methods » | Opérations User registered security info et User changed default security info — suivez qui inscrit des passkeys, et quand |
| Contrôle de l'inscription | Politiques Conditional Access ciblant l'action utilisateur Register security information | Confirmez que l'inscription est restreinte aux réseaux/appareils attendus avant d'élargir la porte des passkeys |
💡 Astuce : Exécutez le rapport d'activité des méthodes d'authentification avant que la Phase 1 ne commence à être déployée dans la région de votre tenant. Cela vous donne une vraie référence à comparer une fois l'inscription sans mot de passe en premier activée — utile pour prouver que le changement a réellement fait progresser l'adoption, pas seulement le supposer.
Remédiation : préparer le déploiement
- Activez la méthode passkey (FIDO2) avec configuration en libre-service, si ce n'est pas déjà fait — c'est le prérequis pour que les utilisateurs bénéficient de l'inscription sans mot de passe en premier.
- Décidez dès maintenant de la cible de votre registration campaign. Si vous voulez que les nouveaux utilisateurs arrivent sur les passkeys plutôt que sur les notifications Authenticator, définissez explicitement
targetedAuthenticationMethodsurfido2plutôt que de vous fier aux valeurs par défaut gérées par Microsoft, qui changent selon le calendrier de Microsoft, pas le vôtre. - Revoyez le Conditional Access sur « Register security information ». Si l'inscription ne doit se faire que depuis des appareils gérés ou des réseaux de confiance, confirmez que cette politique s'applique toujours une fois le sans mot de passe devenu l'option de premier contact, pas seulement une mise à niveau ultérieure — voir notre guide des failles Conditional Access pour les erreurs courantes.
- Pilotez avant la fin de la Phase 1 dans votre région. Les incitations aux passkeys sont évaluées par combinaison appareil-et-navigateur, pas par utilisateur — testez l'expérience sur votre parc d'appareils réel (Windows/Chrome, macOS/Safari, mobile) plutôt que de supposer un comportement uniforme.
- Revérifiez directement MC1450133 dans votre centre d'admin Microsoft 365, message center, à l'approche de la fenêtre de déploiement — le texte du calendrier de Phase 2 de Microsoft est incohérent en interne, et le message center est la source de vérité propre à votre tenant pour votre vague de déploiement.
- N'en restez pas à l'ordre d'inscription. L'inscription sans mot de passe en premier ne comble qu'une partie de l'écart — voir pourquoi le MFA seul ne suffit pas pour les contrôles Conditional Access et Security Defaults qui doivent rester en place.
Comment EtcSec détecte cela
EtcSec signale les tenants où les méthodes sans mot de passe ne sont pas disponibles ou appliquées via les contrôles MFA_NO_PASSWORDLESS et MFA_NO_FIDO2 (passkey/FIDO2 non activé ou non configuré en libre-service), MFA_NO_STRONG_METHOD (aucune méthode résistante au phishing configurée du tout), MFA_PHONE_ONLY (utilisateurs limités au MFA basé sur le téléphone, exactement le schéma que ce changement de Microsoft vise à faire disparaître), et CA_NO_MFA_REQUIREMENT (aucune politique Conditional Access n'exige réellement le MFA en premier lieu, ce qui annule tout bénéfice de l'amélioration de l'ordre d'inscription).
ℹ️ Remarque : EtcSec vérifie automatiquement ces écarts lors de chaque audit Azure/Entra. Lancez un audit gratuit pour voir si votre tenant est positionné pour tirer parti de l'inscription sans mot de passe en premier une fois qu'elle atteindra votre région.
Explorez les pages identité liées à ce sujet