Le MFA par notification push, par SMS ou par code TOTP était suffisant en 2020. Il ne l’est plus en 2026. Les attaques AiTM (Adversary-in-the-Middle) ont basculé la balance : un attaquant place un reverse proxy entre l’utilisateur et login.microsoftonline.com, relaie la session en temps réel, capture le cookie de session après validation du MFA. Le second facteur est franchi sans que la victime, ni Microsoft, ni l’IT n’aient vu passer une alerte.

Microsoft a documenté plus de 10 000 attaques AiTM en 2024, en hausse d’environ 46 % en 2025 (business-reporter.com, teiss.co.uk). L’équipe de recherche Sekoia.io a identifié onze kits AiTM majeurs en activité au premier semestre 2025 (blog.sekoia.io) : Tycoon 2FA (threat score 4,8/5), EvilProxy (environ 8 % des attaques observées), Storm-1167, NakedPages, Sneaky 2FA, Mamba 2FA, Greatness, et l’historique Evilginx. Le modèle économique est mature : Phishing-as-a-Service à 100-1 000 dollars par mois selon la sophistication.

CrowdStrike a publié dans son 2026 Global Threat Report que 82 % des détections en 2025 étaient malware-free, c’est-à-dire centrées sur l’identité, le vol de jetons et l’abus d’outils légitimes. Le contournement du MFA classique est devenu la voie royale.

Le seul antidote technique est le phishing-resistant MFA : FIDO2, Windows Hello for Business, certificate-based authentication, passkeys. Ces méthodes signent cryptographiquement l’authentification en liant la signature au domaine d’origine — un site proxy ne peut pas obtenir une signature valide pour login.microsoftonline.com puisqu’il n’est pas login.microsoftonline.com. Pour les bases du sujet, consultez notre guide complet de sécurisation Microsoft 365 et le guide de déploiement du MFA en entreprise. Ce guide-ci se concentre sur le sous-ensemble qui résiste à l’AiTM : la configuration concrète de Conditional Access avec Authentication Strengths, l’enrôlement FIDO2, et la détection.

Comment fonctionne AiTM, concrètement

Le scénario type tient en cinq mouvements.

1. Le lure. L’utilisateur reçoit un déclencheur : email avec lien vers un domaine fraîchement enregistré imitant Microsoft, pièce jointe HTML (technique HTML Smuggling), fichier SVG contenant du JavaScript de redirection (Storm-1167, NakedPages), QR code dans un PDF (quishing, qui pousse la victime à scanner sur son téléphone hors périmètre MDM), ou message Teams depuis un compte interne déjà compromis (vecteur Teams).

2. Le reverse proxy. La victime arrive sur un serveur contrôlé par l’attaquant. Ce n’est pas une fausse copie statique : c’est un proxy qui transmet en temps réel chaque requête vers login.microsoftonline.com et chaque réponse vers la victime. La page est pixel-perfect — c’est le contenu réel de Microsoft rendu via le proxy. Evilginx, Modlishka, EvilProxy et Tycoon 2FA fonctionnent tous sur ce principe, avec des « phishlets » qui configurent les règles de réécriture pour des centaines de services.

3. Authentification complète. La victime saisit son login, son password, complète son MFA (push approuvé, code TOTP, code SMS). Chaque interaction est transmise telle quelle à Microsoft. Microsoft voit une connexion parfaitement légitime : bon mot de passe, bon second facteur, depuis une IP (celle du proxy) qui peut se trouver dans le pays attendu.

4. Microsoft émet un cookie, l’attaquant le capture. Une fois l’authentification réussie, Microsoft renvoie via le proxy un cookie de session (ESTSAUTHPERSISTENT et associés). Le proxy capture ce cookie avant de le transmettre à la victime, qui voit Outlook ou Teams s’ouvrir normalement — sans signal d’alerte.

5. L’attaquant rejoue le cookie. Depuis sa propre machine, il accède à la session : email, OneDrive, SharePoint, Teams. Aucun login, aucun MFA. Premières actions documentées par Sekoia.io et Microsoft Threat Intelligence : création d’une règle Outlook qui transfère discrètement les messages contenant « facture », « IBAN », « virement » vers une adresse externe, ajout d’une méthode MFA contrôlée par l’attaquant pour persister, lancement d’un lateral phishing Teams/email vers les contacts internes, consentement à une application OAuth malveillante pour survivre à la révocation du cookie.

