Déployer les passkeys avec Microsoft Entra ID sans bloquer les utilisateurs

Pourquoi les passkeys méritent mieux qu’un simple bouton Activé

Une passkey est une information d’identification FIDO2 résistante à l’hameçonnage. La clé privée demeure dans l’authentificateur, tandis que Microsoft Entra ID conserve la clé publique. Le navigateur lie l’authentification au véritable domaine du service : une fausse page de connexion ne peut donc pas obtenir une réponse utilisable pour le domaine légitime.

Cette protection n’élimine toutefois pas les erreurs de déploiement. Si une stratégie Conditional Access exige immédiatement une méthode résistante à l’hameçonnage pour des utilisateurs qui n’en possèdent pas, ceux-ci peuvent être bloqués. La séquence sécuritaire est : préparer la récupération, autoriser l’inscription, piloter les profils, mesurer l’adoption, puis imposer graduellement la force d’authentification.

Comprendre les options avant de créer les groupes

Microsoft Entra ID prend en charge les passkeys synchronisées et les passkeys liées à l’appareil. Les passkeys sont disponibles dans toutes les éditions Entra ID, y compris Free, sans licence supplémentaire. Conditional Access, utilisé plus tard pour exiger une force d’authentification, nécessite Entra ID P1; Microsoft 365 Business Premium inclut aussi cette capacité.

Pour les administrateurs et comptes hautement privilégiés, privilégiez une information d’identification liée à l’appareil avec attestation, idéalement deux clés ou une clé et une autre méthode résistante à l’hameçonnage. Pour les utilisateurs généraux, une passkey synchronisée peut réduire le soutien si la politique de l’organisation accepte le modèle de récupération du fournisseur.

1 — Préparer les groupes, les rôles et les comptes d’urgence

Créez au minimum un groupe pilote, un groupe de déploiement et un groupe d’exclusion temporaire contrôlé. Le pilote doit représenter Windows, macOS, iOS, Android, appareils personnels et gérés, ainsi que les applications réellement utilisées. Ne limitez pas le test à l’équipe TI.

Utilisez Authentication Policy Administrator pour configurer les méthodes et Conditional Access Administrator pour les forces et stratégies d’accès. Excluez les comptes d’accès d’urgence de la stratégie d’obligation, surveillez leur utilisation et protégez-les avec une méthode forte distincte. Une exclusion d’urgence n’est pas un groupe général de dépannage.

• Documenter le propriétaire de chaque groupe et la date de retrait des exclusions.
• Valider les navigateurs, versions mobiles et restrictions Bluetooth du parc.
• Prévoir le scénario téléphone perdu, appareil remplacé et employé sans téléphone professionnel.
• Former le centre de services avant la première campagne d’inscription.

2 — Activer le Temporary Access Pass avant les passkeys

Le Temporary Access Pass, ou TAP, est un code temporaire à usage unique ou multiple qui permet d’amorcer une méthode sans mot de passe. Activez-le dans Entra ID > Authentication methods > Policies > Temporary Access Pass et ciblez d’abord les équipes d’accueil et de soutien. Un administrateur peut ensuite créer un TAP sous Utilisateurs > Méthodes d’authentification.

Pour l’accueil et la récupération, préférez un TAP à usage unique, de courte durée, remis après vérification de l’identité par un canal approuvé. Le code n’est affiché qu’une fois. Chaque utilisateur ne peut avoir qu’un TAP valide; la création d’un nouveau remplace l’ancien. Un TAP ne supprime pas le mot de passe du compte.

• Ne jamais envoyer le TAP et le nom d’utilisateur dans le même message non protégé.
• Révoquer le TAP après l’inscription lorsqu’il n’est plus requis.
• Retirer l’ancienne passkey perdue dans les méthodes d’authentification de l’utilisateur.
• Pour un processus d’inscription dépassant dix minutes, tester le comportement des TAP à usage unique et prévoir un second TAP au besoin.

