L’authentification multifacteur (MFA) est une approche qui exige des utilisateurs qu’ils vérifient leur identité à l’aide de plusieurs méthodes d’authentification distinctes avant de leur accorder l’accès aux ressources demandées. Ce processus à plusieurs niveaux évite de se fier à un seul facteur, comme un mot de passe, qui peut être facilement volé, deviné ou divulgué.

La menace permanente du vol d’identifiants rend le MFA essentiel. Le rapport Data Breach Investigations Report (DBIR) 2025 de Verizon révèle que l’utilisation frauduleuse d’identifiants reste le principal vecteur d’accès initial lors de brèches, représentant 22 % des cas. L’implémentation d’un MFA fort permet de réduire les risques d’accès non autorisé résultant de la compromission d’identifiants.

Le MFA vérifie l’identité à l’aide de facteurs appartenant à trois catégories, chacune validant l’identité par un mécanisme différent.

La combinaison de facteurs relevant de plusieurs catégories augmente le niveau d’assurance :

Une information que vous connaissez (connaissance)

• Mots de passe
• Codes PIN
• Séquences mémorisées

Quelque chose que vous possédez (possession)

• Applications d’authentification TOTP
• Notifications push
• Clés FIDO2/WebAuthn
• Cartes à puce

Une caractéristique qui vous est propre (inhérence)

• Empreinte digitale
• Reconnaissance faciale
• Scan de l’iris

La force du MFA provient de la combinaison de facteurs issus de catégories distinctes (deux mots de passe ne créent pas une authentification multifacteur).

Chaque type de facteur repose sur des mécanismes et protections différents pour vérifier l’identité en toute sécurité. L’implémentation correcte du MFA nécessite une compréhension des détails techniques et des considérations de sécurité associés aux facteurs de connaissance, de possession et d’inhérence.

Facteurs de connaissance

• La validation des mots de passe et des codes PIN fonctionne en comparant la saisie d’un utilisateur à un hachage préenregistré. Le système génère le hachage à l’aide d’algorithmes adaptatifs, gourmands en mémoire ou en puissance processeur (Argon2, bcrypt ou PBKDF2) avec des clés uniques et des facteurs travail conformes aux directives de l’OWASP et au document SP 800-63B 5.1.1.2 du NIST.
• Les questions de sécurité reposent sur des informations privées connues uniquement de l’utilisateur. Ce mécanisme est intrinsèquement faible, car les attaquants peuvent souvent obtenir des réponses à partir de sources de données publiques, par des tactiques de social engineering ou via des brèches de données.

Facteurs de possession

• Les mots de passe à usage unique à durée limitée (TOTP) génèrent des codes à partir d’un secret partagé et de l’heure actuelle. Les serveurs valident les codes dans un court laps de temps (généralement 30 secondes, avec une tolérance de ±1), ce qui garantit que chaque code expire rapidement et ne peut être utilisé qu’une seule fois.
• Les notifications push envoient une demande d’authentification à un terminal enregistré. L’action d’approbation de l’utilisateur sur son terminal sert de preuve cryptographique de possession. Cette preuve est souvent complétée par des informations contextuelles (par exemple la localisation, le type de terminal, l’horodatage) afin d’aider les utilisateurs à distinguer les demandes légitimes des demandes frauduleuses.
• Les clés FIDO2/WebAuthn utilisent la cryptographie asymétrique, où une clé privée est stockée sur un terminal physique. Lors de l’authentification, le terminal signe une demande avec la clé privée, et la signature est cryptographiquement liée au domaine d’origine, ce qui rend l’identifiant invalide sur n’importe quel autre site.
• Les cartes à puce stockent des identifiants cryptographiques dans un matériel inviolable. La carte effectue des opérations cryptographiques en interne lorsque l’utilisateur saisit un code PIN, garantissant que la clé privée ne quitte jamais la puce sécurisée.
• Les codes de secours sont des mots de passe à usage unique prégénérés lors de l’inscription au MFA. Chaque code ne peut être validé qu’une seule fois, ce qui permet la récupération du compte sans avoir recours au deuxième facteur principal.

Facteurs d’inhérence

• L’authentification biométrique compare une capture en direct à un modèle stocké qui a été transformé cryptographiquement à partir des données biométriques d’origine. Le système ne stocke jamais d’images ni de scans bruts. Il ne stocke que les représentations mathématiques qui permettent de vérifier une correspondance sans reconstruire les données biométriques d’origine.
• La détection de la vivacité permet de distinguer les données biométriques humaines authentiques des tentatives d’usurpation d’identité à l’aide de photos, masques ou enregistrements, par exemple. Elle emploie pour ce faire des techniques telles que la détection de la profondeur, la détection des micro-mouvements ou la réponse à une demande (par exemple " cligner des yeux deux fois "). L’efficacité de ces contre-mesures varie en fonction des terminaux, selon qu’il s’agisse d’appareils grand public ou de systèmes sophistiqués à niveau d’assurance élevé.
• La sécurité des modèles enregistrés détermine si le facteur biométrique reste sécurisé en cas de compromission du terminal. Les processeurs d’enclave sécurisée et les keystores pris en charge par le matériel isolent le traitement biométrique du système d’exploitation central, empêchant ainsi l’extraction de modèles, même avec un accès au niveau du terminal.

