Authentification MFA : obligations et déploiement
MFA : exigences RGPD et NIS2, différences entre facteurs et étapes, récupération des accès et suivi des exceptions.
L’authentification multifacteur, ou MFA, ajoute des preuves de catégories différentes à la vérification d’un accès. Son déploiement ne consiste pas seulement à activer une option : il faut identifier les accès couverts, sécuriser la récupération et éviter que des exceptions permanentes rendent la protection inopérante.
MFA, deux étapes et robustesse : des notions différentes
La CNIL distingue trois catégories : connaissance, possession et inhérence. Une MFA combine au moins deux catégories. Deux secrets mémorisés ne suffisent donc pas. La recommandation distingue également le code reçu par courriel, qui ne prouve pas par principe la possession d’un objet unique, et le SMS, dont le niveau de confiance doit être évalué. Une passkey ne doit pas non plus être qualifiée automatiquement de multifacteur : cela dépend de sa mise en œuvre. Source : recommandation CNIL du 20 mars 2025, § 2.2 et 2.3.
Le choix d’une solution doit préciser ce qui est vérifié à chaque connexion. Demandez au fournisseur de décrire le fonctionnement normal, les appareils autorisés, la synchronisation éventuelle et la récupération du compte. Le libellé commercial « authentification forte » ne répond pas à ces questions.
Quand la MFA est-elle requise ?
L’Art. 32 RGPD impose une sécurité adaptée au risque. Le texte ne prescrit pas une méthode identique pour tous les accès, mais cette approche ne permet pas de traiter une protection nécessaire comme facultative. Source : RGPD, Art. 32(1) et (2).
Pour les bases concernant plusieurs millions de personnes, la CNIL demande notamment de sécuriser les accès distants des employés, partenaires et prestataires par MFA. Elle annonce un renforcement des contrôles sur ce point dès 2026. Elle rappelle également cette nécessité dans d’autres contextes de risque élevé, notamment pour certaines données sensibles, bancaires ou le numéro de sécurité sociale. Source : CNIL, sécurité des grandes bases de données.
NIS2 mentionne la MFA ou l’authentification continue à l’Art. 21(2)(j), selon les besoins, dans une approche proportionnée au risque. Il serait inexact d’en déduire que toute méthode MFA s’impose identiquement sur chaque système. Les dispositions nationales et sectorielles applicables doivent être examinées. Source : directive (UE) 2022/2555, Art. 21.
L’analyse des risques sert à établir les priorités : administration, messagerie, accès distant, applications contenant les données les plus exposantes et comptes des prestataires.
Choisir une méthode à partir des usages réels
Voici les questions à faire démontrer pendant un pilote, avec des comptes et environnements autorisés.
| Sujet | Démonstration attendue |
|---|---|
| Facteurs utilisés | Catégories distinctes et protection des éléments secrets |
| Appareils | Inscription, changement de terminal, retrait et inventaire |
| Tentative de fraude | Traitement d’une demande non sollicitée ou d’un faux parcours de connexion |
| Perte du facteur | Récupération avec contrôle suffisant de l’identité |
| Accès d’urgence | Procédure limitée, traçable et suivie après utilisation |
| Compatibilité | Applications anciennes, accès indirects et protocoles qui pourraient contourner la MFA |
| Support | Parcours utilisable sans équipement personnel imposé par défaut |
Ne mesurez pas uniquement le nombre de personnes inscrites. Il faut aussi vérifier que les accès concernés exigent effectivement la protection. Un utilisateur peut avoir enregistré un facteur tandis qu’un ancien mode de connexion reste ouvert.
La politique de mot de passe doit être cohérente avec ce dispositif lorsque des mots de passe sont encore utilisés. L’authentification ne remplace pas la limitation des habilitations : un compte correctement authentifié peut disposer de droits excessifs.
Traiter la MFA comme un traitement de données
La CNIL souligne que la solution de sécurité doit elle-même respecter le RGPD : base légale, données nécessaires, durée de conservation, rôle des fournisseurs et exercice des droits. Elle attire aussi l’attention sur la biométrie et l’emploi d’un équipement personnel par les salariés. Source : CNIL, présentation de la recommandation MFA.
Pour instruire le choix, demandez la liste des informations collectées, les destinataires, les lieux de traitement et les usages secondaires. Une fonctionnalité d’authentification ne justifie pas une collecte illimitée d’informations sur le terminal ou le comportement de l’utilisateur. En cas de données biométriques utilisées pour identifier une personne de manière unique, l’analyse de l’Art. 9 doit être conduite ; l’étiquette « sécurité » ne suffit pas à autoriser le traitement. Source : RGPD, Art. 9.
Suivre le déploiement et les exceptions
La PSSI peut prévoir une fiche par application : utilisateurs concernés, méthode, responsable, date de déploiement, accès exclus et échéance des exceptions. Chaque perte d’appareil, départ ou changement de prestataire doit pouvoir être traité sans laisser un ancien facteur actif.
Un audit de sécurité doit examiner le parcours de récupération et les accès d’urgence en plus de la connexion normale. La présence d’une option MFA dans la console d’administration ne démontre pas son efficacité sur tout le périmètre.
Cas pratique : protéger les accès d’un cabinet de gestion
Exemple entièrement fictif : un cabinet de vingt-huit salariés gère des dossiers de paie et les coordonnées bancaires de clients. Sa dirigeante reçoit un bilan rassurant : vingt-quatre salariés ont enregistré un second facteur. Pourtant, une ancienne application permet toujours de télécharger des documents avec un simple mot de passe.
Le responsable informatique inventorie six accès : messagerie, connexion distante, paie, administration de l’annuaire, portail documentaire et ancien extranet. La dirigeante valide la priorité donnée aux accès externes et aux comptes privilégiés. Le projet ne cherche pas à multiplier les demandes de validation : il doit empêcher qu’un chemin oublié permette d’obtenir les mêmes documents sans protection suffisante.
L’équipe propose, pour les comptes d’administration, une clé matérielle liée à un terminal et déverrouillée par un code, sous réserve de vérifier les caractéristiques de la solution retenue. Un équipement professionnel est fourni aux personnes qui ne souhaitent pas utiliser leur téléphone personnel. Aucune collecte biométrique centralisée n’est prévue. Ces choix appartiennent au scénario ; ils ne constituent pas une recommandation universelle pour tous les organismes.
La fiche de déploiement remplie
| Périmètre | Décision du cabinet | Condition de validation |
|---|---|---|
| Messagerie | Exiger la MFA pour les accès concernés et fermer les anciens modes de connexion qui la contournent | Le compte de démonstration ne peut plus utiliser le chemin ancien |
| Connexion distante | Intégrer salariés et prestataires nommément habilités | Aucun compte partagé ni exception héritée sans responsable |
| Paie | Couvrir la connexion normale et le compte d’administration propre au logiciel | Les deux chemins sont contrôlés séparément |
| Annuaire | Protéger les administrateurs et préparer un secours maîtrisé | La perte d’une clé a une solution sans désactivation générale |
| Portail documentaire | Vérifier le parcours depuis un navigateur neuf et depuis un lien direct | L’accès au document respecte la protection prévue |
| Ancien extranet | Suspendre l’accès externe tant que sa protection n’est pas corrigée | La migration reste une action ouverte, datée et attribuée |
Le pilote porte sur quatre salariés représentant les usages retenus : gestionnaire de paie, assistante, administrateur et salarié en déplacement. L’équipe utilise des comptes et documents fictifs dans un périmètre autorisé. Elle consigne la configuration, le parcours, le résultat et l’écart ; elle n’enregistre pas les codes secrets dans le compte rendu.
Dans ce scénario, le portail impose correctement la MFA. Le logiciel de paie dispose toutefois d’un accès administrateur indépendant de l’annuaire : ce compte échappe à la politique générale. Le responsable demande sa protection propre avant d’ouvrir le périmètre aux utilisateurs. Afficher « annuaire sécurisé » aurait masqué cet écart.
Perte de clé : préparer la réponse avant le premier incident
Pendant le pilote, l’administratrice simule la perte de sa clé. Le support reçoit une demande de remplacement depuis une nouvelle adresse. Il n’utilise pas cette adresse comme preuve de l’identité qu’elle prétend établir. Il suit le parcours de vérification défini à l’avance, avec un interlocuteur connu et, dans ce cas, une vérification en présence de la salariée.
Après cette vérification, l’ancien facteur est révoqué et le nouveau est inscrit. L’équipe examine également les sessions existantes et les accès de secours : remplacer un facteur ne prouve pas à lui seul que tout accès antérieur a cessé. La salariée reçoit une information par le canal déjà validé. Le dossier conserve les décisions et les horodatages nécessaires, sans copie indifférenciée de pièces d’identité.
Si l’identité ne peut pas être suffisamment établie, le support n’accorde pas une exemption permanente. La continuité est organisée autrement : une collègue habilitée réalise la tâche urgente depuis son propre compte, sans partager son secret. Pour une application où ce relais serait impossible, le scénario de secours doit être conçu avant le déploiement, avec les responsables métier et sécurité.
Le compte d’urgence de l’annuaire appelle une procédure distincte, compatible avec l’architecture retenue. Le responsable définit qui peut y accéder, comment les moyens sont conservés, comment son utilisation est signalée et ce qui doit être révoqué ou renouvelé ensuite. Le secours ne doit pas devenir le compte ordinaire d’un prestataire parce qu’il semble plus commode.
Présenter des indicateurs qui décrivent les accès
Au départ, vingt-quatre personnes sur vingt-huit étaient inscrites, soit environ 86 %. Ce chiffre ne disait rien du vieux portail ni du compte administrateur local. À la fin du scénario, les vingt-huit personnes disposent du moyen prévu, cinq accès actifs ont été vérifiés et le sixième est fermé depuis l’extérieur, en attente de migration.
Le bilan distingue donc trois informations : personnes équipées, accès actifs effectivement couverts et accès suspendus ou restant à corriger. Il conserve l’ancien extranet dans le suivi au lieu de le faire disparaître du dénominateur sans explication. Une exception indique toujours son propriétaire, sa justification, la protection temporaire et sa date de réexamen.
La dirigeante programme un nouveau contrôle après la migration et à chaque changement important d’application ou de fournisseur. Elle demande également au support de suivre les échecs de récupération et les validations non sollicitées signalées par les salariés. L’objectif est de corriger un parcours fragile, pas de sanctionner la personne qui remonte une difficulté.
Ce qu’il faut retenir
- Deux étapes ne constituent pas nécessairement deux facteurs.
- Les exigences dépendent du risque et des textes applicables.
- Contrôlez les accès réellement couverts, les secours et les exceptions.
- La solution MFA doit elle-même respecter la protection des données.
FAQ
Un code par courriel constitue-t-il un facteur de possession ?
La recommandation CNIL ne le considère pas comme tel par principe. L’accès au courriel ne démontre pas nécessairement la possession d’un appareil unique.
Une passkey est-elle toujours multifacteur ?
Non. Il faut examiner son architecture, son association au terminal et les conditions de déverrouillage. Robustesse cryptographique et nombre de facteurs sont deux questions distinctes.
Le taux d’inscription des utilisateurs suffit-il comme indicateur ?
Non. Suivez également les applications protégées, les accès qui contournent le dispositif et les exceptions encore ouvertes.
Recevez nos analyses sur la sécurité et la conformité RGPD.
Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.