Étude stratégique et opérationnelle pour la refonte IAM/IGA d'un grand groupe multi-filiales

Classification : Confidentiel — Usage interne
Version : 1.0
Date : Mars 2026

TABLE DES MATIÈRES

1. Introduction et fondamentaux du MFA
2. Les différentes approches et méthodes MFA
3. Standards, protocoles et frameworks
4. Panorama des solutions du marché
5. Architecture et intégration
6. Cas d'usage détaillés
7. Tendances et évolutions du marché
8. Recommandations stratégiques
9. Synthèse et conclusion
10. Annexe — Glossaire

1. INTRODUCTION ET FONDAMENTAUX DU MFA

1.1 Définitions et distinctions clés

L'authentification multi-facteurs (MFA) désigne tout mécanisme d'authentification exigeant la vérification réussie d'au moins deux facteurs d'authentification appartenant à des catégories distinctes avant d'accorder l'accès à une ressource. Il est essentiel de distinguer le MFA de plusieurs concepts adjacents avec lesquels il est fréquemment confondu.

L'authentification à facteur unique (SFA — Single-Factor Authentication) repose sur un seul élément de vérification, typiquement un mot de passe. C'est la forme la plus répandue et aussi la plus vulnérable d'authentification. Elle constitue aujourd'hui le socle que toute stratégie IAM moderne cherche à dépasser.

L'authentification à deux facteurs (2FA — Two-Factor Authentication) est un sous-ensemble du MFA qui exige exactement deux facteurs distincts. Toute 2FA est du MFA, mais tout MFA n'est pas nécessairement de la 2FA : certaines politiques de sécurité peuvent exiger trois facteurs ou plus, notamment pour les accès à haute criticité (comptes à privilèges, opérations financières sensibles).

L'authentification sans mot de passe (Passwordless) représente une approche fondamentalement différente qui vise à éliminer le mot de passe du processus d'authentification, le remplaçant par des mécanismes réputés plus sûrs et plus ergonomiques tels que la biométrie, les clés de sécurité FIDO2 ou les passkeys. Le passwordless peut être mono-facteur (par exemple, une authentification biométrique seule) ou multi-facteurs (par exemple, une clé FIDO2 combinée à une empreinte digitale). Il est crucial de comprendre que passwordless et MFA ne sont pas mutuellement exclusifs : les stratégies les plus avancées combinent les deux, offrant une authentification forte sans recourir au mot de passe.

1.2 Les familles de facteurs d'authentification

La taxonomie classique de l'authentification repose sur trois piliers fondamentaux auxquels viennent s'ajouter des facteurs émergents de plus en plus intégrés dans les architectures modernes.

Le facteur de connaissance ("ce que je sais") englobe les mots de passe, codes PIN, questions secrètes et phrases de passe. C'est historiquement le facteur le plus utilisé, mais aussi le plus vulnérable : il est sujet au phishing, à l'ingénierie sociale, aux attaques par force brute et au credential stuffing. Le rapport Verizon DBIR 2025 révèle que seulement 3 % des mots de passe compromis rencontraient les exigences basiques de complexité, soulignant l'échec structurel de ce facteur lorsqu'il est utilisé seul.

Le facteur de possession ("ce que j'ai") repose sur un objet physique ou numérique détenu par l'utilisateur : smartphone recevant un code OTP ou une notification push, clé de sécurité physique (YubiKey, Titan Key), carte à puce (smart card), token matériel générant des codes, ou encore un certificat numérique stocké sur un appareil. Ce facteur offre un niveau de sécurité supérieur car il nécessite un accès physique à l'objet, mais il reste vulnérable au vol, à la perte et, dans le cas des OTP transmis par SMS, à l'interception (SIM swap, SS7 exploitation).

Le facteur d'inhérence ("ce que je suis") fait appel aux caractéristiques biométriques intrinsèques de l'utilisateur : empreinte digitale, reconnaissance faciale, reconnaissance de l'iris, reconnaissance vocale, ou géométrie de la main. Ce facteur présente l'avantage d'être difficilement reproductible et de ne pas pouvoir être oublié ou perdu. Cependant, il soulève des enjeux de protection des données personnelles (RGPD), de précision (taux de faux positifs et faux négatifs) et de révocabilité : contrairement à un mot de passe, une empreinte digitale compromise ne peut être changée.

Les facteurs contextuels ("où je suis, quand et comment") constituent une quatrième catégorie émergente qui enrichit l'évaluation de l'authentification sans solliciter directement l'utilisateur. Ils incluent la géolocalisation (adresse IP, GPS), le réseau utilisé (réseau d'entreprise, Wi-Fi public, VPN), l'heure et le jour de connexion, le type d'appareil et son état de conformité (device trust, posture assessment). Ces signaux ne constituent pas à eux seuls des facteurs d'authentification au sens strict du NIST, mais ils alimentent les moteurs de risk-based authentication pour moduler dynamiquement le niveau d'exigence MFA.

Les facteurs comportementaux ("comment j'agis") représentent la frontière la plus récente de l'authentification. Ils analysent les patterns comportementaux de l'utilisateur : dynamique de frappe au clavier (keystroke dynamics), mouvements de souris, habitudes de navigation, patterns d'utilisation des applications, démarche (via les capteurs du smartphone). Ces facteurs, souvent alimentés par l'intelligence artificielle et le machine learning, permettent une authentification continue et transparente, sans friction pour l'utilisateur. Ils sont au cœur du concept de continuous authentication qui émerge comme composante clé des architectures Zero Trust.

1.3 Positionnement du MFA dans la chaîne d'identité IAM/IGA

Dans une architecture IAM/IGA complète, le MFA se positionne comme un composant transversal qui intervient à plusieurs niveaux de la chaîne d'identité. Il constitue le gardien du processus d'authentification, mais son rôle s'étend bien au-delà du simple contrôle d'accès initial.

Au niveau de l'authentification primaire, le MFA intervient lors de la connexion initiale de l'utilisateur au portail d'entreprise, au SSO ou à une application spécifique. C'est le cas d'usage le plus évident et le plus déployé. Le MFA s'intègre ici avec les briques de SSO (Single Sign-On) et de fédération d'identités (via SAML 2.0, OpenID Connect) pour offrir une expérience authentifiée unifiée.

Au niveau du step-up authentication, le MFA intervient de manière conditionnelle lorsqu'un utilisateur déjà authentifié tente d'accéder à une ressource sensible ou d'effectuer une action critique. Par exemple, un collaborateur connecté au portail intranet via SSO peut se voir demander une vérification MFA supplémentaire lorsqu'il accède à l'ERP financier ou valide un virement. Cette approche permet d'équilibrer sécurité et expérience utilisateur.

Dans le cadre de la gouvernance des identités (IGA), le MFA intervient pour sécuriser les workflows d'approbation des demandes d'accès, les campagnes de recertification et les opérations de provisioning/deprovisioning sensibles. Il garantit que les décisions de gouvernance sont prises par des personnes dûment authentifiées.

En lien avec la gestion des accès à privilèges (PAM), le MFA constitue un prérequis absolu pour toute connexion à des comptes administrateurs ou à des sessions privilégiées. Les solutions PAM modernes intègrent nativement des mécanismes MFA renforcés, souvent au niveau AAL3 du NIST.

Enfin, dans un contexte Zero Trust, le MFA devient un signal d'évaluation continue plutôt qu'un événement ponctuel. Il s'inscrit dans un modèle de vérification permanente où chaque accès, chaque transaction et chaque changement de contexte peut déclencher une réévaluation du niveau de confiance et, le cas échéant, une demande de réauthentification.

1.4 Pourquoi le MFA est devenu un pilier incontournable

Les données les plus récentes confirment de manière écrasante la nécessité du MFA comme contrôle de sécurité fondamental. Le rapport Verizon DBIR 2025, qui a analysé plus de 22 052 incidents de sécurité dont 12 195 brèches confirmées dans 139 pays, place une nouvelle fois l'utilisation d'identifiants compromis comme le premier vecteur d'accès initial, impliqué dans 22 % des brèches. Ce chiffre, bien que déjà alarmant, masque la réalité complète du problème : 88 % des attaques contre les applications web basiques impliquaient l'utilisation d'identifiants volés, et 60 % de l'ensemble des brèches comportaient un élément humain (phishing, ingénierie sociale).

Sur le plan quantitatif, 2,8 milliards de mots de passe ont été mis en vente ou diffusés gratuitement sur les marchés criminels en 2024 — via les forums du dark web, les groupes de messagerie chiffrée et les plateformes clandestines. Les attaques par force brute contre les applications web ont quasiment triplé en un an, passant d'environ 20 % à 60 %. L'implication de tiers dans les brèches a doublé, passant de 15 % à 30 % de l'ensemble des incidents, comme l'a illustré de manière spectaculaire la brèche Snowflake, où l'absence de MFA obligatoire chez le fournisseur cloud a permis la compromission de clients majeurs tels qu'AT&T, Ticketmaster et Santander Group.

Le marché du MFA reflète cette prise de conscience collective. Estimé à 15,2 milliards de dollars en 2025, il devrait atteindre 51,5 milliards de dollars d'ici 2033, soit un taux de croissance annuel composé remarquable. Le marché connexe de l'authentification passwordless, évalué à 15,24 milliards de dollars en 2025, est projeté à plus de 17,26 milliards dès 2026 et pourrait atteindre 45 milliards de dollars d'ici 2029. Ces chiffres traduisent une dynamique d'investissement massive, portée par la convergence de la pression réglementaire (NIS2, DORA), de l'évolution des menaces et de la maturité croissante des solutions.

Microsoft, qui gère l'un des plus grands écosystèmes d'identité au monde, a adopté une politique de "passwordless by default" pour tous les nouveaux comptes, avec des résultats éloquents : les passkeys sont 3 fois plus rapides que les mots de passe traditionnels et 8 fois plus rapides que les mots de passe combinés au MFA classique, les connexions par passkey réussissent dans 98 % des cas contre seulement 32 % pour les mots de passe, et 99 % des utilisateurs qui commencent l'enregistrement d'une passkey le finalisent avec succès. Ces chiffres démontrent que le MFA moderne, et plus particulièrement le passwordless, n'est plus uniquement un impératif de sécurité mais aussi un levier d'amélioration de l'expérience utilisateur.

2. LES DIFFÉRENTES APPROCHES ET MÉTHODES MFA

2.1 Inventaire détaillé des méthodes MFA

2.1.1 OTP par SMS

Le One-Time Password transmis par SMS constitue historiquement la méthode MFA la plus largement déployée, principalement en raison de sa simplicité d'implémentation et de son universalité (tout téléphone mobile peut recevoir un SMS). L'utilisateur reçoit un code numérique à usage unique (généralement 6 chiffres) par message texte après avoir saisi son mot de passe. Ce code doit être renseigné dans un délai imparti, typiquement 5 à 10 minutes.

Du point de vue de la sécurité, le SMS OTP est aujourd'hui considéré comme la méthode MFA la plus faible. Le NIST l'a officiellement classé comme méthode "restreinte" (restricted) dans sa publication SP 800-63B dès 2017. Le Verizon DBIR 2025 recommande explicitement de ne pas utiliser le SMS OTP, citant sa vulnérabilité au SIM swapping. Les vulnérabilités connues incluent les attaques par SIM swap (l'attaquant convainc l'opérateur de transférer le numéro sur une nouvelle carte SIM), l'exploitation des failles du protocole SS7 permettant l'interception des SMS, les attaques de type man-in-the-middle via des malwares mobiles, et l'ingénierie sociale ciblant les opérateurs télécoms. Malgré ces faiblesses, le SMS OTP reste significativement plus sûr que l'absence totale de MFA et conserve une pertinence dans les contextes B2C où l'ergonomie et l'accessibilité priment, ou dans les phases transitoires de déploiement MFA.

2.1.2 OTP par email

L'envoi d'un code à usage unique par email suit un principe identique au SMS OTP mais utilise la messagerie électronique comme canal de transmission. Cette méthode présente les mêmes avantages d'accessibilité que le SMS mais souffre de vulnérabilités supplémentaires. La compromission d'un compte email (qui est précisément ce contre quoi le MFA est censé protéger) invalide totalement ce second facteur, créant une dépendance circulaire. Les emails peuvent être interceptés en transit si le chiffrement TLS n'est pas systématiquement appliqué, et les délais de réception peuvent être imprévisibles, dégradant l'expérience utilisateur. Cette méthode est généralement considérée comme appropriée uniquement pour les cas d'usage à faible risque ou comme mécanisme de récupération.

2.1.3 TOTP (Time-based One-Time Password)

Le TOTP, standardisé par la RFC 6238 et basé sur le standard OATH, génère des codes à usage unique à partir d'un secret partagé (seed) et de l'horodatage courant. L'utilisateur installe une application d'authentification (Microsoft Authenticator, Google Authenticator, Authy, etc.) qui génère un nouveau code toutes les 30 secondes. Le secret partagé est établi lors de l'enrollment initial, généralement via la lecture d'un QR code.