Catégories et mécanismes MFA de base

L’authentification à deux facteurs (2FA) nécessite exactement deux facteurs. Il s’agit généralement d’un mot de passe et d’une méthode de vérification supplémentaire. Le 2FA est le modèle d’implémentation le plus courant et celui que la plupart des gens entendent par "MFA".

L’authentification multifacteur (MFA) est une catégorie plus large qui englobe toute méthode d’authentification nécessitant plusieurs facteurs d’authentification. Bien que la distinction puisse sembler sémantique, elle est importante en termes de politique de sécurité. Par exemple, les systèmes nécessitant trois facteurs (mot de passe, TOTP et biométrie) pour les actions à haut risque répondent à des types de menaces différents de ceux que peut contrer le 2FA standard.

Dans la pratique, le 2FA est une implémentation spécifique du MFA.

Le fait d’exiger les mêmes facteurs d’authentification à chaque connexion crée des frictions sans apporter d’avantage proportionnel en termes de sécurité.

L’authentification renforcée demande aux utilisateurs authentifiés de fournir des facteurs supplémentaires uniquement lorsqu’ils tentent d’accéder à des ressources plus sensibles. Par exemple, un utilisateur se connecte normalement, navigue dans une application, puis reçoit une demande MFA lorsqu’il accède à des ressources protégées ou effectue des actions à haut risque.

Application concrète : un portail destiné aux collaborateurs peut utiliser l’authentification par mot de passe seul pour la lecture de la documentation. Cependant, des actions telles que la modification des informations relatives à la paie, le téléchargement des informations personnelles des collaborateurs ou le changement des configurations système exigent un deuxième facteur, qui peut inclure un code TOTP ou une vérification biométrique.

Ce flux offre une expérience utilisateur plus fluide pour les tâches de routine, tout en maintenant une sécurité accrue lorsque les circonstances l’exigent. L’implémentation nécessite d’identifier les ressources et les actions qui justifient une vérification supplémentaire — une décision d’architecture de sécurité qui pondère les risques par rapport à la friction pour les utilisateurs.

Le MFA adaptatif (également appelé authentification basée sur les risques) ajuste dynamiquement les exigences d’authentification en fonction des signaux contextuels. Plutôt que d’appliquer des règles identiques à chaque tentative de connexion, le système calcule les scores de risque en fonction des éléments suivants :

• Signaux de localisation : réputation de l’adresse IP, localisation géographique et détection des déplacements impossibles
• Contexte du terminal : terminal connu ou inconnu, empreinte du terminal, posture de sécurité
• Modèles comportementaux : heure de la journée, habitudes d’accès, contrôles de vitesse
• Threat intelligence : identifiants compromis connus, campagnes d’attaques actives

Les scénarios à faible risque (par exemple un terminal reconnu, un emplacement familier ou un comportement normal) permettent parfois une authentification à facteur unique. Les scénarios à haut risque (par exemple un nouveau terminal, des emplacements inhabituels ou un accès en dehors des heures de bureau) exigent automatiquement des facteurs de vérification supplémentaires ou bloquent complètement l’accès.

Pour être efficace, le MFA adaptatif nécessite un moteur d’analyse des risques qui traite les signaux de sécurité en temps réel et les données historiques. Les plateformes d’identité remplissent généralement ce critère, car c’est le taux de faux positifs qui détermine si le MFA adaptatif améliore ou dégrade l’expérience utilisateur.

Les codes TOTP et la vérification par SMS renforcent la sécurité par rapport à l’authentification par mot de passe seul, mais les cybercriminels sophistiqués se sont adaptés à ces méthodes. Les proxys de phishing en temps réel peuvent capturer les mots de passe et les codes à usage unique au moment où les utilisateurs les saisissent, puis transmettre immédiatement ces identifiants au service légitime avant qu’ils n’expirent.

Cette attaque réussit parce que les codes TOTP et la vérification par SMS reposent sur des secrets partagés qui existent à la fois sur le client et sur le serveur. Si un attaquant se positionne au milieu, il peut intercepter et réutiliser ces secrets pour contourner l’authentification.

