Accès Conditionnel Informations de Sécurité Windows Hello macOS Platform SSO : Changement de Scope (13 juillet 2026)

Accès conditionnel Register Security Information Windows Hello macOS Platform SSO : ce qui a changé

Accès conditionnel register security information windows hello macos platform sso — voilà le terme technique que les administrateurs Microsoft Entra doivent désormais connaître. Depuis le 13 juillet 2026, les politiques d'Accès conditionnel ciblant l'action utilisateur Register security information régissent également l'inscription des identifiants Windows Hello for Business (WHfB) et macOS Platform Single Sign-on (SSO), que ce comportement ait été voulu ou non lors du scoping initial de la politique. Si votre tenant avait scopé cette action utilisateur de façon étroite — par exemple pour ne couvrir que le parcours combiné d'inscription MFA/SSPR — l'inscription WHfB et macOS Platform SSO est désormais soumise, sans que vous l'ayez anticipé, aux mêmes Grant controls. Si votre tenant excluait délibérément ces parcours pour garder un provisioning des appareils sans friction, cette exclusion ne tient plus non plus : ces parcours sont désormais dans le scope par défaut.

Avant ce changement, l'inscription Windows Hello for Business et macOS Platform SSO n'évaluait pas du tout les politiques d'Accès conditionnel scopées sur Register security information — même quand une politique existait et ciblait cette action utilisateur, elle n'était tout simplement pas consultée pendant l'inscription WHfB/Platform SSO. Les indications officielles de Microsoft sont explicites sur ce qui a changé et ce qui n'a pas changé :

Microsoft a également confirmé la fenêtre de déploiement et le périmètre d'impact dans la publication Message Center MC1326253, « Conditional Access policies now apply to Windows Hello for Business and macOS Platform SSO registration » : le déploiement a débuté le 6 juillet 2026 et s'est achevé le 13 juillet 2026, et les tenants sans politique d'Accès conditionnel ciblant Register security information ne constatent aucun changement — l'application par défaut du MFA pour l'inscription des identifiants sans mot de passe reste inchangée.

Comment fonctionne l'application du contrôle

Le mécanisme lui-même n'est pas nouveau — il s'agit de la même action utilisateur Register security information qui régit depuis des années le parcours combiné d'inscription MFA/SSPR. Ce qui change, c'est que le provisioning Windows Hello for Business et l'inscription macOS Platform SSO passent désormais par cette même évaluation d'Accès conditionnel. Concrètement, après mise en application, un utilisateur qui inscrit des identifiants WHfB ou macOS Platform SSO doit satisfaire les Grant controls exigés par la politique correspondante — force d'authentification, emplacement de confiance, méthode MFA spécifique ou conformité de l'appareil — avant que l'inscription ne se termine.

Deux points des indications de Microsoft comptent pour planifier votre réponse :

• Les méthodes d'authentification externes sont actuellement incompatibles avec l'authentication strength en tant que grant control pour cette action utilisateur — un écart de compatibilité qui fait écho au retrait des Custom Controls pour les méthodes d'authentification externes déjà en cours dans Entra. Si votre politique associe Register security information à une exigence d'authentication strength et que votre tenant s'appuie sur des méthodes d'authentification externes, Microsoft recommande d'utiliser à la place le grant control Require multifactor authentication.
• Le Temporary Access Pass (TAP) satisfait l'exigence MFA de l'Accès conditionnel pour l'inscription, ce qui est la façon dont Microsoft prévoit que les administrateurs amorcent les nouveaux utilisateurs vers WHfB/macOS Platform SSO sans se heurter à un problème de l'œuf et de la poule (un utilisateur ne peut pas satisfaire un grant control MFA/authentication strength avec un identifiant qu'il n'a pas encore inscrit). Le TAP ne fonctionne pas pour les utilisateurs invités (guest).

Qui est concerné

Il s'agit d'un changement de scope, pas d'une nouvelle politique à créer — ce qui explique pourquoi il est facile de le manquer. Deux scénarios d'échec méritent une vérification spécifique :

