Microsoft Entra : fin de vie programmée du MFA par SMS et appel vocal - guide de préparation (mis à jour le 20 août 2026)

Microsoft a annoncé via le Message Center MC1426371 que les SMS et les appels téléphoniques ne seront plus pris en charge comme méthodes d'authentification intégrées dans Microsoft Entra.

C'est un changement important pour les organisations qui s'appuient encore sur des méthodes MFA basées sur les télécommunications.

À partir du 1er septembre 2026, les passkeys deviendront l'expérience d'authentification par défaut dans Microsoft Entra. Les SMS et les appels vocaux seront ensuite progressivement retirés et basculeront vers un modèle de fournisseurs configurés par les clients via le Microsoft Security Store.

Ce qui change

Microsoft oriente Microsoft Entra vers des méthodes d'authentification plus fortes et résistantes au phishing.

Concrètement :

• Les passkeys deviennent la méthode d'authentification par défaut et recommandée.
• Les SMS et les appels vocaux ne seront plus disponibles comme méthodes MFA natives dans Microsoft Entra.
• Les organisations qui ont encore besoin des SMS ou des appels vocaux devront configurer un fournisseur télécom tiers via le Microsoft Security Store.
• La transition commence en 2026 et se termine le 1er février 2027.

Microsoft l'explique clairement dans son article :

À mesure que les attaques contre les identités deviennent plus sophistiquées à l'ère de l'IA, les organisations ont besoin de méthodes d'authentification plus fortes pour protéger les utilisateurs contre le phishing, le vol d'identifiants et l'ingénierie sociale. Pour répondre à ces menaces, Microsoft Entra ID fait évoluer son expérience d'authentification en faisant des passkeys la méthode par défaut résistante au phishing, afin d'aider les clients à réduire leur dépendance aux méthodes vulnérables comme les SMS et les appels vocaux.

Microsoft rappelle également que les mots de passe, les codes à usage unique par SMS et la vérification par appel vocal restent vulnérables au phishing, à l'interception et à l'ingénierie sociale.

Périmètre du changement

Avant d'aborder le calendrier, il est utile de préciser ce qui est réellement concerné :

• Uniquement les environnements cloud public. Les autres environnements suivront selon un calendrier ultérieur, avec des communications préalables.
• Azure AD B2C n'est pas concerné. Pour Microsoft Entra External ID, le changement est prévu l'an prochain avec une annonce séparée.
• La prise en charge des passkeys pour les utilisateurs B2B et les invités internes est prévue pour la fin de l'année 2026. Ces utilisateurs sont bien dans le périmètre de la fin de vie.
• Les méthodes MFA externes ne sont pas impactées, sauf si les mêmes utilisateurs sont également activés pour les SMS ou les appels vocaux.
• Le SSPR est concerné. Voir la section dédiée plus bas.

Source : https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq

Calendrier

1er septembre 2026

Microsoft démarre le déploiement progressif.

Pour les tenants ayant des utilisateurs activés pour le MFA par SMS ou appel vocal, que ce soit via la stratégie moderne des méthodes d'authentification Microsoft Entra (AMP) ou via les anciens paramètres MFA par utilisateur :

• Ces utilisateurs seront automatiquement activés pour les passkeys.
• Ils seront placés dans un profil passkey autorisant tous les types de passkeys.
• Microsoft passera automatiquement la campagne d'inscription en mode Microsoft managed afin de proposer l'enregistrement d'une passkey à ces utilisateurs.
• Lors de leur prochaine connexion, après validation du MFA, ces utilisateurs seront invités à enregistrer une passkey. Par défaut, ils pourront reporter cette invitation sans limite. Ce report ne doit pas être interprété comme une absence d'urgence : à partir du 1er février 2027, les utilisateurs dont la seule méthode MFA disponible est le SMS ou l'appel vocal seront bloqués tant qu'ils n'auront pas enregistré une passkey.
• Il faudra informer les utilisateurs finaux du changement à venir. Microsoft recommande d'utiliser le guide de déploiement des passkeys pour préparer l'environnement.

