Introduction : pourquoi cet article technique ?
Notre page gestion des identités et accès conditionnel explique pourquoi le contrôle des identités est la première ligne de défense de votre PME. Cet article va plus loin : il détaille comment fonctionne le moteur d'accès conditionnel de Microsoft Entra ID, quels mécanismes techniques protègent vos comptes et comment architecturer une politique Zero Trust réaliste pour une entreprise de 20 à 250 collaborateurs.
Selon le Verizon Data Breach Investigations Report 2025, 81 % des compromissions impliquent des identifiants volés ou faibles. L'identité est devenue le périmètre de sécurité. Ce n'est plus le pare-feu.
Le modèle Zero Trust : ne jamais faire confiance, toujours vérifier
Le paradigme fondamental
Le Zero Trust repose sur un principe simple mais radical : aucune connexion n'est de confiance par défaut, qu'elle vienne du bureau, du VPN ou du réseau interne. Chaque tentative d'accès est évaluée en temps réel selon un ensemble de signaux contextuels.
Concrètement, le modèle Zero Trust appliqué à l'identité fonctionne en trois étapes :
- Vérifier explicitement : chaque authentification est évaluée sur la base de multiples signaux (identité, appareil, localisation, comportement)
- Appliquer le moindre privilège : un utilisateur n'obtient que les droits strictement nécessaires, pour une durée limitée
- Présumer la compromission : le système se comporte comme si le réseau était déjà infiltré et surveille en continu les anomalies
Ce n'est pas une technologie unique. C'est une architecture qui orchestre l'accès conditionnel, le MFA, la détection de risques et la gestion des privilèges. Microsoft Entra ID est le point d'orchestration central pour les environnements Microsoft 365.
Pourquoi le VPN seul ne suffit plus
Un VPN accorde un accès réseau large après une authentification unique. Une fois connecté, l'utilisateur accède à tout le réseau interne — exactement ce que recherche un attaquant ayant compromis un compte. Le Zero Trust remplace cette logique par un contrôle par ressource, par session, en continu. Chaque accès à SharePoint, Teams, un ERP ou une application métier est évalué indépendamment.
Le moteur d'accès conditionnel Entra ID : évaluation des signaux
Architecture du moteur de décision
L'accès conditionnel Entra ID fonctionne comme un moteur de règles if/then évalué à chaque authentification. Il analyse simultanément cinq catégories de signaux :
1. Signaux liés à l'utilisateur
- Appartenance à un groupe ou rôle d'annuaire
- Niveau de risque utilisateur (calculé par Identity Protection)
- Statut du compte (actif, suspendu, compromis)
2. Signaux liés à la connexion (sign-in risk)
- Risque de la tentative de connexion en cours
- Adresse IP source (connue, anonyme, Tor, proxy)
- Détection de voyage impossible (connexion depuis Paris puis Lagos en 20 minutes)
3. Signaux liés à l'appareil
- Appareil inscrit dans la gestion de flotte mobile (MDM) ou joint à Entra ID
- Conformité de l'appareil (chiffrement BitLocker actif, antivirus à jour, OS patché)
- Type de plateforme (Windows, macOS, iOS, Android, Linux)
4. Signaux liés à l'application cible
- Application cloud spécifique (Exchange Online, SharePoint, application tierce)
- Action demandée (lecture, écriture, administration)
5. Signaux de localisation
- Plages IP de confiance (bureaux, datacenters)
- Pays d'origine de la connexion
- Réseau conforme ou non
Sur la base de cette évaluation, le moteur rend une décision : autoriser, bloquer, ou autoriser sous conditions (exiger le MFA, exiger un appareil conforme, limiter la session).
Exemple concret pour une PME
Voici une politique réaliste pour une PME de 50 collaborateurs :
| Scénario | Signaux évalués | Décision |
|---|---|---|
| Connexion depuis le bureau, PC conforme | IP de confiance + appareil géré | Autoriser (MFA non requis) |
| Connexion depuis le domicile, PC personnel | IP inconnue + appareil non géré | Exiger MFA + limiter à l'accès web uniquement |
| Connexion depuis un pays non autorisé | Géolocalisation hors périmètre | Bloquer |
| Connexion avec risque élevé détecté | Sign-in risk = high | Exiger MFA résistant au phishing (FIDO2) |
| Accès admin au portail Azure | Rôle = Global Admin | Exiger MFA + appareil conforme + PIM activé |
Hiérarchie des méthodes MFA : toutes ne se valent pas
Du plus faible au plus résistant
Toutes les méthodes d'authentification multifacteur ne se valent pas. Microsoft les classe désormais par force d'authentification (Authentication Strength) :
SMS (force faible) : un code à 6 chiffres envoyé par SMS. Vulnérable au SIM swapping (l'attaquant convainc l'opérateur de transférer le numéro), à l'interception SS7 et au phishing en temps réel (l'utilisateur saisit le code sur un faux site, l'attaquant le rejoue instantanément). Microsoft et l'ANSSI déconseillent le SMS comme seul facteur secondaire depuis 2023.
TOTP — Time-based One-Time Password (force moyenne) : une application (Microsoft Authenticator, Google Authenticator) génère un code toutes les 30 secondes, basé sur un secret partagé et l'horodatage. Plus sûr que le SMS car non interceptable sur le réseau, mais toujours vulnérable au phishing en temps réel : l'utilisateur peut saisir le code sur un faux site.
Push notification (force moyenne-haute) : Microsoft Authenticator affiche une notification avec un numéro à confirmer (number matching). Résiste au phishing simple, mais reste vulnérable aux attaques de fatigue MFA (l'attaquant envoie des dizaines de notifications jusqu'à ce que l'utilisateur approuve par lassitude). Le number matching réduit ce risque.
FIDO2 / Passkeys (force maximale) : c'est la méthode recommandée par Microsoft, l'ANSSI et le NIST. Et pour cause : elle est résistante au phishing par conception.
Pourquoi FIDO2 est résistant au phishing : explication technique
FIDO2 repose sur la cryptographie asymétrique avec liaison d'origine :
- Lors de l'enregistrement, la clé de sécurité (YubiKey, Windows Hello, Touch ID) génère une paire de clés unique pour le domaine
login.microsoftonline.com - La clé publique est envoyée à Microsoft, la clé privée reste sur l'appareil (elle n'en sort jamais)
- Lors de l'authentification, le navigateur envoie un challenge qui inclut l'origine (le domaine exact du site)
- La clé de sécurité ne signe le challenge que si l'origine correspond au domaine enregistré
- Un site de phishing sur
login-microsoftonline.com(avec un tiret) ne déclenchera jamais la signature
Cette liaison d'origine est gérée par le navigateur au niveau du protocole WebAuthn — l'utilisateur n'a aucune décision à prendre. C'est une protection cryptographique, pas comportementale. L'erreur humaine est éliminée de l'équation.
Pour compléter votre stratégie d'identifiants, un gestionnaire de mots de passe professionnel gère les secrets applicatifs qui ne supportent pas encore le passwordless.
Identity Protection : détection de risques en temps réel
Les signaux analysés par le moteur de risques
Entra ID Identity Protection (inclus dans Entra ID P2) analyse en temps réel des milliards de signaux issus de l'écosystème Microsoft pour calculer un score de risque par utilisateur et par connexion :
Risques liés à la connexion (sign-in risk) :
- Voyage impossible : connexion depuis Paris à 10h puis depuis Singapour à 10h30
- Adresse IP anonyme : connexion via Tor, VPN public ou proxy anonymisant
- Adresse IP malveillante : IP répertoriée dans les bases de threat intelligence Microsoft
- Propriétés de connexion inhabituelles : navigateur, OS ou localisation jamais observés pour cet utilisateur
- Password spray détecté : tentatives de connexion avec des mots de passe courants sur plusieurs comptes
Risques liés à l'utilisateur (user risk) :
- Identifiants divulgués : le couple email/mot de passe détecté dans des bases de données de fuites (dark web monitoring)
- Anomalie de jeton : durée de vie, émetteur ou claims inhabituels dans le jeton d'authentification
- Activité suspecte : modifications de boîte aux lettres, règles de transfert créées automatiquement
Ces scores alimentent directement les politiques d'accès conditionnel. Une PME peut configurer : "si le risque de connexion est moyen, exiger le MFA ; si le risque est élevé, bloquer et forcer la réinitialisation du mot de passe."
La détection de menaces est renforcée lorsqu'elle est corrélée avec un EDR/XDR/MDR qui couvre les endpoints et qu'un SOC managé surveille les alertes 24/7.
Privileged Identity Management (PIM) : l'administration just-in-time
Le problème des administrateurs permanents
Dans une PME typique, le responsable IT est Global Admin en permanence. Son compte a les clés du royaume — 24 heures sur 24, 7 jours sur 7. Si ce compte est compromis (phishing, infostealer, session hijacking), l'attaquant obtient immédiatement le contrôle total du tenant Microsoft 365.
Selon IBM Security, le coût moyen d'une compromission impliquant des identifiants privilégiés est de 4,55 millions d'euros en 2025 — soit 20 % de plus que la moyenne globale.
Comment PIM résout le problème
Privileged Identity Management supprime les droits permanents et les remplace par une activation à la demande :
- Le responsable IT est éligible au rôle Global Admin (mais ne l'a pas activement)
- Quand il a besoin d'effectuer une action administrative, il demande l'activation via le portail PIM
- Il fournit une justification obligatoire ("Modification de la politique de rétention SharePoint")
- Selon la configuration, un approbateur valide la demande (le dirigeant, un second IT, un prestataire)
- Le rôle est activé pour une durée limitée (typiquement 1 à 4 heures)
- À l'expiration, les droits sont automatiquement retirés
- Chaque activation est journalisée avec justification, durée et actions effectuées
Pour une PME, PIM élimine le scénario catastrophe de l'administrateur compromis en dehors des fenêtres d'activation. C'est le principe du moindre privilège appliqué aux comptes les plus sensibles.
Authentication Strength : imposer la bonne méthode MFA par scénario
Une nouveauté d'Entra ID sous-exploitée
Les politiques d'Authentication Strength permettent de définir quelles méthodes MFA sont acceptables pour un scénario donné, au lieu de simplement exiger "un MFA quelconque".
Exemples de configuration :
| Scénario | Authentication Strength requise |
|---|---|
| Accès standard à Microsoft 365 | MFA standard (TOTP, Push ou FIDO2) |
| Accès aux données financières (SharePoint confidentiel) | MFA résistant au phishing (FIDO2 uniquement) |
| Administration Azure / Entra ID | MFA résistant au phishing + appareil conforme |
| Enregistrement d'une méthode MFA (bootstrap) | Temporary Access Pass (TAP) |
Cette granularité est essentielle : exiger FIDO2 pour tout le monde dès le premier jour n'est pas réaliste. L'Authentication Strength permet un déploiement progressif en réservant les exigences maximales aux scénarios à haut risque, tout en sécurisant l'ensemble de l'environnement Microsoft 365.
Protocoles legacy : pourquoi IMAP, POP3 et SMTP Basic Auth doivent disparaitre
Le problème technique
Les protocoles de messagerie historiques (IMAP, POP3, SMTP avec authentification basique) transmettent les identifiants en clair (encodés en Base64, ce qui n'est pas du chiffrement). Plus grave encore : ils ne supportent pas le MFA.
Concrètement, si un attaquant obtient le mot de passe d'un utilisateur, il peut se connecter via IMAP depuis n'importe où dans le monde, sans déclencher aucune vérification supplémentaire. L'accès conditionnel ne peut pas protéger ce qui ne passe pas par le flux d'authentification moderne (OAuth 2.0).
Selon Microsoft, les comptes qui autorisent l'authentification legacy sont 3 fois plus susceptibles d'être compromis. C'est la porte dérobée que les attaquants cherchent en premier lors d'une campagne de credential stuffing.
La solution
L'accès conditionnel permet de créer une politique dédiée :
- Cible : tous les utilisateurs
- Applications clientes : Exchange ActiveSync, Other clients (IMAP, POP3, SMTP)
- Décision : bloquer
Cette politique doit être déployée progressivement : identifiez d'abord les applications métier qui utilisent encore ces protocoles (imprimantes multifonctions, anciens CRM, scanners), migrez-les vers OAuth 2.0 ou des comptes de service dédiés, puis bloquez.
Continuous Access Evaluation (CAE) : révocation en quasi-temps réel
La limite des jetons classiques
Dans le modèle OAuth 2.0 traditionnel, un jeton d'accès a une durée de vie fixe (1 heure par défaut pour Microsoft 365). Pendant cette heure, même si le compte est désactivé, le mot de passe changé ou l'utilisateur déconnecté d'Entra ID, le jeton reste valide. L'attaquant a une heure de libre.
Comment CAE change la donne
Le Continuous Access Evaluation établit un canal de communication permanent entre Entra ID et les services Microsoft 365 (Exchange Online, SharePoint, Teams). Quand un événement critique survient :
- Compte désactivé ou supprimé
- Mot de passe modifié
- MFA réinitialisé par un administrateur
- Localisation IP qui change de manière suspecte
Le service cible est notifié en quelques minutes et invalide le jeton immédiatement, sans attendre son expiration naturelle. Pour un offboarding, cela signifie que l'ancien collaborateur perd l'accès à sa messagerie en 2 à 5 minutes au lieu d'une heure.
Le CAE est activé par défaut sur les tenants Microsoft 365 depuis 2024 et ne nécessite aucune configuration supplémentaire. C'est une amélioration silencieuse mais fondamentale pour la posture de sécurité.
Conformité DORA et NIS2 : ce que couvre l'accès conditionnel
Cartographie des exigences
Les réglementations européennes DORA (secteur financier) et NIS2 (entités essentielles et importantes) imposent des mesures spécifiques que l'accès conditionnel Entra ID adresse directement :
| Exigence réglementaire | Capacité Entra ID correspondante |
|---|---|
| Authentification forte pour tous les accès (NIS2 Art. 21) | Accès conditionnel + MFA obligatoire |
| Gestion des accès privilégiés (DORA Art. 9) | Privileged Identity Management (PIM) |
| Surveillance continue des accès (NIS2 Art. 21) | Identity Protection + CAE |
| Principe du moindre privilège (DORA Art. 9) | Accès conditionnel basé sur les rôles + PIM |
| Journalisation des accès (NIS2 Art. 21) | Journaux d'audit Entra ID (rétention 30j P1, illimitée avec Log Analytics) |
| Blocage des protocoles non sécurisés (DORA Art. 9) | Politique de blocage legacy authentication |
| Détection des compromissions d'identité (NIS2 Art. 21) | Identity Protection (user risk + sign-in risk) |
| Révocation rapide des accès (DORA Art. 9) | CAE + SCIM provisionnement/déprovisionnement |
L'ANSSI recommande dans son guide d'hygiène informatique (42 mesures) l'utilisation de l'authentification forte et la restriction des privilèges d'administration — deux piliers directement couverts par Entra ID P2.
Comparatif des licences : Entra ID P1 vs P2 vs MFA standalone
| Fonctionnalité | MFA standalone (incl. M365 Business) | Entra ID P1 (incl. M365 Business Premium) | Entra ID P2 |
|---|---|---|---|
| MFA (SMS, TOTP, Push, FIDO2) | Oui | Oui | Oui |
| Accès conditionnel | Non (defaults de sécurité uniquement) | Oui (complet) | Oui (complet) |
| Authentication Strength | Non | Oui | Oui |
| Blocage legacy authentication | Partiel (defaults) | Oui (granulaire) | Oui (granulaire) |
| Identity Protection (sign-in risk) | Non | Non | Oui |
| Identity Protection (user risk) | Non | Non | Oui |
| Privileged Identity Management | Non | Non | Oui |
| Revues d'accès automatisées | Non | Non | Oui |
| Continuous Access Evaluation | Oui | Oui | Oui |
| Prix indicatif/utilisateur/mois | Inclus dans M365 | ~6 EUR (ou inclus Business Premium) | ~9 EUR |
Pour une PME de 30 à 100 utilisateurs soumise à NIS2 ou DORA, Entra ID P2 est le choix rationnel. Le surcoût de 3 EUR/utilisateur/mois par rapport à P1 est dérisoire face au coût d'une compromission d'identité — estimé à 165 EUR par enregistrement compromis selon le rapport IBM Cost of a Data Breach 2025.
Conclusion
L'accès conditionnel Entra ID n'est pas une case à cocher. C'est le moteur central d'une stratégie Zero Trust qui transforme chaque authentification en une décision de sécurité contextuelle. Combiné à Identity Protection, PIM et des méthodes MFA résistantes au phishing comme FIDO2, il constitue la fondation sur laquelle construire toute votre posture cybersécurité.
Le déploiement n'a pas besoin d'être un projet titanesque. En 2 à 3 jours, une PME peut passer d'un tenant Microsoft 365 avec des defaults de sécurité basiques à une architecture Zero Trust opérationnelle : accès conditionnel granulaire, MFA imposé, protocoles legacy bloqués, administration just-in-time et détection de risques en temps réel.
Si vous souhaitez évaluer votre posture actuelle, nous proposons un audit gratuit de 30 minutes de votre configuration Entra ID. Contactez-nous.
Cet article est le complément technique de notre page Gestion des identités et accès conditionnel. Pour une vue d'ensemble orientée business, consultez-la directement.






