Défis et solutions de déploiement des clés d'accès en entreprise

1. Introduction : réalité opérationnelle des clés d'accès en entreprise pour les employés#

Les clés d'accès ont fait leur entrée dans le monde du travail. La question n'est plus "la technologie fonctionne-t-elle ?". La question est maintenant "comment gérons-nous cela à grande échelle ?". Les points de friction se sont déplacés vers la couche opérationnelle : le problème "de la poule et de l'œuf" de l'inscription initiale (l'amorçage), la différence entre les clés d'accès liées à l'appareil (device-bound) et synchronisées (synced), l'interopérabilité multiplateforme et les mécanismes de récupération qui ne reviennent pas à l'insécurité d'un mot de passe.

Ce guide aborde les défis réels du déploiement des clés d'accès dans les environnements Microsoft Entra ID, couvrant les pièges de configuration, les flux de travail opérationnels et les stratégies de récupération. Plus précisément, nous allons répondre aux questions suivantes :

1. Quelle est la différence entre les clés d'accès liées à un appareil et synchronisées dans Entra ID ?
2. Comment amorcer des clés d'accès pour les nouveaux employés sans mots de passe ?
3. Comment les utilisateurs récupèrent-ils l'accès lorsqu'ils obtiennent un nouveau téléphone et perdent l'accès à leur authentificateur ?
4. Quelles erreurs de configuration provoquent des échecs d'inscription des clés d'accès ?
5. Comment gérer les invités B2B lors de l'exigence d'une MFA résistante au hameçonnage ?
6. Dois-je utiliser des clés de sécurité matérielles (YubiKeys) ou des clés d'accès mobiles ?
7. Comment gérer les appareils macOS aux côtés de Windows dans un déploiement de clés d'accès ?
8. Quelles mesures proactives empêchent la surcharge du centre d'assistance en cas de remplacement de téléphone ?

2. Comprendre les clés d'accès dans Microsoft Entra#

Dans Entra, "clés d'accès" = identifiants FIDO2/WebAuthn. Au lieu d'un mot de passe, l'utilisateur prouve la possession d'une clé privée stockée dans un authentificateur. C'est résistant au hameçonnage car WebAuthn lie l'identifiant à l'origine réelle de connexion (de sorte qu'un site de hameçonnage similaire ne peut pas le rejouer). Consultez la présentation de Microsoft dans la documentation sur les concepts des clés d'accès (FIDO2).

Entra prend effectivement en charge deux "modes" de clés d'accès qui se comportent différemment.

2.1 Clés d'accès liées à un appareil (device-bound) dans Entra#

Ces clés d'accès sont liées à un seul appareil physique (non synchronisables). La clé privée existe sur un élément matériel spécifique (TPM sur un ordinateur portable, Secure Element sur une YubiKey). Elle n'est pas exportable.

Dans Entra, le scénario lié à l'appareil se traduit généralement par :

• Clés d'accès Microsoft Authenticator
• Clés d'accès Windows Hello ou Windows Hello for Business (WHfB) (non synchronisées à partir de janvier 2026)
• Clés de sécurité FIDO2 (clés matérielles comme les YubiKeys)
• Cartes à puce

Les conseils de configuration de base de Microsoft pour les clés d'accès liées aux appareils sont disponibles ici : https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

Cas d'utilisation : Accès à privilèges élevés, comptes "brise-glace" (break-glass), environnements de postes de travail partagés. Inconvénient : Friction élevée. La perte de l'appareil signifie la perte de l'identifiant. Coût opérationnel élevé (ex: expédition des YubiKeys).

2.2 Clés d'accès synchronisées (synced passkeys) dans Entra#

Ce sont des clés d'accès stockées dans l'écosystème d'un fournisseur et synchronisées sur les appareils de l'utilisateur (ex: iCloud Keychain, Google Password Manager ou des fournisseurs tiers). La clé privée est chiffrée et stockée dans l'infrastructure de synchronisation d'un fournisseur de cloud.

À partir de janvier 2026, dans Entra, les clés d'accès synchronisées sont gérées via la fonctionnalité en préversion (preview) : Synced passkeys (preview). Pour activer et contrôler les clés d'accès synchronisées, Entra utilise des profils de clés d'accès (Passkey Profiles (preview)).

Adéquation réglementaire : Récemment validées par le NIST SP 800-63B Supplement 1 comme répondant aux exigences AAL2. Il s'agit d'une victoire réglementaire massive confirmant que les clés d'accès synchronisées sont suffisamment "résistantes au hameçonnage" pour une utilisation générale par les employés.

Cas d'utilisation : Travailleurs du savoir, utilisateurs BYOD, commodité pour les cadres. Inconvénient : Assurance "inférieure" au matériel. Dépendance à l'égard de la sécurité du flux de récupération de compte du fournisseur de cloud.

Vous trouverez ici un aperçu des fournisseurs de clés d'accès synchronisées pris en charge par Entra :

Dans la page Infos de sécurité d'un utilisateur, les clés d'accès synchronisées et liées à un appareil sont clairement distinguées. Ci-dessous, vous pouvez voir comment une clé d'accès synchronisée (à partir de 1Password) et une clé d'accès liée à un appareil (YubiKey 5C NFC) apparaissent :

2.3 Alignement réglementaire : niveaux AAL du NIST#

• L'AAL3 nécessitait historiquement des authentificateurs basés sur le matériel et liés à un appareil (comme des YubiKeys ou des cartes à puce) qui utilisent une clé privée non exportable.
• L'AAL2 peut désormais être atteint avec des clés d'accès synchronisées selon les directives du NIST.
• Nuance : Bien que les clés d'accès synchronisées (comme celles d'iCloud) soient excellentes pour les utilisateurs standard, elles peuvent ne pas répondre strictement à l'exigence de "non-exportabilité" de l'AAL3 pour les niveaux de privilèges les plus élevés. Par conséquent, une stratégie segmentée est requise : Clés matérielles pour les administrateurs (AAL3), Clés d'accès synchronisées pour les employés (AAL2).

2.4 Exigences de préparation des appareils#

Pour garantir que les appareils sont prêts pour une authentification sans mot de passe résistante au hameçonnage, ils doivent exécuter ces versions minimales :