Une nuance importante : le déclencheur de cette activation automatique est le périmètre de la stratégie, pas l'usage réel. Un utilisateur présent dans le périmètre de la stratégie sms ou voice, mais qui s'authentifie exclusivement avec Microsoft Authenticator, sera malgré tout activé automatiquement pour les passkeys et sollicité. À l'inverse, les utilisateurs qui se connectent déjà avec une passkey, Windows Hello Entreprise ou une autre méthode résistante au phishing ne sont pas concernés, sauf s'ils sont également activés pour les SMS ou les appels vocaux.

À noter également : la campagne d'inscription est une conséquence, pas une cause. Microsoft regarde le périmètre sms et voice, en déduit les utilisateurs concernés, les active automatiquement pour les passkeys, et modifie seulement ensuite la campagne pour les solliciter. Modifier l'état de la campagne ne change rien à qui est dans le périmètre. Voir la section sur l'opt-out plus bas.

Cela ne signifie pas que les SMS et les appels vocaux cessent immédiatement de fonctionner, mais c'est le début du chemin de migration vers les passkeys.

18 septembre 2026

Le Microsoft Security Store permet aux organisations d'évaluer des opérateurs télécoms tiers.

Cette option vise les organisations qui ne peuvent pas encore basculer complètement vers une méthode d'authentification plus sécurisée.

Elle doit être considérée comme une voie d'exception, pas comme l'état cible. À noter qu'elle a un coût : la tarification varie selon le fournisseur et la région, et se fait généralement au message, en fonction du volume et de la répartition géographique. La migration des utilisateurs vers les passkeys n'entraîne aucun coût supplémentaire.

30 octobre 2026

Les organisations qui souhaitent continuer à utiliser les SMS ou les appels vocaux pourront sélectionner un opérateur télécom disponible via le Microsoft Security Store.

À partir de ce moment, les SMS et les appels vocaux passent d'un modèle fourni directement par Microsoft à un modèle de fournisseurs télécoms configurés par le client.

1er février 2027

Microsoft arrête les SMS et les appels vocaux comme méthodes MFA natives dans Microsoft Entra.

Après cette date :

• Les SMS et les appels vocaux ne seront plus disponibles directement depuis Microsoft Entra.
• Seuls les opérateurs télécoms configurés par le client pourront continuer à prendre en charge ces méthodes.
• Les passkeys deviennent la méthode d'authentification par défaut et recommandée.

À noter : la documentation officielle et le Message Center indiquent tous deux le 1er février 2027, alors que le script PowerShell d'analyse publié par Microsoft et son README affichent actuellement le 28 janvier 2027 dans leur résumé d'impact. Planifiez sur la base du 1er février 2027, et gardez cet écart en tête à la lecture de la sortie du script.

Après le 1er février

Les passkeys deviennent la méthode d'authentification par défaut et recommandée. Les utilisateurs dont la seule méthode MFA disponible est le SMS ou l'appel vocal devront enregistrer une passkey lors de la connexion pour continuer à accéder à leur compte.

Cette invitation sera bloquante : l'utilisateur devra enregistrer une passkey avant de pouvoir poursuivre sa connexion. Microsoft précise que les utilisateurs ne sont pas verrouillés hors de leur compte : ils font face à une invitation d'enregistrement bloquante qu'ils ne peuvent plus reporter, pas à un refus de connexion.

Il n'y aura pas d'opt-out pour ce comportement à partir du 1er février 2027. Il sera appliqué à tous les tenants.

Migrez les utilisateurs vers une méthode résistante au phishing ou choisissez un opérateur télécom pour continuer à utiliser les SMS ou les appels vocaux.

Pourquoi c'est important

Le MFA par SMS et appel vocal a été utile comme méthode de transition, mais il n'offre plus un niveau de sécurité suffisant pour les environnements modernes.

