De nouvelles perspectives pour l’authentification forte

Les opérations de paiement occupent une place centrale dans le secteur économique. Le pouvoir réglementaire est intervenu afin de sécuriser leur exécution. L’intérêt était de réduire la fraude tout en préservant la confiance des clients lors de l’utilisation des services de paiement à distance en ligne.

La directive sur les services de paiement du 25 novembre 2015 (DSP 2)¹ a joué un rôle majeur en ce sens. Transposé par l’ordonnance n° 2017-1252 du 9 août 2017², ce texte vise la gestion des risques cyber, et en particulier renforce la protection des utilisateurs de services de paiement. À cet effet, il instituait l’authentification forte pour les clients tout en modifiant les procédures de contestation des paiements. L’authentification forte revêt deux intérêts majeurs : la preuve du consentement à une opération de paiement électronique et le régime de responsabilité en cas d’opération non autorisée.

L’authentification forte est prévue à l’article L. 133-44 du Code monétaire et financier, lequel impose aux prestataires de services de paiement de la mettre en œuvre. Sa définition se situe à l’article L. 133-4, f) du même code, qui dispose que l’authentification forte constitue « une authentification reposant sur l’utilisation de deux éléments ou plus appartenant aux catégories “connaissance” (quelque chose que seul l’utilisateur connaît), “possession” (quelque chose que seul l’utilisateur possède) et “inhérence” (quelque chose que l’utilisateur est) et indépendants en ce sens que la compromission de l’un ne remet pas en question la fiabilité des autres, et qui est conçue de manière à protéger la confidentialité des données d’authentification ».

De nombreuses jurisprudences sont venues préciser le régime de responsabilité en la matière, venant ou pas sanctionner la négligence grave des utilisateurs quant à la transmission des données permettant d’activer la procédure d’authentification forte³.

Bien que la Commission européenne ait reconnu elle-même que l’évaluation de la DSP2 menée en 2022 « était largement couronnée de succès quant à la réalisation de bon nombre de ses objectifs »⁴, le paquet « Accès aux données financières et paiements »⁵ a été publié le 28 juin 2023. Trois projets de textes viennent réformer le marché européen des paiements autour de deux objectifs centraux :

– la révision de la directive sur les services de paiement (avec un projet de directive DSP3 et un Règlement sur les services de paiement RSP) ;

– la mise en place d’un cadre législatif pour permettre l’accès aux données financières (Règlement FIDA), le Règlement correspondant n’étant pas l’objet de cet article.

Il était attendu que la DSP2 soit remplacée par un seul règlement, d’application directe dans chaque État membre. Mais il n’en a rien été puisque deux actes distincts – une directive et un règlement – ont été publiés. Par analogie avec le Paquet des services financiers, les règles concernant l’agrément et la surveillance des établissements figurent dans la directive, les règles applicables à ces derniers, dont l’authentification forte et les Regulatory Technical Standards (RTS) sur l’authentification publiés en 2018⁶, dans le RSP.

Tout commence par la définition de l’authentification forte (projet art. 3.35) qui apparaît comme identique à celle présente dans la DSP2 mais bénéficie en fait d’une atténuation prévue au projet d’art. 85-12. Les facteurs sur lesquels se fonde l’authentification forte du client (au moins deux facteurs parmi les trois suivants : possession, connaissance, inhérence) ne doivent pas nécessairement appartenir à des catégories différentes, contrairement à la doctrine de l’Autorité bancaire européenne (EBA)⁷.

De plus, les opérations visées par l’obligation d’authentification forte sont désormais plus nombreuses. Outre l’accès au compte de paiement en ligne, l’initiation de l’opération de paiement, l’exécution d’une action, grâce à un moyen à distance, susceptible de comporter un risque de fraude en matière de paiement ou de toute autre utilisation frauduleuse, opérations prévues dans la DSP2, l’obligation d’authentification forte s’étend au passage de tout ordre de paiement pour une opération électronique ainsi qu’à l’accès aux informations du compte de paiement (projet art. 85.1).

Par contre, à l’inverse de la DSP2, les ordres de paiement passés en recourant à la technologie NFC (projet art. 85-9) devraient requérir l’application d’une authentification forte par les PSP, celle-ci devant intégrer des éléments liant dynamiquement la transaction à un montant et à un bénéficiaire spécifiques ou d’autres mesures de sécurité du même ordre.

Le projet de Règlement est plus disert également sur les opérations exemptées de l’obligation d’authentification : les transactions initiées par le bénéficiaire (projet, art. 85-2) sans aucune interaction ou implication du payeur, les opérations de paiement initiées ultérieurement par un bénéficiaire à la suite de l’authentification forte effectuée lors de la passation originelle d’un mandat (projet, art. 85-3) et sans que le PSP intervienne dans la fourniture d’un canal à distance (projet, art. 85-5) pour le mandat, les ordres de paiement sur support papier, les opérations par correspondance ou par téléphone sous certaines conditions (projet, art. 85-7).