Pourquoi push, SMS, TOTP ne sauvent rien

Ces facteurs partagent une propriété fatale : ils ne sont pas liés au domaine d’origine. Un code TOTP à six chiffres est valide pour quiconque l’entre dans les 30 secondes suivantes, peu importe sur quelle page. Une notification push approuve un événement Microsoft, pas le navigateur précis de la victime. Le SMS est encore pire (SIM swapping).

FIDO2/WebAuthn change l’équation : la clé signe un challenge cryptographique lié au domaine (rpId = login.microsoft.com). Si la victime atterrit sur login.microsoftonline.com.evil.tld, la clé refuse de signer parce que le domaine vu par le navigateur ne correspond pas à celui enregistré lors de l’enrôlement. Le proxy ne peut pas relayer une signature qui n’a jamais été produite. C’est pour cette raison qu’aucun kit AiTM commercial ne contourne FIDO2.

Conditions de licence : ce qu’il vous faut

Composant	Licence minimale	Inclus dans
Conditional Access	Microsoft Entra ID P1	M365 Business Premium, E3, E5
Authentication Strengths	Microsoft Entra ID P1	M365 Business Premium, E3, E5
Built-in « Phishing-resistant MFA » strength	Microsoft Entra ID P1	M365 Business Premium, E3, E5
Temporary Access Pass	Microsoft Entra ID P1	M365 Business Premium, E3, E5
Identity Protection (risk-based CA)	Microsoft Entra ID P2	M365 E5, Entra ID P2 standalone
Automatic Attack Disruption	Microsoft 365 Defender XDR	E5, Defender for Office 365 Plan 2 + Defender for Endpoint P2
Token Protection (CA control)	Microsoft Entra ID P1 + plateformes éligibles	M365 Business Premium, E3, E5

Sans Entra ID P1, vous ne pouvez pas créer la politique décrite dans ce guide. Si vous êtes en Business Standard, la première étape concrète est la montée vers Business Premium (avant même d’acheter la moindre YubiKey).

Source : learn.microsoft.com — Conditional Access policy template: Require phishing-resistant MFA for administrators.

Les trois forces d’authentification built-in de Microsoft Entra

Microsoft fournit trois Authentication Strengths préconfigurées. Une politique Conditional Access peut exiger l’une d’elles via le contrôle « Require authentication strength ».

Authentication strength	Méthodes acceptées	Cas d’usage
Multifactor authentication	Tous : password + Authenticator push/TOTP, SMS, voice, Authenticator passwordless, FIDO2, WHfB, certificate-based	MFA classique pour la population générale, ne résiste pas à l’AiTM
Passwordless MFA	Authenticator passwordless, FIDO2, WHfB, certificate-based, passkeys	Élimine le mot de passe, mais Authenticator passwordless reste capturable par AiTM dans certaines configurations
Phishing-resistant MFA	FIDO2 security keys, Windows Hello for Business, certificate-based authentication, passkeys (device-bound, attestation)	Comptes à haut risque : administrateurs, direction, finance

Source : learn.microsoft.com — Overview of Microsoft Entra authentication strength.

Vous pouvez aussi créer une custom authentication strength si vous voulez restreindre davantage (par exemple n’autoriser que FIDO2 + WHfB, exclure certificate-based). En pratique, la strength built-in « Phishing-resistant MFA » couvre 95 % des besoins.

Étape 1 — Inventaire et préparation

Le plus gros risque dans ce chantier n’est pas technique, c’est le lockout administrateur. Si vous activez la politique avant d’avoir enrôlé toutes les clés, vous vous coupez de votre propre tenant. Préparation rigoureuse obligatoire.

Lister les rôles à protéger

Connectez-vous au Microsoft Entra admin center et exportez la liste des comptes ayant les rôles suivants :

Global Administrator
Privileged Role Administrator
Privileged Authentication Administrator
Conditional Access Administrator
Security Administrator
Exchange Administrator
SharePoint Administrator
User Administrator
Authentication Administrator
Helpdesk Administrator
Application Administrator
Cloud Application Administrator
Billing Administrator (souvent oublié)
Hybrid Identity Administrator

Microsoft recommande explicitement ces quatorze rôles dans le template policy-admin-phish-resistant-mfa. Ajoutez tout rôle personnalisé sensible spécifique à votre organisation.

