Pourquoi la cryptographie occupe désormais une place centrale dans la directive PSD2
La conformité à la directive PSD2 et à l'authentification forte du client (SCA) relève d'une obligation cryptographique, et non d'une simple case à cocher. L'authentification forte du client (SCA) s'applique à la plupart des paiements électroniques à distance depuis le 14 septembre 2019, en vertu du règlement délégué (UE) 2018/389 de la Commission et des normes techniques de réglementation (RTS) élaborées par l'Autorité bancaire européenne. Plusieurs autorités nationales ont mis en place une mise en œuvre progressive pour le commerce électronique par carte jusqu’en 2020. Derrière chaque processus d’authentification conforme se cache un ensemble de clés, de certificats et de liaisons cryptographiques qui doivent fonctionner correctement et rester à jour.
L'« open banking » a élargi le champ d'application des éléments nécessitant cette protection. La directive PSD2 a ouvert l'accès aux comptes de paiement à des tiers agréés ; les banques mettent donc désormais à disposition des API qui doivent respecter les mêmes exigences en matière de sécurité des communications que les canaux destinés aux clients. Ce guide présente en détail les exigences réglementaires et les techniques de cryptographie permettant de satisfaire à chaque mesure de contrôle.
Ce qu'exigent réellement la directive PSD2 et l'authentification forte du client
La règle fondamentale est simple. La loi SCA exige une authentification utilisant au moins deux éléments indépendants issus de trois catégories différentes, pour la plupart des paiements électroniques à distance et des accès aux comptes. Pour les opérations de paiement à distance, le code d'authentification doit être lié de manière dynamique au montant et au bénéficiaire concernés.
Les trois catégories de facteurs d'authentification
Ces trois catégories sont la connaissance, la possession et l'inhérence :
- Connaissance : information connue uniquement de l'utilisateur, telle qu'un mot de passe ou un code PIN.
- Possession : élément dont seul l'utilisateur dispose, tel qu'un appareil enregistré ou une clé stockée sur un élément sécurisé.
- Caractéristique intrinsèque : élément propre à l'utilisateur, tel qu'une empreinte digitale ou un scan facial.
L'expression « deux éléments indépendants » signifie que les facteurs doivent provenir d'au moins deux de ces catégories. Ils doivent également être indépendants, de sorte que le fait d'en compromettre un n'entraîne pas la compromission des autres. Cette indépendance est une propriété technique, et non une simple déclaration de principe.
Les repères réglementaires
Cette obligation découle d’actes juridiques précis. La disposition de base est l’article 97 de la directive (UE) 2015/2366. Les détails techniques sont précisés dans le règlement délégué (UE) 2018/389 de la Commission, qui établit les normes techniques de réglementation (RTS) relatives à l’authentification forte des clients et aux communications communes et sécurisées.
Au sein du RTS, un ensemble d'articles porte sur les aspects cryptographiques. Les articles 4 à 9 traitent de l'authentification du code et de sa liaison dynamique, ainsi que de l'indépendance des éléments d'authentification. Les conditions d'exemption sont énoncées aux articles 10 à 21. Les articles suivants régissent les communications sécurisées et la protection des identifiants de sécurité personnalisés.
Qui est concerné ?
La directive PSD2 concerne plusieurs acteurs, et chacun d'entre eux a un intérêt cryptographique dans son issue.
Prestataires de services de paiement chargés de la gestion des comptes (ASPSP)
Les ASPSP sont les banques et les établissements qui gèrent des comptes de paiement. Ils doivent mettre à disposition des API sécurisées aux tiers agréés et appliquer l'authentification forte (SCA) pour l'accès aux comptes et les paiements. Ils déterminent également la manière dont leur interface authentifie les parties qui s'y connectent.
Prestataires de services d'initiation de paiement et d'information sur les comptes (PISP et AISP)
Les PISP initient des paiements pour le compte d'un utilisateur, tandis que les AISP regroupent les informations relatives aux comptes. Ces deux types d'acteurs sont des prestataires tiers qui accèdent aux comptes dans le cadre de l'open banking. Pour se connecter, ils doivent s'identifier auprès de l'ASPSP à l'aide de certificats qualifiés et communiquer via un canal sécurisé. Les émetteurs d'instruments de paiement par carte (CBPII) accèdent également aux comptes pour vérifier la disponibilité des fonds et sont soumis aux mêmes règles d'identification et de communication sécurisée.
Émetteurs et acquéreurs de cartes
Les émetteurs et les acquéreurs appliquent la SCA aux transactions à distance, sans présentation physique de la carte. Dans la pratique, cela se fait généralement via le protocole EMV 3-D Secure. Ce protocole assure l'authentification et la liaison dynamique entre le commerçant, l'acquéreur et l'émetteur.
Comment la directive PSD2 s'applique à la cryptographie, mesure par mesure
Il s'agit du cœur analytique. Chaque domaine de contrôle du RTS correspond à un mécanisme cryptographique spécifique. Chacune des sous-sections ci-dessous est indépendante ; répondez d'abord à celles-ci.
Liaison dynamique des codes d'authentification (articles 4 et 5 du RTS)
La liaison dynamique associe le code d'authentification à un paiement spécifique. Ce code est lié de manière cryptographique au montant exact et au bénéficiaire ; toute modification de l'un ou de l'autre le rend donc invalide. Cela empêche toute relecture et empêche un pirate de falsifier les détails de la transaction après son approbation.
Indépendance des éléments d'authentification (article 9 du RTS)
L'indépendance garantit la séparation cryptographique des facteurs. Un facteur de possession basé sur un certificat ou une clé est isolé des facteurs de connaissance et d'inherent utilisés conjointement avec lui. Si un canal ou un élément est compromis, cette isolation empêche les autres d'être compromis à leur tour.
Communication sécurisée pour les API de l'open banking (articles 28, 30, 34 et 35 du RTS)
Les API d'open banking doivent authentifier les deux parties et protéger les données en transit. La norme RTS s'appuie sur des certificats qualifiés délivrés dans le cadre de la directive eIDAS. Deux types de certificats sont concernés : les certificats qualifiés pour l'authentification de sites web (QWAC) et les certificats qualifiés pour les cachets électroniques (QSealC).
Ces deux types de certificats remplissent des fonctions différentes. Un QWAC identifie les terminaux et sécurise le canal, tandis qu’un QSealC scelle les données de l’application afin d’en prouver l’origine et l’intégrité. L’ TLS e mutuelle permet ensuite d’authentifier la session API entre l’ASPSP et le TPP.
Les API que les ASPSP mettent à la disposition des AISP et des PISP doivent répondre aux mêmes exigences en matière de sécurité des communications que leurs canaux destinés à la clientèle.
Confidentialité et intégrité des identifiants personnalisés (articles 22 à 27 du RTS)
Les identifiants de sécurité personnalisés doivent être protégés tout au long de leur cycle de vie. Cela implique une gestion rigoureuse des certificats et des clés qui protègent ces identifiants contre toute divulgation ou compromission. Toute faille dans la délivrance, le stockage ou le renouvellement de ces clés compromet toutes les authentifications qui s’appuient sur celles-ci.
Justificatifs relatifs à l'exemption de l'analyse des risques de transaction (articles 18 à 20 du RTS)
L'exemption relative à l'analyse des risques liés aux transactions (TRA) permet à un prestataire de ne pas appliquer la SCA aux paiements présentant un risque moindre, mais uniquement s'il peut en apporter la preuve. Les calculs documentés du taux de fraude sur lesquels repose une demande d'exemption TRA s'appuient sur des données cryptographiques et d'authentification justificatives. Si le taux de fraude surveillé dépasse les seuils fixés par les RTS, le droit de bénéficier de cette exemption est perdu.
Intégrité des demandes de paiement (article 9, paragraphe 3, du RTS)
La fiabilité du facteur de possession dépend entièrement de celle de l’application qui le met en œuvre. L’article 9, paragraphe 3, exige la mise en place d’environnements d’exécution sécurisés et séparés sur les appareils polyvalents, ainsi que de mécanismes permettant de vérifier que l’ software u l’appareil n’a pas été altéré. Les versions signées des applications bancaires et de paiement mobiles garantissent cette intégrité. La signature de code permet à un appareil de vérifier qu’une version provient bien du fournisseur et qu’elle n’a pas été modifiée pendant son transfert.
Ce que recherchent les auditeurs : l'état de préparation à l'audit
Les évaluations prudentielles s'appuient sur des éléments probants concrets, et non pas uniquement sur des déclarations de principe. Pour vous y préparer, il est utile de procéder à une auto-évaluation en vous référant aux contrôles sur lesquels l'inspecteur se penchera. Considérez chaque point comme un élément que vous devez être en mesure de démontrer, et pas seulement de décrire.
- Liaison dynamique : montrer que le code d'authentification est lié au montant et au bénéficiaire, et que toute modification l'invalide.
- Indépendance des facteurs : démontrer que le facteur de possession est cryptographiquement isolé des autres éléments.
- Certificats qualifiés : attestent que les certificats QWAC et QSealC destinés aux API d’open banking sont valides, à jour et utilisés correctement.
- Documents relatifs aux exonérations TRA : fournir les éléments prouvant le taux de fraude justifiant chaque exonération demandée.
- Cycle de vie des identifiants : preuve que les certificats et les clés protégeant les identifiants personnalisés sont gérés de bout en bout.
- Préparation aux normes PSD3 et PSR : présenter un plan pour la prochaine mise à jour du cadre relatif aux dérogations et à l’authentification.
Les enjeux : responsabilité, application de la réglementation et risques liés à l’« open banking »
Le non-respect des exigences en matière d'authentification forte (SCA) entraîne des conséquences concrètes. Les infractions à l’authentification forte (SCA), en particulier les défaillances de liaison dynamique et l’utilisation abusive de l’exemption TRA, figurent toujours parmi les constatations les plus courantes dans le cadre de la surveillance exercée par les autorités nationales compétentes. En vertu de l’article 74, paragraphe 2, de la directive PSD2, lorsque le prestataire de services de paiement (PSP) du payeur n’exige pas d’authentification forte (SCA), le payeur ne subit aucune perte financière en l’absence de fraude de sa part, et le bénéficiaire ou le PSP du bénéficiaire qui n’accepte pas l’authentification forte (SCA) indemnise le PSP du payeur.
L'« open banking » accroît encore davantage cette vulnérabilité. Chaque API qu'une banque met à la disposition de tiers constitue un canal supplémentaire qui doit satisfaire aux mêmes exigences cryptographiques. L'expiration d'un certificat qualifié sur l'une de ces API entraîne à la fois une interruption de service et un manquement à la conformité, et peut donner lieu à des mesures coercitives directes.
Perspectives d'avenir : PSD3, PSR et préparation à l'ère post-quantique
La PSD2 n'est pas définitive. Le Parlement européen et le Conseil sont parvenus à un accord politique provisoire sur la PSD3 et le règlement sur les services de paiement (PSR) le 27 novembre 2025, et le Conseil a publié les textes de compromis définitifs le 23 avril 2026. L'adoption formelle et la publication au Journal officiel sont encore en suspens. Les principales règles de conduite du PSR s'appliqueront environ 18 à 21 mois après l'entrée en vigueur, ce qui place leur application effective entre fin 2027 et 2028. La PSD2 reste le cadre applicable jusqu'à cette date.
Ces mesures devraient permettre d'affiner le cadre des dérogations et de renforcer l'authentification dans le cadre de l'« open banking ». L'obligation relative à l'authentification forte (SCA) qui sous-tend ces mesures reste toutefois en vigueur.
Une deuxième échéance approche parallèlement. Le NIST a finalisé les normes FIPS 203, 204 et 205 en août 2024. Le calendrier de transition figure dans un document distinct, le NIST IR 8547, qui n'en est encore qu'à l'état d'avant-projet public. Selon ce document, les algorithmes à clé publique vulnérables aux attaques quantiques, notamment RSA, ECDSA, ECDH et Diffie-Hellman sur corps fini, seront dépréciés après 2030 et interdits après 2035.
Le 13 janvier 2026, le groupe d'experts sur la cybersécurité du G7, présidé par le ministère américain des Finances et la Banque d'Angleterre, a publié une feuille de route coordonnée pour la migration vers des systèmes post-quantiques dans le secteur financier. Celle-ci définit six phases, allant de la sensibilisation et de la préparation à l'inventaire, l'évaluation des risques, la planification, la mise en œuvre et la validation, et précise qu'elle ne fixe ni orientations ni attentes réglementaires.
Le calendrier est plus serré qu'il n'y paraît pour l'infrastructure de paiement. SWIFT a indiqué que SwiftNet 8.0 devrait être compatible avec les systèmes post-quantiques en 2027, avec une période de migration de 15 mois pour les établissements participants. Or, des enquêtes récentes révèlent que seul un faible pourcentage des établissements financiers mondiaux a entamé une migration concrète.
Les données collectées pouvant être déchiffrées ultérieurement, c'est la durée de confidentialité de ces données qui fixe la véritable échéance. C'est pourquoi la « crypto-agilité » constitue une priorité dès aujourd'hui, à l'ère de la PSD2, et non pas une priorité pour l'avenir.
Comment « Keyfactor » assure la conformité aux normes PSD2 et SCA
Keyfactor aide les prestataires de services de paiement réglementés à gérer la confiance cryptographique dont dépendent la conformité à la directive PSD2 et à l’authentification forte (SCA). Le lien entre les contrôles RTS et le produit est direct.
EJBCA Il émet et gère les certificats liés à la liaison dynamique, à l'indépendance vis-à-vis des facteurs et à l'TLS mutuelle, y compris la délivrance de certificats QWAC et QSealC. Il est conforme aux normes PKI et est prêt pour les certificats post-quantiques et hybrides.
SignServer signe les demandes de paiement et les autorisations relatives aux services bancaires mobiles, garantissant ainsi l’intégrité du facteur de possession mis en œuvre par ces applications. AgileSec identifie et recense les actifs cryptographiques, fournissant ainsi les éléments probants nécessaires à la documentation TRA et à la planification post-quantique.
Keyfactor Command tient à jour un registre de tous les certificats et clés protégeant les identifiants personnalisés et les API d'open banking. Il automatise le renouvellement bien avant la date d'expiration, de sorte qu'un certificat valide ne soit jamais à l'origine d'une interruption de service ou d'une anomalie constatée lors d'un audit.
Le « Trust Control Plane » d’ Keyfactor rassemble ces éléments au sein d’une plateforme unique qui observe, analyse, provisionne, orchestre et gère chaque actif cryptographique et chaque identité de machine au sein des infrastructures bancaires centrales, de paiement et d’open banking, de sorte que les preuves requises par n’importe quel cadre réglementaire proviennent d’un système d’enregistrement unique. C’est sur cette base que seront évaluées tant la directive PSD2 aujourd’hui que la PSD3 demain.
Synthèse et prochaines étapes
La SCA est une fonctionnalité cryptographique, et non un moyen de contrôle à usage unique. Ces règles se traduisent par des éléments concrets : des codes d’authentification liés aux données de transaction, des facteurs de possession isolés, des certificats qualifiés sur chaque interface bancaire ouverte, ainsi que des données documentées sur les taux de fraude.
Quatre points de départ concrets s’appliquent, quelle que soit la situation actuelle d’un établissement :
- Dresser l'inventaire des certificats et des clés utilisés pour l'authentification et les API d'open banking.
- Vérifiez que la liaison dynamique fonctionne et que les facteurs d'authentification sont bel et bien indépendants.
- Veillez à ce que les certificats qualifiés pour les API d’open banking restent valides et à jour.
- Consigner le taux de fraude et les preuves cryptographiques justifiant chaque dérogation au TRA.
Considérée comme un programme continu plutôt que comme un projet, cette base permet à chaque nouvelle exigence, qu’il s’agisse d’une norme PSD3, d’une recommandation PSR ou d’une échéance post-quantique, d’être prise en charge par une infrastructure qui y répond déjà. Demander une démo
Vous avez des questions sur la directive PSD2 et l'authentification forte (SCA) ? Nous avons les réponses.
Qu'est-ce que la PSD2 ?
La PSD2 est la deuxième directive européenne sur les services de paiement, la directive (UE) 2015/2366, applicable depuis le 13 janvier 2018. Elle a remplacé la première directive sur les services de paiement. Elle a ouvert l'accès aux comptes de paiement à des tiers agréés et a établi des règles de sécurité pour les paiements électroniques, notamment l'authentification forte du client.
Qu'est-ce que l'authentification forte du client (SCA) ?
La SCA exige au moins deux éléments d'authentification indépendants issus de trois catégories : la connaissance, la possession et l'inherent. Elle s'applique à la plupart des paiements électroniques à distance et des accès aux comptes depuis le 14 septembre 2019, conformément aux normes techniques de mise en œuvre (RTS) de l'ABE.
Qu'est-ce que la liaison dynamique ?
La liaison dynamique lie de manière cryptographique le code d'authentification à un montant de paiement et à un bénéficiaire spécifiques. Toute modification de l'un ou de l'autre invalide le code, ce qui empêche la relecture et la falsification des détails de la transaction.
Que sont les QWAC et les QSealC ?
Il s'agit dans les deux cas de certificats qualifiés délivrés dans le cadre du règlement eIDAS. Un QWAC (certificat qualifié d'authentification de site web) identifie les terminaux et sécurise le canal de communication TLS . Un QSealC (certificat qualifié de sceau électronique) scelle les données API afin d'en prouver l'origine et l'intégrité.
Quels sont les articles du RTS les plus importants en matière de cryptographie ?
Les articles 4 à 9 traitent du code d'authentification, de la liaison dynamique, des catégories d'éléments et de l'indépendance. Les articles 18 à 20 traitent de l'exemption TRA et des preuves relatives au taux de fraude. Les articles 22 à 27 traitent de la protection des identifiants personnalisés. Les articles 28, 30, 34 et 35 traitent de l'identification et des communications sécurisées pour les API de l'open banking.
Qu'est-ce que l'exemption TRA ?
L'analyse des risques liés aux transactions permet à un prestataire de ne pas appliquer la SCA pour les paiements présentant un risque moindre. Elle n'est autorisée que lorsque les taux de fraude documentés restent inférieurs aux seuils fixés par les RTS, et sont étayés par des preuves cryptographiques et d'authentification.
En quoi la PSD3 diffère-t-elle de la PSD2 ?
La PSD3 associe une directive à un règlement sur les services de paiement directement applicable. La PSD3 intègre également les établissements de monnaie électronique dans un régime d’agrément unique, remplaçant ainsi la directive EMD2. En matière d’authentification, le règlement sur les services de paiement (PSR) devrait préciser dans son texte que l’authentification forte (SCA) s’applique à l’ajout d’une carte à un portefeuille numérique, et prendre en charge les méthodes d’authentification ne nécessitant pas de smartphone. La mise en œuvre effective est prévue entre fin 2027 et 2028. L’obligation fondamentale relative à l’authentification forte (SCA) reste en vigueur.
Pourquoi la gestion des certificats est-elle essentielle pour la conformité à la directive PSD2 ?
La directive PSD2repose sur des certificats et des clés qualifiés qui ont une durée de validité limitée et doivent être validés, renouvelés et révoqués de manière appropriée. L'automatisation de la détection, du renouvellement et de la gouvernance permet d'éviter les interruptions de service, facilite les audits et garantit la fiabilité des API de l'open banking.
Le RTS exige-t-il une « mutual TLS » ?
Le RTS exige des certificats qualifiés pour l'identification et une session de communication sécurisée, et la « mutual TLS » est la mise en œuvre courante sur le marché, comme par exemple dans la spécification du Groupe de Berlin.