Connect-MgGraph -Scopes 'UserAuthenticationMethod.ReadWrite.All'

$body = @{
  isUsableOnce = $true
  lifetimeInMinutes = 60
}

New-MgUserAuthenticationTemporaryAccessPassMethod `
  -UserId 'utilisateur@contoso.com' `
  -BodyParameter $body

3 — Créer des profils de passkeys adaptés aux personnes

Dans Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2), activez les profils de passkeys. Cette adhésion transfère la configuration globale existante vers un profil Default et ne peut pas être annulée. Microsoft prend actuellement en charge jusqu’à trois profils, incluant le profil par défaut.

Activez Allow self-service set up pour permettre l’inscription depuis Security info. Créez ensuite un profil par posture utile, pas par département : par exemple Administrateurs — liée à l’appareil avec attestation; Utilisateurs — liée à l’appareil et synchronisée; Pilote Authenticator — liée à l’appareil et AAGUID Microsoft Authenticator autorisé.

L’attestation vérifie à l’inscription que l’authentificateur provient du fournisseur déclaré. Elle ne rend pas rétroactivement conformes les passkeys déjà inscrites : activer l’attestation plus tard ne bloque pas automatiquement leur utilisation. Inversement, modifier une liste AAGUID peut rendre immédiatement inutilisables des modèles auparavant permis. Testez chaque changement avec des méthodes déjà inscrites.

4 — Tester Microsoft Authenticator et l’expérience multiappareil

Les passkeys liées à l’appareil dans Microsoft Authenticator exigent actuellement Android 14 ou iOS 17, en plus d’une version prise en charge de l’application. Pour les parcours interappareils par code QR, Bluetooth et une connexion Internet doivent être actifs sur les deux appareils. Les pare-feu doivent aussi permettre les points de terminaison caBLE documentés par Microsoft et les fournisseurs de plateforme.

L’attestation et l’inscription interappareils ne sont pas toujours compatibles : Microsoft indique que l’inscription interappareils ne fonctionne pas lorsque l’attestation est exigée. Testez donc l’inscription directement dans Authenticator avec un TAP pour le profil attesté. Vérifiez également les appareils partagés, les téléphones sans verrouillage biométrique, les restrictions MDM et les usagers sans téléphone.

• Inscription sur le même appareil mobile avec un TAP.
• Connexion Web sur un poste avec validation sur le téléphone.
• Remplacement du téléphone et suppression de l’ancienne méthode.
• Deuxième passkey de secours enregistrée avant la perte du premier appareil.
• Accès aux applications héritées qui redemandent encore un mot de passe.

5 — Lancer une campagne d’inscription sans forcer la connexion

Une campagne d’inscription invite l’utilisateur à créer une passkey après une connexion normale et une validation MFA. La méthode Passkey (FIDO2) doit être activée et Allow self-service set up doit être à Yes. Dans Entra ID > Authentication methods > Registration campaign, ciblez le groupe pilote, choisissez Passkey et autorisez quelques reports afin de ne pas bloquer une journée critique.

Un tenant ne peut cibler qu’une méthode à la fois dans sa campagne : passkey ou Microsoft Authenticator, pas les deux simultanément. La campagne couvre les passkeys liées à l’appareil et synchronisées. Un utilisateur peut être invité sur un appareil et pas un autre, car Entra évalue la présence d’une passkey locale pour la combinaison appareil-navigateur.

6 — Mesurer l’adoption avant toute obligation

Le tableau Authentication Methods Activity indique les utilisateurs inscrits, les inscriptions récentes et l’utilisation par méthode. Les détails peuvent prendre jusqu’à 36 heures à refléter la majorité du tenant. Complétez ce rapport par les journaux de connexion, les billets de soutien et une liste des personnes qui ne possèdent encore aucune méthode admissible.