Les anciens systèmes d'exploitation peuvent nécessiter des authentificateurs externes (clés de sécurité FIDO2) pour prendre en charge l'authentification sans mot de passe résistante au hameçonnage.

Au-delà des exigences de version minimale, la prise en charge des capacités côté navigateur varie également selon la plateforme. Selon l'analyse des capacités client WebAuthn du Corbado Passkey Benchmark 2026, la prise en charge des navigateurs au premier trimestre 2026 se situe entre 97 et 100 % pour Conditional Get et Hybrid Transport, mais seulement 83 à 92 % pour Conditional Create sur une combinaison typique de navigateurs grand public — une contrainte qui frappe le plus durement sur Windows car Windows Hello n'est pas un chemin Conditional Create, et Edge en particulier rapporte une très faible prise en charge de Conditional Create dans le même ensemble de données. Le benchmark couvre les déploiements B2C destinés aux consommateurs plutôt que les environnements de travail, mais les mêmes plafonds de capacité navigateur/OS sous-jacents s'appliquent toujours aux déploiements Entra ID ; les populations fortement équipées en Edge en entreprise peuvent atterrir matériellement en dessous de la plage mixte de 83 à 92 % pour Conditional Create.

2.5 Recommandations d'identifiants selon le profil utilisateur#

Microsoft recommande une approche basée sur les profils d'utilisateurs pour le déploiement des identifiants. Différents rôles ont des exigences de sécurité et des niveaux de friction acceptables différents :

Identifiants portables (peuvent être utilisés sur plusieurs appareils) :