Identifier les comptes break-glass

Vous devez disposer d’au moins deux comptes break-glass (emergency access accounts) :

nommage neutre type break-glass-01@tenant.onmicrosoft.com
Global Admin permanent
mot de passe long (32+ caractères), généré aléatoirement, imprimé et stocké dans deux coffres physiques distincts
exclus de toutes vos politiques de Conditional Access, y compris celle que vous allez créer
monitoring sur leur utilisation (alerte SIEM ou email à chaque sign-in)

Ces comptes sont l’assurance contre un lockout total. Leur mot de passe long compense l’absence de MFA dans certains scénarios de récupération. Ne stockez jamais ces mots de passe dans un gestionnaire SaaS qui dépend de votre Microsoft 365.

Identifier les profils sensibles non-admins

Au-delà des administrateurs, ciblez en deuxième vague :

direction générale et comité de direction (cibles BEC, fraude au président)
finance et comptabilité (validation de virements, accès bancaires)
RH et paie (données nominatives, IBAN salariés)
IT non-admin (souvent l’angle d’entrée latéral)
juridique (dossiers confidentiels)

Commander les clés FIDO2

Recommandation matérielle : YubiKey 5 Series, gamme solide, multi-protocole, supportée nativement par Microsoft. Modèles courants :

YubiKey 5 NFC (USB-A + NFC) : 50-60 € TTC, polyvalent
YubiKey 5C NFC (USB-C + NFC) : 60-70 € TTC, pour MacBooks et postes USB-C
YubiKey 5Ci (USB-C + Lightning) : 75-85 € TTC, pour les utilisateurs iPhone qui en ont besoin

Deux clés par administrateur, sans exception : une principale, une de secours dans un coffre. Pour les utilisateurs sensibles non-admins, une seule clé peut suffire avec un Microsoft Authenticator passkey en méthode de secours, selon votre niveau de tolérance au risque.

Alternatives valides : Feitian, Token2, Google Titan. Vérifiez que le modèle figure dans la liste FIDO Alliance des authentificateurs certifiés.

Préparer le Temporary Access Pass

Le TAP est un code à durée limitée (1 à 8 heures) émis par un administrateur pour permettre à un utilisateur de se connecter et d’enrôler ses méthodes fortes. Activez la politique TAP :

Microsoft Entra admin center → Protection → Authentication methods → Policies → Temporary Access Pass
Enable : Yes
Target : All users (ou un groupe restreint si vous préférez)
Configure : durée par défaut 1h, durée max 8h, longueur 8 caractères, usage unique conseillé

Source : learn.microsoft.com — Configure Temporary Access Pass.

Étape 2 — Activer FIDO2 dans la politique d’authentification

Avant qu’un utilisateur puisse enregistrer une clé, le tenant doit l’autoriser.

Microsoft Entra admin center → Protection → Authentication methods → Policies
Sélectionnez FIDO2 security key
Enable : Yes
Target : All users, ou un groupe restreint dans un premier temps si vous préférez piloter
Configure → Allow self-service set up : Yes (sans cela les utilisateurs ne peuvent pas s’enregistrer eux-mêmes via myaccount)
Configure → Enforce attestation : Yes. L’attestation FIDO2 vérifie cryptographiquement que la clé est un authentificateur génuine et non un logiciel rejouant un protocole. Activer ce paramètre garantit que seules des clés matérielles certifiées peuvent être enregistrées.
Configure → Restrict specific keys : optionnel mais recommandé en environnement régulé. Vous pouvez restreindre par AAGUID (l’identifiant unique du modèle) — par exemple, n’accepter que les AAGUID de YubiKey 5 NFC et YubiKey 5C NFC pour standardiser votre flotte.

Sauvegardez. La politique est immédiatement active.

Source : learn.microsoft.com — Enable FIDO2 security key method.

Étape 3 — Enrôler les administrateurs

Pour chaque administrateur, la séquence est la même :