Ces méthodes restent exposées à plusieurs risques :

• Phishing
• SIM swapping
• Interception d'OTP
• Ingénierie sociale
• Abus des appels vocaux
• Fatigue utilisateur et faible niveau d'assurance

Les passkeys apportent un modèle d'authentification plus robuste, car elles sont résistantes au phishing par conception.

Pour les environnements Microsoft Entra, ce changement s'inscrit aussi dans une évolution plus large vers l'authentification sans mot de passe, Conditional Access, les authentication strengths et une meilleure protection des identités.

N'oubliez pas le SSPR

La fin de vie s'applique à l'ensemble d'Entra, ce qui inclut la réinitialisation de mot de passe en libre-service. Les SMS et les appels vocaux ne seront plus disponibles comme options de vérification SSPR, sauf si vous configurez un opérateur télécom via le Security Store.

Microsoft indique également travailler sur la prise en charge du changement de mot de passe pour les utilisateurs qui se connectent avec une méthode sans mot de passe, avec plus de détails à venir. Si vos parcours SSPR reposent aujourd'hui sur l'option téléphone mobile pour une part importante de votre population, ce sujet doit faire partie du même projet, et non être traité après coup.

Source : https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq

Ce que les administrateurs doivent faire maintenant

N'attendez pas 2027.

Si votre tenant utilise encore le MFA par SMS ou appel vocal, commencez par identifier les utilisateurs concernés et l'usage réel des méthodes d'authentification.

Comprendre les trois populations distinctes

C'est là que la plupart des inventaires se trompent. Il y a trois questions différentes, et elles nécessitent trois outils différents :

1. Qui est dans le périmètre des stratégies sms et voice (AMP ou anciens paramètres MFA par utilisateur) ? C'est le seul critère qui déclenche l'activation automatique du 1er septembre 2026.
2. Qui a réellement enregistré un numéro de téléphone comme méthode d'authentification ?
3. Qui utilise réellement les SMS ou l'appel vocal pour s'authentifier ?

Une requête sur les logs de connexion ne répond qu'à la troisième question. Elle indique qui a utilisé la méthode, pas qui est activé pour celle-ci, ni qui y est enregistré. Une personne dans le périmètre de la stratégie sms qui n'utilise jamais les SMS n'apparaîtra pas dans les résultats, et sera pourtant impactée.

Identifier qui est dans le périmètre de la stratégie

Microsoft publie un script PowerShell pour cela : https://github.com/microsoft/entra-sms-voice-usage-analyzer

Rôle requis : Lecteur global, Administrateur de stratégie d'authentification ou Lecteur de sécurité. Scopes Graph requis : Policy.Read.All et Group.Read.All.

Install-Module Microsoft.Graph.Authentication -Scope CurrentUser
Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser
Install-Module Microsoft.Graph.Groups -Scope CurrentUser

.\Get-SmsVoicePolicyUsers.ps1 -TenantId "contoso.onmicrosoft.com"

Le script lit l'état de la campagne d'inscription (une valeur default correspond à Microsoft managed), lit les configurations des méthodes d'authentification sms et voice, résout les cibles incluses et exclues en noms de groupes, exporte un CSV nommé SmsVoicePolicyTargets_<horodatage>.csv, et affiche un résumé d'impact.

Comment lire la sortie : un SMS state ou Voice state à enabled combiné à Include: ALL USERS signifie que l'ensemble de votre tenant, hors exclusions, sera activé automatiquement pour les passkeys le 1er septembre. Tout périmètre non vide vaut mise en périmètre.

Ce que le script ne fait pas, et qu'il vous reste à faire :

• Il ne développe pas les membres des groupes. Vous obtenez un périmètre, pas une liste nominative d'utilisateurs.
• Il ne couvre pas les anciens paramètres MFA par utilisateur, pourtant concernés par le changement.
• Il ne mesure aucun usage réel.

