SMS, application ou passkey : quelle authentification choisir pour vos comptes ?

Distinguer mot de passe, MFA, passkey et clé de sécurité

Choisir une authentification ne consiste pas à remplacer mécaniquement un bouton de connexion par un autre. Je commence par séparer quatre éléments : le mot de passe encore demandé par le service, le second facteur ajouté à la connexion, la passkey enregistrée dans un support compatible et la clé de sécurité physique. Ils peuvent coexister pendant une transition ; leur disponibilité dépend du compte et du service.

Microsoft indique que le SMS, les codes à usage unique et les applications d’authentification améliorent la sécurité par rapport au mot de passe seul, mais restent exposés à certaines attaques de phishing à distance. Une validation supplémentaire est donc utile sans rendre toutes les méthodes équivalentes. Je refuse de qualifier l’une d’elles d’infaillible : le compte, l’appareil, la récupération et l’usage quotidien comptent aussi.

Une passkey peut être enregistrée dans un gestionnaire compatible, un téléphone ou une tablette, une clé de sécurité physique, ou un appareil Windows avec Windows Hello. Son utilisation locale peut demander un visage, une empreinte ou un code PIN pour déverrouiller l’appareil. Ce geste local ne doit pas être confondu avec un mot de passe commun transmis entre collègues.

Comparer résistance au phishing, compatibilité et dépendances

Je compare chaque option sur plusieurs axes au lieu de produire un classement universel. Le SMS peut rester disponible sur un grand nombre de téléphones, mais il appartient aux méthodes que Microsoft décrit comme encore exposées à certaines attaques de phishing à distance. Une application d’authentification améliore elle aussi la situation par rapport au mot de passe seul, sans devenir automatiquement résistante à tout phishing.

Microsoft recommande des méthodes résistantes au phishing comme Windows Hello for Business, les passkeys FIDO2, les clés de sécurité FIDO2 ou l’authentification par certificat. Cette recommandation ne dispense pas de vérifier la compatibilité. Un service qui ne prend pas en charge les passkeys ne propose pas leur création ou leur enregistrement ; conserver une méthode maîtrisée peut alors rester nécessaire.

Je regarde aussi les dépendances : possession du téléphone, accès au gestionnaire compatible, disponibilité d’un port pour une clé, navigateur réellement utilisé, appareils partagés et possibilité d’intervention lorsqu’un utilisateur est absent. Pour un compte professionnel ou scolaire, l’organisation doit prendre en charge la passkey et peut limiter les options disponibles. Une procédure valable sur un compte personnel ne doit donc pas être transposée sans contrôle.

Si un compte est déjà compromis, je commence par reprendre le contrôle du compte Microsoft avant d’organiser sa méthode future. Ajouter une nouvelle authentification sur un accès déjà détourné ne remplace pas la vérification des sessions, des coordonnées de récupération et des changements suspects.

Inventorier comptes, appareils, navigateurs et administrateurs

Avant toute modification, je construis un inventaire simple. Pour chaque compte, j’inscris son type — personnel, professionnel ou scolaire —, son rôle, les personnes autorisées, les appareils utilisés, les navigateurs nécessaires et les méthodes actuellement enregistrées. Je distingue les comptes administrateurs, car une perte d’accès ou une méthode mal gérée y aurait des conséquences plus importantes.

• compte et propriétaire responsable ;
• niveau de privilège et usage quotidien ou exceptionnel ;
• ordinateur, téléphone, tablette et navigateur réellement utilisés ;
• SMS, application, passkey ou clé déjà enregistrés ;
• méthode de récupération disponible et personne qui peut l’employer ;
• date du dernier test concluant.

Cet inventaire évite une erreur classique : retirer une ancienne méthode avant d’avoir prouvé que la nouvelle fonctionne sur tous les chemins nécessaires. Il permet aussi de repérer un appareil qui doit bientôt être remplacé, un navigateur ancien ou un compte d’administration utilisé trop souvent. Je ne transforme pas ces observations en certitudes tant qu’un test réel n’a pas été effectué.

Pour les secrets qui restent nécessaires, le guide sur le gestionnaire de mots de passe et la migration des comptes aide à préparer les accès sans les partager ni les perdre pendant la transition.

Choisir entre passkey synchronisée, liée à l’appareil ou clé physique

Microsoft Entra ID prend en charge des passkeys synchronisées, des clés de sécurité FIDO2 et des passkeys dans Microsoft Authenticator. Le bon choix dépend pourtant du compte et du parc disponible. Une petite structure ne gagne rien à imposer une méthode théoriquement forte si elle laisse plusieurs utilisateurs sans appareil compatible ou sans procédure de remplacement.