L’admin émetteur (vous, depuis un autre compte admin) émet un TAP pour l’administrateur cible : Entra → Users → sélectionnez l’utilisateur → Authentication methods → Add authentication method → Temporary Access Pass. Communiquez le TAP via un canal sécurisé (jamais par email du tenant cible).
L’utilisateur ouvre une session privée sur myaccount.microsoft.com, se connecte avec son login et le TAP comme méthode de premier facteur.
Security info → Add sign-in method → Security key → suivez l’assistant. Branchez la première clé, touchez le capteur quand demandé, donnez-lui un nom explicite (« YubiKey principale - poste de travail »).
Recommencez avec la seconde clé, nommée « YubiKey secours - coffre ». Cette seconde clé doit être enregistrée immédiatement, pas remise à plus tard.
Vérifiez que l’utilisateur peut se connecter avec sa clé sur une nouvelle session privée.
Supprimez les méthodes faibles devenues inutiles : SMS, voice. Conservez Authenticator passwordless en méthode de secours si vous le souhaitez (mais elle ne sera pas acceptée par la politique Phishing-resistant MFA, ce qui est l’effet voulu).
Stockez physiquement la clé de secours dans un coffre.

Le TAP s’invalide après usage ou expiration.

Étape 4 — Créer la politique Conditional Access « Phishing-resistant MFA pour admins »

Vous voilà à l’étape pivot. Vous avez enrôlé toutes les clés. Vous avez vérifié vos break-glass. La politique peut être créée.

Configuration pas-à-pas

Microsoft Entra admin center → Protection → Conditional Access → Policies → New policy
Name : Require phishing-resistant MFA for admin roles (gardez le nommage Microsoft pour cohérence avec la doc)
Users → Include → Directory roles → cochez les quatorze rôles listés à l’étape 1
Users → Exclude → ajoutez vos comptes break-glass (vérifiez deux fois)
Target resources → Cloud apps → All resources (Microsoft a renommé en 2024 « All cloud apps », comportement identique)
Grant → Grant access → Require authentication strength → Phishing-resistant MFA
Enable policy → Report-only → Create

Phase de validation Report-only

Durée recommandée : une à deux semaines. Chaque jour, Entra → Sign-in logs → filtrez par Conditional Access status Report-only: Failure ou Report-only: Not satisfied. Un admin marqué « Not satisfied » n’a pas enrôlé de méthode phishing-résistante — corrigez avant de passer en On. Vérifiez aussi qu’aucun process automatisé utilisant un compte admin ne casse.

Bascule en production

Zéro Not satisfied pendant trois jours consécutifs et tous les admins connectés au moins une fois avec leur clé : ré-ouvrez la politique, Enable policy → On → Save. À partir de cet instant, tout login admin sans méthode phishing-résistante est bloqué. Les break-glass restent utilisables grâce à l’exclusion.

Avertissement. N’activez jamais cette politique sans avoir vérifié que 100 % des administrateurs ont au moins une méthode phishing-résistante enrôlée, que vos break-glass sont bien dans la liste d’exclusion, et que vous avez un accès physique au coffre des mots de passe break-glass. Un lockout total nécessite un ticket Microsoft Premier Support et 24 à 72 heures de récupération.

Étape 5 — Étendre aux comptes sensibles non-admins

Une fois les admins protégés, élargissez à la population sensible. Créez une seconde politique CA distincte (ne mélangez pas avec celle des admins, pour la lisibilité et la maintenance).

Name : Require phishing-resistant MFA - High-value users
Users → Include → un groupe Entra CA-PhishResistant-Users rempli par vagues
Target resources → All resources, ou plus finement Exchange Online + SharePoint + Teams
Grant → Require authentication strength → Phishing-resistant MFA

Approche progressive : vague 1 direction + finance, vague 2 RH + juridique, vague 3 IT non-admin + accès données clients, puis extension trimestrielle. Pour ces profils, une seule clé FIDO2 + un passkey Authenticator en sauvegarde est un compromis raisonnable.

Plan de communication minimum : email DG 2 semaines avant, FAQ interne, vidéo de 3 min montrant l’enrôlement, créneaux d’aide ouverts par le helpdesk les premiers jours, référents par service.

Étape 6 — Détecter les tentatives AiTM dans les logs Entra

FIDO2 bloque le vol de cookie par reverse proxy, mais ne dispense pas de surveiller : tous vos utilisateurs ne sont pas encore protégés, et d’autres vecteurs subsistent.

Sources de logs

Entra → Monitoring & health → Sign-in logs : sign-ins interactifs et non-interactifs
Entra → Identity Protection (P2 requis) : Risky users, Risky sign-ins, Risk detections
Microsoft 365 Defender → Incidents : corrélation multi-signal
Unified Audit Log dans Microsoft Purview : opérations boîtes, règles, partages

