Passkeys Entra ID : sécuriser l'enregistrement avec un TAP

Avec MC1450133, un attaquant qui détient un mot de passe pourra enregistrer une passkey sans avoir à configurer d'abord une autre méthode MFA : ce petit frein disparaît. Ce tutoriel montre comment verrouiller l'action « Register security information » avec l'accès conditionnel et un Temporary Access Pass (TAP), d'abord en mode report-only, puis en production.

MC1450133 retire un frein et ouvre un chemin d'attaque

Selon le message center MC1450133, Microsoft Entra ID laissera les utilisateurs enregistrer une passkey ou une connexion sans mot de passe comme première méthode MFA. Jusqu'ici, il fallait d'abord ajouter une autre méthode. Ce prérequis n'a jamais été une vraie barrière : sans stratégie d'accès conditionnel ciblant l'action d'enregistrement des informations de sécurité, un mot de passe volé suffisait déjà, à condition d'enregistrer d'abord une méthode quelconque (application d'authentification, par exemple).

Le chemin d'attaque change donc de forme, pas de nature :

• Avant : mot de passe, puis enregistrement d'une méthode MFA, puis enregistrement ou mise à niveau vers une passkey.
• Après : mot de passe, puis enregistrement d'une passkey.

Microsoft indique qu'aucune action n'est requise, mais recommande de revoir les stratégies d'accès conditionnel sur l'enregistrement des informations de sécurité et d'envisager d'y exiger la MFA. Les utilisateurs activés pour les passkeys seront invités par défaut à en enregistrer une, et les invites MFA de Security Defaults adopteront ce comportement en janvier-février 2027 (détail du message MC1450133).

MC1450134, annoncé en parallèle, fera de Windows Hello for Business et de macOS Platform SSO des facteurs MFA autonomes dans davantage de scénarios (analyse de Our Cloud Network). Le mouvement va dans le sens d'un enregistrement plus fluide, donc d'un enregistrement plus facile à abuser si rien ne le protège.

Prérequis et permissions avant de toucher à la production

Le tutoriel crée une force d'authentification et une stratégie d'accès conditionnel. Les deux sont à impact tenant : prévoyez un pilote et un compte d'accès d'urgence exclu.

Trois garde-fous pour l'action Register security information

Dans l'accès conditionnel, créez une ou plusieurs stratégies dont la cible est l'action utilisateur Register security information. Vous pouvez combiner les trois approches ci-dessous selon votre contexte.

Imposer une force d'authentification réservée au bootstrap

Créez une force d'authentification dédiée au démarrage et à la récupération, qui ne contient que le Temporary Access Pass. Vous pouvez y ajouter d'autres méthodes résistantes au hameçonnage, par exemple Windows Hello ou l'authentification par certificat, afin de pouvoir enregistrer une nouvelle passkey avec elles. N'y placez aucune méthode faible.

Associez ensuite cette force à la stratégie :

Bloquer hors des lieux de confiance

Cette stratégie bloque l'action si l'utilisateur n'est pas dans un lieu nommé de confiance. Avec Global Secure Access, un réseau conforme est une alternative. Concrètement, l'enregistrement et la récupération des identifiants exigent d'être au bureau ou connecté par VPN.

Exiger un appareil conforme

Même logique, mais le contrôle porte sur la conformité de l'appareil : un poste non conforme ne peut plus enregistrer de passkey. Si votre organisation tolère le BYOD, cette stratégie cassera l'enregistrement pour ces utilisateurs.

L'erreur à éviter et les pièges d'évaluation

Le raccourci tentant consiste à ajouter le TAP à la force d'authentification qui protège toutes les ressources, pour régler d'un coup les problèmes d'enregistrement. Ne le faites pas : un TAP deviendrait alors un sésame pour l'ensemble de vos applications.

La documentation Microsoft Learn sur les forces d'authentification décrit plusieurs comportements à connaître :

• Quand plusieurs stratégies ciblent « Register security information » avec chacune une force, l'utilisateur doit toutes les satisfaire.
• Ces forces ont priorité sur celles ciblant « All resources ».
• Certaines méthodes sans mot de passe ne s'enregistrent pas en mode Interrupt : on peut tomber dans une boucle où il faut une passkey pour en enregistrer une.

Microsoft documente donc un schéma à deux forces : « Bootstrap and recovery » avec TAP, et « MFA for sign-in » sans TAP.

Un guide du Q&R Microsoft, généré par IA et donc à prendre avec prudence, ajoute une règle pour le mobile : exclure l'application « Azure Credential Configuration Endpoint Service » de la stratégie mobile, faute de quoi la mise à niveau vers une passkey dans Authenticator est bloquée (échange Microsoft Q&R). Validez-le dans votre tenant avant de généraliser.

Mise en œuvre : force TAP et stratégie en report-only

Le schéma ci-dessous suit le conseil de Microsoft : tester en report-only avant l'application.

Prérequis du script : module Microsoft.Graph.Identity.SignIns, scopes Policy.ReadWrite.AuthenticationMethod, Policy.ReadWrite.ConditionalAccess et Policy.Read.All. Sortie : l'identifiant de la force et de la stratégie, ainsi que l'état de cette dernière.

1param(
2    [Parameter(Mandatory)][string]$BreakGlassGroupId,
3    [string]$PilotGroupId,
4    [switch]$Enforce
5)
6$ErrorActionPreference = 'Stop'
7 
8# Connexion avec les permissions minimales pour ce scénario
9Connect-MgGraph -Scopes 'Policy.ReadWrite.AuthenticationMethod','Policy.ReadWrite.ConditionalAccess','Policy.Read.All' -NoWelcome
10 
11# 1. Force d'authentification dédiée au bootstrap et à la récupération (TAP uniquement)
12$strengthName = 'Bootstrap and recovery'
13$strength = Get-MgPolicyAuthenticationStrengthPolicy -All | Where-Object { $_.DisplayName -eq $strengthName }
14if (-not $strength) {
15    $strength = New-MgPolicyAuthenticationStrengthPolicy `
16        -DisplayName $strengthName `
17        -Description 'Enregistrement des informations de securite : TAP uniquement' `
18        -AllowedCombinations @('temporaryAccessPassOneTime','temporaryAccessPassMultiUse')
19}
20Write-Host ('Force : ' + $strength.Id)
21 
22# 2. Etat : report-only par defaut, application seulement avec -Enforce
23$state = if ($Enforce) { 'enabled' } else { 'enabledForReportingButNotEnforced' }
24 
25# 3. Ciblage : pilote si fourni, sinon tous les utilisateurs ; break-glass toujours exclus
26$users = @{ IncludeUsers = @('All'); ExcludeGroups = @($BreakGlassGroupId) }
27if ($PilotGroupId) {
28    $users = @{ IncludeGroups = @($PilotGroupId); ExcludeGroups = @($BreakGlassGroupId) }
29}
30 
31# 4. Stratégie ciblant l'action Register security information
32$body = @{
33    DisplayName   = 'CA - Register security info - TAP only'
34    State         = $state
35    Conditions    = @{
36        Applications = @{ IncludeUserActions = @('urn:user:registersecurityinfo') }
37        Users        = $users
38    }
39    GrantControls = @{
40        Operator               = 'OR'
41        AuthenticationStrength = @{ Id = $strength.Id }
42    }
43}
44$policy = New-MgIdentityConditionalAccessPolicy -BodyParameter $body
45Write-Host ('Stratégie : ' + $policy.Id + ' / état : ' + $policy.State)

Pour délivrer un TAP à un utilisateur de test (scope UserAuthenticationMethod.ReadWrite.All), utilisez la cmdlet dédiée. La durée de vie de 60 minutes et l'usage unique sont des valeurs d'exemple à adapter à votre politique.

1Connect-MgGraph -Scopes 'UserAuthenticationMethod.ReadWrite.All' -NoWelcome
2$params = @{ lifetimeInMinutes = 60; isUsableOnce = $true }
3New-MgUserAuthenticationTemporaryAccessPassMethod -UserId 'utilisateur@contoso.com' -BodyParameter $params

Vérifier, dépanner et gérer les exceptions

Pour contrôler l'état de la stratégie après création :

1Get-MgIdentityConditionalAccessPolicy -All |
2    Where-Object { $_.DisplayName -like 'CA - Register security info*' } |
3    Select-Object DisplayName, State, Id

L'état attendu est enabledForReportingButNotEnforced pendant le pilote, puis enabled. Testez ensuite un enregistrement de passkey avec un utilisateur du pilote, avec et sans TAP.

Pour les exceptions ponctuelles, plutôt qu'une exclusion permanente, privilégiez PIM pour les groupes : voir ce billet sur les exclusions temporaires de l'accès conditionnel avec PIM pour groupes.

Questions fréquentes

Dois-je agir pour MC1450133 ?

Selon le message center, aucune action n'est requise. Microsoft recommande néanmoins de revoir les stratégies d'accès conditionnel sur l'enregistrement des informations de sécurité et d'envisager d'y exiger la MFA.

Mes stratégies Register security information s'appliquent-elles à Windows Hello for Business ?

Oui, depuis le 6 juillet 2026, elles s'appliquent aussi à l'enregistrement de Windows Hello for Business et de macOS Platform SSO. Avant cette date, ces flux ne les évaluaient pas.

Que se passe-t-il pour les utilisateurs qui n'ont que SMS ou voix ?

Les SMS et appels vocaux fournis par Microsoft sont retirés le 1er février 2027, et le 1er juillet 2027 pour les Global Administrators et les utilisateurs externes. Après la date applicable, un utilisateur dont la seule méthode MFA est SMS ou voix doit enregistrer une passkey à la connexion (invite bloquante).

Puis-je ajouter le TAP à la force qui protège toutes les ressources ?

Non. Le TAP doit rester cantonné à la force de bootstrap et de récupération, sinon il ouvre l'accès à l'ensemble de vos applications.

Par où commencer : trois décisions à prendre

Si vous autorisez le BYOD, commencez par la force TAP seule et laissez de côté l'appareil conforme. Si vos utilisateurs sont tous sur des postes gérés et sur site ou VPN, cumulez les trois garde-fous.

Pour aller plus loin

• Passkeys en entreprise : stratégie et déploiement avec Microsoft Entra ID : cadrer le déploiement global des passkeys.
• System-Preferred Authentication : le changement Passkey de septembre : comprendre l'évolution des invites de connexion.
• Microsoft Entra Passkeys : Enregistrement et Retards Explores : les délais autour de l'enregistrement.
• Protect security info registration with Conditional Access policy : la documentation de référence Microsoft Learn.
• FAQ for Microsoft-provided SMS and voice retirement : le calendrier de retrait SMS et voix.