Connect-MgGraph -Scopes "Policy.Read.All"

foreach ($m in "sms","voice") {
    $c = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/$m" -OutputType PSObject
    "=== $m : $($c.state) ==="
    "include:"; $c.includeTargets | ConvertTo-Json -Depth 3
    "exclude:"; $c.excludeTargets | ConvertTo-Json -Depth 3
}

Si les deux ressortent à disabled, personne n'est dans le périmètre, rien ne se passera sur votre tenant le 1er septembre, et l'opt-out décrit plus bas est inutile. Vérifiez ce point avant toute autre chose. Beaucoup d'administrateurs vont poser l'opt-out sans jamais vérifier s'ils sont réellement concernés.

Identifier qui a enregistré un numéro de téléphone

Utilisez le rapport User registration details dans le portail Entra : https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/UserRegistrationDetails/fromNav/Identity

Ou via Microsoft Graph :

Connect-MgGraph -Scopes "AuditLog.Read.All","UserAuthenticationMethod.Read.All"

Get-MgReportAuthenticationMethodUserRegistrationDetail -All | Where-Object { $_.MethodsRegistered -contains "mobilePhone" } | Select-Object UserPrincipalName, IsMfaRegistered, IsPasswordlessCapable, @{n="Methods";e={$_.MethodsRegistered -join ","}} | Export-Csv .\PhoneRegisteredUsers.csv -NoTypeInformation

Mesurer l'usage réel

Trois approches possibles, selon ce dont vous disposez. Choisissez celle qui correspond à votre environnement.

Avec PS365

La voie la plus rapide. Mon module PS365 encapsule la requête sur les logs de connexion, gère la pagination et la conversion des dates, et expose les détails d'authentification sous une forme exploitable :

Install-Module PS365 -Scope CurrentUser
Import-Module PS365

Get-MgAuditLogSigninInfo -TimeRange Maximum -SmsVoiceMFASignInsOnly -ExportToExcel

TimeRange Maximum correspond à la fenêtre de rétention maximale disponible dans Entra ID, soit 30 jours avec une licence Entra ID P1 ou P2, et 7 jours sinon.

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

$days = 1
$since = (Get-Date).AddDays(-$days).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
$uri = "https://graph.microsoft.com/beta/auditLogs/signIns?`$filter=createdDateTime ge $since&`$top=999"
$csvPath = ".\SmsVoiceUsageByUser_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv"

[System.Collections.Generic.List[PSCustomObject]]$signInLogList = @()

while ($uri) {
    $response = Invoke-MgGraphRequest -Method GET -Uri $uri -OutputType PSObject
    if ($response.value) {
        $signInLogList.AddRange([PSCustomObject[]]$response.value)
    }
    Write-Host "Retrieved $($signInLogList.Count) records"
    $uri = $response.'@odata.nextLink'
}

[System.Collections.Generic.List[PSCustomObject]]$phoneSignInList = @()

foreach ($signIn in $signInLogList) {
    $phoneMethods = @($signIn.authenticationDetails | Where-Object { $_.authenticationMethod -match "Text message|SMS|Voice call|Phone call approval" })
    if ($phoneMethods.Count -eq 0) { continue }

    $phoneSignIn = [PSCustomObject][ordered]@{
        UserPrincipalName = $signIn.userPrincipalName
        CreatedDateTime   = $signIn.createdDateTime
        ErrorCode         = $signIn.status.errorCode
        AppDisplayName    = $signIn.appDisplayName
        IPAddress         = $signIn.ipAddress
        Methods           = ($phoneMethods.authenticationMethod | Sort-Object -Unique) -join ","
    }

    $phoneSignInList.Add($phoneSignIn)
}