Pour Microsoft Entra, Microsoft recommande des passkeys liées à l’appareil pour les administrateurs et utilisateurs très privilégiés, et des passkeys synchronisées pour de nombreux utilisateurs non administrateurs. J’en fais un point de départ, pas une règle étendue à tous les services. Les politiques d’une organisation, les appareils autorisés et la prise en charge réelle doivent confirmer le choix.

La clé physique peut avoir du sens lorsqu’un support séparé est souhaité, à condition d’organiser son attribution, son rangement et son remplacement. Une passkey synchronisée peut faciliter l’usage sur plusieurs appareils compatibles ; une passkey liée à l’appareil concentre davantage la dépendance sur le matériel concerné. Je documente donc toujours où se trouve la méthode et qui peut déclencher sa révocation.

Organiser un déploiement progressif et des tests réels

Je commence par un petit groupe : un utilisateur standard, un responsable et, séparément, un compte privilégié si le périmètre le permet. Je conserve la méthode de récupération maîtrisée pendant les essais. Le but est de tester la connexion habituelle, mais aussi un nouvel appareil, une session privée, le navigateur secondaire et l’absence temporaire du téléphone lorsque ces situations font partie de l’usage réel.

• enregistrer la nouvelle méthode depuis un poste contrôlé ;
• se connecter puis se déconnecter réellement ;
• vérifier les appareils et navigateurs prévus ;
• tester sans supprimer l’accès de secours ;
• consigner le résultat, l’utilisateur et la date ;
• corriger l’écart avant d’élargir le déploiement.

Je n’annonce pas qu’un test réussi sur un seul ordinateur valide toute la structure. Les comptes professionnels ou scolaires peuvent subir des politiques différentes, tandis qu’un service sans prise en charge des passkeys ne proposera pas leur enregistrement. Chaque élargissement du groupe doit donc reprendre les contrôles de compatibilité et de récupération.

Le déploiement devient généralisable lorsque les chemins nécessaires sont connus, que les utilisateurs comprennent le geste demandé et qu’une personne identifiée sait intervenir sans improviser. Je préfère une transition plus lente et réversible à une bascule rapide qui crée de nouveaux contournements.

Préparer récupération, perte, remplacement et révocation

Une méthode de connexion n’est exploitable que si sa perte a été prévue. Je décris ce qui se passe lorsqu’un téléphone est cassé, lorsqu’un ordinateur est remplacé, lorsqu’une clé physique disparaît ou lorsqu’un salarié quitte la structure. Le document précise qui confirme l’identité, qui révoque l’ancienne méthode, comment une nouvelle méthode est enregistrée et quelles preuves doivent être conservées.

La récupération ne doit pas reposer sur le même objet que la méthode principale sans solution alternative maîtrisée. Je conserve les accès de secours jusqu’à la validation du déploiement, puis je retire uniquement ceux qui sont devenus inutiles et dont la suppression a été vérifiée. Cette prudence ne signifie pas conserver indéfiniment des méthodes faibles : elle évite simplement de provoquer un verrouillage pendant la migration.

Pour les passkeys Microsoft Entra, l’absence d’expiration automatique rend le suivi du cycle de vie nécessaire. Un changement de rôle, un appareil cédé ou un départ impose donc une action explicite. Je teste aussi le remplacement avec un compte non critique avant de l’appliquer aux administrateurs.

Suivre les méthodes enregistrées et retirer les anciennes prudemment

Le travail continue après l’activation. Les administrateurs Microsoft Entra peuvent suivre la création et l’usage des passkeys dans les journaux d’audit et de connexion. Je m’en sers pour vérifier que les méthodes prévues sont réellement adoptées, sans interpréter l’absence d’un événement isolé comme une preuve complète de sécurité.

Je tiens un registre minimal : compte, méthode, support, date d’enregistrement, dernier usage vérifié, méthode de récupération et date de revue. Comme les passkeys Microsoft Entra n’expirent pas automatiquement, ce registre sert à déclencher la révocation lorsqu’un support ou un utilisateur ne doit plus conserver l’accès.

Le retrait des anciennes méthodes se fait compte par compte, après un test de connexion et un test de récupération. Je commence par le groupe pilote, j’observe les erreurs, puis j’étends la règle. Si une dépendance non recensée apparaît, je corrige l’inventaire avant de continuer au lieu de forcer la suppression.

Pour une petite structure, le meilleur résultat n’est pas d’afficher le plus grand nombre de technologies. C’est de savoir qui accède à quoi, avec quelle méthode réellement compatible, comment l’accès est récupéré et à quel moment il doit être retiré. Cette visibilité permet de renforcer progressivement les comptes sans bloquer les utilisateurs.