Identifiants locaux (spécifiques à l'appareil) :

L'objectif final : La plupart des utilisateurs devraient avoir au moins un identifiant portable plus des identifiants locaux sur chaque appareil informatique.

3. Expériences de déploiements de clés d'accès en direct#

En discutant avec des organisations qui ont déployé des clés d'accès, des points de friction et des modèles du monde réel sont reconnus.

3.1 Changement opérationnel#

"Les défis ne se situent pas dans la pile technologique mais dans la couche opérationnelle." Cela confirme que les obstacles techniques tels que les erreurs "Clé d'accès non enregistrée" ou l'invisibilité des options Windows Hello sur les appareils personnels ne sont pas des anomalies uniques mais des points de friction systémiques inhérents à la maturité actuelle de l'écosystème. Pour les opérations d'entreprise, la clé est de séparer les défaillances attendues et inattendues dans la surveillance. Regroupez les erreurs WebAuthn explicitement et suivez NotAllowedError, AbortError et les erreurs de clés d'accès du Credential Manager comme des signaux distincts. Notre playbook d'analyse d'authentification fournit un cadre pour classer ces signaux, et l'analyse des clés d'accès couvre les KPI spécifiques aux clés d'accès comme les taux d'activation et de connexion.

3.2 L'inscription : le moment décisif#

L'inscription est la phase la plus difficile du déploiement, nécessitant une gestion du changement importante.

• Complexité de pré-inscription : L'intégration de nouveaux employés qui n'ont aucun identifiant préalable est le principal goulot d'étranglement. La dépendance à l'égard de l'inscription médiatisée par l'administrateur crée une expérience utilisateur décousue.
• Fragmentation des plateformes : "Frustration des utilisateurs avec les étapes" due aux itérations indépendantes des navigateurs, des systèmes d'exploitation et des gestionnaires de mots de passe. Cela conduit à des incohérences temporaires où un flux fonctionne sur Chrome/Windows mais échoue sur Safari/macOS ou échoue sur des appareils personnels non gérés tout en réussissant sur les appareils de l'entreprise.

3.3 L'écart du modèle mental#

"Les utilisateurs n'ont pas besoin de cryptographie, ils ont besoin d'un modèle mental". La confusion terminologique crée une charge cognitive :

• Clé d'accès
• Clé de sécurité
• Clé matérielle
• YubiKey
• Sans mot de passe (passwordless)
• Sécurité Windows
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• Connexion par téléphone

Pour les utilisateurs non avertis ou même avertis, les différences entre ces termes ne sont pas évidentes.

Nous recommandons d'éviter le jargon comme "résistant au hameçonnage" ou "paire de clés" dans les communications avec les utilisateurs finaux. Concentrez-vous plutôt sur le concept de "déverrouillage" : "Utilisez votre visage pour déverrouiller les systèmes de l'entreprise", analogue au déverrouillage de leur téléphone.

3.4 Limites de la communication#

Une forte adoption au début est critique pour le succès, mais la communication a ses limites. Vous ne pouvez pas envoyer d'e-mails réguliers demandant aux utilisateurs de vérifier leurs méthodes d'authentification. En général, vous ne pouvez pas bien planifier le comportement des utilisateurs. Cette réalité entraîne la nécessité de mesures techniques proactives plutôt que de s'appuyer uniquement sur l'éducation des utilisateurs.

4. Analyse approfondie de la configuration de Microsoft Entra ID#

Le déploiement de clés d'accès dans un environnement d'entreprise nécessite de comprendre et de configurer des politiques interdépendantes. Les clés d'accès ne sont pas simplement une fonctionnalité que vous pouvez activer, car elles ont un impact énorme sur chaque employé dans son travail quotidien.

4.1 Politique des méthodes d'authentification#

Les portails MFA et SSPR hérités sont obsolètes. Toute configuration FIDO2 doit se faire dans le panneau unifié de la politique des méthodes d'authentification.

• Méthode de clé de sécurité FIDO2 : Celle-ci doit être activée et ciblée. Il est recommandé de cibler "Tous les utilisateurs" pour l'activation mais de contrôler l'application via l'Accès Conditionnel (Conditional Access).
• Restrictions de clé (AAGUID) : Chaque appareil FIDO2 (ex: YubiKey 5 NFC, Microsoft Authenticator sur iOS, Google Password Manager) possède un identifiant globalement unique d'attestation d'authentificateur (AAGUID). En tant que bonne pratique, pour les environnements de haute sécurité, utilisez le paramètre "Appliquer les restrictions de clé" pour Autoriser uniquement les AAGUID spécifiques et approuvés. Cela empêche les utilisateurs d'enregistrer des clés de sécurité bon marché et non vérifiées du "marché gris".

4.2 Attestation : le point de décision critique#

L'une des décisions de configuration les plus importantes est "Appliquer l'attestation" (Enforce Attestation).

• Ce que cela fait : Force l'authentificateur à prouver cryptographiquement sa marque et son modèle à Entra ID lors de l'inscription.
• Conflit : Les clés d'accès synchronisées (stockées dans des fournisseurs de logiciels comme iCloud Keychain, Bitwarden ou Google Password Manager) ne prennent généralement pas en charge l'attestation car elles sont basées sur un logiciel et indépendantes de la plateforme. Elles ne peuvent pas signer un défi avec un certificat de lot matériel.
• Compromis :
  • Défini sur OUI : Requis pour une assurance élevée (AAL3). Garantit que la clé est liée au matériel. Bloque les fournisseurs de clés d'accès basées sur un logiciel.
  • Défini sur NON : Autorise les clés d'accès synchronisées. Diminue légèrement l'assurance (AAL2). Active les fournisseurs de clés d'accès basées sur un logiciel.

Vous ne pouvez pas appliquer une politique globale "Pas d'attestation" si vous avez des administrateurs à privilèges élevés qui ont besoin de clés matérielles. Vous devez utiliser les Passkey Profiles (Preview) :

• Profil A (Administrateurs) : Appliquer l'attestation = Oui
• Profil B (Personnel général) : Appliquer l'attestation = Non

4.3 Explication des profils de clés d'accès (Passkey Profiles)#

Considérez les profils de clés d'accès comme le mécanisme permettant de définir :

• "Ces utilisateurs peuvent utiliser des clés d'accès synchronisées"
• "Ces utilisateurs doivent utiliser uniquement des clés liées à l'appareil"
• "Attestation requise vs non requise" (et par conséquent : clés d'accès synchronisées autorisées vs exclues)
• "Restreindre à certains types d'authentificateurs (restrictions AAGUID)"

Ci-dessous, vous pouvez voir la page des paramètres des clés d'accès (FIDO2) dans le centre d'administration Microsoft Entra où vous configurez les profils de clés d'accès :

Lors de la modification d'un profil de clé d'accès, vous pouvez configurer l'application de l'attestation, les types de cibles (liées à un appareil, synchronisées ou les deux) et les restrictions AAGUID spécifiques :

4.4 Accès Conditionnel et forces d'authentification#

L'application peut être gérée via des politiques d'Accès Conditionnel (CA) utilisant les forces d'authentification.

• Force de MFA résistante au hameçonnage : Cette force intégrée nécessite FIDO2, Windows Hello for Business (WHfB) ou l'Authentification basée sur les certificats (CBA).
• Piège de verrouillage : Si vous créez une politique de CA qui nécessite une "MFA résistante au hameçonnage" pour "Toutes les applications cloud" et que vous l'appliquez à "Tous les utilisateurs", vous verrouillerez immédiatement tous les utilisateurs qui n'ont pas encore enregistré de clé d'accès. Ils ne pourront même pas se connecter pour en enregistrer une.
• Paradoxe "Enregistrer les informations de sécurité" : Il s'agit d'une action utilisateur spécifique dans l'Accès Conditionnel. Si vous exigez une MFA résistante au hameçonnage pour effectuer l'action d'enregistrement des informations de sécurité, vous créez une dépendance circulaire (la poule et l'œuf). Un utilisateur ne peut pas enregistrer sa première clé d'accès car il a besoin d'une clé d'accès pour accéder à la page d'inscription.

Voici un aperçu des méthodes d'authentification qui satisfont à quelles exigences de force :

4.5 Authentification préférée par le système#

La fonctionnalité "Authentification multifactorielle préférée par le système" d'Entra ID force le moteur de connexion à inviter l'utilisateur à utiliser la méthode enregistrée la plus sécurisée.

Si un utilisateur a enregistré à la fois un SMS et une clé d'accès, le système utilisera par défaut la clé d'accès. Cela stimule l'adoption des clés d'accès de manière organique sans application stricte. Cela met essentiellement à niveau la posture de sécurité de l'utilisateur automatiquement une fois qu'il enregistre l'identifiant.

Ci-dessous, vous pouvez voir l'expérience de connexion par clé d'accès. L'utilisateur est invité à utiliser "Visage, empreinte digitale, code PIN ou clé de sécurité" et peut sélectionner sa clé d'accès à partir d'une extension de navigateur ou du gestionnaire d'identifiants du système :

4.6 Considérations macOS : Platform SSO#

Pour les organisations disposant d'environnements mixtes Windows/macOS, macOS Platform SSO fournit l'équivalent Apple de Windows Hello for Business. Combiné avec des solutions MDM, vous pouvez obtenir :

• Des identifiants liés à l'appareil associés à l'Enclave sécurisée du Mac
• Une expérience SSO sur les applications natives et les applications web
• Une authentification résistante au hameçonnage qui répond aux exigences AAL2/AAL3

Remarque : macOS Platform SSO nécessite macOS 13+ et une configuration MDM appropriée. La configuration diffère considérablement de Windows WHfB, prévoyez donc des pistes de déploiement distinctes.

5. Mauvaises configurations courantes : pourquoi "cela ne fonctionne qu'avec Microsoft Authenticator"#

Si votre objectif est d'avoir des clés d'accès synchronisées sur des appareils non gérés, voici les blocages les plus courants :

5.1 Clés d'accès synchronisées non activées/ciblées#

Il ne suffit pas de simplement activer "FIDO2" de manière générale dans Entra. Pour les clés d'accès synchronisées, vous avez généralement besoin de :

• Le chemin de la fonctionnalité en préversion décrit dans Synced passkeys (preview)
• Une configuration de profil utilisant les Passkey Profiles

Si un groupe n'est pas ciblé par un profil qui autorise les clés d'accès synchronisées, vous serez ramené dans le monde "uniquement lié à l'appareil".

5.2 Attestation appliquée (bloque les clés d'accès synchronisées)#

C'est ce qui suscite le plus de questions dans les organisations soucieuses de la sécurité :

• Entra peut exiger une attestation pour certains scénarios de clés d'accès (aide à valider le type/la provenance de l'authentificateur)
• Les clés d'accès synchronisées ne prennent pas en charge l'attestation dans Entra, donc si l'attestation est appliquée, l'inscription des clés d'accès synchronisées échouera et vous vous retrouverez avec uniquement des options liées à l'appareil.

5.3 La liste d'autorisation AAGUID bloque les fournisseurs#

Entra vous permet de restreindre les authentificateurs autorisés (souvent via des listes d'autorisation/blocage AAGUID). Si vous n'autorisez que Microsoft Authenticator (ou un ensemble restreint d'authentificateurs), les fournisseurs tiers de clés synchronisées peuvent être implicitement bloqués. La partie déroutante est que l'authentification locale (ex: Touch ID, Face ID, scan biométrique Windows) fonctionne, mais la page de connexion Entra affiche ensuite une erreur.

5.4 L'Accès Conditionnel force certains types de clés d'accès#

Même si les clés d'accès sont activées, l'Accès Conditionnel peut effectivement forcer les utilisateurs vers un sous-ensemble de méthodes (ex: "Authenticator uniquement" ou une configuration de force qui ne permet pas le profil de clé d'accès prévu). Dans la pratique, cela crée la "dépendance Authenticator" même lorsque le plan concerne des clés d'accès synchronisées.

5.5 Comptes invités B2B vs membres#

Si les partenaires externes sont des utilisateurs invités B2B dans un locataire de ressources, il existe des limitations connues concernant où et comment ils peuvent enregistrer des méthodes d'authentification. C'est souvent le "pourquoi ça ne marche pas" caché lorsque l'intention est "les partenaires utilisent des clés d'accès dans notre locataire".

6. Défis opérationnels et solutions#

6.1 Le paradoxe de l'amorçage (bootstrapping)#

Le problème le plus répandu ("L'inscription est la partie la plus difficile") est le problème d'amorçage : Comment délivrer de manière sécurisée un identifiant de haute assurance à un utilisateur qui n'a actuellement aucun identifiant (ou uniquement des identifiants de faible assurance) ?

6.1.1 Passe d'accès temporaire (TAP)#

Le passe d'accès temporaire (TAP) est une approche architecturale pour l'intégration sans mot de passe.

• Ce que c'est : Un code d'accès limité dans le temps (ex: 1 heure) à haute entropie qu'Entra ID traite comme une méthode "d'authentification forte". Il contourne le besoin d'un mot de passe ou d'une MFA existante.
• Flux de travail :
  1. Vérification d'identité : L'identité du nouvel employé est vérifiée (ex: via le processus RH ou la vérification du responsable).
  2. Émission : Un administrateur (ou une application logique automatisée) génère un TAP pour l'utilisateur.
  3. Connexion "Magique" : L'utilisateur navigue vers aka.ms/mysecurityinfo. Il entre son nom d'utilisateur et le TAP.
  4. Inscription : Étant donné que le TAP satisfait à l'exigence "d'authentification forte", l'utilisateur est autorisé à accéder au panneau d'informations de sécurité. Il clique sur "Ajouter une méthode" et enregistre sa clé d'accès.
  5. Régime permanent : Le TAP expire. L'utilisateur dispose désormais d'un identifiant résistant au hameçonnage. Il n'a jamais tapé de mot de passe.

6.1.2 Automatisation via l'API Graph#

Pour les grandes organisations, l'émission manuelle de TAP n'est pas évolutive. La meilleure pratique consiste à automatiser via l'API Microsoft Graph.

• Scénario : Une nouvelle recrue est traitée dans le système RH (Workday/SuccessFactors).
• Déclencheur : L'événement de provisionnement déclenche une Azure Logic App.
• Action : La Logic App appelle l'API Graph POST /users/{id}/authentication/temporaryAccessPassMethods.
• Livraison : Le TAP est remis en toute sécurité au responsable de l'embauche de l'utilisateur ou à son e-mail personnel (chiffré) pour un accès dès le premier jour.

6.1.3 Microsoft Entra Verified ID pour une intégration à haute assurance#

Pour l'intégration à distance ou les scénarios nécessitant une haute assurance de l'identité, Entra Verified ID de Microsoft avec Face Check fournit un chemin d'inscription sans mot de passe en premier lieu :

1. Vérification de l'identité : Le nouvel utilisateur vérifie son identité via un partenaire IDV (scan de pièce d'identité gouvernementale).
2. Correspondance biométrique : Face Check compare un selfie en direct avec la photo du document d'identité à l'aide d'Azure AI Vision. Seul un score de confiance de correspondance est partagé (aucune donnée biométrique brute).
3. Identifiant vérifié émis : L'utilisateur reçoit un identifiant Verified ID.
4. Émission du TAP : Lors de la vérification réussie, le système émet un Passe d'accès temporaire.
5. Amorçage de la clé d'accès : L'utilisateur enregistre sa première clé d'accès à l'aide du TAP.

Le flux Face Check guide les utilisateurs à travers trois étapes : Vérifier (partager les identifiants), Confirmer (effectuer un scan du visage) et Examiner (voir le résultat de la correspondance) :

Ce flux permet des comptes véritablement sans mot de passe dès le premier jour. Aucun mot de passe n'est jamais créé.

6.2 Problème de remplacement du téléphone (le défi caché de l'échelle)#

C'est souvent la plus grande source d'appels au centre d'assistance dans les déploiements de clés d'accès. Les organisations ayant de grandes populations BYOD (ex: plus de 10 000 appareils) peuvent voir un nombre énorme d'appels d'assistance simplement de la part d'utilisateurs qui obtiennent de nouveaux téléphones et ne connaissent pas le processus de réenregistrement des méthodes d'authentification.

Lorsque vous introduisez des clés d'accès dans le mix, cela devient encore plus critique car :

• Les utilisateurs installent des applications (comme Outlook) sur leur nouveau téléphone
• Ces applications demandent une authentification
• L'invite MFA apparaît sur l'ancien téléphone (qu'ils ont peut-être déjà échangé ou effacé)
• L'utilisateur est bloqué et appelle le centre d'assistance

6.2.1 Matrice de scénarios pour le remplacement de téléphone#

Le but est de déplacer autant de cas que possible dans les deux premières lignes, minimisant ainsi l'intervention du centre d'assistance.

6.2.2 L'astuce de l'inscription Intune#

Une idée judicieuse : Exiger une clé d'accès pour l'inscription à Intune force les utilisateurs à terminer la configuration de Microsoft Authenticator sur leur nouveau téléphone immédiatement - avant de pouvoir accéder aux applications de l'entreprise.

• Aujourd'hui : L'inscription à Intune nécessite une élévation de la MFA. Cela signifie que si vous voulez vous connecter sur un nouveau téléphone, vous y installez Outlook. Cependant, l'invite MFA va sur l'ancien téléphone.
• Avec l'exigence de la clé d'accès : Les utilisateurs doivent d'abord configurer des clés d'accès Microsoft Authenticator sur le nouveau téléphone pour terminer l'inscription. Cela se produit rapidement (le jour du changement de téléphone) plutôt que des mois plus tard, lorsque l'ancien téléphone n'est plus là.

Cela ne résout pas la récupération, mais déplace le calendrier. Les utilisateurs enregistrent leur nouvel appareil pendant qu'ils ont encore accès à l'ancien.

6.3 Les clés de sécurité matérielles s'accompagnent de problèmes logistiques#

Les clés matérielles (YubiKeys, etc.) sont parfois positionnées comme la solution universelle. En théorie, elles le sont, mais la réalité montre d'autres défis :

• Cauchemar logistique : Les organisations qui déployaient auparavant des jetons physiques (comme RSA SecurID) passaient souvent des années à essayer de les éliminer. Remplacer un programme de jeton physique par un autre n'est pas attrayant.
• Expédition directe (Drop-shipping) : Yubico peut expédier des clés directement aux utilisateurs et elles ne nécessitent pas de remplacement de batterie tous les quelques années (contrairement à SecurID). Mais si quelqu'un oublie sa clé, il ne peut pas se connecter (pour les bureaux partagés).
• Charge informatique locale : Les superviseurs locaux ne devraient pas devenir le support informatique de facto pour les clés oubliées.
• Coût : Les clés matérielles ajoutent un coût par utilisateur qui évolue avec l'effectif.

Quand les clés matérielles ont du sens :

• Administrateurs de niveau 0 (Tier 0) : Administrateurs de domaine, comptes "brise-glace"
• Postes de travail partagés : Environnements de kiosque, ateliers, tablettes de terrain
• Sous-traitants sans BYOD : Utilisateurs externes qui n'utiliseront pas d'appareils personnels

6.4 Défis des appareils non gérés#

De nombreux utilisateurs se plaignent de ne pas pouvoir voir les options d'utilisation des clés d'accès sur un appareil personnel. Il s'agit d'un point de friction classique des "appareils non gérés".

6.4.1 Analyse de l'erreur "Clé d'accès non enregistrée"#

Les utilisateurs peuvent ne pas être en mesure d'ajouter des clés d'accès sur un appareil personnel, alors que cela fonctionne sur un appareil d'entreprise. Cela est probablement dû aux politiques de conformité Intune qui interagissent avec le flux d'inscription.

• Mécanisme : Windows Hello for Business (WHfB) est un identifiant de plateforme. Il est lié au TPM spécifique de l'appareil (clé d'accès liée à l'appareil).
• Contrainte : Pour s'inscrire à WHfB, l'appareil doit généralement être joint (Entra Joined ou Hybrid Joined) au locataire. Un appareil personnel qui est simplement "Enregistré" (Workplace Joined) peut avoir des restrictions de stratégie appliquées via Intune qui bloquent le provisionnement des conteneurs WHfB si l'appareil n'est pas entièrement géré ou conforme. Consultez les exigences de connexion par clé de sécurité FIDO2.
• Option "Clé d'accès" : Sur un appareil personnel, l'utilisateur devrait essayer d'enregistrer une clé de sécurité FIDO2 (itinérante) ou une clé d'accès multi-appareils (sur son téléphone), et non Windows Hello for Business (à moins que l'inscription BYOD ne soit entièrement prise en charge).
• Problème de visibilité dans Entra ID : Si "Windows Hello" n'apparaît pas comme option, l'appareil n'a pas terminé l'inscription MDM préalable.

6.4.2 Échecs de l'authentification multi-appareils (CDA)#

Sur les appareils non gérés, les utilisateurs essaient souvent le flux d'authentification multi-appareils (CDA) (en scannant un code QR sur le PC avec leur téléphone).

• Dépendance Bluetooth : La CDA nécessite que le Bluetooth soit activé à la fois sur le PC et sur le téléphone. Ils n'ont pas besoin d'être appariés, mais doivent effectuer une poignée de main Bluetooth Low Energy (BLE) pour prouver la proximité. Consultez la documentation sur les clés d'accès liées aux appareils dans Microsoft Authenticator pour plus de détails.
• Blocage de la politique d'entreprise : Si le Bluetooth est désactivé sur les ordinateurs portables de l'entreprise via le BIOS ou une stratégie de groupe (GPO) pour la "sécurité", vous avez déjà cassé le principal mécanisme des clés d'accès itinérantes.
• Blocage Websocket : Le flux CDA utilise une connexion WebSocket vers cable.ua5v.com ou cable.auth.com. Des pare-feu d'entreprise agressifs ou des configurations Zscaler bloquent souvent ces domaines, provoquant le blocage ou l'échec silencieux de l'analyse du code QR. Consultez la documentation sur les clés d'accès Microsoft Authenticator.

6.5 Identités externes et B2B#

Un autre point de douleur pour les entreprises est le traitement des consultants externes (invités B2B).

• Problème : Un consultant tente d'accéder à un site SharePoint. Le locataire applique une politique d'Accès Conditionnel exigeant une "MFA résistante au hameçonnage".
• Échec : Le consultant tente d'enregistrer une clé FIDO2 dans le locataire de ressources. Cela échoue. Entra ID ne prend pas en charge l'enregistrement des clés FIDO2 par les utilisateurs invités dans le locataire de ressources.
• Correction : Paramètres d'accès inter-locataires (Cross-Tenant Access Settings)
  • Logique : Au lieu d'obliger l'invité à enregistrer un identifiant dans votre locataire, vous devriez faire confiance à l'identifiant qu'il utilise dans son locataire.
  • Configuration : Allez dans Identités externes > Paramètres d'accès inter-locataires. Sélectionnez l'organisation partenaire. Sous Approbation entrante, cochez "Faire confiance à l'authentification multifactorielle des locataires Microsoft Entra".
  • Résultat : Lorsque le consultant se connecte à l'aide d'une YubiKey dans son locataire d'origine, votre locataire reçoit une réclamation indiquant "MFA satisfaite + Résistante au hameçonnage". L'accès est accordé sans que l'utilisateur ait besoin de s'enregistrer. Cela sous-traite la gestion du cycle de vie des identifiants au partenaire, réduisant ainsi votre responsabilité et la charge de votre centre d'assistance.

7. Stratégies de récupération#

Souvent, les décisions de récupération sont à la traîne par rapport au déploiement réel. Plusieurs options de récupération existent selon les besoins de votre organisation.

7.1 Récupération de compte en libre-service (SSAR) avec Verified ID#

Le nouveau flux de récupération de compte en libre-service (SSAR) de Microsoft Entra ID (en préversion) permet une récupération à haute assurance sans l'intervention du centre d'assistance.

1. Déclencheur : L'utilisateur ne peut pas se connecter. Il sélectionne "Récupérer mon compte".
2. Vérification d'identité : L'utilisateur est redirigé vers un fournisseur tiers de vérification d'identité (IDV) (ex: Onfido, IDemia).
3. Vérification des documents : L'utilisateur scanne son permis de conduire physique, sa carte d'identité nationale ou son passeport à l'aide de sa caméra mobile.
4. Vérification du vivant : L'utilisateur effectue un selfie Face Check. Cela correspond au document d'identité (et potentiellement à la photo stockée dans Entra ID). La correspondance utilise les API Face d'Azure AI Vision et seul un score de confiance est partagé. Aucune donnée biométrique brute ne va à l'application.
5. Restauration : En cas de succès, le système émet automatiquement un Passe d'accès temporaire (TAP) à l'utilisateur.
6. Réinscription : L'utilisateur utilise le TAP pour enregistrer immédiatement une nouvelle clé d'accès.

Recommandation : Ce chemin de récupération automatisé et soutenu par la biométrie est supérieur à "Appeler le centre d'assistance", qui est vulnérable à l'ingénierie sociale (attaques vocales par Deepfake).

7.2 Récupération assistée par le responsable avec My Staff#

Si vous souhaitez réduire la charge du centre de services mais que vous ne pouvez pas activer le libre-service complet, Microsoft Entra inclut une fonctionnalité d'administration déléguée native appelée My Staff.

• Comment ça marche : Déléguer des autorisations limitées aux "Responsables d'équipe" (via les Unités Administratives dans Entra).
• Flux : Si un utilisateur perd l'accès, il peut contacter un administrateur local délégué, qui peut utiliser le portail My Staff pour les tâches de récupération prises en charge, telles que la réinitialisation d'un mot de passe ou la mise à jour d'un numéro de téléphone.
• Pourquoi cela aide : Cela déplace le travail de récupération de compte courant loin du centre d'assistance central et accélère le support.

7.3 Kiosque de récupération en libre-service (intranet)#

Étant donné que les utilisateurs disposent souvent encore d'un ordinateur portable de confiance, sécurisé par WHfB, vous pouvez créer une simple page intranet "brise-glace".

• Construction : Une simple application web interne qui nécessite une connexion WHfB (authentification forte).
• Action : Une fois authentifié, l'utilisateur clique sur "J'ai un nouveau téléphone". L'application utilise l'API Microsoft Graph (service en arrière-plan) pour générer un passe d'accès temporaire (TAP) de courte durée et l'affiche à l'écran.
• Résultat : L'utilisateur tape ce TAP dans son nouveau téléphone pour amorcer l'application Microsoft Authenticator. Aucune implication du centre d'assistance.

C'est le levier clé pour réduire les réinitialisations des méthodes d'authentification sans affaiblir la politique. Si vous disposez d'un mécanisme solide d'amorçage via ordinateur portable, la charge de vos communications chute considérablement car les utilisateurs peuvent récupérer sans connaître la séquence parfaite.

8. Recommandations pour les déploiements de clés d'accès en entreprise#

Structurez votre déploiement autour de Stades de Maturité. Reconnaissez la friction ("La technologie est prête, les opérations sont difficiles") et appliquez ces atténuations.

8.1 Actions immédiates (Phase "Fix-It")#

1. Audit Bluetooth et Pare-feu : Assurez-vous que les ordinateurs portables de l'entreprise autorisent le Bluetooth (pour les vérifications de proximité) et mettez sur liste blanche les domaines relais FIDO/WebAuthn (\*.cable.auth.com) pour résoudre les pannes multi-appareils.
2. Activer l'approbation inter-locataires : Arrêtez d'essayer d'enregistrer des clés d'accès d'invités. Configurez l'Approbation entrante pour la MFA pour les partenaires clés afin de résoudre immédiatement les problèmes d'accès B2B.
3. Mettre en œuvre le TAP pour l'intégration : Rendez obligatoire l'utilisation du Passe d'accès temporaire pour toute nouvelle intégration d'utilisateur afin de résoudre le blocage de l'inscription "poule et œuf".

8.2 Décisions stratégiques (Phase "Architecture")#

1. Adopter un modèle "d'assurance hybride" :
   • Niveau 0 (Administrateurs) : Appliquer l'Attestation et les Restrictions de clé. Seules les YubiKeys/Matériel sont autorisés (AAL3).
   • Niveau 1 (Employés) : Désactiver l'application de l'Attestation via les Profils de clés d'accès. Autorisez les clés d'accès synchronisées pour réduire la friction et les coûts (AAL2).
2. Planifier pour macOS : Déployez Platform SSO avec votre MDM en tant que piste parallèle à Windows WHfB.

8.3 Pérennisation (Phase "Optimisation")#

1. Planifier le SSAR : Lancez un projet pilote pour la récupération de compte en libre-service avec Verified ID afin d'éliminer le centre d'assistance en tant que vecteur d'ingénierie sociale.
2. Authentification préférée par le système : Activez cette politique pour "mettre à niveau" automatiquement les utilisateurs vers des clés d'accès dès qu'ils en enregistrent une, favorisant ainsi l'adoption sans mandat strict.
3. Déployer les options de récupération : Mettez en œuvre le TAP assisté par le responsable via My Staff et/ou un kiosque de récupération en libre-service.
4. Exigence de clé d'accès Intune : Envisagez d'exiger une clé d'accès pour l'inscription à Intune afin de forcer l'inscription précoce sur de nouveaux appareils.

8.4 Matrice de dépannage#

9. Surveillance du déploiement avec le classeur Phishing-Resistant Passwordless#

Microsoft a publié un classeur Phishing-Resistant Passwordless que les organisations disposant de journaux dans Azure Monitor peuvent utiliser pour suivre la progression du déploiement. Accédez-y via le centre d'administration Entra sous Surveillance > Classeurs :

Le classeur comporte deux sections principales :

9.1 Phase de préparation à l'inscription#

Utilisez cet onglet pour analyser les journaux de connexion et déterminer quels utilisateurs sont prêts pour l'inscription par rapport aux utilisateurs qui peuvent être bloqués. Vous pouvez filtrer par plate-forme de système d'exploitation (Windows, macOS, iOS, Android) et par type d'identifiant (Clé d'accès d'application Authenticator, Clé de sécurité FIDO2, Authentification basée sur certificat) :

Le classeur montre :

• Paires Utilisateur/Appareil prêtes pour l'inscription : les utilisateurs qui peuvent enregistrer le type d'identifiant sélectionné
• Paires Utilisateur/Appareil non prêtes : les utilisateurs qui peuvent avoir des problèmes d'inscription (ex: anciennes versions d'OS)

Vous pouvez exporter des listes d'utilisateurs qui ont besoin d'actions de remédiation (ex: mises à niveau de l'OS, remplacements d'appareils ou options d'identifiants alternatives).

9.2 Phase de préparation à l'application#

Une fois les utilisateurs prêts pour l'authentification résistante au hameçonnage uniquement, utilisez l'onglet Préparation à l'application (Enforcement Readiness). Tout d'abord, créez une politique d'Accès Conditionnel En rapport uniquement qui exige une MFA résistante au hameçonnage. Cela remplit les journaux de connexion avec des données indiquant si l'accès aurait été bloqué si l'application était active.

Le tableau de bord affiche :

• Total des utilisateurs dans le périmètre
• Succès en rapport uniquement - les utilisateurs qui passeraient l'application
• Politique non satisfaite - les utilisateurs qui seraient bloqués (enquêtez sur ceux-ci !)
• Répartitions de l'État de l'appareil, Plate-forme de l'appareil et Application cliente

Utilisez l'onglet Analyse de données supplémentaire pour déterminer pourquoi certains utilisateurs seraient bloqués. Ces données vous aident à cibler les utilisateurs pour une remédiation avant d'activer l'application.

9.3 Déploiement par vagues avec surveillance par le centre d'assistance#

Microsoft recommande d'exécuter les déploiements par vagues avec des plages de dates flexibles. Surveillez le volume de tickets du centre d'assistance comme signal :

• Augmentation du volume de tickets : Ralentissez les déploiements, les communications et les actions d'application
• Diminution du volume de tickets : Relancez les activités

Créez des groupes de sécurité Microsoft Entra ID pour chaque vague et ajoutez des groupes à vos politiques de manière incrémentielle. Cela évite de submerger les équipes d'assistance.

10. Liste de contrôle pilote pour les clés d'accès synchronisées#

Si l'objectif est d'utiliser des clés d'accès synchronisées sans la dépendance à Microsoft Authenticator, suivez cette approche pilote :

1. Activer les clés d'accès synchronisées (en préversion) Suivez Synced passkeys (preview).

2. Utiliser les profils de clés d'accès (en préversion) et cibler le groupe pilote Créez/attribuez un profil qui autorise les clés d'accès synchronisées comme décrit dans Passkey Profiles.

3. Ne pas appliquer l'attestation (au moins pour le groupe pilote) L'application de l'attestation exclut les clés d'accès synchronisées selon la documentation sur les concepts des clés d'accès (FIDO2).

4. Éviter les listes d'autorisation AAGUID strictes au départ Commencez par être permissif pour confirmer le flux, puis resserrez les restrictions une fois que vous savez quels fournisseurs vous souhaitez autoriser. Consultez Activer les clés d'accès (FIDO2).

5. Confirmer que l'Accès Conditionnel ne force pas Microsoft Authenticator Assurez-vous que les CA/forces d'authentification autorisent toujours le profil de clé d'accès que vous prévoyez (sinon cela ressemble à une dépendance à Microsoft Authenticator).

6. Valider le modèle d'identité (membre vs invité) Si les utilisateurs sont des invités, confirmez la prise en charge attendue dans votre modèle de locataire avant de passer du temps à régler les profils.

11. Conclusion#

Le déploiement des clés d'accès en entreprise est opérationnellement complexe, mais la voie à suivre est bien définie. Voici les réponses clés, alignées sur les principales questions opérationnelles soulevées ci-dessus :

1. Clés d'accès liées à l'appareil vs synchronisées : Les identifiants liés à un appareil (ex: Microsoft Authenticator, Windows Hello, YubiKeys, cartes à puce) sont strictement liés à un seul appareil et satisfont l'AAL3. Les clés d'accès synchronisées (ex: iCloud Keychain, Google Password Manager) fonctionnent sur plusieurs appareils et répondent à l'AAL2. La plupart des organisations ont besoin des deux : des authentificateurs matériels pour les administrateurs (AAL3) et des clés d'accès synchronisées pour l'ensemble du personnel (AAL2).

2. Amorçage de nouveaux employés : Utilisez le Passe d'accès temporaire (TAP) pour résoudre le problème de la poule et de l'œuf lors de l'intégration. Pour les déploiements à grande échelle, automatisez cela via l'API Graph. Pour les cas d'utilisation à haute assurance, complétez l'intégration avec Entra Verified ID et Face Check.

3. Récupération de téléphone de remplacement : Offrez plusieurs méthodes de récupération : Kiosque de récupération en libre-service (utilisez un ordinateur portable comme appareil d'amorçage), TAP assisté par un responsable via My Staff et SSAR (Récupération de compte en libre-service) avec Verified ID pour les cas limites.

4. Erreurs de configuration : Les erreurs les plus fréquentes incluent l'application globale de l'attestation, la non-activation des fonctionnalités en préversion pour les clés d'accès synchronisées, les listes d'autorisation AAGUID trop strictes et les politiques d'Accès Conditionnel (CA) qui créent des dépendances circulaires.

5. Invités B2B : Évitez d'enregistrer des clés d'accès directement pour les invités B2B dans votre locataire. À la place, activez l'Approbation d'accès inter-locataires pour valider les identifiants du locataire principal de l'invité.

6. Clés matérielles vs clés d'accès mobiles : Les clés de sécurité matérielles sont requises pour certains rôles de haute sécurité (administrateurs, postes de travail partagés) mais présentent des obstacles logistiques à grande échelle. Les clés d'accès mobiles sont généralement plus pratiques pour la main-d'œuvre.

7. macOS aux côtés de Windows : Utilisez Platform SSO avec JAMF/MDM pour activer la prise en charge des clés d'accès sur macOS en parallèle avec les déploiements Windows. Planifiez des flux de travail spécifiques à la plate-forme.

8. Mesures proactives : Utilisez Intune pour identifier les appareils inactifs et inciter les utilisateurs à la remédiation avant que le verrouillage ne se produise. Envisagez de faire de l'enregistrement de la clé d'accès une condition préalable à l'inscription à Intune pour favoriser une adoption précoce. Créez un flux de travail de récupération en libre-service à l'aide d'ordinateurs portables comme appareils d'amorçage.

La technologie est prête. Le principal défi est l'exécution opérationnelle. La planification de la récupération doit être intégrale dès le premier jour, et non une réflexion après coup. Une fois l'infrastructure solide, concentrez-vous sur l'optimisation de l'adoption de la connexion par clé d'accès pour vous assurer que les clés d'accès deviennent la principale méthode d'authentification de l'ensemble de votre personnel.

À propos de Corbado

Corbado est la Passkey Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion — le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →

Foire aux questions#

Pourquoi l'activation d'une MFA résistante au hameçonnage dans l'Accès Conditionnel verrouille-t-elle tous mes utilisateurs ?#

La création d'une politique d'Accès Conditionnel exigeant une MFA résistante au hameçonnage pour toutes les applications cloud bloque immédiatement tout utilisateur qui n'a pas encore enregistré de clé d'accès, y compris le blocage de l'accès à la page d'inscription des informations de sécurité elle-même. Cette dépendance circulaire, appelée le paradoxe "Enregistrer les informations de sécurité", signifie que vous devez émettre un Passe d'accès temporaire aux utilisateurs concernés avant d'activer l'application afin qu'ils puissent terminer l'inscription initiale.

Comment gérer les utilisateurs invités B2B lorsque mon locataire nécessite une MFA résistante au hameçonnage ?#

Entra ID ne prend pas en charge l'enregistrement des clés FIDO2 par les utilisateurs invités dans un locataire de ressources, de sorte que toute tentative d'application de l'inscription des clés d'accès pour les invités échouera. La bonne solution consiste à configurer les Paramètres d'accès inter-locataires sous Identités externes pour faire confiance aux réclamations MFA du locataire d'origine de l'invité, ce qui signifie qu'une YubiKey utilisée dans sa propre organisation satisfait à votre exigence de MFA résistante au hameçonnage sans aucune inscription dans votre locataire.

Qu'est-ce qui provoque l'échec silencieux de l'authentification par code QR multi-appareils lors de la connexion avec une clé d'accès ?#

L'authentification multi-appareils nécessite que le Bluetooth soit activé à la fois sur le PC et sur le téléphone pour effectuer une poignée de main de proximité BLE, de sorte que toute politique d'entreprise désactivant le Bluetooth rompra entièrement le flux. Le flux utilise également une connexion WebSocket vers cable.auth.com, que les pare-feu ou les configurations Zscaler bloquent fréquemment, ce qui provoque le blocage ou l'échec de l'analyse du code QR sans message d'erreur clair.

Comment surveiller quels employés sont prêts pour l'application d'une MFA résistante au hameçonnage avant de l'activer ?#

Le classeur Phishing-Resistant Passwordless de Microsoft, accessible via le centre d'administration Entra sous Surveillance > Classeurs, fournit une vue Préparation à l'inscription indiquant quelles paires utilisateur/appareil peuvent s'inscrire par plate-forme et par type d'identifiant. Pour la préparation à l'application, créez une politique d'Accès Conditionnel en rapport uniquement exigeant une MFA résistante au hameçonnage afin que les journaux de connexion révèlent quels utilisateurs seraient bloqués avant que vous n'activiez l'application en direct.

Quelle est la meilleure stratégie de récupération pour les employés qui obtiennent un nouveau téléphone et perdent l'accès à leur clé d'accès ?#

L'approche recommandée est stratifiée : un Kiosque de récupération en libre-service utilisant un ordinateur portable sécurisé WHfB génère un Passe d'accès temporaire via l'API Graph et couvre la plupart des cas sans l'intervention du centre d'assistance. Pour les utilisateurs sans ordinateur portable, le TAP assisté par un responsable via le portail My Staff délègue la récupération aux responsables directs, et la récupération de compte en libre-service avec le biométrique Face Check d'Entra Verified ID gère les cas limites nécessitant une revérification complète de l'identité.

Lectures complémentaires#

Pour une analyse approfondie des déploiements FIDO2/clés d'accès en entreprise, suivez des experts comme Merill Fernando et Jan Bakker qui publient régulièrement des conseils pratiques sur l'authentification Microsoft Entra.