$phoneSignInList | Group-Object UserPrincipalName | ForEach-Object {
    [PSCustomObject][ordered]@{
        UserPrincipalName = $_.Name
        Attempts          = $_.Count
        Success           = ($_.Group | Where-Object { $_.ErrorCode -eq 0 }).Count
        LastUsed          = ($_.Group.CreatedDateTime | Measure-Object -Maximum).Maximum
        Methods           = ($_.Group.Methods -split "," | Sort-Object -Unique) -join ","
    }
} | Sort-Object LastUsed -Descending | Export-Csv -Path $csvPath -NoTypeInformation -Encoding UTF8

SigninLogs
| summarize Oldest = min(TimeGenerated), Newest = max(TimeGenerated)

let lookback = 90d;
SigninLogs
| where TimeGenerated > ago(lookback)
| mv-expand AuthDetail = parse_json(AuthenticationDetails)
| extend AuthMethod = tostring(AuthDetail.authenticationMethod)
| where AuthMethod has_any ("Text message", "SMS", "Voice call", "Phone call approval")
| summarize Attempts = count(), Success = countif(ResultType == 0), LastUsed = max(TimeGenerated), Methods = make_set(AuthMethod) by UserPrincipalName
| sort by LastUsed desc

Gardez ces limites en tête, quelle que soit l'approche retenue :

• Filtrer uniquement sur les connexions réussies masquerait les tentatives en échec, alors qu'un utilisateur qui échoue son SMS est tout autant concerné. Les requêtes ci-dessus comptent les deux.
• Les valeurs de authenticationMethod ne sont pas stables d'un scénario à l'autre (SMS, Text message, Voice call, Phone call approval (Authentication phone), Phone call approval (Office phone)), donc un filtrage par motif est plus sûr qu'une liste exacte.
• Un diagnostic setting ne rejoue pas le passé. Si vous avez activé l'export vers Log Analytics il y a deux mois, vous avez deux mois d'historique, quelle que soit la rétention configurée.
• Les utilisateurs trimestriels ou saisonniers peuvent simplement ne pas apparaître dans la fenêtre interrogeable. L'absence du rapport d'usage ne prouve pas que personne n'a besoin de la méthode.

C'est le croisement des trois populations qui donne un plan d'action. Les utilisateurs présents dans l'export du périmètre mais absents du rapport d'usage sont ceux que vous pouvez sortir en premier du périmètre SMS/Voice.

Retirer les utilisateurs du périmètre SMS et appel vocal

C'est le levier le plus efficace, et il doit être actionné avant le 1er septembre 2026.

La formulation « sortir les utilisateurs de SMS ou Voice dans l'AMP » peut induire en erreur. L'Authentication Methods Policy n'est pas un conteneur dans lequel les utilisateurs seraient inscrits. C'est un ensemble de configurations par méthode, chacune avec un state et ses propres includeTargets et excludeTargets. Un utilisateur est dans le périmètre SMS simplement parce que la configuration sms est enabled et qu'il entre dans ses cibles incluses sans être exclu. Sortir des utilisateurs signifie donc l'une de ces trois choses : désactiver la méthode, restreindre ses cibles incluses, ou ajouter les utilisateurs à ses cibles exclues. Il n'y a pas d'opération distincte.

Vérifiez d'abord policyMigrationState sur la stratégie. Une valeur migrationComplete signifie que les anciens paramètres MFA par utilisateur ne constituent plus une source de périmètre distincte, et que tout se décide dans l'AMP. Sinon, les deux doivent être traités.

(Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/policies/authenticationmethodspolicy" -OutputType PSObject).policyMigrationState

Dans le centre d'administration Entra, allez dans Entra ID > Méthodes d'authentification > Stratégies, puis ouvrez SMS et Appel vocal. Vous pouvez :

• Passer l'état de la méthode à Disabled si personne n'en a besoin,
• ou retirer les groupes et utilisateurs ciblés,
• ou basculer les populations concernées dans la liste d'exclusion.

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

foreach ($m in "sms","voice") {
    $body = @{ "@odata.type" = "#microsoft.graph.${m}AuthenticationMethodConfiguration"; id = $m; state = "disabled" } | ConvertTo-Json -Depth 3
    Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/$m" -Body $body -ContentType "application/json"
}

$groupId = "00000000-0000-0000-0000-000000000000"

$body = @{
    "@odata.type" = "#microsoft.graph.smsAuthenticationMethodConfiguration"
    id = "sms"
    state = "enabled"
    includeTargets = @(
        @{ targetType = "group"; id = $groupId; isRegistrationRequired = $false }
    )
} | ConvertTo-Json -Depth 4

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/sms" -Body $body -ContentType "application/json"

Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/sms" -OutputType PSObject | ConvertTo-Json -Depth 5 | Out-File .\sms-policy-backup.json

L'ordre compte. Faites l'inventaire d'abord, sinon vous coupez les SMS à des utilisateurs qui n'ont rien d'autre. Les utilisateurs dont le téléphone est l'unique méthode enregistrée doivent avoir enregistré autre chose au préalable, faute de quoi ils se retrouvent sans MFA utilisable à leur prochaine connexion.

Les utilisateurs retirés du périmètre avant le 1er septembre ne sont pas activés automatiquement pour les passkeys et ne sont pas ramenés automatiquement dans la campagne d'inscription Microsoft managed.

Si vous avez besoin de plus de temps : l'opt-out temporaire

Un opt-out temporaire couvre la période du 1er septembre 2026 au 1er février 2027. Il diffère l'activation automatique des passkeys et le déploiement de la campagne d'inscription, le temps de mener vos travaux de transition, par exemple la configuration d'un opérateur télécom ou la migration des utilisateurs vers une autre méthode.

Il nécessite la permission Microsoft Graph Policy.ReadWrite.AuthenticationMethod :

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{
   "optOutSettings": {
     "passkeyDynamicMigration": true
   }
}

En PowerShell :

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

$body = @{ optOutSettings = @{ passkeyDynamicMigration = $true } } | ConvertTo-Json -Depth 3

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/beta/policies/authenticationmethodspolicy" -Body $body -ContentType "application/json"

Pour vérifier la valeur actuelle :

$policy = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/policies/authenticationmethodspolicy" -OutputType PSObject

if ($null -eq $policy.optOutSettings) {
    "optOutSettings non défini - le tenant n'est PAS en opt-out"
} else {
    $policy.optOutSettings | ConvertTo-Json -Depth 3
}

optOutSettings apparaît dans le schéma de la stratégie mais revient à null tant que la propriété n'a pas été écrite au moins une fois. Une valeur null correspond à l'état par défaut et signifie que le tenant n'est pas en opt-out. Repasser passkeyDynamicMigration à false rétablit le comportement standard.

Deux avertissements. D'abord, cela ne vous fait gagner du temps que jusqu'au 1er février 2027 : les calendriers standards de migration et d'application s'appliquent à partir de cette date quelle que soit la valeur du paramètre, et il n'existe aucun opt-out pour l'échéance du 1er février. Ensuite, vous lirez peut-être ailleurs qu'il suffit de sortir la campagne d'inscription de l'état Microsoft managed pour différer l'impact. Ce n'est pas ce que Microsoft documente. La campagne d'inscription et les configurations des méthodes sms et voice sont deux objets distincts, et la campagne se situe en aval du périmètre, pas l'inverse. Les deux leviers documentés sont le retrait des utilisateurs du périmètre SMS/Voice, et l'opt-out passkeyDynamicMigration. Ne comptez pas sur l'état de la campagne seul.

Un effet de bord à anticiper : si vous exploitez déjà une campagne d'inscription pour une autre méthode, Microsoft écrasera cette configuration le 1er septembre pour les tenants dans le périmètre, état et méthode ciblée compris.

Choisir vos types de passkeys en connaissance de cause

Microsoft Entra ID prend en charge deux catégories de passkeys, et ce choix a un impact direct sur la charge de votre support :

• Passkeys liées à l'appareil (device-bound) : passkey dans Microsoft Authenticator, Entra Passkey sur Windows, clés de sécurité FIDO2. Le credential est créé et stocké sur un seul appareil et ne peut pas être transféré vers un nouvel appareil, même avec la sauvegarde Microsoft Authenticator configurée. Prévoyez des appels de réenregistrement à chaque renouvellement, perte ou vol d'appareil.
• Passkeys synchronisées : stockées dans un gestionnaire d'identifiants de plateforme comme iCloud Keychain ou Google Password Manager, et synchronisées entre les appareils de l'utilisateur. Une option pragmatique pour les populations à faible risque, et un moyen de réduire la charge support liée aux credentials device-bound.

Un schéma courant consiste à réserver les passkeys device-bound ou les clés FIDO2 aux utilisateurs à privilèges et à risque élevé, et à autoriser les passkeys synchronisées pour les utilisateurs standards.

Préparer le déploiement et l'amorçage

• Validez les appareils compatibles, les versions d'OS, les navigateurs, les applications, les scénarios VDI, les populations concernées, les parcours d'enrôlement et les processus support. C'est généralement là que se cache la complexité, et là où une montée en version « simple » se transforme en projet de six mois.
• Vérifiez que Passkey (FIDO2) est activée comme méthode d'authentification et que vos utilisateurs SMS et appel vocal sont inclus dans une stratégie de méthodes d'authentification autorisant les passkeys, avant de lancer le moindre enregistrement.
• Attention à l'accès conditionnel. Imposer une authentification résistante au phishing de manière trop large peut casser le flux d'enregistrement de la passkey lui-même, puisque l'utilisateur ne dispose pas encore d'un credential résistant au phishing. Prévoyez une voie d'amorçage, typiquement un Temporary Access Pass, et testez-la avant d'appliquer la contrainte.
• Lancez votre propre campagne d'inscription de manière proactive plutôt que d'attendre celle imposée par Microsoft le 1er septembre. Allez dans Entra ID > Méthodes d'authentification > Campagne d'inscription, et ciblez le groupe de sécurité des utilisateurs SMS et appel vocal constitué à l'étape 2.

Quand l'invite passkey ne se déclenche pas

L'invite n'est pas évaluée par utilisateur. Elle est évaluée par couple appareil et navigateur. Un utilisateur disposant d'un identifiant Windows Hello for Business n'est pas sollicité sur Windows avec Chrome, mais l'est sur un Mac avec Chrome, parce que cet identifiant ne s'applique pas à cette plateforme. Attendez-vous à la question côté support.

Plusieurs configurations suppriment complètement l'invite. En mode Microsoft managed, un utilisateur n'est pas sollicité si son profil passkey porte l'une de ces restrictions :

• synced only
• device-bound only
• attestation forcée
• restriction d'AAGUID

À lire en regard de la section sur les types de passkeys. Si vous réservez les passkeys device-bound aux utilisateurs à privilèges, ces utilisateurs cessent de recevoir l'invite. La restriction qui améliore votre posture supprime aussi le mécanisme qui pousse l'enregistrement, donc ces populations demandent un déploiement dirigé plutôt qu'une campagne.

La même chose s'applique au niveau du tenant. Si votre stratégie passkey (FIDO2) cible des AAGUID précis, la campagne Microsoft managed ne bascule pas sa méthode ciblée vers les passkeys. Elle continue de cibler ce qu'elle ciblait avant.

Une campagne passkey a deux prérequis, et le second est facile à manquer :

• la méthode passkey (FIDO2) doit être activée dans la stratégie des méthodes d'authentification
• le paramètre Allow self-service setup doit être activé dans la configuration de cette même méthode

Quel identifiant supprime l'invite, par plateforme

Il suffit d'un identifiant correspondant pour que l'invite soit supprimée sur ce couple appareil et navigateur. C'est le tableau à garder sous la main quand quelqu'un signale être sollicité sur une machine et pas sur une autre.

Linux est volontairement absent du tableau : les passkeys FIDO2 n'y sont pas disponibles, donc les utilisateurs Linux ne sont jamais sollicités.

Autres comportements à connaître avant le 1er septembre :

• une campagne ne cible qu'une méthode à la fois. Si vous exploitez aujourd'hui une campagne Authenticator, basculer sur les passkeys l'arrête.
• en mode Microsoft managed, le délai de report est d'un jour et les reports sont illimités, et ni l'un ni l'autre n'est configurable.
• la documentation de la campagne d'inscription indique qu'en mode Microsoft managed le ciblage passe à tous les utilisateurs capables de MFA, alors que la page de fin de vie décrit la campagne comme mettant vos utilisateurs SMS et voix dans le périmètre. Planifiez sur la lecture la plus large.
• les invités ne sont pas sollicités pour les passkeys, la prise en charge des passkeys pour les comptes invités n'existe pas encore.
• l'invite ne part pas dans une session SSO, quand une stratégie d'accès conditionnel bloque la page Register security information, quand un écran de conditions d'utilisation s'affiche, ou avec des contrôles personnalisés d'accès conditionnel.

Source : https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-registration-campaign

Préparer la communication utilisateur

Les utilisateurs doivent comprendre ce qu'est une passkey, pourquoi ils doivent en enregistrer une et ce qui va changer lors de la connexion. Microsoft recommande un plan en trois temps : sensibilisation, puis action, puis relances auprès de ceux qui n'ont pas encore enregistré de méthode.

Des modèles de communication utilisateur sont disponibles sur https://aka.ms/mfatemplates

Ciblez vos messages sur le groupe de sécurité des utilisateurs SMS et appel vocal, pour que les bonnes personnes reçoivent l'information au bon moment.

Gérer les exceptions

Certains utilisateurs, scénarios partagés ou comptes opérationnels peuvent nécessiter une trajectoire différente. Documentez ces cas dès maintenant, et documentez le besoin réel (quelle réglementation, quel scénario) si vous envisagez de justifier le recours à un opérateur télécom.

Éviter de faire du fallback télécom la stratégie par défaut

L'option Microsoft Security Store peut être utile pour les organisations ayant une contrainte réglementaire ou opérationnelle avérée, mais elle ne doit pas remplacer la migration vers une authentification résistante au phishing. Elle implique un coût récurrent au message et maintient une méthode vulnérable dans votre environnement. Si vous prenez cette voie, traitez-la comme un projet à part entière. Montez le contrat opérateur via le parcours marketplace, puis testez avec un groupe pilote avant de basculer des utilisateurs de production. Vous ajoutez un contrat tiers, une facturation au message et un canal de livraison que vous ne maîtrisez pas.

À retenir

Ce n'est pas une simple modification de configuration MFA.

Microsoft déplace clairement l'authentification Entra hors des méthodes télécoms et vers des méthodes résistantes au phishing par défaut.

Si les SMS et les appels vocaux font encore partie de votre stratégie MFA, la fenêtre de migration est maintenant connue :

• 1er septembre 2026 : les passkeys deviennent l'expérience par défaut, et les utilisateurs dans le périmètre des stratégies sms et voice sont activés automatiquement et sollicités.
• 1er février 2027 : les SMS et appels vocaux MFA natifs sont supprimés, avec une invitation d'enregistrement bloquante et sans opt-out.

Deux dates comptent plus que l'échéance elle-même : le jour où vous terminez votre inventaire, et le jour où vous décidez qui reste dans le périmètre SMS/Voice après le 1er septembre. La bonne approche consiste à préparer l'adoption des passkeys dès maintenant, avant que le sujet ne devienne un chantier de remédiation urgent.

Références

• https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
• https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq
• https://github.com/microsoft/entra-sms-voice-usage-analyzer
• https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication
• https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2
• https://github.com/bastienperez/PS365