Le RGPD ne prescrit aucune méthode d'authentification. Il demande des mesures techniques et organisationnelles appropriées au risque, et il impose en parallèle de ne collecter que les données nécessaires. C'est le seul texte de ce cluster qui pousse simultanément dans deux directions opposées : renforcer l'accès conduit à collecter davantage de signaux sur les personnes, minimiser conduit à en collecter moins. Un choix d'authentification mal posé règle un problème de sécurité en créant un problème de conformité.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. Les qualifications — base légale, statut de responsable ou de sous-traitant, nécessité d'une analyse d'impact — relèvent de votre délégué à la protection des données et de vos conseils.
Ce que le règlement demande, sans nommer de technologie
Les obligations qui touchent l'authentification se lisent par leur intitulé, jamais par un catalogue d'outils :
- la sécurité du traitement, c'est-à-dire des mesures appropriées au regard du risque pour les personnes concernées — pas au regard du risque pour l'entreprise seule ;
- la protection des données dès la conception et par défaut, qui déplace la décision en amont : le choix du facteur d'authentification est une décision de conception, pas un réglage ;
- la minimisation et la limitation de la conservation, qui s'appliquent aussi aux données produites par le dispositif d'authentification ;
- la notification des violations de données, qui suppose de pouvoir qualifier rapidement ce qui s'est passé ;
- les rapports responsable de traitement / sous-traitant, et la chaîne de sous-traitance ultérieure ;
- les catégories particulières de données, dont les données biométriques traitées aux fins d'identifier une personne de manière unique.
Ce dernier point est le plus sous-estimé : ajouter de la biométrie à un parcours de connexion n'ajoute pas seulement un facteur, cela ouvre un traitement de catégorie particulière.
La tension sécurité / minimisation, traitée de front
Un dispositif robuste a besoin de signaux : appareil, empreinte de navigateur, comportement, localisation approximative, historique. Chacun est une donnée personnelle supplémentaire, conservée, exfiltrable, et à justifier. La question utile n'est donc pas « quel est le facteur le plus fort ? », mais « quel est le facteur le plus fort qui crée le moins de données nouvelles ? ». Les arbitrages récurrents tiennent en quelques lignes.
| Choix d'architecture | Gain de sécurité | Coût de conformité créé | Question à poser avant de décider |
|---|---|---|---|
| Gabarit biométrique stocké côté serveur | Facteur d'inhérence sur tous les appareils | Base centralisée de données de catégorie particulière, irrévocable en cas de fuite | Peut-on obtenir le même résultat avec un traitement local sur l'appareil ? |
| Numéro de téléphone comme second facteur | Déploiement immédiat, parc hétérogène | Donnée d'identification supplémentaire, souvent réutilisée à d'autres fins | La méthode est-elle défendable, sachant que le NIST SP 800-63B classe l'OTP par SMS « restricted » ? |
| Score de risque contextuel | Friction ciblée sur les seules situations anormales | Profilage, conservation de signaux comportementaux | Quels signaux peut-on calculer sans les conserver ? |
C'est précisément cet arbitrage qui rend intéressantes les architectures décentralisées, où la biométrie est traitée localement sur l'appareil et où le fournisseur ne détient aucune donnée identifiante. C'est le parti pris de HIAsecure, avec une approche passwordless et IDless : il n'y a pas de base de secrets à protéger, donc pas de base à déclarer, à conserver, ni à notifier.
Les journaux d'authentification sont eux-mêmes un traitement
Un journal qui dit « telle personne s'est connectée à telle heure depuis tel réseau » est une donnée personnelle. Il est nécessaire — la traçabilité est une mesure de sécurité attendue — mais il obéit aux mêmes règles que les autres traitements : finalité déterminée, durée limitée à ce qui est utile, accès restreint, information des personnes.
Trois écarts fréquents, tous constatables en audit :
- des journaux conservés sans durée définie, parfois dupliqués dans un outil d'analyse tiers hébergé ailleurs ;
- des journaux accessibles largement, sans distinction entre exploitation courante et investigation ;
- des journaux inexploitables au moment de qualifier une violation, parce qu'ils tracent la session et non l'action sensible.
Ce dernier écart est le plus coûteux : savoir qu'une session était ouverte ne dit pas qui a validé une opération. La distinction entre authentifier un accès et valider une action sensible relève de la capacité de preuve, pas du confort.
Vérifier l'identité d'une personne qui exerce ses droits
Le droit d'accès crée une obligation paradoxale : vous devez remettre des données à une personne, donc être certain qu'il s'agit bien d'elle. Une vérification trop faible transforme le droit d'accès en canal d'exfiltration ; une vérification trop lourde revient à réclamer une copie de pièce d'identité, donc à créer une donnée sensible pour en protéger une qui l'était moins.
La bonne pratique consiste à réutiliser le lien d'authentification existant plutôt qu'à ouvrir une procédure parallèle, avec une élévation d'exigence au moment de la demande. Le canal de secours, lui, doit être documenté et tracé : c'est le point que les attaquants visent en priorité, comme dans les parcours de récupération de compte.
Sous-traitance, localisation et chaîne de responsabilité
Choisir un fournisseur d'authentification, c'est choisir un sous-traitant qui traite des données d'identification pour votre compte. Trois sujets se traitent au moment du contrat, pas après :
- Qui traite quoi. Le fournisseur détient-il des identifiants, des gabarits biométriques, des numéros de téléphone, ou son architecture est-elle conçue pour ne rien détenir d'identifiant ?
- Où et sous quelle juridiction. Localisation de l'hébergement et droit applicable au fournisseur conditionnent l'analyse des transferts hors Union européenne.
- La sous-traitance ultérieure. Un fournisseur qui s'appuie sur une infrastructure tierce allonge la chaîne, et vous restez comptable de son contenu.
Par où commencer
- Inventoriez les données créées par vos parcours d'authentification, pas seulement les données métier : beaucoup de registres s'arrêtent aux applications.
- Fixez une durée de conservation explicite pour les journaux, distincte des données métier, et vérifiez qu'elle est appliquée.
- Rejouez le parcours de droit d'accès en cherchant par où un tiers pourrait s'y glisser.
- Réexaminez toute base biométrique centralisée : c'est là que le gain de sécurité et le risque de conformité s'inversent le plus vite.
- Reprenez les contrats fournisseurs sous l'angle « que détient-il exactement, et où ».
FAQ
Le RGPD impose-t-il l'authentification multifacteur ?
Aucune technologie n'est imposée. Le règlement demande des mesures appropriées au risque, ce qui rend difficile de justifier un simple mot de passe sur un traitement sensible, alors que les identifiants volés ou réutilisés figurent parmi les tout premiers vecteurs d'intrusion relevés par le Verizon DBIR.
La biométrie est-elle interdite pour se connecter ?
Non, mais elle relève des catégories particulières de données lorsqu'elle sert à identifier une personne de manière unique, ce qui appelle un examen spécifique. La distinction décisive est architecturale : une comparaison effectuée localement sur l'appareil, sans gabarit central, ne pose pas les mêmes questions qu'une base centralisée.
Faut-il conserver les journaux d'authentification longtemps ?
Il faut conserver ce qui sert une finalité identifiée, pendant une durée justifiable, et rien de plus. Partez de l'usage réel — investigation d'incident, preuve en cas de contestation — puis déduisez-en la durée, plutôt que de conserver par défaut.
Une violation d'identifiants est-elle toujours notifiable ?
Cela dépend de l'analyse du risque pour les personnes concernées, menée sans attendre. Ce qui se prépare à l'avance, c'est la capacité à qualifier vite : sans journalisation exploitable, l'organisation passe le plus clair du délai à reconstituer les faits.
Aller plus loin : le pilier : authentification cognitive · RGPD et la santé · protection des données dès la conception face au phishing · hébergement des données en France