Par Tanguy Duthion
·
11 juillet 2026
Si je dois résumer en une phrase : le MFA n’est plus un simple choix de sécurité dans le SaaS, c’est un point à justifier, à mettre en place et à prouver.
Voici ce que je retiens tout de suite :
Un chiffre donne le ton : 83 % des applications SaaS sont utilisées sans validation de la DSI. Et 60 % des entreprises ratent leurs audits à cause d’une mauvaise gouvernance des données SaaS. Donc la question n’est plus « faut-il du MFA ? ». La question est : sur quels accès, avec quelles preuves, et pour quel cadre ?
| Cadre | Ce que je dois retenir sur le MFA | Ce qu’on attend surtout |
|---|---|---|
| RGPD | Attendu selon le risque | Justifier le choix, surtout pour accès à distance, admin et données sensibles |
| NIS2 | Attendu dans les contrôles d’accès | Couvrir les accès critiques et tracer les incidents |
| DORA | Très cadré sur les accès et actifs ICT | Prouver la couverture MFA, le suivi des incidents et la gouvernance |
La suite du sujet tient donc en trois mots : couvrir, tracer, prouver.
Le RGPD, NIS2 et DORA ne parlent pas du MFA avec le même degré de détail. C'est là que beaucoup d'équipes se trompent.
Le RGPD, par exemple, ne dit pas noir sur blanc : mettez du MFA partout. Son article 32 raisonne selon le niveau de risque. Autrement dit, il faut choisir des mesures de sécurité adaptées à la situation. En France, la CNIL a levé le doute le 20 mars 2025 : le MFA est une mesure de base incontournable pour l'accès à des données sensibles, l'accès à distance et les interfaces d'administration [1].
NIS2 va plus loin. Le MFA y entre dans les mesures de contrôle d'accès. DORA, de son côté, le rattache à la protection des actifs et des accès critiques, dans un cadre de gestion des risques ICT bien plus directif.
| Cadre | Statut du MFA | Fondement |
|---|---|---|
| RGPD | Attendu indirectement | Art. 32 + recommandation CNIL du 20 mars 2025 |
| NIS2 | Explicitement attendu | Mesures de contrôle d'accès |
| DORA | Très prescriptif | Dispositif de gestion des risques ICT |
Dans les faits, cette différence change surtout la façon de déployer le MFA. Sous le RGPD, il faut justifier ses choix. Sous NIS2 et DORA, il faut prouver que la mesure est bien en place et qu'elle couvre les bons accès.
Plus un cadre est prescriptif, plus l'entreprise doit documenter la couverture réelle du MFA dans son environnement SaaS. Le point de départ est simple : montrer que le MFA protège bien les accès exposés et les comptes sensibles, comme les administrateurs, les accès distants et les comptes à privilèges.
La vraie question n'est donc plus de savoir s'il faut du MFA, mais sur quels comptes il doit passer en premier.
Quand les moyens sont serrés, il faut aller droit au but. Commencez par les accès les plus exposés.
La priorité va aux comptes administrateurs, aux consoles d'administration SaaS et aux accès à distance [1].
Ensuite viennent les accès tiers. Les prestataires et les partenaires ouvrent souvent une porte vers la chaîne d'approvisionnement et vers des fonctions critiques. Une fois ces comptes couverts, il faut pouvoir le prouver : qui a activé le MFA, quand, et sur quel accès ?
| Scénario d'accès | Priorité | Cadres concernés |
|---|---|---|
| Consoles d'administration SaaS et comptes privilégiés | Critique | CNIL / NIS2 / DORA |
| Accès à distance aux systèmes internes et aux applications SaaS | Critique | CNIL / NIS2 |
| Applications traitant des données de santé ou financières | Élevée | RGPD / DORA |
| Accès tiers et prestataires de services numériques | Élevée | DORA / NIS2 |
| Accès standard des collaborateurs sur SaaS non sensibles | Modérée | RGPD (proportionnalité) |
Sur le terrain, l'ordre le plus simple est souvent le bon : sécurisez d'abord les fournisseurs d'identité et le SSO, puis les consoles d'administration des applications critiques [1]. Dit autrement, on verrouille d'abord le trousseau de clés, puis les portes les plus sensibles.
Après ça, un point compte autant que l'activation elle-même : la preuve. La couverture des comptes prioritaires doit être visible et vérifiable dans les journaux d'accès.
Une fois les comptes critiques protégés, il faut aller plus loin : il faut pouvoir prouver chaque événement MFA. En situation d’audit, les journaux et leur durée de conservation pèsent autant que l’activation du contrôle elle-même.
Les règles changent selon le cadre visé. Le RGPD traite les journaux d’authentification comme des données personnelles, avec une logique de minimisation et une durée de conservation limitée [3]. DORA demande un registre complet des incidents ICT pour justifier les revues d’accès. NIS2, de son côté, impose une documentation des incidents significatifs pour l’alerte sous 24 heures, puis le rapport complet sous 72 heures auprès de l’ANSSI.
Voici les événements à journaliser en priorité.
| Type d'événement MFA | Priorité de journalisation | Cadre principal |
|---|---|---|
| Contournements MFA ou accès non autorisés sur systèmes critiques | Haute (immédiate) | DORA (qualification automatique en incident majeur) |
| Connexions réussies et échouées sur comptes à privilèges | Haute | NIS2 (signalement d'incident) |
| Contournements MFA et dérogations administrateur | Haute | RGPD (responsabilité) |
| Inscriptions, réinitialisations et récupérations MFA | Moyenne | DORA (revues d'accès) |
| Décisions d'autorisation ou de blocage MFA | Moyenne | NIS2 (gestion des risques) |
Sous NIS2, la direction doit être en mesure de montrer qu’elle supervise les contrôles MFA et les revues d’accès. Ce n’est pas un simple point de conformité sur une checklist. 60 % des entreprises échouent aux audits en raison d’une mauvaise gouvernance des données SaaS [2].
Pour rester aligné avec le RGPD, gardez seulement les événements utiles. En pratique, cela veut dire :
Pas besoin d’enregistrer tout et n’importe quoi. L’idée, c’est de conserver ce qui sert à la fois à la gouvernance des risques et aux preuves d’audit.
Une fois les événements MFA journalisés, le vrai sujet n'est plus seulement de les avoir. Il faut montrer qu'ils s'inscrivent dans une gouvernance SaaS formalisée.
En clair : des journaux seuls ne suffisent pas. Lors d'un audit, il faut aussi une gouvernance SaaS documentée, avec un inventaire des applications, des politiques d'accès formalisées et une traçabilité des décisions.
Sous le RGPD, le MFA doit apparaître dans le ROPA, rester proportionné au risque et s'appuyer sur une base légale documentée [3]. Le fil conducteur entre les trois cadres est simple : documenter les choix et les responsabilités. NIS2 impose une supervision active des contrôles d'accès par la direction. De son côté, DORA demande un Register of Information (RoI) qui relie les actifs ICT aux fonctions critiques, avec une validation par le conseil.
Le tableau ci-dessous présente les preuves d'audit attendues par cadre [4].
| Catégorie de preuve | RGPD | NIS2 | DORA |
|---|---|---|---|
| Contrôle d'accès | Politique MFA documentée sur les accès aux données personnelles sensibles | Politique MFA documentée sur les accès critiques des entités essentielles et importantes | Politique MFA documentée sur l'ensemble des systèmes ICT soutenant des fonctions critiques |
| Comptes sensibles | Documentation du DPO et des accès à privilèges élevés | Identification des actifs critiques et des risques de la chaîne d'approvisionnement | Registre d'information liant actifs et fonctions critiques |
| Journaux | Conservation, revue et export des journaux d'authentification selon une durée définie | Journaux d'incidents disponibles pour notification à l'ANSSI | Reporting d'incidents en cascade (4 h / 72 h / 1 mois) avec capacité d'enquête |
| Gouvernance | Registre des activités de traitement (ROPA) et revue périodique des droits | Validation par la direction et revue périodique des droits | Validation par le conseil sur les cadres de risques ICT et les tests de résilience |
Un point passe souvent sous le radar : les revues périodiques des droits d'accès. C'est pourtant là que beaucoup de choses se jouent.
Documenter la création et la désactivation des comptes, puis vérifier que les accès restent alignés avec le principe du moindre privilège, donne une preuve directe qu'un contrôle MFA n'est pas juste activé "sur le papier", mais bien gouverné [4].
Ces preuves servent ensuite à prioriser les actions concrètes par équipe et par parc SaaS.
Après les preuves d’audit, place à l’exécution sur le terrain. La séquence utile reste simple : inventaire SaaS, classification, MFA, puis supervision continue.
Commencez par cartographier le parc SaaS, y compris le Shadow IT et les usages en dehors du SSO. Ensuite, classez les applications selon leur niveau de sensibilité et leur criticité. Puis imposez le MFA sur les comptes privilégiés, les accès distants et les consoles d’administration. Enfin, alimentez le SIEM pour permettre une supervision SOC en continu.
Cette hiérarchie sert de base aux contrôles à traiter en premier, selon chaque cadre. En pratique :
Le point clé n’est plus la théorie. Ce qui compte, c’est la capacité à voir, bloquer et prouver en continu. Sur ce périmètre, Avanoo aide à détecter le Shadow IT, repérer les comptes sans MFA et centraliser les preuves d’audit.
Une fois les exigences et les preuves posées, le vrai sujet est simple : qu'est-ce que chaque cadre dit, concrètement, sur le MFA dans le SaaS ? Et tout se joue moins sur le fait d'avoir un MFA que sur le degré de précision demandé, ainsi que sur la preuve à fournir en cas de contrôle.
Le RGPD aborde le MFA par le prisme du risque. La CNIL, elle, le présente comme une mesure de base dès qu'on parle de données sensibles, d'accès à distance ou d'interfaces d'administration.
| Cadre | Points forts | Limites | Effet sur le SaaS |
|---|---|---|---|
| RGPD | Portée large : tout traitement de données personnelles. Sanctions jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires mondial [2]. | Précision technique limitée : le MFA n'est pas cité de façon explicite, avec une logique de proportionnalité [1]. | Le MFA devient prioritaire pour les données sensibles, l'accès distant et l'administration. Une AIPD permet de formaliser cette proportionnalité [1]. |
| NIS2 | Le MFA est attendu de façon explicite dans les mesures de contrôle d'accès. Supervision active imposée à la direction. | Périmètre limité aux entités essentielles et importantes ; les autres organisations ne sont pas visées de façon directe. | Le MFA est obligatoire sur les accès critiques, avec documentation des incidents pour notification à l'ANSSI sous 24 h / 72 h. |
| DORA | Cadre ICT très prescriptif : le MFA est lié à la protection des actifs et des accès critiques. Validation par le conseil requise. | Périmètre centré sur le secteur financier ; hors champ pour les autres secteurs. | Le MFA s'intègre au registre d'information (RoI), avec un reporting d'incidents en cascade (4 h / 72 h / 1 mois) et des tests de résilience documentés. |
Dit autrement, le RGPD laisse plus de marge, mais demande de justifier ses choix. NIS2 et DORA vont plus loin dans la prescription, surtout pour les accès critiques, la gouvernance et la gestion d'incident. Pour un éditeur SaaS, la différence n'est donc pas théorique : elle change ce qu'il faut déployer, tracer et montrer en audit.
Au fond, la différence entre ces trois textes ne tient pas tant à la présence du MFA qu'au niveau de preuve demandé. Le RGPD, NIS2 et DORA vont dans le même sens sur le MFA, mais pas avec le même degré d'exigence : d'abord la justification par le risque, ensuite la mise en place explicite, puis la preuve dans la durée.
La bonne question n'est donc pas seulement : « avons-nous un MFA ? ». La bonne question, c'est plutôt : « pouvons-nous le prouver en continu ? » Sans gouvernance SaaS, un MFA isolé ne suffit pas pour passer un audit.
Pour les équipes françaises, la priorité est assez claire : commencez par couvrir les accès les plus exposés, puis documentez chaque contrôle. En pratique, cela veut dire traiter d'abord les accès à distance, les interfaces d'administration et les données sensibles, puis formaliser les preuves liées à chacun de ces points.
Le MFA SaaS n'est pas juste un réglage de sécurité. C'est un contrôle de gouvernance.
::: faq
Le RGPD n’impose pas le MFA dans tous les cas. En revanche, il demande un niveau de sécurité adapté au risque.
Concrètement, pour des accès sensibles - comme les données de santé, les informations financières ou les interfaces d’administration - l’absence de MFA peut être vue comme un manquement à cette obligation. Et là, ce n’est pas anodin : cela peut entraîner des sanctions de la CNIL. :::
::: faq
Pour le RGPD, NIS2 et DORA, commencez par protéger les accès SaaS les plus exposés, selon le niveau de risque et la sensibilité des données.
En clair, la priorité va à :
Il faut aussi classer les actifs SaaS en fonction de leur criticité, des données traitées et du niveau de dépendance au fournisseur. :::
::: faq
Conservez une documentation à jour et traçable. En clair, il faut pouvoir retrouver sans détour l’inventaire des actifs et des fournisseurs TIC, le registre des risques, les politiques de sécurité, les rapports d’incidents, les tests de résilience et l’historique des mesures d’accès, y compris le MFA.
Faites la même chose pour les contrats des prestataires tiers. Gardez sous la main les clauses d’audit, les SLA, la localisation des données et les plans de sortie. Le but est simple : lors d’un audit, vous devez montrer ces éléments vite, dans le bon format, et sans zones floues.
Avanoo peut aider à centraliser ces documents pour en simplifier la présentation pendant un audit. :::
Co-fondateur & CEO
Tanguy Duthion est co-fondateur et CEO d'Avanoo. Ancien de Google et d'Asana, il a fondé Avanoo pour aider les organisations à reprendre la main sur leurs usages SaaS et IA.
Découvrez comment Avanoo peut cartographier votre paysage SaaS et IA, réduire les risques et optimiser les coûts. Une plateforme fiable avec un accompagnement humain dédié.