Le TOTP offre un niveau de sécurité nettement supérieur au SMS OTP car il ne dépend pas d'un canal de communication interceptable. Il fonctionne hors ligne et ne nécessite aucune connectivité réseau au moment de l'authentification. Ses vulnérabilités résiduelles incluent la possibilité de phishing en temps réel (l'attaquant peut relayer le code TOTP avant son expiration), la compromission du secret partagé stocké côté serveur, et les attaques adversary-in-the-middle (AiTM). Le TOTP n'est pas considéré comme phishing-resistant car le code peut être saisi sur un site frauduleux et relayé vers le site légitime. Le Verizon DBIR 2025 recommande néanmoins le TOTP via les applications d'authentification comme une option nettement plus sûre que le SMS.

2.1.4 HOTP (HMAC-based One-Time Password)

Le HOTP, défini par la RFC 4226, génère des codes à partir d'un secret partagé et d'un compteur incrémenté à chaque utilisation, plutôt que de l'horodatage. Cette méthode est principalement utilisée dans les tokens matériels (hardware tokens) et certaines applications d'authentification. Elle offre un niveau de sécurité comparable au TOTP mais nécessite une synchronisation du compteur entre le client et le serveur, ce qui peut poser des problèmes de désynchronisation si des codes sont générés sans être utilisés.

2.1.5 Notifications push

L'authentification par notification push envoie une demande d'approbation directement sur l'application d'authentification installée sur le smartphone de l'utilisateur. Ce dernier reçoit une notification contextuelle indiquant le service demandant l'accès, l'heure et parfois la localisation, et doit approuver ou rejeter la demande d'un simple tapotement.

Cette méthode offre une expérience utilisateur significativement meilleure que la saisie manuelle de codes OTP et fournit un contexte qui aide l'utilisateur à détecter les tentatives frauduleuses. Cependant, elle a fait l'objet de la vulnérabilité critique dite de "MFA fatigue" ou "prompt bombing" : l'attaquant, ayant déjà compromis les identifiants de l'utilisateur, déclenche un flux incessant de notifications push jusqu'à ce que la victime, excédée ou distraite, finisse par approuver l'une d'entre elles. Selon les données du DBIR 2025 analysant les attaques contre Microsoft 365, 22 % des attaques de type MFA bypass utilisaient cette technique d'interruption MFA. Pour contrer ce vecteur d'attaque, les éditeurs ont intégré des mécanismes de "number matching" (l'utilisateur doit saisir un nombre affiché sur l'écran de connexion dans l'application mobile) et des limites de fréquence des notifications.

2.1.6 FIDO2 / WebAuthn

FIDO2 représente le standard d'authentification le plus avancé disponible aujourd'hui, conjointement développé par la FIDO Alliance et le W3C. Il repose sur deux composants complémentaires : WebAuthn (Web Authentication API), une API standardisée permettant aux navigateurs et applications de communiquer avec des authentificateurs, et CTAP (Client-to-Authenticator Protocol), le protocole de communication entre l'appareil client et l'authentificateur (clé de sécurité physique, capteur biométrique intégré, ou authentificateur de plateforme).

FIDO2 utilise la cryptographie asymétrique : lors de l'enregistrement, une paire de clés publique/privée est générée, la clé privée restant stockée de manière sécurisée sur l'authentificateur (dans un élément sécurisé matériel, TPM, ou enclave sécurisée) tandis que la clé publique est envoyée au serveur. Lors de l'authentification, le serveur envoie un challenge que l'authentificateur signe avec la clé privée. Ce mécanisme est intrinsèquement résistant au phishing car la clé privée est liée cryptographiquement au domaine du site légitime (origin binding) : même si l'utilisateur interagit avec un site frauduleux, l'authentificateur refusera de signer le challenge car le domaine ne correspondra pas. Les attaques AiTM sont également neutralisées car les données interceptées sont inutilisables sans la clé privée.

FIDO2 est unanimement reconnu par le NIST, l'ANSSI, l'ENISA et la CISA comme la méthode d'authentification phishing-resistant de référence. Son adoption a connu une accélération considérable avec l'avènement des passkeys.

2.1.7 Passkeys

Les passkeys constituent l'évolution grand public du standard FIDO2. Introduites conjointement par Apple, Google et Microsoft à partir de 2022, elles rendent les identifiants FIDO2 synchronisables entre les appareils d'un même écosystème (via iCloud Keychain, Google Password Manager, ou Windows Hello). Cette synchronisation résout le principal frein historique à l'adoption de FIDO2 — la perte d'accès en cas de perte ou changement d'appareil.

Selon la FIDO Alliance, 87 % des entreprises aux États-Unis et au Royaume-Uni ont déployé ou sont en cours de déploiement de passkeys en 2025, un chiffre en hausse de 14 points par rapport à l'année précédente. Côté grand public, 69 % des utilisateurs possèdent désormais au moins une passkey, 48 % des 100 premiers sites web mondiaux supportent les passkeys, et le taux de réussite de connexion par passkey atteint 93 % contre 63 % pour les méthodes traditionnelles. Il convient toutefois de distinguer les passkeys synchronisées (synced passkeys), stockées dans le cloud de l'écosystème de l'utilisateur et transférables entre appareils, des passkeys liées à l'appareil (device-bound passkeys), qui restent strictement sur un dispositif matériel spécifique (clé de sécurité, TPM). Les passkeys liées à l'appareil offrent un niveau de sécurité supérieur (AAL3 du NIST) mais avec une flexibilité moindre. Les passkeys synchronisées, bien qu'offrant un excellent équilibre sécurité/ergonomie, posent la question de la confiance dans le fournisseur cloud hébergeant les clés.

2.1.8 Clés de sécurité physiques

Les clés de sécurité physiques (YubiKey de Yubico, Titan Security Key de Google, Feitian, SoloKeys, etc.) sont des authentificateurs matériels portables qui implémentent les protocoles FIDO2/CTAP, et souvent également FIDO U2F, OTP, PIV (smart card), et OpenPGP. Elles se connectent via USB-A, USB-C, NFC ou Lightning.

Elles représentent le niveau de sécurité le plus élevé en authentification MFA, correspondant au niveau AAL3 du NIST. La clé privée ne quitte jamais le composant sécurisé de la clé et ne peut être extraite, éliminant tout risque de vol à distance. Elles sont résistantes au phishing, aux attaques AiTM, au MFA fatigue, et ne nécessitent aucune batterie ni connectivité réseau. Leurs inconvénients principaux sont le coût unitaire (25 à 70 € par clé, avec nécessité de fournir deux clés par utilisateur pour la redondance), le risque de perte ou d'oubli physique, et la nécessité d'un processus logistique d'enrollment et de remplacement. Pour un grand groupe multi-filiales, le déploiement de clés de sécurité représente un investissement significatif mais justifié pour les populations à haut risque (administrateurs, dirigeants, développeurs).

2.1.9 Biométrie