1. Politique étroite, nouvelle friction. Une politique scopée sur Register security information avec Grant : require authentication strength (conçue pour sécuriser l'inscription MFA/SSPR) s'applique désormais aussi à WHfB et macOS Platform SSO. Un nouvel employé qui inscrit un appareil Windows managé depuis un réseau de confiance peut se retrouver bloqué en plein provisioning parce qu'il ne peut pas encore satisfaire l'authentication strength exigée par la politique — exactement l'écart que le Temporary Access Pass est censé combler.
2. Exclusion volontaire, silencieusement annulée. Si votre équipe avait volontairement laissé le provisioning WHfB/macOS Platform SSO hors du scope de l'Accès conditionnel — par exemple pour ne pas ralentir un déploiement d'appareils zero-touch — cette exception a disparu depuis le 13 juillet 2026. Le parcours d'inscription est désormais appliqué par défaut ; l'en exclure de nouveau nécessite un changement explicite.

Lectures connexes : notre couverture du changement d'inscription MFA sans mot de passe et le guide plus large sur les failles de l'Accès conditionnel abordent tous deux des décisions de scoping adjacentes qu'il vaut la peine de revoir avec ce déploiement.

Détection — Auditer l'exposition de votre tenant

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=(createdDateTime ge 2026-07-06T00:00:00Z and createdDateTime le 2026-07-13T23:59:59Z) and conditionalAccessStatus eq 'failure'

Get-MgAuditLogSignIn -Filter "createdDateTime gt 2026-07-06T00:00:00Z" | Select-Object `
  @{Name="User";Expression={$_.UserDisplayName}}, `
  @{Name="ClientApp";Expression={$_.ClientAppUsed}}, `
  @{Name="CA Result";Expression={$_.ConditionalAccessStatus}}, `
  @{Name="FailureReason";Expression={$_.FailureReason}}, `
  @{Name="Device";Expression={$_.DeviceDetail.DeviceDisplayName}}

Remédiation — Les étapes à suivre dès maintenant

1. Recensez chaque politique scopée sur Register security information et notez ses Grant controls. C'est l'intégralité de la surface d'exposition pour ce changement — rien d'autre dans votre ensemble de politiques d'Accès conditionnel n'est concerné.
2. Relancez chaque politique en mode report-only et examinez les résultats de policy impact avant de supposer que le comportement n'a pas changé depuis le 13 juillet.
3. Excluez les comptes d'accès d'urgence (break-glass) ainsi que les comptes de service/service principals de toute politique ciblant cette action utilisateur, conformément à la recommandation permanente de Microsoft — voir notre couverture des comptes break-glass pour comprendre pourquoi des comptes d'urgence non exclus constituent un constat récurrent.
4. Émettez un Temporary Access Pass pour les nouveaux employés et le re-provisioning d'appareils, afin que l'inscription WHfB/macOS Platform SSO n'entre pas en collision avec le problème d'authentication strength de l'œuf et de la poule. Le TAP satisfait l'exigence MFA de l'Accès conditionnel pour l'inscription — mais rappelez-vous qu'il ne fonctionne pas pour les utilisateurs invités.
5. N'associez pas les méthodes d'authentification externes à un grant control Require authentication strength sur cette action utilisateur ; utilisez plutôt Require multifactor authentication, conformément à l'avertissement de compatibilité explicite de Microsoft.
6. Mettez à jour la documentation du support concernant les nouvelles invites d'authentification que les utilisateurs peuvent voir en plein provisioning — c'était d'ailleurs l'action recommandée par Microsoft lui-même dans MC1326253, et c'est le moyen le moins coûteux de réduire les tickets de support des nouveaux employés déconcertés. Notre guide d'audit Entra ID explique où les revues de scope de l'Accès conditionnel s'inscrivent dans une revue de tenant plus large.

Comment EtcSec détecte cela

Les vérifications Conditional Access d'EtcSec signalent précisément les mauvaises configurations qui transforment ce déploiement d'un non-événement en incident : CA_POLICY_REPORT_ONLY repère les politiques laissées en mode report-only alors que les administrateurs les croient en application (donc le changement du 13 juillet a été testé mais jamais réellement activé), CA_NO_BREAK_GLASS_EXCLUSION repère les comptes d'accès d'urgence non exclus d'une politique Register-security-information — désormais un risque de verrouillage sur l'inscription, pas seulement sur la connexion — et CA_EXCESSIVE_EXCLUSIONS signale les politiques dont les listes d'exclusion se sont élargies au point que le resserrement de scope apporté par ce déploiement devient de fait sans effet.