MFA : les erreurs qui cassent la sécurité en production

On a tous déjà entendu la phrase « activez la MFA et vous êtes tranquilles ». Et oui, la MFA (authentification multifacteur) fait partie des meilleurs rapports effort vs gain en sécurité.

Sauf que. En production, la MFA peut être… fragile. Pas à cause de la techno, mais à cause des choix d’implémentation, des exceptions, des flux hérités, et des petites habitudes « juste pour dépanner » qui finissent par devenir permanentes.

Dans cet article, je liste les erreurs qu’on voit le plus souvent sur le terrain (et en labs), celles qui donnent une illusion de sécurité tout en laissant une porte entrouverte. Parfois grande ouverte.

Petit rappel de contexte pour les étudiants et admins qui suivent le blog BTS SIO2 SISR Tech Lab (et pour tous les autres aussi) : la MFA n’est pas un produit, c’est un contrôle. Et comme tous les contrôles, il se contourne si vous laissez un chemin plus simple à côté.

La première erreur : croire que « MFA activée » veut dire « MFA imposée »

Ça paraît idiot dit comme ça, mais c’est probablement la source numéro 1 des incidents.

On active la MFA dans l’outil (Microsoft Entra ID, Google Workspace, Okta, Keycloak, un VPN, un bastion, un PAM). Puis on teste sur deux comptes. Ça marche. On se dit ok.

Sauf que dans la vraie vie, l’activation n’implique pas forcément l’application sur tous les flux :

• connexions interactives vs non interactives
• navigateur vs client lourd
• authentification moderne vs legacy
• API tokens
• comptes de service
• comptes breakglass
• exceptions géographiques
• accès via proxy inverse ou SSO

Donc oui, MFA est « on », mais elle n’est pas forcée là où ça compte.

À vérifier, vraiment : quels flux passent sans challenge MFA aujourd’hui, maintenant. Pas en théorie.

L’erreur « SMS » : le facteur faible devenu par défaut

Le SMS est encore partout. Parce que c’est simple. Parce que ça marche. Parce que « tout le monde a un téléphone ».

Et pourtant, c’est un facteur faible, avec des risques connus :

• SIM swapping (détournement de numéro)
• interception SS7 (plus rare, mais réel)
• redirection d’appels, portage frauduleux
• phishing en temps réel : l’attaquant vous fait entrer le code sur une fausse page

Le SMS peut être acceptable en transition, mais le danger c’est quand il devient le seul facteur et qu’on n’a rien prévu pour évoluer.

Préférez, quand c’est possible :

• application TOTP (Google Authenticator, Aegis, FreeOTP, Authy avec prudence)
• notifications push avec number matching
• FIDO2 / passkeys (clé physique ou passkey sur téléphone)
• certificat sur poste géré (selon contexte)

Les politiques « rappel MFA tous les 30 jours » : confortable, mais dangereux

On règle un « se souvenir de moi » pendant 30 jours, 60 jours, parfois 90. L’argument : réduire la friction.

Le problème : vous créez une fenêtre d’exploitation énorme en cas de vol de session.

Aujourd’hui, les attaques ne ciblent pas juste le mot de passe. Elles ciblent :

• le cookie de session
• le token de refresh
• la machine déjà connectée
• le navigateur synchronisé

Avec un infostealer, un attaquant n’a même plus besoin de votre MFA si la session est valide. Donc si vous réduisez trop la fréquence de challenge, vous facilitez la vie des voleurs de sessions.

Bon compromis fréquent :

• challenge MFA plus fréquent pour admin, accès externe, nouvel appareil, risque élevé
• session courte pour les comptes privilégiés
• sign-in risk et device compliance si vous avez l’écosystème (Entra, Intune, etc.)

Ne pas bloquer les protocoles legacy : le contournement classique

C’est vieux, mais ça marche encore trop bien.

IMAP, POP, SMTP AUTH, vieux clients Office, authentification Basic sur certains services. Ces protocoles n’embarquent pas la MFA moderne. Résultat : si vous autorisez encore les flux legacy, un attaquant peut tester des identifiants et passer « sous » la MFA.

Vous voyez le pattern :

• MFA pour le portail web
• mais accès mail en Basic toujours actif
• ou un vieux service qui accepte username/password sans challenge