Dans les attaques exploitant la fatigue MFA, les acteurs malveillants envoient des demandes de notification push, en espérant que les utilisateurs finiront par en approuver une pour stopper les alertes.

FIDO2 implémente la cryptographie à clé publique pour éliminer les vulnérabilités liées aux secrets partagés.

FIDO2 se compose des éléments suivants :

• WebAuthn : l’API standard du W3C que les navigateurs et les systèmes d’exploitation utilisent pour interagir avec des authentificateurs.
• CTAP (Client-to-Authenticator Protocol) : le protocole que les terminaux externes utilisent (clés de sécurité, authentificateurs NFC/Bluetooth/USB) pour communiquer avec le client.

Fonctionnement de l’authentification FIDO2 :

Enregistrement (inscription)

• L’authentificateur génère une paire de clés publique-privée.
• La clé privée ne quitte jamais le terminal et la clé publique est enregistrée auprès du service.

Authentification (connexion)

• Le service envoie une demande d’authentification cryptographique.
• L’authentificateur signe la demande à l’aide de la clé privée.
• La signature est liée à l’origine (domaine) du site, ce qui empêche sa réutilisation sur des sites de phishing.

Même si un utilisateur tente de s’authentifier sur un site malveillant, la réponse signée n’est valide que pour le domaine légitime. Il n’y a pas de secret à voler pour les attaquants, ce qui rend les clés FIDO2 résistantes au phishing.

Les passkeys sont des identifiants FIDO2 stockés dans l’environnement sécurisé du terminal (par exemple le trousseau du système d’exploitation) et peuvent être synchronisées entre les terminaux de confiance. Les utilisateurs déclenchent l’authentification d’un seul geste ou action, par exemple déverrouiller le terminal à l’aide d’une vérification biométrique ou d’un code PIN.

Avec les passkeys :

• Pas de mots de passe à voler
• Pas de codes à usage unique à dérober via des attaques de phishing
• Pas de secrets partagés exposés lors d’une brèche

Les passkeys offrent une sécurité de niveau MFA en une seule action conviviale.

Les API, les comptes de service et les communications machine-to-machine ne peuvent pas répondre aux demandes MFA interactives telles que les codes TOTP ou les notifications push. En revanche, les principes du MFA s’appliquent par le biais de l’attestation cryptographique, fournissant une preuve d’identité et de possession.

• Paires de clés asymétriques : les services utilisent des clés privées pour signer les demandes ou les assertions clients au porteur JWT OAuth 2.0 (comme spécifié dans la RFC 7523). Le serveur d’autorisation enregistre les clés publiques. La clé privée ne quitte jamais le service ou le module HSM et sert d’équivalent au facteur de possession.
• Mutual TLS (mTLS) : le client et le serveur présentent tous deux des certificats pour établir une confiance bidirectionnelle. Le certificat du client prouve l’identité et la possession du service, tandis que le certificat du serveur vérifie l’authenticité.
• Attestation des plateformes/de l’identité des charges de travail : les plateformes cloud attestent cryptographiquement de l’identité et de l’intégrité des charges de travail en cours d’exécution. La plateforme émet des identifiants de courte durée de manière dynamique, ce qui élimine le besoin de secrets de longue durée. Cette approche permet l’authentification des services Zero Trust sans gestion manuelle des clés.

Ces modèles étendent le modèle de vérification en couches du MFA aux systèmes automatisés, en utilisant la cryptographie au lieu de l’entrée interactive de l’utilisateur. Les facteurs de possession pour les identités non humaines peuvent inclure des paires de clés asymétriques, des assertions JWT signées ou des clés de signature soutenues par le module HSM, fournissant une vérification forte et résistante au phishing pour les machines et les services.

Le MFA est devenu obligatoire pour de nombreuses entreprises, car les cadres réglementaires l’imposent de plus en plus souvent pour l’accès aux données sensibles :

• La norme PCI DSS 4.x exige le MFA pour la plupart des accès à l’environnement des données relatives aux titulaires de cartes (CDE), y compris les accès à distance et les utilisateurs à privilèges, bien que des clauses et des exceptions spécifiques s’appliquent. Les services IT et les équipes de sécurité doivent consulter les directives de la norme PCI SSC pour connaître la portée exacte des exigences.
• Le RGPD exige des "mesures techniques et organisationnelles appropriées", que les régulateurs interprètent de plus en plus comme incluant le MFA pour l’accès aux données à caractère personnel.
• Les audits SOC 2 évaluent les contrôles d’authentification, et l’obtention de la certification nécessite généralement le MFA pour l’accès d’administration et les opérations à privilèges.
• Le document SP 800-63B du NIST fournit des directives techniques sur l’authentification des identités numériques que les organismes publics doivent suivre et que les entreprises privées adoptent de plus en plus comme bonnes pratiques.