De plus, toute exemption à l’application de l’authentification devra être fondée par l’EBA sur un ou plusieurs critères suivants : (i) le niveau de risque lié au service fourni, (ii) le montant et/ou la récurrence de la transaction, (iii) le canal de paiement utilisé pour l’exécution de la transaction (projet d’art. 85.11).

Sous l’emprise de la DSP2, c’était aux prestataires de services de paiement gestionnaires de comptes (PSPGC) d’effectuer l’authentification forte de l’utilisateur lorsque ce dernier accédait aux informations du compte de paiement via un prestataire de services d’information sur les comptes (PSIC). Désormais, avec le projet d’art. 86 du RSP, le PSIC devra lui-même effectuer l’authentification forte de l’utilisateur tous les 180 jours (sauf suspicion de fraude). Ce n’est que lors du premier accès aux données du compte de paiement par un PSIC que le PSPGC effectuera une authentification forte (art. 86.3).

Confrontée à des retards pris dans le déploiement de l’authentification forte, la Commission européenne a décidé de responsabiliser les prestataires techniques sur lesquels s’appuient les PSP. Ces prestataires techniques seront reconnus comme responsables en cas de manquement contractuel dans le cadre des prestations nécessaires à la mise en œuvre de l’authentification forte du client (projet d’art. 58).

De manière plus générale, le projet d’art. 87 du RSP oblige expressément les PSP et les prestataires techniques à conclure des accords d’externalisation dans les cas où ces derniers fournissent et vérifient les éléments de l’authentification forte du client. Des RTS de l’EBA, qui pourraient s’inspirer de celles prévues pour les services d’informatique en nuage⁸, seront prévues au sujet de l’externalisation (art. 89-1.d).

De plus, conformément au projet d’art. 88, les PSP devront veiller à ce que tous leurs clients (y compris les personnes handicapées, âgées, ayant de faibles compétences numériques...), disposent d’au moins un moyen adapté à leur situation particulière leur permettant d’effectuer une authentification forte et sans recourir à l’utilisation exclusive d’un seul moyen d’authentification ni à la possession d’un smartphone.

La notion d’authentification forte figure également dans le règlement eIDAS⁹, celle-ci ne se référant pas à celle issue de la DSP2. Le règlement eIDAS est lui-même en cours de révision¹⁰ et fait la part belle au Portefeuille européen d’identité numérique entendu dans la première version du projet de règlement eIDAS 2 comme « un produit et un service qui permettent à l’utilisateur de stocker des données d’identification, des justificatifs et des attributs liés à son identité, de les communiquer aux parties utilisatrices sur demande et de les utiliser pour s’authentifier, en ligne et hors ligne, sur un service conformément à l’article 6 bis ; et de créer des signatures et cachets électroniques qualifiés ».

Les réformes actuelles du règlement eIDAS et de la DSP2 posent avec acuité la question d’une approche harmonisée mais aussi unifiée de l’authentification dans ces deux corps de règles.

Pour l’heure, le règlement eIDAS 2 n’est évoqué que dans le cadre des futurs RTS (projet d’art. 89-3) comme un élément contextuel à prendre en compte lors de leur révision.

Dans le même ordre d’idée, contrairement au secteur bancaire et financier cité dans le Règlement eIDAS, le renvoi à l’authentification forte dans le secteur du paiement se retrouve actuellement dans les considérants du projet de Règlement eIDAS 2 (version du 7 février 2023) : « (31) Secure electronic identification and the provision of attestation of attributes should offer additional flexibility and solutions for the financial services sector to allow identification of customers and the exchange of specific attributes necessary to comply with, for example, customer due diligence requirements under the Anti Money Laundering Regulation, [reference to be added after the adoption of the proposal], with suitability requirements stemming from investor protection legislation, or to support the fulfilment of strong customer authentication requirements for account login and for initiation of transactions in the field of payment services. »

Cette volonté de créer une synergie entre l’authentification forte dans le monde du paiement et celle issue du règlement eIDAS intéresse au premier plan des associations comme la Fédération des tiers de confiance du numérique (FNTC) ou France Payments Forum (FPF), qui ont rédigé un Position Paper sur la question¹¹.

Forte du succès de son implémentation, l’authentification forte devrait se répandre désormais à d’autres aspects du marché du paiement électronique. Cette extension du domaine de l’authentification n’ira pas sans de nombreux ajustements contractuels (avec les prestataires techniques) ni sans la mise en place d’une rationalisation de toutes les solutions d’identification/authentification, notamment celles relevant du futur Règlement eIDAS 2.