Donc, checklist :

• désactiver l’authentification Basic partout où possible
• surveiller les logs d’auth legacy
• migrer vers OAuth2 / Modern Auth
• utiliser des « app passwords » seulement si vous n’avez vraiment pas le choix… et même là, c’est souvent une dette qui dure

Les comptes de service avec MFA… ou sans, mais avec des droits énormes

Les comptes de service sont une zone grise. Souvent non interactifs, donc MFA impossible telle quelle. Et pourtant, ils finissent avec :

• des droits sur des bases
• des accès à des API
• parfois des rôles admin sur un tenant cloud
• des secrets jamais renouvelés

La vraie erreur, c’est de traiter ces comptes comme des utilisateurs.

Bonnes pratiques (selon environnements) :

• remplacer par des identités managées (managed identities), service principals, workload identity
• mettre les secrets dans un coffre (Vault, Key Vault, Secrets Manager)
• rotation régulière
• droits minimaux
• logs et alertes
• séparation stricte prod vs préprod

Et surtout : pas de compte de service « fourre-tout » qui sert à tout parce que « c’est pratique ».

L’erreur breakglass : le compte d’urgence qui devient le compte normal

Le compte breakglass, c’est vital. Si votre système MFA tombe, si vous vous bloquez avec une policy trop agressive, il vous faut un accès de secours.

Mais il y a deux pièges :

1. Vous le laissez sans MFA et sans contrôle
2. Vous l’utilisez au quotidien parce que « plus simple »

Le breakglass doit être :

• très rarement utilisé
• surveillé comme un événement critique
• protégé par un mot de passe très long, stocké offline (coffre physique, procédure)
• exclu de certaines policies pour l’urgence, oui, mais avec compensations : IP restreintes, accès conditionnel, alerte immédiate, journalisation renforcée

Et idéalement, deux comptes breakglass, chacun stocké séparément, pour éviter le point de défaillance unique.

Les exceptions partout : « juste pour ce site », « juste pour ce pays », « juste pour cet utilisateur »

La MFA en production meurt souvent de mille exceptions.

Le scénario typique :

• un VIP ne veut pas de MFA
• un prestataire n’arrive pas à se connecter
• une imprimante scan to mail casse
• un vieux logiciel industriel ne supporte pas le navigateur moderne
• et hop, on exclut un utilisateur, puis un groupe, puis une application

Au bout de 6 mois, votre policy MFA ressemble à un fromage suisse.

À la place :

• comprendre la cause (legacy, device non géré, app mal configurée)
• isoler le flux (réseau, bastion, VDI)
• limiter l’exception : durée, périmètre, justification, validation
• documenter, ticket, date de fin
• auditer régulièrement les exclusions

Une règle simple : toute exception doit faire mal. Si elle ne fait pas un peu mal, elle va rester.

L’erreur « MFA partout » sans penser au parcours utilisateur : fatigue, contournements, shadow IT

Ça peut sembler contradictoire, mais un déploiement MFA trop agressif, mal expliqué, crée des contournements humains :

• utilisateurs qui valident tout sans regarder (push fatigue)
• utilisateurs qui enregistrent leur session sur un poste partagé
• équipes qui se créent des comptes communs
• partage de codes TOTP ou de téléphone
• outils non validés parce que « celui là marche sans MFA »

La solution n’est pas de retirer MFA, c’est de la rendre robuste et acceptable :

• number matching sur push
• géolocalisation ou contexte affiché dans la demande
• formation courte, exemples d’arnaques
• support prêt le jour J
• procédure claire pour perte de téléphone

Et oui, parfois il faut y aller en étapes. Les projets sécurité échouent souvent sur l’adoption, pas sur la techno.

Les flux d’inscription MFA non sécurisés : l’attaque avant la MFA

Une MFA peut être solide… mais si l’attaquant peut enregistrer son propre facteur, c’est fini.

Points de vigilance :

• réinitialisation de mot de passe trop facile
• helpdesk qui réinitialise MFA sur simple demande
• vérification d’identité faible
• absence d’alerte quand un nouveau facteur est ajouté
• possibilité d’ajouter un numéro SMS sans contrôle