1. Flux de récupération non sécurisés : les mécanismes de récupération de comptes qui contournent le MFA (comme les liens de réinitialisation à un seul facteur envoyés par e-mail) créent des portes dérobées. Les équipes doivent concevoir la récupération avec un niveau de sécurité identique ou supérieur à celui de la connexion initiale.
2. SMS comme seul facteur supplémentaire : le fait de s’appuyer exclusivement sur les SMS rend les entreprises vulnérables aux attaques par échange de carte SIM. Les applications d’authentification TOTP ou les clés physiques contribuent à renforcer la protection.
3. Tokens de session non protégés : le MFA à la connexion est inefficace si les attaquants volent et réutilisent les tokens de session. Les tokens ont besoin d’une durée d’expiration appropriée, d’un stockage sécurisé et d’une surveillance.
4. MFA appliqué de manière universelle, sans contexte lié aux risques : exiger des facteurs d’authentification identiques pour chaque action crée des frictions qui poussent les utilisateurs à trouver des solutions de contournement. L’authentification renforcée concentre la protection là où c’est important, tout en préservant la convivialité.
5. Aucune méthode résistante au phishing : les codes TOTP et les SMS sont des améliorations par rapport aux seuls mots de passe, mais ils restent vulnérables aux attaques de phishing en temps réel. Les entreprises qui traitent des données sensibles doivent prioriser les clés de sécurité WebAuthn/FIDO2 et les passkeys.

Quel est le principal avantage du MFA en termes de sécurité par rapport à l’authentification par mot de passe seul ?

Le MFA protège contre le vol d’identifiants. Même si des acteurs malveillants volent un mot de passe, ils ne peuvent pas accéder au compte sans le deuxième facteur, qu’il s’agisse d’un code généré par le terminal, d’une vérification biométrique ou d’une clé de sécurité physique.

Pourquoi les experts en sécurité déconseillent-ils le MFA par SMS ?

Les attaquants exploitent les codes envoyés par SMS au moyen d’attaques par échange de carte SIM, où ils convainquent les opérateurs mobiles de transférer des numéros de téléphone vers des terminaux qu’ils contrôlent. Si le MFA par SMS est plus efficace que l’authentification par mot de passe seul, les applications d’authentification TOTP et les clés de sécurité physiques offrent une protection plus forte qui ne dépend pas des pratiques de sécurité des opérateurs mobiles.

Les attaquants peuvent-ils contourner ou déjouer le MFA ?

Les attaques de phishing sophistiquées utilisant des proxys en temps réel peuvent contourner le MFA traditionnel reposant sur des codes TOTP ou envoyés par SMS. Le MFA utilisant des clés de sécurité FIDO2/WebAuthn ou des passkeys repose sur des preuves cryptographiques de possession liées à des domaines spécifiques.

Que se passe-t-il si les utilisateurs perdent l’accès à leur deuxième facteur ?

Les équipes IT peuvent fournir des méthodes de récupération sécurisées pour restaurer l’accès, comme des codes de secours générés lors de l’inscription ou lors de la réinscription, avec vérification de l’identité. Les équipes sécurité doivent protéger les flux de récupération avec un niveau d’assurance identique ou supérieur à celui du processus MFA d’origine ; ils doivent donc éviter les flux à facteur unique, tels que les réinitialisations par e-mail uniquement, qui pourraient contourner le MFA.

Des lois ou réglementations exigent-elles l’implémentation du MFA ?

De nombreux cadres réglementaires exigent ou recommandent fortement le MFA. La norme PCI DSS 4.x exige le MFA pour la plupart des accès à l’environnement des données relatives aux titulaires de cartes (CDE), y compris les accès à distance et les utilisateurs à privilèges, bien que des clauses et des exceptions spécifiques s’appliquent. Dans le cadre de la loi HIPAA, le MFA est une mesure de protection potentielle. Les entreprises qui choisissent de ne pas l’appliquer doivent justifier leurs raisons et mettre en œuvre des contrôles alternatifs qui offrent une protection comparable pour les données médicales personnelles électroniques.

Bien que vous puissiez créer vous-même des fonctionnalités MFA, les plateformes d’identité modernes fournissent des implémentations prêtes au déploiement en production avec des moteurs d’analyse des risques adaptatifs, des authentificateurs résistants au phishing et des contrôles de conformité intégrés. Explorez notre série d’articles "Introduction à l’IAM" pour en savoir plus sur la gestion des identités et des accès.

En savoir plus

Le contenu de ce document revêt un caractère purement informatif. Il vous revient de vous adresser à des conseillers professionnels pour obtenir des conseils en matière de sécurité, confidentialité, conformité ou conduite des affaires, et de ne pas vous en remettre aux recommandations formulées dans le présent document.