Signaux à corréler

Sekoia.io a documenté plusieurs patterns récurrents des sessions issues d’AiTM (blog.sekoia.io, Global analysis of AiTM phishing threats, 2025) :

User-Agent / Application ID incohérents : sign-in via Edge sur Windows, puis quelques secondes plus tard activité Graph API depuis un User-Agent Linux/PowerShell. Le proxy rejoue le cookie depuis sa propre infrastructure.
Sign-in successful suivi d’opérations depuis une IP différente : victime connectée depuis Paris, requête Outlook 30 secondes plus tard depuis l’IP du proxy (DigitalOcean, AWS, OVH).
Création d’une règle Outlook de transfert/suppression dans les minutes suivant le login (mots-clés « facture », « IBAN », « payment »). Détectable via Get-InboxRule ou Unified Audit Log opération New-InboxRule.
Risk levels Entra ID Protection : Anomalous token, Token issuer anomaly, Anonymous IP address, Atypical travel, Unfamiliar sign-in properties.
Ajout d’une méthode MFA par l’utilisateur juste après le login, ou consentement OAuth : tentatives de persistance.

Alertes

Microsoft Sentinel (ou SIEM tiers ingérant les logs Entra) permet de coder ces corrélations. À défaut : Defender → Settings → Email notifications pour les Risk events, Identity Protection → Sign-in risk policy (MFA si Medium, bloquer si High), et revue hebdomadaire des Risky sign-ins par un membre de l’équipe sécurité.

Étape 7 — Automatic Attack Disruption

Microsoft a introduit en mai 2023 une capacité de perturbation automatique dans Microsoft 365 Defender XDR. La fonction est GA depuis le 17 mai 2023 pour l’AiTM, étendue depuis aux BEC et ransomwares human-operated (learn.microsoft.com — Automatic attack disruption).

Defender XDR corrèle les signaux de Defender for Identity, for Endpoint, for Office 365, for Cloud Apps et Entra ID Protection. Au-delà d’un seuil de confiance élevé sur un scénario AiTM, le système agit sans intervention humaine : désactivation du compte compromis, révocation de toutes les sessions actives (équivalent Revoke-AzureADUserAllRefreshToken), blocage de l’appareil suspect via Defender for Endpoint. L’attaquant perd l’accès au cookie volé avant d’avoir eu le temps d’exfiltrer.

Prérequis : Defender for Office 365 Plan 2, Defender for Endpoint Plan 2, Entra ID P2. Couverture par défaut sur les tenants Defender XDR ; vérifiez Settings → Microsoft 365 Defender → Automated response.

Limites : la fonction agit après que l’attaquant a obtenu le cookie — elle limite les dégâts mais ne les évite pas, FIDO2 reste la prévention primaire. Faux positifs rares mais existants. Délai compromission-disruption de l’ordre de quelques minutes : un attaquant rapide peut tout de même créer une règle inbox avant l’intervention.

Étape 8 — Compléter avec Token Protection

Token Protection (anciennement « Token Binding ») est un contrôle Conditional Access plus récent qui lie cryptographiquement le jeton de session à l’appareil d’origine. Un attaquant qui aurait volé un cookie ne peut pas le rejouer depuis une autre machine.

Disponible en GA pour les applications Office natives Windows (Outlook, Teams, OneDrive, Word…) et progressivement étendu. Vérifiez l’état actuel sur learn.microsoft.com — Token protection in Conditional Access avant déploiement.

Activation : Conditional Access → New policy → Require token protection - Windows → Users : groupe pilote → Target resources : Exchange Online + SharePoint → Conditions : Device platforms Windows, Client apps Mobile apps and desktop clients → Session : Require token protection for sign-in sessions → Report-only puis On.

Bénéfice : un cookie volé sur le poste (malware) ou via AiTM résiduel ne fonctionne pas hors de l’appareil d’émission. Défense en profondeur contre le pass-the-cookie post-auth.

Couverture complète et limites

FIDO2 + Conditional Access + Defender XDR couvrent la grande majorité du risque AiTM, pas la totalité. Restent possibles, même avec une politique stricte :