Bon réflexe :

• exiger une vérification forte pour l’enrôlement et le reset MFA
• alerter l’utilisateur (mail, notification) lors d’ajout ou changement de facteur
• logs d’administration surveillés
• processus helpdesk : questions, preuve, validation manager selon sensibilité

Dans un monde idéal, l’enrôlement initial se fait sur un appareil déjà de confiance, ou en présentiel, ou avec une identité vérifiée.

L’absence de phishing resistant MFA : le piège du proxy en temps réel

Même avec TOTP, même avec push, vous pouvez être phishé.

Les kits de phishing modernes utilisent des proxies inverses : l’utilisateur se connecte sur une fausse page, le kit relaie en temps réel vers le vrai site, récupère cookie et session, et vous êtes dedans. MFA validée, mais validée pour l’attaquant aussi.

La réponse, quand possible :

• FIDO2 / WebAuthn (phishing resistant)
• passkeys
• policies qui bloquent les connexions suspectes et imposent des facteurs résistants au phishing pour admins
• réduction de durée de session, surtout sur comptes sensibles
• détection de sessions anormales

On ne bascule pas tout en FIDO2 en un après midi, ok. Mais il faut au moins l’envisager pour les comptes à privilèges.

Oublier la MFA sur les accès internes « parce que c’est le LAN »

Celle là est encore fréquente en PME ou en campus.

« On est derrière le firewall. »
« C’est que pour le réseau interne. »
« Personne d’externe ne peut. »

Sauf que :

• compromission d’un poste interne via phishing
• VPN d’un utilisateur déjà infecté
• Wi-Fi invité mal isolé
• rebond via un serveur exposé

Donc, même en interne, au minimum :

• MFA pour accès admin (hyperviseur, firewall, AD, vCenter, iDRAC, consoles)
• MFA pour accès distant, évidemment
• segmentation réseau + bastion
• journalisation

Ne pas tester les scénarios de panne : MFA indisponible, téléphone perdu, horloge TOTP décalée

En prod, il y a des jours où :

• l’IdP a une panne
• le service push a un incident
• l’utilisateur casse son téléphone
• le TOTP ne marche plus (heure du device)
• le roaming bloque les SMS

Si vous n’avez pas de procédure, vous allez improviser. Et l’impro, en sécurité, ça donne des contournements permanents.

À prévoir :

• procédure de récupération, documentée
• stock de clés FIDO2 de secours pour les profils critiques
• codes de récupération imprimables (à stocker correctement)
• support helpdesk formé
• tests réguliers, pas juste un document dans un dossier

Ne pas surveiller : MFA sans logs, c’est un verrou sans alarme

Vous pouvez avoir la meilleure MFA du monde. Si personne ne surveille :

• les tentatives échouées en rafale
• les connexions depuis pays atypiques
• l’ajout de nouveaux facteurs
• les désactivations MFA
• les exceptions appliquées

… vous apprendrez le problème après l’incident.

Minimum viable côté supervision :

• alertes sur ajout de facteur / reset MFA
• alertes sur connexion admin hors plage habituelle
• détection de password spraying
• corrélation avec EDR si possible

C’est typiquement un bon sujet de mini lab sur BTS SIO2 SISR Tech Lab : partir des logs Entra, Google, ou VPN, et construire des alertes simples, puis les faire évoluer.

Les comptes admins qui utilisent la même MFA que le compte perso

Un grand classique. Un admin a :

• un compte utilisateur normal
• un compte admin (ou des rôles élevés)

Et les deux sont protégés par le même téléphone, la même app, parfois le même numéro. En soi ce n’est pas toujours « interdit ». Mais ça réduit la séparation.

Recommandations réalistes :

• comptes séparés, clairement
• politiques plus strictes sur admin (facteur phishing resistant si possible)
• pas de session longue pour admin
• poste admin dédié ou au moins navigateur dédié
• accès admin via bastion ou PAW (selon moyens)

L’objectif, c’est de réduire les scénarios où un simple vol de poste ou de session donne immédiatement l’admin.

La MFA sans hygiène mot de passe : additionner deux faiblesses ne fait pas une force

Oui, la MFA compense beaucoup. Mais si vos mots de passe sont :