La biométrie exploite les caractéristiques physiologiques ou comportementales uniques de l'individu. Les modalités biométriques physiologiques les plus courantes incluent l'empreinte digitale (le plus répandu, intégré dans la majorité des smartphones et ordinateurs portables modernes), la reconnaissance faciale (Face ID d'Apple, Windows Hello, et systèmes équivalents Android), la reconnaissance de l'iris (haute précision, mais déploiement coûteux et contraignant), et la reconnaissance vocale (utilisée principalement dans les centres d'appels et les assistants vocaux).

La biométrie offre un excellent équilibre entre sécurité et ergonomie lorsqu'elle est utilisée comme facteur d'authentification locale, débloquant un authentificateur (smartphone, clé de sécurité) plutôt que comme donnée envoyée et comparée côté serveur. Cette distinction est fondamentale pour le respect du RGPD : dans le modèle FIDO2, la vérification biométrique s'effectue localement sur l'appareil et seul le résultat cryptographique (signature) est transmis, jamais la donnée biométrique elle-même.

Les menaces émergentes contre la biométrie incluent les deepfakes (vidéos ou images synthétiques générées par IA pour tromper la reconnaissance faciale), les empreintes synthétiques, et les attaques par rejeu (replay). Les solutions modernes intègrent des mécanismes de détection de vivacité (liveness detection) pour contrer ces attaques, mais la course entre attaquants et défenseurs s'intensifie avec les progrès de l'IA générative.

2.1.10 Certificats X.509 et smart cards

L'authentification par certificat numérique X.509, délivrée par une infrastructure à clé publique (PKI), constitue l'une des méthodes d'authentification les plus robustes et les plus anciennes. Les certificats sont typiquement stockés sur des cartes à puce (smart cards), des tokens USB cryptographiques ou dans des magasins de certificats logiciels (TPM, keystore du système d'exploitation).

Cette méthode est phishing-resistant par conception (cryptographie asymétrique liée au domaine), offre une traçabilité fine et une gestion de cycle de vie mature (émission, renouvellement, révocation via CRL/OCSP). Elle est largement utilisée dans les environnements gouvernementaux, militaires et de haute sécurité (PIV aux États-Unis, eIDAS en Europe). Son principal inconvénient réside dans la complexité de déploiement et de gestion de la PKI sous-jacente, qui nécessite une infrastructure dédiée (autorité de certification, autorité d'enregistrement, infrastructure de révocation) et des compétences spécialisées. Pour un grand groupe, la question de la gouvernance de la PKI (centralisée ou fédérée entre filiales) constitue un enjeu architecturel majeur.

2.1.11 QR codes et magic links

Les QR codes d'authentification permettent à un utilisateur de scanner un code-barres 2D affiché sur l'écran de connexion à l'aide de son smartphone préalablement enregistré. Cette méthode est utilisée par certains services (WhatsApp Web, Signal Desktop) et solutions MFA. Les magic links envoient à l'utilisateur un lien unique et temporaire par email sur lequel il doit cliquer pour s'authentifier.

Ces deux méthodes offrent une bonne ergonomie mais un niveau de sécurité limité. Les QR codes peuvent être capturés et relayés (attaque de type QRLJacking), tandis que les magic links héritent des vulnérabilités de l'email (interception, compromission de la boîte mail). Elles sont principalement adaptées aux cas d'usage à faible risque ou comme mécanismes de fallback.

2.2 Matrice comparative des méthodes MFA

2.3 Approche adaptative / Risk-Based MFA

Le Risk-Based MFA (ou authentification adaptative) représente un changement de paradigme majeur par rapport à l'application statique et uniforme du MFA. Plutôt que d'exiger le même niveau d'authentification pour chaque accès, indépendamment du contexte, le Risk-Based MFA évalue dynamiquement le niveau de risque associé à chaque tentative de connexion et adapte les exigences d'authentification en conséquence.

Les critères d'évaluation du risque intégrés dans les moteurs d'authentification adaptative sont multiples et opèrent en combinaison. La géolocalisation analyse l'adresse IP et, lorsqu'elle est disponible, la position GPS de l'appareil : une connexion depuis un pays inhabituel ou depuis deux localisations géographiquement incompatibles dans un laps de temps court (impossible travel) élèvera le score de risque. Le device trust évalue la conformité de l'appareil (système d'exploitation à jour, antivirus actif, chiffrement du disque, enregistrement MDM) et sa familiarité (appareil connu vs. nouveau). Le contexte réseau distingue une connexion depuis le réseau d'entreprise, un VPN autorisé, ou un réseau public inconnu. Le comportement utilisateur analyse les patterns d'utilisation habituels : horaires de connexion, applications accédées, volume de données manipulées. L'analyse de la session observe les actions post-authentification pour détecter des anomalies.

En fonction du score de risque calculé, le système peut décider de différentes réponses : autoriser l'accès sans MFA supplémentaire (risque faible, contexte familier), exiger un facteur MFA standard (risque modéré), exiger un facteur MFA renforcé ou phishing-resistant (risque élevé), bloquer l'accès et déclencher une alerte de sécurité (risque critique), ou réduire les permissions de la session (accès en lecture seule, par exemple).

Pour un grand groupe multi-filiales, le Risk-Based MFA offre l'avantage majeur de pouvoir différencier les politiques par entité, par population d'utilisateurs et par sensibilité des ressources, tout en maintenant un socle commun de gouvernance. Il permet également d'améliorer significativement l'expérience utilisateur en réduisant la friction d'authentification dans les contextes de confiance élevée.

2.4 Step-Up Authentication

Le step-up authentication est le mécanisme par lequel un utilisateur déjà authentifié à un certain niveau se voit demander une authentification supplémentaire lorsqu'il tente d'accéder à une ressource de sensibilité supérieure ou d'effectuer une action critique. Ce concept est étroitement lié au Risk-Based MFA mais opère à un niveau applicatif plus granulaire.

Les cas d'application typiques incluent l'accès à des données financières ou RH sensibles depuis un portail intranet déjà authentifié, la validation d'un virement ou d'une opération financière dépassant un certain seuil, la modification de paramètres de sécurité du compte (changement de mot de passe, ajout d'un facteur MFA), l'accès à des dossiers patients dans un contexte médical, l'approbation d'une demande d'accès à privilèges élevés dans le workflow IGA, et l'accès à des environnements de production dans un contexte DevOps.

La mise en œuvre du step-up authentication nécessite une intégration étroite entre la solution MFA, le SSO et les applications métier. Les standards OpenID Connect et OAuth 2.0 prévoient des mécanismes natifs pour gérer les niveaux d'assurance d'authentification (acr_values, amr claims) qui permettent aux applications de requérir un niveau d'authentification spécifique.

2.5 Articulation passwordless et MFA

L'approche passwordless ne vise pas à supprimer le MFA mais à en redéfinir les composantes en éliminant le facteur le plus faible — le mot de passe. Dans une authentification passwordless MFA, les facteurs combinés pourraient par exemple être une clé de sécurité FIDO2 (possession) activée par une empreinte digitale (inhérence), ou un smartphone enregistré (possession) avec reconnaissance faciale (inhérence).

Cette combinaison offre un niveau de sécurité objectivement supérieur à la combinaison traditionnelle mot de passe (connaissance) + SMS OTP (possession), tout en offrant une expérience utilisateur radicalement améliorée. Le passwordless MFA est aujourd'hui considéré comme la cible stratégique par la majorité des analystes et des grandes organisations. La transition vers le passwordless ne peut toutefois être envisagée comme un basculement brutal : elle nécessite une coexistence prolongée avec les méthodes traditionnelles, une refonte des processus d'enrollment et de recovery, et une gestion du changement significative. Pour un grand groupe multi-filiales, cette transition devra être planifiée sur un horizon de 2 à 5 ans, avec des jalons intermédiaires adaptés à la maturité de chaque entité.

3. STANDARDS, PROTOCOLES ET FRAMEWORKS

3.1 Standards techniques clés

FIDO2, WebAuthn et CTAP

FIDO2 constitue aujourd'hui le standard de référence pour l'authentification forte phishing-resistant. Développé conjointement par la FIDO Alliance et le W3C, il se compose de deux spécifications complémentaires. WebAuthn (Web Authentication, devenu Recommandation W3C en mars 2019) définit l'API JavaScript standard permettant aux applications web de créer et d'utiliser des credentials basées sur la cryptographie asymétrique via les navigateurs. Elle est supportée par l'ensemble des navigateurs majeurs (Chrome, Firefox, Safari, Edge) et par les systèmes d'exploitation mobiles (iOS, Android). CTAP2 (Client-to-Authenticator Protocol) standardise la communication entre le client (navigateur, système d'exploitation) et les authentificateurs externes (clés de sécurité USB/NFC, smartphones). CTAP2 a succédé à CTAP1 (anciennement FIDO U2F), avec lequel il maintient une rétrocompatibilité.

L'architecture FIDO2 repose sur le modèle de confiance suivant : chaque service (relying party) stocke uniquement la clé publique de l'utilisateur, la clé privée restant confinée dans l'authentificateur (secure element, TPM, enclave). L'authentification s'effectue par un mécanisme de challenge-response : le serveur envoie un challenge aléatoire, l'authentificateur le signe avec la clé privée après vérification de l'utilisateur (biométrie, PIN), et le serveur vérifie la signature avec la clé publique. Le binding de l'origin (domaine du site) dans le processus cryptographique rend le phishing structurellement impossible.

OATH (TOTP/HOTP)

L'Initiative for Open Authentication (OATH) a produit les deux standards ouverts les plus utilisés pour la génération de codes à usage unique. HOTP (RFC 4226) définit la génération de codes basée sur un compteur HMAC-SHA1, tandis que TOTP (RFC 6238) étend HOTP en utilisant le temps comme variable, générant un nouveau code toutes les 30 secondes (configurable). Ces standards, matures et largement implémentés, constituent le socle des applications d'authentification (Google Authenticator, Microsoft Authenticator) et des tokens matériels. Leur interopérabilité est excellente et ne crée pas de dépendance envers un éditeur spécifique.

OpenID Connect, SAML 2.0 et OAuth 2.0

Ces protocoles de fédération d'identité et d'autorisation constituent la couche de transport sur laquelle s'appuie le MFA dans les architectures modernes. SAML 2.0 (Security Assertion Markup Language) reste le standard dominant pour la fédération d'identités en entreprise, particulièrement pour l'intégration avec les applications SaaS et les portails d'entreprise. Il permet le SSO et transporte les informations d'authentification (y compris le niveau MFA utilisé) sous forme d'assertions XML signées. OpenID Connect (OIDC) est une couche d'identité construite au-dessus d'OAuth 2.0, devenue le standard préféré pour les nouvelles implémentations grâce à sa simplicité (basée sur JSON/REST) et sa richesse fonctionnelle. Il supporte nativement les claims d'authentification (acr, amr) permettant de communiquer le niveau d'assurance MFA aux applications. OAuth 2.0 gère l'autorisation déléguée et complète OIDC dans les scénarios où le consentement de l'utilisateur et l'accès aux API sont impliqués.

Pour un grand groupe multi-filiales, la maîtrise et le support de ces trois protocoles par la solution MFA retenue sont indispensables. L'architecture cible devra supporter SAML 2.0 pour les intégrations legacy et OIDC pour les nouvelles applications, avec une fédération inter-filiales basée sur des trusts configurables.

3.2 Frameworks et recommandations institutionnelles

NIST SP 800-63B — Niveaux AAL

La publication spéciale 800-63B du NIST (Digital Identity Guidelines — Authentication and Lifecycle Management) définit trois niveaux d'assurance de l'authentification (Authentication Assurance Levels) qui servent de référence mondiale pour calibrer les exigences MFA.

AAL1 (Authenticator Assurance Level 1) exige un facteur unique d'authentification. Il offre une assurance raisonnable que le demandeur contrôle l'authentificateur lié au compte. Les mots de passe seuls, les OTP par email ou SMS (avec restrictions) peuvent satisfaire ce niveau. AAL1 est approprié pour les accès à faible sensibilité.

AAL2 exige deux facteurs d'authentification distincts et apporte une haute confiance que le demandeur contrôle les authentificateurs liés au compte. Les méthodes éligibles incluent les combinaisons mot de passe + TOTP, mot de passe + push notification, ou un authentificateur multi-facteur unique (comme un smartphone avec biométrie). AAL2 est le niveau cible standard pour la majorité des accès d'entreprise et celui exigé par la plupart des réglementations.

AAL3 exige une authentification basée sur la preuve de possession d'une clé cryptographique via un protocole cryptographique, utilisant un authentificateur matériel résistant à la vérification d'impersonation. Concrètement, seules les clés de sécurité physiques FIDO2 (device-bound), les smart cards avec PKI et les solutions de type hardware security module répondent à ce niveau. AAL3 est requis pour les accès à très haute sensibilité : comptes à privilèges critiques, systèmes de contrôle industriels, accès aux données classifiées.

Recommandations ANSSI

L'Agence nationale de la sécurité des systèmes d'information (ANSSI) publie régulièrement des guides et recommandations sur l'authentification. Ses préconisations s'inscrivent dans le cadre du Référentiel Général de Sécurité (RGS) et des guides de bonnes pratiques pour les systèmes d'information d'importance vitale (SIIV). L'ANSSI recommande l'authentification forte pour tout accès à des ressources sensibles, privilégie les méthodes basées sur la cryptographie asymétrique (FIDO2, certificats) et déconseille explicitement l'utilisation du SMS comme second facteur pour les niveaux de sensibilité élevés. Pour les opérateurs d'importance vitale (OIV) et les opérateurs de services essentiels (OSE), l'authentification multi-facteurs est une obligation réglementaire.

ENISA

L'Agence de l'Union européenne pour la cybersécurité (ENISA) a publié des orientations sur l'authentification forte dans le cadre de NIS2 et du Cybersecurity Act. Ses recommandations convergent avec celles du NIST et de l'ANSSI, avec un accent particulier sur la résistance au phishing, l'interopérabilité européenne et la souveraineté des solutions d'authentification.

NIST SP 800-207 — Zero Trust Architecture

Le framework Zero Trust du NIST positionne l'identité et l'authentification comme le pilier central de la sécurité. Le principe fondamental "never trust, always verify" implique que chaque accès, qu'il provienne de l'intérieur ou de l'extérieur du réseau d'entreprise, doit être authentifié, autorisé et continuellement validé. Le MFA devient dans ce contexte non pas un contrôle ponctuel mais un mécanisme de vérification continue, alimentant en permanence le moteur de décision Zero Trust (Policy Decision Point) avec des signaux de confiance mis à jour.

3.3 Réglementations impactant le MFA

NIS2 (Directive (UE) 2022/2555)

La directive NIS2, entrée en application en octobre 2024, élargit considérablement le périmètre des entités soumises à des obligations de cybersécurité dans l'Union européenne, couvrant 18 secteurs critiques. Elle impose aux entités essentielles et importantes la mise en œuvre de mesures de sécurité proportionnées incluant des "politiques et procédures relatives à l'utilisation de la cryptographie et, le cas échéant, du chiffrement" ainsi que "des politiques de contrôle d'accès et de gestion des actifs". Bien que NIS2 ne mentionne pas explicitement le terme "MFA", l'authentification forte est unanimement interprétée comme un prérequis implicite de la conformité, notamment au regard de l'article 21 sur les mesures de gestion des risques. Les sanctions en cas de non-conformité peuvent atteindre 10 millions d'euros ou 2 % du chiffre d'affaires mondial annuel pour les entités essentielles.

DORA (Règlement (UE) 2022/2554)

Le Digital Operational Resilience Act, applicable depuis le 17 janvier 2025, constitue un lex specialis de NIS2 pour le secteur financier. Il impose des exigences détaillées en matière de gestion des risques liés aux TIC, incluant explicitement l'authentification forte. DORA exige la mise en œuvre de "mécanismes d'authentification robustes" et de "contrôles d'accès physiques et logiques solides". Pour les entités financières, l'exigence de MFA est renforcée par l'héritage de la directive DSP2/SCA (Strong Customer Authentication) qui impose déjà l'authentification forte pour les paiements électroniques et l'accès aux comptes bancaires en ligne depuis 2019.

RGPD (Règlement (UE) 2016/679)

Le Règlement général sur la protection des données n'impose pas directement le MFA, mais son article 32 exige la mise en œuvre de "mesures techniques et organisationnelles appropriées" pour garantir un niveau de sécurité adapté au risque. Dans la pratique, les autorités de protection des données (CNIL en France, notamment) considèrent de plus en plus le MFA comme une mesure de sécurité attendue pour l'accès aux systèmes traitant des données personnelles, en particulier les données sensibles (article 9). Le RGPD a également un impact direct sur le déploiement du MFA biométrique : le traitement de données biométriques aux fins d'identification est soumis aux conditions restrictives de l'article 9, nécessitant un consentement explicite ou un autre fondement juridique spécifique. Le modèle FIDO2, où la biométrie est traitée localement et jamais transmise au serveur, est conforme par conception à ces exigences.

SOX (Sarbanes-Oxley Act)

Pour les filiales cotées aux États-Unis ou assujetties aux obligations SOX, le contrôle de l'accès aux systèmes financiers est un axe majeur d'audit. Le MFA pour l'accès aux ERP, systèmes comptables et applications de reporting financier est considéré comme un contrôle interne attendu dans le cadre des sections 302 et 404.

HIPAA (Health Insurance Portability and Accountability Act)

Pour les filiales opérant dans le secteur de la santé aux États-Unis, HIPAA exige des "safeguards" techniques incluant des "procédures de contrôle d'accès" et la "vérification de l'identité des personnes". Le MFA, bien que non explicitement mandaté dans le texte original, est considéré comme une mesure de sécurité "addressable" attendue dans les évaluations de conformité.

3.4 Le MFA dans une approche Zero Trust

L'intégration du MFA dans une architecture Zero Trust dépasse considérablement le simple ajout d'un second facteur d'authentification. Le Zero Trust repose sur cinq piliers fondamentaux — identité, appareil, réseau, application et données — et le MFA intervient de manière transversale sur l'ensemble de ces piliers.

Dans le modèle Zero Trust, l'authentification MFA n'est plus un événement binaire (authentifié/non authentifié) mais un signal continu alimentant un score de confiance. Chaque accès est évalué en fonction de la force de l'authentification utilisée (le facteur MFA utilisé est-il phishing-resistant ?), de la conformité de l'appareil, du contexte réseau, du comportement observé et de la sensibilité de la ressource demandée. Le Policy Decision Point (PDP) agrège ces signaux pour prendre une décision d'accès qui peut être positive (accès autorisé), conditionnelle (accès autorisé avec restrictions ou après step-up authentication), ou négative (accès refusé). Cette décision est réévaluée en continu tout au long de la session, ce qui implique une capacité de réauthentification MFA transparente et peu intrusive — d'où l'importance croissante des facteurs comportementaux et contextuels.

4. PANORAMA DES SOLUTIONS DU MARCHÉ

4.1 Analyse détaillée des principales solutions

4.1.1 Microsoft Entra ID (anciennement Azure AD)

Microsoft Entra ID est la solution d'identité cloud de Microsoft, intégrée nativement à l'écosystème Microsoft 365, Azure et Windows. Son module MFA offre un large éventail de méthodes d'authentification : Microsoft Authenticator (push avec number matching, TOTP, passwordless), Windows Hello for Business (biométrie, PIN lié au TPM), clés de sécurité FIDO2, SMS et appel vocal, certificats X.509, et passkeys. L'approche de Conditional Access de Microsoft constitue l'un des moteurs de Risk-Based MFA les plus avancés du marché, intégrant la conformité de l'appareil (via Intune), la localisation, le niveau de risque de l'utilisateur et du sign-in (via Identity Protection), et l'application cible.

Les forces de Microsoft Entra ID résident dans son intégration native avec l'écosystème Microsoft (Active Directory, Microsoft 365, Azure), sa base installée considérable (plus d'un milliard d'utilisateurs), la richesse de son Conditional Access, et le support natif de FIDO2/passkeys. Ses limitations incluent une dépendance forte à l'écosystème Microsoft, une complexité de licensing (les fonctionnalités MFA avancées nécessitent des licences Entra ID P1 ou P2), et une couverture moins native des environnements non-Microsoft. Le modèle de déploiement est exclusivement SaaS avec une synchronisation possible depuis les annuaires on-premise via Entra Connect. Pour un grand groupe multi-filiales, Microsoft Entra ID est souvent le choix naturel lorsque l'écosystème Microsoft est déjà dominant, avec la possibilité de gérer des tenants multiples ou un tenant unique avec des unités administratives.

Microsoft a été nommé Leader dans le Gartner Magic Quadrant for Access Management 2025 pour la neuvième année consécutive (novembre 2025).

4.1.2 Okta / Auth0

Okta est une plateforme d'identité cloud-native positionnée comme un pure-player de l'IAM, indépendant de tout écosystème infrastructure. Sa solution MFA, Okta Verify, supporte les notifications push avec number matching, TOTP, la biométrie (via le capteur du smartphone), les clés de sécurité FIDO2, et les passkeys. L'acquisition d'Auth0 en 2021 a enrichi l'offre d'Okta sur le volet CIAM (Customer Identity) avec une plateforme particulièrement appréciée des développeurs pour sa flexibilité et ses API.

L'Adaptive MFA d'Okta évalue le risque en temps réel en s'appuyant sur des signaux contextuels (appareil, réseau, localisation, comportement) et permet des politiques granulaires par application, par groupe d'utilisateurs et par niveau de risque. Okta excelle dans sa neutralité vis-à-vis des écosystèmes (intégration native avec plus de 7 000 applications via le Okta Integration Network), sa couverture Workforce + CIAM unifiée, son API-first approach facilitant les intégrations avancées, et la richesse de son moteur de politiques. Les limitations notables sont un coût élevé (modèle par utilisateur par mois, avec les fonctionnalités avancées réservées aux plans supérieurs), la dépendance à une plateforme 100 % SaaS (pas d'option on-premise), et l'incident de sécurité d'octobre 2023 (compromission du système de support) qui a temporairement impacté la confiance du marché, bien qu'Okta ait depuis renforcé considérablement sa posture de sécurité.

Okta a été nommé Leader dans le Gartner Magic Quadrant for Access Management 2025 (novembre 2025).

4.1.3 Ping Identity

Ping Identity propose une plateforme d'identité destinée aux grandes entreprises avec une flexibilité de déploiement importante : cloud (PingOne), hybride et on-premise (PingFederate, PingAccess). Cette polyvalence en fait un choix particulièrement pertinent pour les grands groupes ayant des exigences de souveraineté des données ou des environnements legacy nécessitant un déploiement on-premise.

PingID, le module MFA de Ping, supporte les push notifications, TOTP, FIDO2/passkeys, biométrie (empreinte et faciale), QR code et SMS/email. La solution PingOne DaVinci offre un orchestrateur d'identité visuel permettant de créer des flux d'authentification complexes sans code, intégrant le MFA, la vérification d'identité, la détection de fraude et l'évaluation du risque en une chaîne unifiée.

Ping Identity a été nommé Leader dans le KuppingerCole Leadership Compass Access Management 2025, avec des scores élevés en matière d'orchestration, de sécurité et de flexibilité. Pour un grand groupe multi-filiales, Ping Identity offre l'avantage d'une architecture hybride permettant de répondre aux exigences spécifiques de chaque filiale en termes de souveraineté et de modèle de déploiement.

4.1.4 CyberArk (Identity / Workforce Identity)

CyberArk, historiquement leader incontesté de la gestion des accès à privilèges (PAM), a étendu son périmètre à la gestion des identités workforce avec l'acquisition d'Idaptive (elle-même issue de Centrify). La convergence IAM + PAM offre une proposition de valeur unique : une plateforme unifiée capable de gérer le MFA pour les utilisateurs standards et les comptes à privilèges dans un continuum de sécurité.

CyberArk Identity MFA supporte les push notifications, TOTP, FIDO2, clés de sécurité, biométrie, QR code et OTP par email/SMS. Son MFA adaptatif intègre nativement les signaux de risque provenant des modules PAM (détection de comportements anormaux sur les sessions privilégiées) pour une évaluation du risque enrichie. CyberArk a été nommé Leader dans le Forrester Wave Privileged Identity Management Q3 2025, confirmant sa domination sur le segment PAM.

Pour un grand groupe multi-filiales, CyberArk représente un choix stratégique particulièrement pertinent lorsque la refonte IAM inclut un volet PAM majeur et que la convergence IAM/PAM est un objectif architectural. Sa faiblesse relative réside dans la moindre maturité de ses fonctionnalités workforce IAM pure par rapport aux pure-players comme Okta ou Microsoft.

4.1.5 Thales (SafeNet Trusted Access)

Thales, à travers sa division Digital Identity & Security et sa solution SafeNet Trusted Access (héritée de l'acquisition de Gemalto), propose une offre MFA historiquement forte sur le marché européen, avec une expertise reconnue en matière de tokens matériels, smart cards et PKI. SafeNet offre l'un des catalogues d'authentificateurs les plus larges du marché : tokens OTP matériels (SafeNet eToken), tokens logiciels, push (MobilePASS+), FIDO2, certificats X.509, smart cards, grilles d'authentification (GrIDsure), et biométrie.

Les forces de Thales résident dans sa couverture européenne et son alignement avec les exigences de souveraineté (hébergement des données en Europe, conformité eIDAS), la richesse de son catalogue d'authentificateurs matériels (essentiel pour les environnements nécessitant des tokens physiques), et son modèle hybride (cloud et on-premise). Ses limitations incluent une interface d'administration considérée comme moins moderne que celle des pure-players cloud, et un écosystème d'intégrations applicatives moins étendu que celui d'Okta ou Microsoft.

4.1.6 Duo Security (Cisco)

Duo Security, acquise par Cisco en 2018, s'est positionnée comme la solution MFA la plus simple à déployer du marché, avec un time-to-value remarquablement court. Duo Push, sa notification push phare, offre une expérience utilisateur fluide avec number matching et contexte géographique. La solution supporte également TOTP, FIDO2/WebAuthn, biométrie, SMS, appel téléphonique et tokens matériels.

Duo Trusted Access intègre l'évaluation de la posture de l'appareil (système d'exploitation, chiffrement, état de l'antivirus) dans la décision d'authentification, s'inscrivant pleinement dans la logique Zero Trust. L'intégration dans l'écosystème Cisco (ISE, AnyConnect VPN, Umbrella) constitue un avantage dans les environnements réseau Cisco. Duo propose des plans tarifaires progressifs (Free, Essentials, Advantage, Premier) qui facilitent l'adoption incrémentale.

Pour un grand groupe multi-filiales, Duo offre l'avantage d'un déploiement rapide pouvant servir de quick win initial, avant une éventuelle convergence vers une plateforme IAM plus complète. Sa limitation principale est qu'elle reste une solution MFA/access management et ne couvre pas les besoins IGA, SSO avancé ou PAM de manière native.

4.1.7 Yubico

Yubico, inventeur de la YubiKey et co-créateur du standard FIDO U2F puis FIDO2, occupe une position unique en tant que fournisseur d'authentificateurs matériels phishing-resistant de référence. Les YubiKeys supportent FIDO2/WebAuthn, FIDO U2F, smart card (PIV), OpenPGP, OATH-TOTP, OATH-HOTP et OTP Yubico. Elles sont disponibles en format USB-A, USB-C, NFC et Lightning, couvrant l'ensemble des facteurs de forme nécessaires.

Yubico complète son offre matérielle avec YubiEnterprise Delivery (plateforme logistique de distribution et remplacement des clés à l'échelle de l'entreprise), YubiEnterprise Subscription (modèle d'abonnement incluant le remplacement des clés) et Yubico Authenticator (application compagnon pour TOTP).

Pour un grand groupe multi-filiales, Yubico n'est pas une solution MFA complète à proprement parler mais un fournisseur d'authentificateurs qui se combine avec toutes les plateformes IAM du marché (Entra ID, Okta, Ping, CyberArk, etc.). Le programme YubiEnterprise est spécifiquement conçu pour les déploiements à grande échelle avec gestion logistique multi-sites. Le coût par clé (25 à 70 € selon le modèle) et la nécessité de fournir des clés de secours doivent être intégrés au TCO global.

4.1.8 ForgeRock (désormais partie de Ping Identity)

ForgeRock, acquise par Thoma Bravo en 2023 puis rapprochée de Ping Identity, offrait une plateforme d'identité open-source enterprise (basée sur OpenAM/OpenIDM) avec une forte présence dans les secteurs de la banque, de l'assurance et des télécommunications. Sa solution MFA intégrait l'authentification adaptative, FIDO2, push, TOTP et des arbres d'authentification (authentication trees) permettant une orchestration visuelle sophistiquée des flux. Suite au rapprochement avec Ping Identity, la stratégie produit converge vers une plateforme unifiée PingOne combinant les forces des deux solutions. Pour les organisations évaluant ForgeRock, il est recommandé d'analyser la feuille de route commune Ping/ForgeRock et la trajectoire de convergence des produits.

4.1.9 OneSpan

OneSpan se distingue par son expertise historique dans la sécurité des transactions financières et la signature électronique. Sa solution DIGIPASS supporte une gamme étendue de tokens matériels et logiciels, complétée par Intelligent Adaptive Authentication, un moteur d'authentification adaptative dopé à l'intelligence artificielle et au machine learning, spécialisé dans la détection de fraude en temps réel.

OneSpan est particulièrement pertinent pour les filiales bancaires ou financières du groupe, où la conformité DSP2/SCA et DORA exige un niveau d'authentification transactionnelle avancé. Sa force réside dans l'analyse comportementale des transactions, la détection de manipulation de l'appareil et la signature visuelle des transactions (WYSIWYS — What You See Is What You Sign). Sa couverture est en revanche plus limitée pour les cas d'usage workforce IAM génériques.

4.1.10 IBM Security Verify

IBM Security Verify est une plateforme IAM cloud qui intègre le MFA adaptatif, le SSO, la gestion du cycle de vie des identités et la gouvernance. Son module MFA supporte les push notifications, TOTP, FIDO2, biométrie (empreinte, faciale), email OTP, SMS et QR code. L'intelligence artificielle d'IBM (Watson/AI) alimente le moteur de Risk-Based Authentication avec des capacités d'analyse comportementale et de détection d'anomalies.

IBM a été nommé Leader dans le Gartner Magic Quadrant for Access Management 2025 (novembre 2025), une reconnaissance notable de sa progression sur ce segment. Les forces d'IBM Security Verify incluent la couverture fonctionnelle IAM/IGA complète au sein d'un même écosystème, les capacités IA avancées pour l'authentification adaptative, le support multi-cloud et hybride, et la crédibilité d'IBM auprès des grandes entreprises. Le positionnement tarifaire et la complexité de l'écosystème IBM peuvent constituer des freins.

4.1.11 Transmit Security

Transmit Security mérite une mention particulière en tant qu'acteur émergent qui a été reconnu comme Leader dans le Gartner Magic Quadrant for Access Management 2025 — une progression remarquable. Sa plateforme se différencie par une approche API-first et une spécialisation dans l'orchestration de parcours d'identité complexes, avec un focus sur l'authentification passwordless native et la détection de fraude intégrée. Pour un grand groupe cherchant une solution innovante et flexible, Transmit Security représente une option à évaluer, notamment pour les cas d'usage CIAM.

4.1.12 RSA

RSA, historiquement synonyme du token SecurID qui a contribué à populariser le MFA dans les entreprises, maintient une présence significative avec sa solution RSA ID Plus. La plateforme a évolué vers le cloud et le MFA moderne (FIDO2, biométrie, push) tout en maintenant la compatibilité avec les tokens matériels SecurID encore déployés dans de nombreuses organisations. RSA a été reconnu comme acteur de niche (Niche Player) dans le Gartner Magic Quadrant for Access Management 2025. Pour les organisations ayant un historique RSA, la trajectoire de modernisation vers ID Plus mérite d'être évaluée par rapport à une migration vers une plateforme alternative.

4.2 Matrice de comparaison synthétique

4.3 Positionnement des analystes (données les plus récentes)

Le Gartner Magic Quadrant for Access Management de novembre 2025 identifie cinq Leaders : Microsoft, Okta, Ping Identity, IBM et Transmit Security. Ce positionnement reflète la consolidation du marché autour de plateformes complètes combinant SSO, MFA, passwordless, adaptive authentication et orchestration d'identité.

Le KuppingerCole Leadership Compass Access Management 2025, publié en juin 2025, confirme les positions de leadership de Ping Identity, Okta et Microsoft, avec une attention particulière portée aux capacités d'orchestration, de support des standards FIDO2 et d'authentification adaptative.

Le Forrester Wave Privileged Identity Management Q3 2025 positionne CyberArk et BeyondTrust comme Leaders, soulignant la convergence croissante entre PAM et MFA dans la protection des accès à privilèges.

Le Forrester State of Workforce Identity and Access Management 2025 (novembre 2025) fournit des benchmarks de dépenses et d'adoption technologique qui confirment l'accélération des investissements en MFA et passwordless dans les grandes organisations.

5. ARCHITECTURE ET INTÉGRATION

5.1 Architecture MFA de référence pour un grand groupe multi-filiales

L'architecture MFA cible pour un grand groupe multi-filiales doit répondre à des exigences apparemment contradictoires : centralisation de la gouvernance et des politiques de sécurité d'une part, flexibilité et autonomie opérationnelle des filiales d'autre part. L'architecture de référence recommandée s'articule autour de plusieurs couches.

La couche de gouvernance centrale (Corporate Identity Authority) constitue le cœur de l'architecture. Elle héberge le moteur de politiques MFA centralisé définissant le socle commun de sécurité (politiques minimales obligatoires pour l'ensemble du groupe), le référentiel d'identités maître (meta-directory ou identity hub) fédérant les identités de toutes les filiales, le portail d'administration centralisé permettant la supervision, le reporting et l'audit consolidés, et le moteur de Risk-Based Authentication global alimenté par les signaux de toutes les entités.

La couche de fédération (Federation Hub) assure l'interopérabilité entre les filiales et avec l'extérieur. Elle implémente un Identity Provider (IdP) central ou un broker de fédération connecté aux IdP locaux des filiales, supporte SAML 2.0 et OIDC pour la fédération des identités, et gère les trusts inter-filiales et les relations avec les partenaires B2B. Ce hub de fédération permet aux filiales disposant de leur propre IdP de s'intégrer à l'écosystème du groupe sans migration brutale de leurs identités.

La couche d'authentification MFA regroupe les services d'authentification proprement dits : le service MFA central (cloud ou hybride) intégré à l'IdP, les adaptateurs MFA pour les applications legacy (RADIUS, agents web, SDK), les connecteurs vers les différentes méthodes d'authentification (push, TOTP, FIDO2, biométrie, etc.), et le service d'enrollment et de gestion du cycle de vie des facteurs MFA (portail self-service). Cette couche peut être implémentée de manière centralisée (une instance unique pour tout le groupe) ou fédérée (des instances locales synchronisées avec une gouvernance centrale), selon les contraintes de latence, de souveraineté des données et d'autonomie des filiales.

La couche d'intégration applicative constitue le dernier maillon, assurant la connexion du MFA aux ressources protégées via des agents applicatifs pour les applications web on-premise, des connecteurs SAML/OIDC pour les applications SaaS, des serveurs RADIUS pour les accès VPN et réseau, des credential providers pour le logon Windows/Mac, des SDK mobiles pour les applications mobiles propriétaires, et des API REST pour les intégrations custom et DevOps.

5.2 Intégration dans l'écosystème IAM/IGA

Le MFA ne peut être conçu comme un silo technologique ; il doit s'intégrer de manière cohérente dans l'écosystème IAM/IGA complet.

L'intégration avec le SSO est la plus fondamentale : le MFA doit intervenir lors de la session SSO initiale, et le niveau MFA utilisé doit être propagé aux applications via les assertions SAML (attribut AuthnContextClassRef) ou les claims OIDC (acr, amr). Les applications peuvent ainsi prendre des décisions d'autorisation différenciées en fonction du niveau d'authentification.

L'intégration avec la fédération d'identités est essentielle dans un contexte multi-filiales. Le broker de fédération doit être capable de "step-up" le MFA lorsqu'une application d'une filiale A accédée par un utilisateur d'une filiale B exige un niveau d'authentification supérieur à celui de la session de l'utilisateur.

L'intégration avec le provisioning (IGA) garantit que les facteurs MFA sont gérés en cohérence avec le cycle de vie de l'identité : l'enrollment MFA est déclenché lors de l'onboarding de l'utilisateur, les facteurs MFA sont mis à jour lors des changements de rôle ou de sensibilité, et les facteurs MFA sont révoqués lors du départ de l'utilisateur ou de la révocation de ses accès.

L'intégration avec la gouvernance (IGA) permet d'inclure le MFA dans les politiques de conformité et les campagnes de recertification : vérification que tous les utilisateurs à haut risque ont un facteur MFA phishing-resistant enregistré, audit des méthodes MFA utilisées par population et par filiale, et reporting de conformité réglementaire (NIS2, DORA).

L'intégration avec le PAM est critique pour les comptes à privilèges. Les solutions PAM modernes doivent exiger un MFA de niveau AAL3 (clé physique FIDO2 ou smart card) avant toute ouverture de session privilégiée, supporter le MFA pour l'approbation des demandes d'élévation de privilèges (JIT — Just-In-Time), et intégrer les signaux MFA dans l'analyse comportementale des sessions privilégiées.

5.3 Patterns d'architecture : centralisé, fédéré, hybride

Le pattern centralisé déploie une instance unique de la solution MFA pour l'ensemble du groupe. Toutes les filiales s'authentifient via le même service, avec des politiques MFA gérées centralement. Ce pattern offre une gouvernance unifiée, un coût de possession optimisé et une administration simplifiée. Il est recommandé lorsque le groupe a une maturité IAM homogène, une stratégie cloud-first et des exigences de souveraineté compatibles avec un hébergement centralisé. Sa limitation principale est la dépendance à un point unique (nécessitant une haute disponibilité robuste) et le risque de latence pour les filiales géographiquement éloignées.

Le pattern fédéré permet à chaque filiale de conserver son propre IdP et sa solution MFA, avec une interconnexion via un hub de fédération et des politiques de sécurité minimales imposées par le groupe. Ce pattern respecte l'autonomie des filiales et facilite l'intégration de nouvelles entités acquises. Il est recommandé dans les contextes de forte hétérogénéité technologique, d'exigences de souveraineté locale ou de résistance culturelle à la centralisation. Sa complexité de gouvernance et son coût plus élevé (multiples instances à maintenir) constituent ses principales limitations.

Le pattern hybride, recommandé comme cible pour la majorité des grands groupes multi-filiales, combine une gouvernance centrale (politiques, reporting, audit) avec une flexibilité de déploiement locale. Le service MFA central est utilisé par défaut, mais les filiales ayant des exigences spécifiques (souveraineté, environnements legacy, historique technologique fort) peuvent opérer leur propre service MFA à condition de se conformer aux politiques minimales du groupe et de s'interconnecter avec le hub de fédération. Ce pattern offre le meilleur compromis entre contrôle et agilité.

5.4 Intégration avec les environnements

L'intégration du MFA avec Active Directory et Entra ID constitue la pierre angulaire pour la plupart des grands groupes. Le MFA doit protéger l'authentification Windows (logon poste de travail), l'accès aux applications intégrées AD (Kerberos, NTLM), l'accès aux portails Entra ID et Microsoft 365, et les opérations d'administration AD/Entra ID. Microsoft Entra MFA gère nativement ces scénarios ; les solutions tierces (Okta, Duo, CyberArk) proposent des agents on-premise ou des intégrations fédérées pour couvrir le même périmètre.

Pour les applications SaaS, l'intégration s'effectue principalement via SAML 2.0 ou OIDC, avec le MFA appliqué au niveau de l'IdP lors de l'authentification fédérée. Les connecteurs pré-intégrés (catalogues Okta, Microsoft, Ping) simplifient considérablement le déploiement. Pour les applications SaaS ne supportant pas la fédération, des approches alternatives (Secure Web Gateway, CASB avec re-authentification MFA) peuvent être envisagées.

Les applications legacy on-premise représentent souvent le défi le plus complexe. Les approches d'intégration incluent les agents applicatifs (installés sur le serveur web ou applicatif), les reverse proxies d'authentification (interposés devant l'application), les serveurs RADIUS (pour les applications supportant RADIUS, notamment les VPN et les équipements réseau), les connecteurs mainframe/AS400 (pour les environnements les plus anciens), et les API gateways pour les applications proposant des API. Certaines applications legacy ne supportant aucune de ces méthodes peuvent nécessiter un wrapping applicatif ou une migration.

Pour les accès VPN et distants, l'intégration s'effectue généralement via RADIUS (protocole standard supporté par tous les concentrateurs VPN) ou SAML (pour les VPN supportant l'authentification web). Le MFA pour le VPN est un quick win fréquent lors du déploiement initial car il protège un vecteur d'attaque critique (l'accès au réseau d'entreprise) sans nécessiter de modification des applications internes.

L'intégration sur les postes de travail (Windows, Mac, Linux) nécessite l'installation d'un credential provider (Windows) ou d'un mécanisme PAM (Linux/Mac) qui intercepte le processus d'authentification local. Windows Hello for Business (pour les environnements Microsoft) et les agents tiers (Duo, CyberArk, Thales) offrent cette fonctionnalité. La gestion du mode hors-ligne (offline MFA) est un enjeu spécifique : le MFA doit continuer à fonctionner lorsque le poste de travail n'a pas de connectivité réseau, ce qui implique un cache local sécurisé des facteurs d'authentification ou l'utilisation d'une méthode offline (TOTP, FIDO2 avec authentificateur local).

Pour les applications mobiles, le SDK de la solution MFA est intégré dans l'application mobile pour offrir une authentification native (biométrie du smartphone, FIDO2 platform authenticator) sans redirection vers un navigateur externe. Les solutions comme Okta, Microsoft et Ping proposent des SDK mobiles matures pour iOS et Android.

Les environnements OT (Operational Technology) et IoT posent des défis spécifiques : les systèmes de contrôle industriel (SCADA, ICS) fonctionnent souvent sur des systèmes d'exploitation obsolètes, ont des contraintes temps-réel incompatibles avec les délais d'authentification interactive, et ne supportent pas les protocoles d'identité modernes. L'approche recommandée combine un MFA au point d'entrée (jump server, bastion) plutôt que sur chaque système OT, l'utilisation de solutions PAM spécialisées OT (CyberArk, Wallix) avec MFA intégré, et la segmentation réseau stricte entre les zones IT et OT avec authentification MFA au point de passage.

5.5 Considérations multi-tenant / multi-filiales

La gouvernance centralisée vs. l'autonomie des filiales constitue la tension architecturale fondamentale d'un déploiement MFA multi-filiales. L'approche recommandée définit un socle de politiques MFA non négociables imposé par le groupe (par exemple : MFA obligatoire pour tous les accès à privilèges, interdiction du SMS OTP comme seul second facteur, enrollment FIDO2 obligatoire pour les populations IT) tout en laissant aux filiales la latitude d'appliquer des politiques plus restrictives ou des méthodes supplémentaires adaptées à leur contexte local.

Les politiques MFA différenciées par entité et par population sont essentielles pour gérer la diversité d'un grand groupe. Une segmentation typique distingue les dirigeants et membres du COMEX (niveau très élevé, FIDO2 obligatoire + device managed), les administrateurs IT et comptes à privilèges (AAL3, clé physique FIDO2 obligatoire), les développeurs et DevOps (FIDO2 + MFA pour les accès aux pipelines CI/CD et aux environnements de production), les collaborateurs sédentaires standards (AAL2, push notification ou TOTP minimum), les collaborateurs nomades (AAL2 renforcé, device trust obligatoire), les prestataires et partenaires B2B (MFA obligatoire, méthodes compatibles avec le BYOD), et les utilisateurs en zones à faible infrastructure technologique (méthodes offline, tokens matériels).

5.6 Haute disponibilité, résilience et mode dégradé

Le MFA devenant un composant critique de l'infrastructure (un dysfonctionnement bloque tous les accès), la haute disponibilité est une exigence non négociable. L'architecture doit prévoir une redondance géographique (instances multi-régions pour les solutions SaaS, clusters actif-actif pour les déploiements on-premise), des SLA contractuels exigeants (99,99 % minimum, soit moins de 52 minutes d'indisponibilité par an), et un monitoring en temps réel de la disponibilité du service MFA.

La gestion du mode dégradé définit le comportement du système lorsque le service MFA est indisponible. Trois approches existent : le fail-closed (tout accès est refusé si le MFA est indisponible — sécurité maximale mais impact opérationnel majeur), le fail-open conditionnel (l'accès est autorisé sans MFA sous certaines conditions strictement définies et auditées — compromis risqué mais parfois nécessaire), et le fallback vers une méthode MFA alternative offline (TOTP local, clé FIDO2 en mode offline — approche recommandée). La politique de mode dégradé doit être formalisée, validée par le RSSI, et régulièrement testée.

5.7 Gestion du cycle de vie des facteurs MFA

L'enrollment (enregistrement initial des facteurs MFA) doit être intégré au processus d'onboarding des utilisateurs. Les bonnes pratiques incluent un enrollment guidé lors de la première connexion ou via un portail self-service dédié, l'obligation d'enregistrer au minimum deux facteurs MFA (un principal et un de secours), la vérification d'identité renforcée lors de l'enrollment initial (via un manager, un desk IT ou une vérification d'identité à distance), et un délai de grâce limité et contrôlé pour les utilisateurs n'ayant pas complété leur enrollment.

Le recovery (récupération en cas de perte d'accès aux facteurs MFA) est l'un des processus les plus critiques et les plus fréquemment sous-estimés. La perte d'un smartphone ou d'une clé de sécurité peut bloquer totalement l'utilisateur. Les mécanismes de recovery doivent inclure un second facteur de secours pré-enregistré (d'où l'importance d'exiger deux facteurs minimum), des codes de récupération à usage unique (recovery codes) générés lors de l'enrollment et stockés de manière sécurisée, une procédure de récupération supervisée par le helpdesk avec vérification d'identité renforcée (et le processus de vérification d'identité du helpdesk lui-même doit être sécurisé contre l'ingénierie sociale), et des procédures d'urgence pour les comptes à privilèges avec approbation multi-niveaux.

La révocation des facteurs MFA doit être automatisée dans le workflow de départ (offboarding) et déclenchée immédiatement en cas de suspicion de compromission. Le remplacement (perte, vol, changement d'appareil) doit être fluide via un portail self-service tout en maintenant un niveau de vérification suffisant pour prévenir les attaques de prise de contrôle de compte.

6. CAS D'USAGE DÉTAILLÉS

6.1 MFA pour les collaborateurs internes (Workforce)

Le cas d'usage workforce est le plus vaste en volume et le plus structurant pour l'architecture. Il couvre l'ensemble des salariés du groupe, typiquement des milliers à des dizaines de milliers d'utilisateurs répartis sur plusieurs filiales et géographies.

Les enjeux spécifiques incluent l'équilibre entre sécurité et productivité (un MFA trop contraignant génère de la frustration et des contournements), la diversité des profils et des environnements de travail (sédentaires, nomades, terrain, usines), et la nécessité de supporter le BYOD (Bring Your Own Device) pour les utilisateurs ne disposant pas d'un smartphone d'entreprise. L'approche recommandée s'appuie sur un MFA adaptatif comme socle, combinant push notification avec number matching comme méthode standard (bon équilibre sécurité/ergonomie), passkeys/FIDO2 comme cible de migration progressive (phishing-resistant, excellente UX), et TOTP comme fallback universel. Le niveau MFA cible est AAL2 minimum pour tous les accès, avec step-up vers AAL3 pour les accès sensibles.

6.2 MFA pour les administrateurs et comptes à privilèges

Ce cas d'usage est le plus critique du point de vue de la sécurité : la compromission d'un compte administrateur peut entraîner une prise de contrôle complète du système d'information. Le Verizon DBIR 2025 et l'ensemble des frameworks de sécurité positionnent la protection des accès à privilèges comme la priorité absolue.

L'approche recommandée exige un MFA de niveau AAL3 systématique (clé de sécurité physique FIDO2 ou smart card — aucune exception), un MFA à chaque élévation de privilège (même au sein d'une session déjà authentifiée), l'interdiction des méthodes MFA phishable (SMS, email, TOTP standard) pour les comptes à privilèges, l'intégration native avec la solution PAM (CyberArk, BeyondTrust, Wallix) pour que le MFA soit une condition préalable à l'ouverture de toute session privilégiée, et un monitoring continu des sessions privilégiées avec possibilité de réauthentification MFA en cas d'anomalie comportementale.

6.3 MFA pour les prestataires et partenaires externes (B2B)

La gestion du MFA pour les populations externes (prestataires, sous-traitants, partenaires) pose des défis spécifiques liés à l'absence de contrôle sur les appareils et les identités de ces utilisateurs. Le DBIR 2025 souligne que l'implication de tiers dans les brèches a doublé en un an (de 15 % à 30 %), rendant ce cas d'usage particulièrement critique.

Les approches possibles incluent la fédération d'identités B2B (le partenaire s'authentifie avec son propre IdP et le trust de fédération transmet le niveau MFA — approche préférable lorsque le partenaire a une maturité IAM suffisante), les identités B2B managées (le groupe crée et gère des identités pour les prestataires dans son propre annuaire, avec un MFA imposé — approche Microsoft Entra External ID / Okta Universal Directory), et le BYOI (Bring Your Own Identity) avec MFA obligatoire (le prestataire utilise une identité sociale ou professionnelle vérifiée avec un MFA additionnel imposé par le groupe). Le niveau MFA cible minimum est AAL2, avec AAL3 pour les prestataires accédant à des environnements de production ou des données sensibles.

6.4 MFA pour les clients (CIAM/B2C)

Le MFA B2C obéit à des contraintes radicalement différentes du workforce : l'expérience utilisateur est le critère dominant car tout friction excessive entraîne un abandon et une perte de chiffre d'affaires. Le taux de conversion et la fluidité du parcours client doivent être préservés tout en assurant la sécurité des comptes.

L'approche recommandée s'appuie sur un MFA progressif et contextualisé, où l'authentification est renforcée uniquement lorsque le risque le justifie (connexion depuis un nouvel appareil, transaction sensible, changement de coordonnées). Les passkeys constituent le vecteur de transformation le plus prometteur pour le B2C : plus rapides, plus sûres et plus simples que les mots de passe, elles permettent de renforcer la sécurité tout en améliorant le taux de conversion. Les solutions CIAM spécialisées (Auth0/Okta, Transmit Security, ForgeRock/Ping, OneSpan pour le secteur financier) offrent des capacités d'orchestration de parcours adaptées aux exigences B2C.

6.5 MFA pour l'accès aux applications cloud (SaaS)

La protection des applications SaaS par le MFA s'effectue naturellement via la fédération d'identités : les applications SaaS sont configurées pour déléguer l'authentification à l'IdP d'entreprise (via SAML 2.0 ou OIDC), et le MFA est appliqué au niveau de l'IdP. Cette approche présente l'avantage majeur de centraliser le contrôle MFA et de ne pas dépendre des capacités MFA natives (souvent hétérogènes) de chaque application SaaS.

Les enjeux spécifiques incluent le shadow IT (applications SaaS adoptées hors du circuit IAM officiel et non protégées par le MFA — les solutions CASB aident à détecter et contrôler ces applications), les comptes d'administration SaaS (les comptes admin des tenants SaaS, souvent hors périmètre SSO, nécessitent un MFA dédié et renforcé), et les tokens OAuth (les accès applicatifs via tokens OAuth de longue durée peuvent contourner le MFA — une politique de rotation des tokens et de conditional access sur les app registrations est nécessaire).

6.6 MFA pour l'accès aux systèmes legacy / on-premise

L'intégration du MFA avec les applications legacy constitue souvent le chantier le plus complexe et le plus chronophage. Les applications développées il y a 10, 20 ou 30 ans n'ont pas été conçues pour supporter les protocoles d'identité modernes. Les approches d'intégration, par ordre de préférence, sont la modernisation de l'authentification de l'application (ajout du support SAML/OIDC — souvent irréaliste à court terme), l'interposition d'un reverse proxy d'authentification qui gère le MFA et transmet l'identité vérifiée à l'application via des headers HTTP, l'injection de credentials post-MFA (la solution MFA vérifie l'identité puis injecte automatiquement les credentials dans l'application legacy — technologie Enterprise SSO / ESSO), et l'accès via un bastion/jump server avec MFA appliqué au niveau du bastion avant d'accéder aux applications legacy. Le plan de déploiement doit inventorier les applications legacy, évaluer leur capacité d'intégration et prioriser celles présentant le risque le plus élevé.

6.7 MFA pour l'accès VPN et accès distant

Le MFA pour les accès VPN et distants est universellement reconnu comme l'un des quick wins les plus efficaces en termes de réduction du risque. La majorité des concentrateurs VPN (Cisco AnyConnect, Palo Alto GlobalProtect, Fortinet FortiGate, etc.) supportent RADIUS et/ou SAML, rendant l'intégration MFA relativement directe. L'approche recommandée impose le MFA pour toute connexion VPN, utilise le Risk-Based MFA pour adapter le niveau d'exigence au contexte (connexion depuis un pays autorisé sur un appareil managé vs. connexion depuis un pays à risque sur un appareil inconnu), et intègre l'évaluation de la posture de l'appareil (device trust) dans la décision d'accès.

6.8 MFA pour les environnements DevOps / CI-CD

La sécurisation des environnements DevOps par le MFA couvre plusieurs points d'accès critiques : les dépôts de code source (GitHub, GitLab, Bitbucket), les pipelines CI/CD (Jenkins, Azure DevOps, GitLab CI), les registres de conteneurs et d'artefacts, les consoles cloud (AWS, Azure, GCP), les outils d'Infrastructure as Code (Terraform, Ansible), et les secrets managers (HashiCorp Vault, CyberArk Conjur, AWS Secrets Manager).

L'enjeu spécifique du DevOps est l'équilibre entre sécurité et vélocité de développement. Le MFA ne doit pas entraver les cycles de déploiement tout en protégeant les environnements de production. Les approches recommandées incluent le MFA obligatoire pour l'accès aux environnements de production (step-up par rapport aux environnements de développement), les signed commits avec clés FIDO2 pour garantir l'intégrité du code, la gestion centralisée des secrets avec MFA pour l'accès au vault, et des tokens d'accès aux API à durée de vie limitée avec rotation automatique.

6.9 MFA pour les environnements OT / industriels

Comme évoqué dans la section architecture, les environnements OT présentent des contraintes spécifiques qui rendent l'application directe du MFA sur chaque système impraticable. L'approche par bastions et jump servers avec MFA au point d'entrée est la plus répandue. Les enjeux spécifiques incluent la compatibilité avec les systèmes SCADA anciens (pas de support des protocoles modernes), les contraintes temps-réel (pas de latence d'authentification acceptable sur les boucles de contrôle), les environnements physiquement isolés (air-gapped) nécessitant des méthodes MFA offline, et la gestion des comptes partagés (encore fréquents en environnement industriel) qui nécessite une solution de coffre-fort de mots de passe (PAM) avec MFA pour le check-out.

6.10 MFA sur les postes de travail

Le MFA au logon du poste de travail (Windows Hello for Business, credential providers tiers) constitue la première ligne de défense en cas d'accès physique non autorisé et complète le MFA applicatif. Sous Windows, Windows Hello for Business offre une solution native intégrant biométrie (empreinte, reconnaissance faciale), PIN lié au TPM et/ou clé FIDO2, le tout dans un modèle passwordless. Les solutions tierces (Duo, CyberArk, Thales) ajoutent des fonctionnalités telles que le MFA offline (cache local des facteurs), le MFA pour l'accès RDP, et le support des environnements non-Windows (Mac via des agents spécifiques, Linux via des modules PAM).

6.11 MFA dans un contexte de fusion/acquisition

L'intégration d'une filiale acquise dans l'écosystème IAM/MFA du groupe est un cas d'usage stratégique récurrent. L'approche recommandée suit un processus en trois phases. La phase 1 (immédiate, J+0 à J+30) impose un MFA minimal sur les points d'accès les plus critiques de l'entité acquise (VPN, email, comptes à privilèges) via une solution rapid-deploy comme Duo, sans modification de l'infrastructure IAM existante de l'entité. La phase 2 (court terme, J+30 à J+180) établit une fédération d'identités entre l'entité acquise et le groupe, permettant un SSO cross-entités avec MFA centralisé pour les accès aux ressources du groupe. La phase 3 (moyen terme, J+180 à J+365) planifie la migration progressive vers la plateforme MFA cible du groupe, avec harmonisation des politiques et des méthodes d'authentification.

7. TENDANCES ET ÉVOLUTIONS DU MARCHÉ

7.1 Passwordless et la fin annoncée du mot de passe

La disparition du mot de passe est annoncée depuis plus d'une décennie, mais l'année 2025 a marqué un tournant tangible. La décision de Microsoft de passer en "passwordless by default" pour tous les nouveaux comptes constitue un signal de marché majeur, venant du gestionnaire d'identités numériques le plus vaste au monde. Combinée aux investissements similaires d'Apple (passkeys intégrées à iCloud Keychain et synchronisées via AirDrop) et de Google (passkeys dans Google Password Manager et Android), cette convergence des trois géants de la tech crée un effet d'entraînement sans précédent.

Cependant, l'horizon temporel de la disparition complète du mot de passe est réaliste à 5-10 ans plutôt qu'à court terme. Les freins résiduels incluent l'immense base installée d'applications ne supportant pas le passwordless, les populations utilisatrices sans smartphone ou sans appareil compatible (environnements industriels, pays en développement), les processus de recovery qui, paradoxalement, retombent souvent sur le mot de passe comme ultime filet de sécurité, et la résistance culturelle et les habitudes profondément ancrées. Pour un grand groupe, la trajectoire recommandée est d'adopter une stratégie "passwordless-first" (tout nouveau déploiement privilégie le passwordless) tout en maintenant la compatibilité avec les mots de passe pour une période transitoire, avec un objectif de couverture passwordless à 80 % des accès workforce à horizon 3 ans.

7.2 Passkeys : état d'adoption et implications

L'adoption des passkeys a atteint un point d'inflexion en 2025. Les chiffres sont éloquents : 87 % des entreprises aux États-Unis et au Royaume-Uni ont déployé ou sont en cours de déploiement de passkeys (source : FIDO Alliance / HYPR, 2025), 69 % des utilisateurs grand public possèdent au moins une passkey, 48 % des 100 premiers sites web mondiaux supportent les passkeys, et le taux de réussite de connexion atteint 93 % avec passkeys contre 63 % avec les méthodes traditionnelles.

Les implications pour un grand groupe sont multiples. Stratégiquement, les passkeys doivent être intégrées dans la feuille de route MFA comme méthode cible. Techniquement, la plateforme IAM retenue doit supporter nativement les passkeys (synced et device-bound). Opérationnellement, les processus d'enrollment, de recovery et de support doivent être repensés pour le paradigme passkey. Financièrement, les passkeys offrent un potentiel de réduction du TCO significatif (moins d'appels au helpdesk pour les réinitialisations de mots de passe, moins de tokens matériels à gérer pour les populations standards).

La distinction entre passkeys synchronisées et device-bound reste un enjeu de politique de sécurité : les passkeys synchronisées offrent une meilleure ergonomie mais dépendent de la sécurité du compte cloud de l'utilisateur (Apple ID, Google Account, Microsoft Account), tandis que les passkeys device-bound (clés physiques) offrent le niveau AAL3 mais nécessitent une gestion logistique matérielle.

7.3 MFA résistant au phishing : le nouveau standard

L'analyse du Verizon DBIR 2025 sur les attaques contre Microsoft 365 quantifie la réalité des attaques contournant le MFA traditionnel : 31 % des attaques utilisaient le vol de token, 22 % le MFA fatigue / prompt bombing, et 9 % les attaques adversary-in-the-middle (AiTM). Ces chiffres démontrent que le MFA basé sur OTP (SMS, TOTP) et push notification simple n'est plus suffisant contre des attaquants sophistiqués.

Le MFA phishing-resistant — principalement FIDO2/WebAuthn/passkeys et les certificats PKI — neutralise structurellement ces vecteurs d'attaque. La liaison cryptographique au domaine (origin binding) rend le phishing et les attaques AiTM inopérants, l'absence de secret partagé transmis rend le vol de token inutile, et l'absence de notification à approuver élimine le vecteur MFA fatigue.

La CISA (Cybersecurity and Infrastructure Security Agency) américaine a officiellement désigné FIDO/WebAuthn et l'authentification PKI comme les seules méthodes d'authentification phishing-resistant approuvées. Cette position est de facto devenue le standard de référence mondial.

Pour un grand groupe, la recommandation est d'établir le MFA phishing-resistant comme cible obligatoire pour les populations à haut risque (administrateurs, dirigeants, développeurs) à court terme (12 mois) et comme cible pour l'ensemble de la population à moyen terme (24-36 mois), avec un plan de migration depuis les méthodes phishable (SMS, TOTP) vers FIDO2/passkeys.

7.4 Intelligence artificielle et MFA

L'IA transforme le MFA sur deux fronts. Côté défense, les moteurs d'authentification adaptative intègrent de plus en plus le machine learning pour affiner l'évaluation du risque en temps réel : analyse comportementale continue (keystroke dynamics, mouse movement, patterns de navigation), détection d'anomalies dans les sessions authentifiées, identification automatique des tentatives de MFA fatigue et des patterns d'attaque AiTM, et amélioration continue des règles de Conditional Access grâce à l'apprentissage sur les incidents passés.

Côté attaque, l'IA générative renforce les capacités des adversaires : génération de deepfakes audio et vidéo pour tromper la biométrie vocale et faciale, phishing hyper-personnalisé via le traitement du langage naturel, automatisation et accélération des attaques de credential stuffing et de MFA fatigue, et vishing (voice phishing) assisté par IA pour l'ingénierie sociale ciblant les helpdesks.

Cette course aux armements IA impose une veille continue et une mise à jour régulière des défenses. Les solutions MFA intégrant des capacités IA/ML natives (Okta, IBM, CyberArk, OneSpan) sont à privilégier pour anticiper les menaces émergentes.

7.5 Decentralized Identity / Self-Sovereign Identity (SSI)

L'identité décentralisée, basée sur les standards W3C Verifiable Credentials et Decentralized Identifiers (DIDs), propose un modèle où l'utilisateur contrôle ses propres attributs d'identité sans dépendre d'un fournisseur d'identité centralisé. Dans ce modèle, le MFA pourrait évoluer vers un paradigme où l'utilisateur présente des credentials vérifiables (diplômes, certifications professionnelles, preuves d'appartenance à une organisation) qui, combinées à une authentification biométrique locale (sur son portefeuille numérique), constituent une authentification multi-facteurs décentralisée.

L'European Digital Identity Wallet (eIDAS 2.0), dont le déploiement est prévu d'ici 2026, pourrait accélérer cette tendance en Europe en fournissant un cadre réglementaire et une infrastructure de confiance pour les identités décentralisées. Pour un grand groupe, le SSI est à surveiller comme tendance de moyen à long terme (3-5 ans), notamment pour les cas d'usage B2B et B2C, mais ne constitue pas encore une alternative mature aux solutions MFA centralisées pour le workforce.

7.6 Continuous Authentication / Zero Trust Continuous Verification

La continuous authentication représente l'évolution naturelle du MFA dans un modèle Zero Trust. Plutôt qu'une vérification ponctuelle au moment de la connexion, l'identité de l'utilisateur est continuellement réévaluée tout au long de sa session grâce à des signaux passifs (comportementaux et contextuels) qui ne nécessitent aucune interaction de l'utilisateur.

Les technologies sous-jacentes incluent l'analyse comportementale continue (UEBA — User and Entity Behavior Analytics), le device posture assessment en temps réel (l'appareil est-il toujours conforme ?), la détection de changement de contexte (l'utilisateur a-t-il changé de réseau ? de localisation ?), et l'analyse de la session applicative (les actions effectuées sont-elles cohérentes avec le profil et le rôle ?). Lorsqu'un signal de risque dépasse un seuil défini, le système peut automatiquement réduire les privilèges de la session, demander une réauthentification MFA transparente (step-up), ou terminer la session et déclencher une alerte.

7.7 Convergence IAM + PAM + IGA + MFA (Identity Security)

Le marché de l'identité évolue vers une consolidation autour de plateformes d'Identity Security unifiées regroupant les fonctions historiquement séparées d'IAM (authentification, SSO, fédération), de PAM (gestion des accès à privilèges), d'IGA (gouvernance et administration des identités) et de MFA. Cette convergence est portée par des acquisitions (CyberArk acquiert Idaptive, Thoma Bravo rapproche Ping Identity et ForgeRock, Okta étend ses fonctionnalités de governance) et par les demandes des clients pour simplifier leur paysage technologique.

Pour un grand groupe, cette tendance a des implications directes sur la stratégie de sélection des solutions : privilégier un éditeur offrant une couverture multi-domaines (ou un roadmap crédible vers cette couverture) réduit la complexité d'intégration, le nombre de fournisseurs et le coût total de possession. Toutefois, la maturité des offres "convergées" étant variable (un leader du PAM n'est pas nécessairement un leader du MFA, et vice versa), une évaluation rigoureuse par domaine fonctionnel reste nécessaire.

7.8 Menaces émergentes

Les menaces les plus préoccupantes pour le MFA en 2025-2026 sont les suivantes.

Les attaques Adversary-in-the-Middle (AiTM) ont connu une explosion en 2025. Microsoft a identifié en janvier 2026 une campagne multi-étapes d'AiTM phishing ciblant SharePoint, et les chercheurs en sécurité ont répertorié au moins 11 kits de phishing AiTM actifs au premier semestre 2025. Ces attaques interceptent en temps réel les tokens de session après authentification MFA réussie, rendant le MFA par OTP et push notification inefficace. Seules les méthodes phishing-resistant (FIDO2) les neutralisent.

Le MFA fatigue continue de représenter un vecteur significatif (22 % des attaques MFA bypass selon le DBIR 2025). L'adoption du number matching et des limites de fréquence de notifications atténue ce risque, mais la migration vers FIDO2 est la seule solution structurelle.

Le vol de token (token theft), représentant 31 % des attaques MFA bypass, exploite les cookies de session et les tokens d'accès post-authentification. Les countermeasures incluent le token binding, les Continuous Access Evaluation (CAE) et la réduction de la durée de vie des tokens.

Les deepfakes biométriques constituent une menace croissante : les avancées de l'IA générative permettent de créer des deepfakes audio et vidéo de plus en plus convaincants, menaçant la fiabilité de la biométrie faciale et vocale. Les solutions de liveness detection doivent évoluer en permanence pour contrer ces attaques.

Le SIM swap reste une menace persistante pour le SMS OTP, avec des cas documentés de compromission de masse impliquant la corruption d'employés d'opérateurs télécoms.

7.9 Impact de l'informatique quantique

Les ordinateurs quantiques, lorsqu'ils atteindront une capacité suffisante (estimation : 2030-2035 pour les applications cryptanalytiques), pourraient menacer les algorithmes cryptographiques asymétriques (RSA, ECC) qui sous-tendent FIDO2, les certificats X.509 et la PKI. Le NIST a publié en 2024 ses premiers standards de cryptographie post-quantique (PQC) — FIPS 203, 204 et 205 — qui définissent les algorithmes de remplacement.

Pour un grand groupe, l'impact sur le MFA est à anticiper dès maintenant en s'assurant que la solution MFA retenue suit une feuille de route de migration vers la cryptographie post-quantique, que les clés de sécurité physiques achetées aujourd'hui pourront être mises à jour firmware, que l'infrastructure PKI est prête pour une transition vers les algorithmes PQC, et en engageant une veille active sur le sujet (participation aux groupes de travail FIDO Alliance sur le PQC). L'urgence n'est pas immédiate, mais le principe de "harvest now, decrypt later" (les attaquants collectent dès maintenant des données chiffrées pour les décrypter lorsque les ordinateurs quantiques seront disponibles) justifie une préparation proactive.

7.10 Évolution réglementaire et durcissement des exigences MFA

La trajectoire réglementaire est clairement vers un durcissement progressif des exigences MFA. NIS2 et DORA sont entrés en vigueur, imposant l'authentification forte comme composante des mesures de gestion des risques. La CISA a rendu le MFA phishing-resistant obligatoire pour les agences fédérales américaines, créant un standard de facto qui influence le secteur privé. Le Cyber Resilience Act (CRA) européen, qui entrera progressivement en application, imposera des exigences de sécurité incluant l'authentification forte pour les produits numériques. Les régulateurs financiers (BCE, EBA, ACPR) durcissent leurs attentes en matière d'authentification forte dans le cadre de la supervision DORA.

Pour un grand groupe multi-filiales opérant dans plusieurs juridictions, la conformité réglementaire constitue un driver majeur du déploiement MFA et justifie l'investissement dans des méthodes phishing-resistant (FIDO2) qui satisfont les exigences les plus strictes.

8. RECOMMANDATIONS STRATÉGIQUES

8.1 Critères de sélection d'une solution MFA pour un grand groupe multi-filiales

La sélection de la solution MFA cible doit s'appuyer sur une grille d'évaluation couvrant dix dimensions critiques.

La couverture fonctionnelle MFA évalue la richesse des méthodes d'authentification supportées, le support natif de FIDO2/passkeys, les capacités d'authentification adaptative/risk-based, le passwordless natif, et le step-up authentication. Le support des standards et de l'interopérabilité vérifie la conformité FIDO2/WebAuthn/CTAP, le support SAML 2.0 et OIDC, la compatibilité RADIUS, les API REST et les SDK disponibles. La flexibilité de déploiement évalue les options SaaS, on-premise et hybride, le multi-tenant natif, la data residency (possibilité de localiser les données en Europe), et les capacités de haute disponibilité.

L'intégration dans l'écosystème existant mesure la compatibilité avec Active Directory et Entra ID, l'intégration avec le SSO en place, les connecteurs applicatifs pré-intégrés (taille du catalogue), et l'intégration avec les solutions PAM et IGA existantes ou cibles. La couverture des cas d'usage vérifie le support workforce, CIAM (B2C), B2B/partenaires, DevOps, OT/IoT, et le logon poste de travail (Windows/Mac). La scalabilité et la performance évaluent la capacité à gérer le volume d'utilisateurs cible (avec marge de croissance), les performances sous charge, et les SLA garantis.

La sécurité de la solution elle-même vérifie les certifications de la solution (SOC 2 Type II, ISO 27001, certification de sécurité), le track record de sécurité de l'éditeur, la transparence sur les incidents passés, et les capacités de détection d'attaques MFA (fatigue, AiTM). L'expérience utilisateur évalue la fluidité du processus d'authentification, la qualité du portail self-service (enrollment, recovery), le support multilingue, et l'accessibilité (conformité WCAG). L'écosystème éditeur et pérennité analyse le positionnement dans les rapports analystes (Gartner, Forrester, KuppingerCole), la solidité financière de l'éditeur, l'investissement R&D, la feuille de route produit, et la qualité du support et de l'accompagnement. Enfin, le modèle économique et le TCO évaluent le modèle de pricing (par utilisateur, par authentification, par fonctionnalité), les coûts d'implémentation et de migration, les coûts opérationnels récurrents, et les coûts cachés (licensing, formation, intégrations custom).

8.2 Approche de déploiement recommandée

L'approche recommandée pour un grand groupe multi-filiales est un déploiement progressif en quatre vagues, préférant les quick wins rapides à un big bang risqué.

La vague 1 (mois 0-3, "Secure the Crown Jewels") cible les comptes à privilèges et les accès VPN. Elle déploie le MFA AAL3 (clé FIDO2) pour tous les administrateurs IT et comptes à privilèges, active le MFA pour tous les accès VPN et distant, et sécurise les accès aux consoles d'administration cloud (Azure, AWS, GCP). Cette vague offre le meilleur ratio risque réduit / effort investi et démontre rapidement la valeur du projet.

La vague 2 (mois 3-9, "Protect the Workforce") étend le MFA AAL2 à l'ensemble des collaborateurs pour l'accès aux applications cloud (Microsoft 365, SaaS critiques) via SSO fédéré, déploie les passkeys comme méthode cible avec push notification comme fallback, active le MFA adaptatif (Risk-Based) pour moduler l'exigence selon le contexte, et intègre le MFA au logon poste de travail pour le siège et les principales filiales.

La vague 3 (mois 9-18, "Extend to Ecosystem") étend le MFA aux prestataires et partenaires B2B, déploie le MFA CIAM pour les portails clients (si applicable), intègre le MFA avec la solution PAM pour les sessions privilégiées, et couvre les applications legacy on-premise prioritaires.

La vague 4 (mois 18-36, "Optimize & Converge") migre progressivement vers le passwordless pour l'ensemble des populations, déploie la continuous authentication basée sur l'analyse comportementale, couvre les environnements OT/IoT et les cas d'usage résiduels, optimise les politiques risk-based sur la base des données collectées, et entame la convergence vers une plateforme d'Identity Security unifiée.

8.3 Facteurs clés de succès et pièges à éviter

Les facteurs clés de succès sont le sponsorship exécutif (CISO et au-delà, idéalement un membre du COMEX) car le MFA impacte l'ensemble des utilisateurs et nécessite un arbitrage politique fort, la conduite du changement (communication, formation, accompagnement) engagée en amont du déploiement technique, le processus de recovery robuste et testé avant le lancement (un utilisateur bloqué par le MFA sans possibilité de recovery est un échec visible et coûteux), le pilote représentatif avant le déploiement massif (incluant des utilisateurs non-IT pour valider l'ergonomie), et les KPIs définis dès le départ pour mesurer le succès et ajuster la trajectoire.

Les pièges à éviter sont le "MFA partout d'un coup" (un déploiement trop rapide sans préparation adéquate génère une vague de support ingérable), l'oubli du helpdesk (le service desk doit être formé et outillé pour gérer les demandes MFA avant le déploiement), le sous-dimensionnement de l'infrastructure de recovery (la perte d'accès MFA est le scénario le plus fréquent et le plus impactant), l'absence de politique de mode dégradé (si le service MFA est indisponible, que se passe-t-il ?), le focus exclusif sur la technologie sans adresser les processus et l'humain, et le maintien du SMS OTP comme méthode acceptée par défaut (alors qu'il devrait être une exception temporaire et encadrée).

8.4 KPIs et métriques

Les KPIs recommandés pour piloter le programme MFA couvrent quatre dimensions. En matière d'adoption, le taux d'enrollment MFA mesure le pourcentage d'utilisateurs ayant enregistré au moins un facteur MFA (cible : 100 %), le taux d'enrollment multi-facteurs mesure le pourcentage d'utilisateurs ayant enregistré au moins deux facteurs (cible : 95 %+), et le taux d'adoption des méthodes phishing-resistant mesure le pourcentage d'utilisateurs utilisant FIDO2/passkeys (cible croissante selon la roadmap).

En matière de sécurité, le nombre d'incidents liés à des identifiants compromis mesure la réduction attendue post-déploiement MFA, le taux de blocage MFA d'accès frauduleux mesure l'efficacité du MFA pour empêcher les accès non autorisés, et le nombre d'attaques MFA détectées (fatigue, AiTM) quantifie les tentatives de contournement.

En matière d'opérations, le volume de tickets helpdesk liés au MFA (enrollment, recovery, problèmes) doit être suivi et réduit progressivement, le temps moyen de résolution d'un incident MFA mesure l'efficacité du support, et la disponibilité du service MFA mesure la fiabilité de l'infrastructure (cible : 99,99 %).

En matière d'expérience utilisateur, le taux de succès de l'authentification MFA mesure la fluidité du processus (cible : >98 %), le temps moyen d'authentification mesure la friction (les passkeys doivent l'améliorer significativement), et la satisfaction utilisateur concernant le MFA est mesurée par des enquêtes périodiques.

8.5 Conduite du changement et adoption utilisateur

Le MFA modifie une habitude quotidienne de chaque utilisateur — se connecter — et tout changement de ce type provoque des résistances naturelles. Un programme de conduite du changement structuré est indispensable.

La communication doit débuter 4 à 6 semaines avant le déploiement, expliquer le "pourquoi" (protection des données personnelles et de l'entreprise contre les cyberattaques) avec des exemples concrets et des chiffres marquants (le DBIR fournit d'excellentes données), présenter le "comment" de manière simple et visuelle (vidéos tutorielles, guides pas-à-pas), identifier et former des champions dans chaque entité/filiale pour servir de relais et de support de proximité, et adapter le discours et les supports aux différentes populations (IT vs. non-IT, siège vs. terrain, générations).

La formation doit être multimodale (e-learning, présentiel, tutoriels vidéo, sessions FAQ), progressive (d'abord les concepts, puis la pratique guidée, puis l'autonomie), et accompagnée d'un support renforcé pendant les premières semaines de déploiement (hot line dédiée, permanences IT).

8.6 Budget et TCO

L'estimation du TCO d'un déploiement MFA pour un grand groupe doit intégrer plusieurs postes de coûts. Les licences logicielles représentent typiquement le poste principal, avec un coût par utilisateur par mois variant de 2 € (solutions de base) à 15 € (plateformes IAM complètes avec MFA avancé). Pour 10 000 utilisateurs, cela représente de 240 000 € à 1 800 000 € par an.

Les authentificateurs matériels (clés FIDO2) représentent un investissement initial significatif si le déploiement inclut des clés physiques. Pour 2 clés par utilisateur à privilèges (estimons 15 % du parc, soit 1 500 utilisateurs) à 50 € par clé, le coût est de 150 000 € plus le remplacement annuel (estimé à 10-15 % du parc).

Les coûts d'implémentation et d'intégration incluent l'intégration technique (connecteurs, agents, configurations), la migration depuis les solutions existantes, les développements custom pour les applications legacy, et les prestations de conseil et d'accompagnement. Ces coûts sont très variables selon la complexité de l'environnement et représentent typiquement 1 à 3 fois le coût annuel des licences.

Les coûts opérationnels récurrents couvrent l'administration et la supervision de la plateforme MFA, le support helpdesk (dimensionner l'augmentation initiale puis la réduction progressive), la formation continue et la conduite du changement, et les audits de sécurité et de conformité.

Les économies à intégrer dans le business case comprennent la réduction des coûts de réinitialisations de mots de passe (estimé à 20-50 € par incident, plusieurs milliers par an dans un grand groupe), la réduction du risque de brèche (le coût moyen d'une brèche de données est de 4,88 millions de dollars selon IBM Cost of a Data Breach 2024), et les gains de productivité liés au passwordless (moins de temps perdu en authentification).

9. SYNTHÈSE ET CONCLUSION

9.1 Résumé des points clés

Cette étude a mis en lumière plusieurs constats structurants pour la stratégie MFA du groupe.

Le MFA n'est plus optionnel : il constitue un contrôle de sécurité fondamental exigé par les réglementations (NIS2, DORA), les frameworks (NIST, Zero Trust) et la réalité des menaces (22 % des brèches impliquent des identifiants compromis comme vecteur initial, 88 % des attaques sur les applications web utilisent des identifiants volés).

Toutes les méthodes MFA ne se valent pas : le MFA phishing-resistant (FIDO2/passkeys, PKI) est devenu le standard cible, les méthodes traditionnelles (SMS OTP, TOTP) étant de plus en plus vulnérables aux attaques AiTM, MFA fatigue et vol de token.

Les passkeys représentent le point d'inflexion : avec 87 % des entreprises en déploiement et le soutien de l'écosystème Apple/Google/Microsoft, les passkeys offrent une combinaison inédite de sécurité élevée et d'expérience utilisateur supérieure.

Le MFA adaptatif est indispensable pour un grand groupe : la diversité des populations, des entités, des niveaux de risque et des contextes d'accès rend l'approche risk-based incontournable pour équilibrer sécurité et productivité.

Le marché des solutions est mature mais en consolidation : les Leaders identifiés (Microsoft, Okta, Ping Identity, IBM, CyberArk) offrent des solutions robustes, avec une tendance à la convergence vers des plateformes d'Identity Security unifiées.

L'architecture hybride avec gouvernance centralisée est le modèle cible : elle permet de concilier le contrôle du groupe avec l'autonomie des filiales et la diversité des environnements.

9.2 Matrice de priorisation des actions

9.3 Prochaines étapes recommandées

Pour poursuivre l'étude et préparer la mise en œuvre, les prochaines étapes recommandées sont les suivantes.

Dans l'immédiat (mois 1-2), il convient de réaliser un audit de l'existant MFA (quelles méthodes sont déployées, pour quelles populations, sur quelles solutions, avec quels taux d'adoption), de cartographier les applications critiques et leur capacité d'intégration MFA, de qualifier les exigences réglementaires spécifiques à chaque filiale et secteur d'activité, et de définir les personae utilisateurs et les niveaux de risque associés.

À court terme (mois 2-4), il est recommandé de rédiger le cahier des charges de la solution MFA cible sur la base du présent document, de conduire un benchmark structuré des solutions shortlistées (PoC avec 3-4 éditeurs), de définir l'architecture cible (centralisé/fédéré/hybride) en fonction des contraintes identifiées, et d'élaborer le business case détaillé (TCO, ROI, réduction du risque).

À moyen terme (mois 4-6), il conviendra de sélectionner la solution cible et de négocier les conditions contractuelles, de planifier la vague 1 (comptes à privilèges + VPN), de préparer le programme de conduite du changement, et de définir les KPIs et le tableau de bord de pilotage du programme.

10. ANNEXE — GLOSSAIRE

AAL — Authenticator Assurance Level. Niveaux d'assurance d'authentification définis par le NIST SP 800-63B (AAL1, AAL2, AAL3).

AiTM — Adversary-in-the-Middle. Attaque par interposition où l'attaquant intercepte et relaie les communications entre l'utilisateur et le service légitime en temps réel.

ANSSI — Agence nationale de la sécurité des systèmes d'information. Autorité nationale française en matière de cybersécurité.

BYOD — Bring Your Own Device. Politique autorisant l'utilisation d'appareils personnels pour le travail.

CASB — Cloud Access Security Broker. Solution intermédiaire de sécurité entre les utilisateurs et les services cloud.

CIAM — Customer Identity and Access Management. Gestion des identités et des accès pour les clients (B2C).

CTAP — Client-to-Authenticator Protocol. Protocole de communication FIDO2 entre le client et l'authentificateur.

DORA — Digital Operational Resilience Act. Règlement européen sur la résilience opérationnelle numérique du secteur financier.

DSP2/SCA — Directive sur les services de paiement 2 / Strong Customer Authentication. Exigence d'authentification forte pour les paiements européens.

ENISA — European Union Agency for Cybersecurity. Agence européenne pour la cybersécurité.

FIDO2 — Fast Identity Online 2. Standard d'authentification sans mot de passe basé sur la cryptographie asymétrique.

HOTP — HMAC-based One-Time Password. Standard de génération de codes à usage unique basé sur un compteur.

IAM — Identity and Access Management. Gestion des identités et des accès.

IdP — Identity Provider. Fournisseur d'identité responsable de l'authentification des utilisateurs.

IGA — Identity Governance and Administration. Gouvernance et administration des identités.

JIT — Just-In-Time. Élévation de privilèges temporaire et à la demande.

MFA — Multi-Factor Authentication. Authentification multi-facteurs.

NIS2 — Network and Information Systems Directive 2. Directive européenne sur la cybersécurité des réseaux et systèmes d'information.

OATH — Initiative for Open Authentication. Organisation développant les standards ouverts TOTP et HOTP.

OIDC — OpenID Connect. Couche d'identité construite au-dessus d'OAuth 2.0.

OTP — One-Time Password. Mot de passe à usage unique.

PAM — Privileged Access Management. Gestion des accès à privilèges.

PDP — Policy Decision Point. Point de décision de politique dans une architecture Zero Trust.

PKI — Public Key Infrastructure. Infrastructure à clé publique.

PQC — Post-Quantum Cryptography. Cryptographie résistante aux ordinateurs quantiques.

RGPD — Règlement général sur la protection des données. Règlement européen sur la protection des données personnelles.

SAML — Security Assertion Markup Language. Standard XML de fédération d'identités.

SFA — Single-Factor Authentication. Authentification à facteur unique.

SSI — Self-Sovereign Identity. Identité auto-souveraine / décentralisée.

SSO — Single Sign-On. Authentification unique permettant d'accéder à plusieurs applications avec une seule session.

TCO — Total Cost of Ownership. Coût total de possession.

TOTP — Time-based One-Time Password. Standard de génération de codes à usage unique basé sur le temps.

TPM — Trusted Platform Module. Module de sécurité matériel intégré aux ordinateurs.

UEBA — User and Entity Behavior Analytics. Analyse comportementale des utilisateurs et des entités.

WebAuthn — Web Authentication API. API W3C standardisant l'authentification forte pour le web.

2FA — Two-Factor Authentication. Authentification à deux facteurs.

SOURCES ET RÉFÉRENCES

• Verizon, 2025 Data Breach Investigations Report (DBIR), mai 2025
• NIST SP 800-63B, Digital Identity Guidelines — Authentication and Lifecycle Management, mise à jour 2024
• NIST SP 800-207, Zero Trust Architecture, août 2020
• Gartner, Magic Quadrant for Access Management, novembre 2025
• Gartner, Magic Quadrant for Privileged Access Management, octobre 2025
• KuppingerCole, Leadership Compass: Access Management, juin 2025
• Forrester, The Forrester Wave: Privileged Identity Management Solutions, Q3 2025, août 2025
• Forrester, The State of Workforce Identity and Access Management 2025, novembre 2025
• FIDO Alliance / HYPR, The State of Passkey Deployment in the Enterprise, février 2025
• Microsoft Security Blog, Pushing Passkeys Forward, mai 2025
• Microsoft Security Blog, Microsoft Named a Leader in the Gartner MQ for AM 2025, novembre 2025
• IBM, Cost of a Data Breach Report 2024, juillet 2024
• ISACA, Resilience and Security in Critical Sectors: Navigating NIS2 and DORA, mai 2025
• Directive (UE) 2022/2555 (NIS2)
• Règlement (UE) 2022/2554 (DORA)
• Règlement (UE) 2016/679 (RGPD)
• CISA, Implementing Phishing-Resistant MFA, 2024
• Picus Security, Red Report 2025, janvier 2025

Fin du document — Version 1.0 — Mars 2026