Phishing par consentement OAuth. L’attaquant ne passe pas par le flow password + MFA. Il envoie à la victime un lien https://login.microsoftonline.com/common/oauth2/v2.0/authorize?... vers une application malveillante qui demande des scopes (Mail.Read, Files.ReadWrite.All). La victime, déjà loguée sur M365, clique « Accepter » : l’application reçoit un jeton OAuth, sans rejeu de mot de passe ni de MFA. Mesures : restreindre le consentement utilisateur (Allow user consent only for verified publishers), workflow d’approbation admin, audit régulier des apps OAuth. Sujet détaillé dans notre audit des applications OAuth Microsoft 365.

Device code phishing. Vecteur en hausse depuis 2024, exploité par UNK_AcademicFlare et TA2723 (helpnetsecurity.com, 2025). L’attaquant déclenche un flow device_code côté Microsoft, envoie le code à la victime par email/Teams en lui demandant de le saisir sur microsoft.com/devicelogin (page Microsoft légitime). La victime entre le code et complète son MFA, l’attaquant récupère un jeton sur son propre appareil. FIDO2 ne bloque pas ce flow car la signature est valide. Mitigation : politique CA bloquant le device_code flow pour les utilisateurs qui n’en ont pas besoin.

Compromission de l’appareil utilisateur. Si le poste est infecté par un infostealer (Lumma, RedLine, StealC), l’attaquant lit le cookie de session dans le navigateur après authentification légitime. FIDO2 n’intervient pas. Mitigations : Defender for Endpoint, App protection policies via Intune, Token Protection.

Verdict. FIDO2 est nécessaire et insuffisant. Il neutralise l’AiTM par reverse proxy — l’essentiel du volume d’attaques 2025-2026. Il s’empile avec restriction du consentement OAuth, App protection policies et device compliance via Intune, monitoring Defender XDR + Identity Protection, formation des utilisateurs. Pour la conformité, la directive NIS2 demande explicitement le MFA résistant au phishing pour les rôles privilégiés des entités essentielles et importantes.

Couche humaine : ce que FIDO2 ne fera jamais

Vous pouvez déployer FIDO2 partout, configurer Conditional Access au cordeau, activer Defender XDR et Token Protection. Un utilisateur peut toujours :

approuver une demande de consentement OAuth pour Mail.ReadWrite à une « application Microsoft Security Update » qui n’a rien de Microsoft
saisir un code device_code reçu via Teams par un attaquant se faisant passer pour le support IT
cliquer sur un lien dans un faux email SharePoint, ouvrir une pièce jointe, exécuter une macro
répondre à un email BEC en envoyant un IBAN sans vérification téléphonique

Ces actes ne sont pas bloqués par la cryptographie. Ils sont bloqués par un cerveau humain entraîné à ralentir, vérifier, douter.

Le taux de clic moyen sur une première simulation de phishing dans une PME française est de 30 à 40 % (rapport nophi.sh 2025). Après six mois de simulations mensuelles, ce taux descend en moyenne sous 8 %. C’est le delta entre une organisation qui a câblé sa technique et une organisation qui a entraîné ses équipes à reconnaître les vecteurs que la technique laisse passer.

Pour les références sur le phishing piloté par IA et les nouveaux vecteurs 2026, voir notre analyse attaques IA en entreprise 2026. Pour comprendre comment les attaques exploitent les outils internes, phishing via Teams et SharePoint. Et pour le détail des kits AiTM commerciaux, le glossaire EvilProxy.

FIDO2 a coupé la voie technique. Maintenant, entraînez la voie humaine. Lancez une simulation de phishing avec nophi.sh — scénarios AiTM, consentement OAuth, device code phishing inclus dans nos campagnes. Mesurez votre taux de clic réel, ciblez le micro-learning sur les utilisateurs qui en ont besoin.

FAQ

Mon MFA push protège-t-il contre les attaques AiTM ?

Non. Une notification push approuvée sur la fausse page de login est relayée en temps réel vers la vraie page Microsoft. L’attaquant capture le cookie de session émis après la validation et l’utilise pour se connecter sans rejouer le MFA. Idem pour le SMS et les codes TOTP : ce sont des secrets transmissibles. Seuls FIDO2, Windows Hello for Business, certificate-based authentication et passkeys résistent à cette technique car ils lient cryptographiquement la signature au domaine d’origine.

Combien coûtent des clés FIDO2 pour 10 administrateurs ?