• réutilisés
• faibles
• compromis dans des fuites
• partagés

… vous augmentez le volume d’attaques et vous testez les limites de votre MFA.

Donc, le socle reste important :

• mots de passe uniques et longs (gestionnaire)
• désactivation des comptes inactifs
• protection contre password spraying
• politique de verrouillage intelligente
• détection de credentials compromis

Et si vous pouvez : passkeys. Ça supprime une grosse partie des problèmes de mots de passe, point.

Petit plan d’action simple (et vraiment utile) pour la prod

Si vous deviez repartir de cet article avec une checklist courte, la voilà :

1. Vérifier quels flux contournent la MFA (legacy, API, clients).
2. Bloquer l’auth legacy, ou au minimum la réduire drastiquement.
3. Réduire la durée des sessions sur comptes sensibles.
4. Sécuriser l’enrôlement et le reset MFA (helpdesk compris).
5. Limiter les exceptions, les documenter, les expirer.
6. Passer les admins sur FIDO2 / phishing resistant si possible.
7. Mettre de la supervision et des alertes sur les événements MFA.
8. Tester les scénarios de panne et de récupération.

Si vous êtes en train de monter une infra de lab, ou de préparer un sujet de sécurisation pour votre alternance, c’est typiquement le genre de thème très concret à documenter. Vous pouvez d’ailleurs retrouver d’autres articles orientés pratique sur https://sio1blog.blogspot.com/ et vous en servir comme base de procédure ou de compte rendu.

Conclusion : la MFA, c’est bien, mais la MFA bien faite, c’est autre chose

La MFA reste indispensable. Mais en production, elle est souvent affaiblie par des détails : une exception, un vieux protocole, une session trop longue, un reset trop facile.

Ce qui protège vraiment, c’est l’ensemble : MFA + politiques + facteurs solides + supervision + procédures. Et un peu de discipline. Oui, ce mot là.

Si vous voulez, je peux aussi proposer une version « audit » sous forme de tableau (contrôle, risque, test, remédiation) utilisable en TP ou en checklist d’entreprise, dans l’esprit des labs BTS SIO SISR.

Questions fréquemment posées

Qu'est-ce que la MFA et pourquoi est-elle importante en sécurité informatique ?

La MFA (authentification multifacteur) est un contrôle de sécurité qui combine plusieurs méthodes d'authentification pour renforcer la protection des comptes. Elle offre un excellent rapport effort vs gain en sécurité en empêchant l'accès non autorisé même si le mot de passe est compromis.

Pourquoi activer la MFA ne signifie pas forcément qu'elle est imposée partout ?

Activer la MFA dans un outil ne garantit pas son application sur tous les flux. Certains accès comme les connexions non interactives, les API tokens, ou les comptes breakglass peuvent contourner la MFA si elle n'est pas bien configurée et forcée partout où c'est nécessaire.

Quels sont les risques liés à l'utilisation du SMS comme facteur d'authentification ?

Le SMS est considéré comme un facteur faible car il est vulnérable au SIM swapping, interception SS7, redirection d'appels frauduleuse et phishing en temps réel. Il peut être utilisé temporairement, mais il ne doit pas rester le seul facteur d'authentification.

Quels facteurs d'authentification sont recommandés plutôt que le SMS ?

Il est préférable d'utiliser des applications TOTP (Google Authenticator, Aegis), des notifications push avec number matching, des clés FIDO2/passkeys physiques ou sur téléphone, ou encore des certificats sur postes gérés selon le contexte pour une meilleure sécurité.

Pourquoi faut-il être prudent avec les politiques « se souvenir de moi » ou rappel MFA tous les 30 jours ?

Ces politiques réduisent la fréquence des challenges MFA pour diminuer la friction utilisateur, mais elles créent une grande fenêtre d'exploitation en cas de vol de session. Les attaquants peuvent utiliser des tokens ou sessions valides pour accéder sans MFA.

Comment éviter que les protocoles legacy contournent la MFA ?

Il faut désactiver l'authentification Basic partout où possible, surveiller les logs d'authentification legacy, migrer vers OAuth2/Modern Auth et limiter l'utilisation des app passwords. Ces mesures empêchent les accès non sécurisés qui ignorent la MFA.