• Taux d’inscription à au moins une passkey par groupe et plateforme.
• Taux d’utilisation réelle, pas seulement d’inscription.
• Nombre d’échecs d’inscription et motifs récurrents.
• Nombre d’utilisateurs avec deux méthodes de récupération valides.
• Volume et durée moyenne des demandes au centre de services.

Connect-MgGraph -Scopes 'AuditLog.Read.All'

$uri = 'https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails'
$rows = @()
do {
  $page = Invoke-MgGraphRequest -Method GET -Uri $uri
  $rows += $page.value
  $uri = $page.'@odata.nextLink'
} while ($uri)

$rows | Select-Object userPrincipalName, isMfaCapable, isPasswordlessCapable, methodsRegistered |
  Export-Csv '.\entra-authentication-methods.csv' -NoTypeInformation -Encoding UTF8

7 — Imposer une force d’authentification par anneaux

Une fois le pilote réellement inscrit, créez une stratégie Conditional Access qui cible une ressource sensible ou un contexte d’authentification, puis exigez la force intégrée Phishing-resistant MFA. Commencez en Report-only, examinez l’impact, puis activez-la uniquement pour le groupe pilote. La force intégrée accepte aussi Windows Hello for Business et l’authentification par certificat multifacteur; créez une force personnalisée si vous devez autoriser seulement certains AAGUID ou passkeys.

N’appliquez pas d’abord la stratégie à All users et All resources. Étendez ressource par ressource ou groupe par groupe après avoir confirmé l’inscription. Les utilisateurs doivent posséder une méthode admissible avant l’application; le flux d’interruption ne peut pas toujours inscrire automatiquement une méthode sans mot de passe au moment précis du blocage.

8 — Séparer l’amorçage de l’accès quotidien

Une bonne architecture Conditional Access peut réserver le TAP à l’action Register security information. Créez une force personnalisée Bootstrap et récupération qui inclut le TAP, puis appliquez-la à cette action utilisateur. Pour les ressources quotidiennes, utilisez une autre force qui exclut le TAP et exige la méthode voulue. Cette séparation évite qu’un code de récupération temporaire devienne un laissez-passer général.

Évitez les politiques contradictoires : si plusieurs stratégies ciblent l’inscription des informations de sécurité avec des forces différentes, l’utilisateur doit satisfaire toutes les exigences. Testez le parcours complet avec un nouvel utilisateur, un appareil non conforme et un utilisateur qui a perdu sa passkey.

Procédure de récupération recommandée

Le résultat recherché n’est pas la disparition instantanée de tous les mots de passe. Il s’agit de rendre les passkeys faciles à inscrire et à récupérer, puis de déplacer progressivement les accès importants vers une authentification résistante à l’hameçonnage. Reliez ce projet à votre audit Active Directory et à la migration Kerberos AES : l’identité hybride doit rester cohérente jusque dans les applications et services hérités.

• Vérifier l’identité avec une procédure documentée, distincte du simple appel téléphonique entrant.
• Révoquer les sessions si la perte de l’appareil pourrait être liée à un incident.
• Supprimer la passkey perdue dans les méthodes d’authentification Entra.
• Émettre un TAP court et à usage unique par un administrateur autorisé.
• Faire inscrire immédiatement une nouvelle passkey et une méthode de secours.
• Supprimer le TAP et consigner l’opération dans le billet de soutien.

• Audit de sécurité Active Directory : 10 contrôles à prioriser →
• Kerberos et RC4 : migrer vers AES sans interruption →

Sources officielles Microsoft

• Activer les passkeys FIDO2 dans Microsoft Entra ID ↗
• Activer les passkeys dans Microsoft Authenticator ↗
• Configurer un Temporary Access Pass ↗
• Déployer l’authentification sans mot de passe résistante à l’hameçonnage ↗
• Campagne d’inscription Passkey ou Authenticator ↗
• Fonctionnement des forces d’authentification Conditional Access ↗
• API Graph des détails d’inscription ↗