Comptez deux clés par administrateur (principale plus secours), soit vingt clés. Une YubiKey 5 NFC coûte 50 à 70 euros TTC selon le revendeur et le format. Budget total : 1 000 à 1 400 euros pour dix administrateurs. Ajoutez le coût d’un coffre-fort ignifuge si vous n’en avez pas pour stocker les clés de secours. C’est l’investissement de sécurité avec le meilleur ratio efficacité-prix sur Microsoft 365. Voir aussi notre tarifs nophi.sh pour la couche humaine.

Faut-il acheter des YubiKey ou un autre modèle suffit ?

Toute clé certifiée FIDO2 fonctionne avec Entra ID. YubiKey domine le marché professionnel pour la solidité matérielle, la gamme (USB-A, USB-C, NFC, Lightning) et le support de protocoles supplémentaires (PIV, OpenPGP, OATH). Feitian et Token2 sont des alternatives moins chères, valides, mais moins répandues. Vérifiez l’AAGUID de tout modèle envisagé sur la liste des authenticators approuvés par votre politique Entra. N’achetez jamais de clés FIDO2 d’occasion.

Que faire si un administrateur perd sa clé FIDO2 ?

Il utilise sa clé de secours pour se connecter et signale immédiatement la perte à l’IT. L’administrateur Entra supprime la clé perdue dans Méthodes d’authentification puis émet un Temporary Access Pass pour enregistrer une nouvelle clé. Ne réutilisez jamais une clé retrouvée après avoir été déclarée perdue. Cette procédure est la raison pour laquelle deux clés sont obligatoires dès l’enrôlement, et pour laquelle un compte break-glass conserve un mot de passe long stocké en coffre.

Les passkeys remplacent-ils les YubiKey ?

Sur le papier, oui. Les passkeys (Microsoft Authenticator, Apple, Google) offrent la même résistance au phishing que les clés FIDO2 matérielles puisqu’elles s’appuient sur le même standard WebAuthn. En pratique, le déploiement en entreprise sur des flottes mixtes reste plus délicat : gestion de la perte de l’appareil, synchronisation entre plateformes, support iOS et Android entreprise. Microsoft pousse les passkeys via Authenticator depuis 2024 ; pour les administrateurs d’un tenant, les clés matérielles restent l’option la plus simple à auditer en 2026.

Conditional Access est-il inclus dans Microsoft 365 Business Standard ?

Non. Conditional Access et les Authentication Strengths nécessitent Microsoft Entra ID P1 minimum. Cette licence est incluse dans Microsoft 365 Business Premium, E3 et E5, ainsi que dans Entra ID P1/P2 acheté seul. Avec Business Standard, vous êtes limité aux Security Defaults, qui imposent le MFA classique mais ne permettent pas d’exiger une force d’authentification phishing-résistante. La montée à Business Premium est un préalable à toute stratégie sérieuse contre l’AiTM.

Comment savoir si un compte M365 a déjà été victime d’AiTM ?

Examinez dans Entra les sign-in logs des trente derniers jours pour ce compte. Cherchez : un sign-in successful suivi en quelques secondes d’opérations API depuis une IP différente ou un User-Agent inconnu, un Risk level marqué Anomalous token ou Token issuer anomaly, la création d’une règle Outlook de transfert vers une adresse externe juste après le login. Cumulez avec un audit des règles inbox (Get-InboxRule) et des consentements OAuth récents. Si vous trouvez un indicateur, révoquez toutes les sessions (Revoke-AzureADUserAllRefreshToken), réinitialisez le mot de passe, ré-enrôlez les méthodes MFA.

Microsoft Authenticator en mode passwordless est-il considéré comme phishing-resistant ?

Pas dans la built-in strength Phishing-resistant MFA de Microsoft Entra. Le mode passwordless de Microsoft Authenticator entre dans Passwordless MFA mais ne figure pas dans la liste phishing-résistante stricte (FIDO2, Windows Hello for Business, certificate-based, passkeys via Authenticator avec attestation device-bound). Microsoft a élargi cette catégorie en intégrant les passkeys Authenticator dans certaines configurations en 2025 ; vérifiez l’état exact de votre tenant dans Authentication strengths avant de vous appuyer dessus pour vos administrateurs. Pour mieux comprendre les attaques contre le MFA, voir le glossaire MFA fatigue et le concept Zero Trust.

Vous avez verrouillé la voie technique. La voie humaine reste à entraîner. Mesurez votre taux de clic réel — résultats en 24 heures, sans engagement.