Calipia : le blog

Microsoft avance, une fois de plus, sur le chemin du sans mot de passe. Un nouveau changement annoncé sur le Message Center sous la référence MC1450134 va modifier en profondeur la façon dont Entra ID traite Windows Hello for Business (WHfB) et le Platform Single Sign-On de macOS (PSSO) dans les scénarios de MFA. Rien d’anodin pour les architectes qui pilotent des politiques d’authentification multifactorielle sur des parcs hétérogènes Windows et Mac.

Le problème que Microsoft corrige

Aujourd’hui, WHfB et macOS PSSO savent déjà satisfaire une exigence de MFA lors de la connexion primaire. Mais les utilisateurs peuvent encore devoir enregistrer et utiliser une clé d’accès ou une méthode d’authentification supplémentaire pour certaines invites d’authentification renforcée, pour les politiques de force d’authentification, ou pour les contrôles de fréquence de connexion. Autrement dit, un collaborateur qui déverrouille déjà sa session avec Windows Hello peut se retrouver à ressortir son téléphone pour approuver une notification Authenticator quelques minutes plus tard, simplement parce qu’une politique d’Authentication Strength ou un contrôle de step-up se déclenche. Une incohérence qui agace autant les utilisateurs que les équipes support. 

Ce qui change à partir d’octobre 2026

À compter d’octobre 2026, Microsoft Entra ID va faire évoluer son moteur d’authentification pour que Windows Hello for Business et macOS Platform Single Sign-On puissent être utilisés comme facteurs MFA autonomes. Le déploiement en disponibilité générale pour les tenants worldwide et GCC commencera début octobre 2026 et devrait s’achever fin novembre. Une fois ce changement en place, les utilisateurs authentifiés via WHfB ou macOS PSSO pourront satisfaire les exigences MFA prises en charge sans avoir à enregistrer une clé d’accès supplémentaire, y compris pour les scénarios de step-up, les politiques de force d’authentification et les contrôles de fréquence de connexion. 

Bonne nouvelle pour les administrateurs déjà débordés : ce changement ne nécessitera aucune modification de configuration côté administration pour prendre effet. Pas de bascule à activer, pas de politique Conditional Access à réécrire dans l’urgence. Le comportement change de lui-même à la date du rollout. 

Un effet de bord qui mérite l’attention du RSSI

C’est là que le sujet devient réellement intéressant pour un architecte sécurité. Les utilisateurs dont la seule méthode MFA enregistrée est WHfB ou macOS PSSO seront désormais considérés comme MFA-capable. Or ce statut a une conséquence directe sur l’expérience d’enregistrement : les utilisateurs qui se connectent uniquement avec un mot de passe ne seront plus automatiquement invités à enregistrer une méthode MFA supplémentaire si WHfB ou macOS PSSO est leur seul identifiant enregistré. 

Concrètement, Entra ID va cesser de pousser les utilisateurs vers l’enregistrement d’un second facteur portable, puisqu’il considère que le premier suffit déjà. Une simplification bienvenue sur le papier, phishing-resistant oblige, mais qui repose sur une hypothèse fragile : les identifiants Windows Hello for Business et macOS Platform SSO sont liés au terminal. Si ce terminal est perdu, remplacé ou simplement indisponible, l’utilisateur ne peut pas transporter son identifiant sur un autre poste pour répondre à un défi MFA. Le commercial qui oublie son ordinateur au comptoir d’un café, ou dont la machine part en réparation trois jours, se retrouve de fait exclu de toute authentification forte tant qu’un second facteur portable n’a pas été prévu en amont.

Microsoft en a d’ailleurs conscience et documente le risque dans sa fiche de changement, avec une série de recommandations pour les administrateurs : mettre à jour les procédures d’onboarding pour garantir l’enregistrement d’au moins une méthode MFA portable, envisager d’exiger une clé d’accès synchronisée ou une clé d’accès Microsoft Authenticator en complément de WHfB ou macOS PSSO, revoir les politiques de force d’authentification personnalisées pour confirmer que WHfB et macOS PSSO y sont bien autorisés, et mettre à jour la documentation utilisateur puisque les porteurs du seul WHfB ou PSSO ne seront plus guidés automatiquement vers un enregistrement complémentaire. 

Une pièce d’un puzzle plus large

Ce changement ne sort pas de nulle part. Microsoft avance en parallèle sur MC1450133, qui permettra aux nouveaux utilisateurs d’enregistrer directement une méthode sans mot de passe comme premier facteur MFA, sans passer par l’étape intermédiaire du SMS ou de la voix. Et il fait écho à un changement plus ancien, MC1326253, qui a étendu l’application des politiques Conditional Access aux étapes d’enregistrement de WHfB et de macOS PSSO. La direction est cohérente : Microsoft resserre l’étau autour des méthodes d’authentification faibles tout en professionnalisant, contrôle par contrôle, le cycle de vie des identifiants forts. Reste aux organisations le travail, moins glamour mais indispensable, d’auditer leurs politiques d’Authentication Strength et leurs parcours d’onboarding avant que le rollout ne s’impose à elles en pilote automatique.

Ce que les DSI doivent retenir

Sur le papier, l’annonce est une simplification pure : moins de frictions, moins d’appels au support pour des enregistrements de secours, une meilleure adoption du sans mot de passe. Dans les faits, elle déplace le curseur du risque de l’ergonomie vers la continuité de service : un utilisateur mono-facteur et mono-terminal devient un utilisateur qui peut se retrouver bloqué. La fenêtre entre maintenant et octobre 2026 est donc le bon moment pour vérifier, tenant par tenant, que chaque profil à risque (itinérant, commercial, dirigeant, personnel en BYOD) dispose bien d’un second facteur portable, avant que Microsoft ne cesse de le lui rappeler.