Couverture MFA dans Entra ID : mesurer la réalité, pas l'intention

« Le MFA est activé chez nous. » C'est la réponse la plus fréquente quand on parle de sécurité Microsoft 365, et souvent la plus trompeuse. Une stratégie d'accès conditionnel peut exister sans couvrir tout le monde, un compte peut être inscrit sans jamais être sollicité, et un administrateur peut se contenter d'un SMS. Voici la méthode que j'applique pour mesurer la couverture réelle, en quatre questions.

1. Qui est inscrit ?

Le point de départ est le rapport d'inscription aux méthodes d'authentification. Il est disponible dans le centre d'administration Entra (Protection › Méthodes d'authentification › Détails de l'inscription des utilisateurs) et via Microsoft Graph, ce qui permet de l'automatiser :

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

$reg = Get-MgReportAuthenticationMethodUserRegistrationDetail -All

# Vue d'ensemble
$reg | Group-Object IsMfaRegistered | Select-Object Name, Count

# Les administrateurs sans MFA : à traiter en premier
$reg | Where-Object { $_.IsAdmin -and -not $_.IsMfaRegistered } |
  Select-Object UserPrincipalName, MethodsRegistered

Mais être inscrit ne veut pas dire être protégé : un compte peut avoir enregistré une méthode sans qu'aucune stratégie ne l'exige à la connexion.

2. Qui est réellement obligé ?

La couverture se joue dans l'accès conditionnel (ou dans les paramètres de sécurité par défaut, pour les petits tenants). L'ennemi, ce sont les exclusions : un groupe « temporaire » créé lors d'un déploiement, un compte de service, un compte de secours mal identifié.

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

Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State,
    @{n="Exclus (utilisateurs)"; e={ $_.Conditions.Users.ExcludeUsers -join ", " }},
    @{n="Exclus (groupes)";      e={ $_.Conditions.Users.ExcludeGroups -join ", " }}

Pour chaque exclusion, une question simple : qui l'a décidée, pourquoi, et jusqu'à quand ? Une stratégie en mode rapport uniquement ne protège personne : c'est utile pour tester, pas pour durer.

3. Avec quelles méthodes ?

Toutes les méthodes ne se valent pas. Le SMS et l'appel vocal restent vulnérables à l'hameçonnage en temps réel et au détournement de numéro. La colonne MethodsRegistered du rapport permet de repérer les comptes qui ne disposent que de ces méthodes.

• Pour tout le monde : Microsoft Authenticator avec correspondance de nombre, au minimum.
• Pour les administrateurs : des méthodes résistantes à l'hameçonnage (clés FIDO2 ou passkeys, Windows Hello Entreprise), imposées via une force d'authentification dans l'accès conditionnel.

4. Que disent les connexions ?

Dernière vérification, la plus honnête : les journaux de connexion. Le champ Exigence d'authentification indique si une connexion réussie s'est faite avec un seul facteur. Filtrer les connexions réussies en « authentification à facteur unique » sur les applications Microsoft 365 montre immédiatement les trous de la couverture, quels que soient les rapports d'inscription.

La checklist

1. Exporter le rapport d'inscription et traiter d'abord les administrateurs non inscrits.
2. Lister les exclusions de chaque stratégie d'accès conditionnel et leur donner un propriétaire et une échéance.
3. Garder deux comptes de secours (« break glass ») exclus, surveillés et documentés — et aucun autre.
4. Imposer des méthodes résistantes à l'hameçonnage aux rôles privilégiés.
5. Vérifier chaque mois les connexions réussies à facteur unique.

Mesurer la couverture MFA, ce n'est pas cocher une case : c'est confronter la configuration, les inscriptions et les connexions réelles. C'est exactement le genre de contrôle qui gagne à être automatisé et rejoué régulièrement.