La DSP2 — directive (UE) 2015/2366 — ne prescrit aucune technologie. Elle pose une exigence de résultat : sur les opérations concernées, l'authentification forte du client (SCA) repose sur au moins deux facteurs issus de catégories distinctes, indépendants l'un de l'autre, et le code d'authentification doit être lié dynamiquement au montant et au bénéficiaire de l'opération. La conformité ne se joue donc pas sur le nombre d'étapes visibles dans un parcours, mais sur deux propriétés bien plus exigeantes : l'indépendance effective des facteurs et le rattachement du geste de validation à l'opération précise qu'il autorise.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. Le périmètre des opérations soumises à la SCA, comme le recours aux exemptions, s'apprécie au cas par cas et doit être arbitré avec vos conseils.
Deux facteurs ne suffisent pas : il faut deux catégories
Le texte raisonne en trois familles : la connaissance (ce que l'utilisateur sait), la possession (ce qu'il détient), l'inhérence (ce qu'il est). Deux facteurs pris dans la même famille ne constituent pas une authentification forte, même s'ils sont demandés l'un après l'autre.
Ce que « catégories distinctes » exclut en pratique
Un mot de passe suivi d'une question secrète reste une double vérification de connaissance. Un code d'accès suivi d'un code confidentiel également. La distinction paraît évidente sur le papier ; elle l'est moins dans des parcours empilés au fil des années, où une étape a été ajoutée pour « renforcer » sans que sa catégorie ait été qualifiée. Le travail utile consiste donc à inventorier les facteurs réellement mobilisés, parcours par parcours, et à qualifier la famille de chacun. L'exercice révèle presque toujours un parcours sensible protégé deux fois par la même chose.
L'indépendance : la propriété la plus souvent perdue
L'exigence est explicite : la compromission d'un facteur ne doit pas entraîner celle de l'autre. C'est là que beaucoup d'architectures se fragilisent sans le voir. Lorsque le mot de passe est conservé dans le gestionnaire du téléphone et que le code à usage unique arrive sur ce même téléphone, un terminal compromis livre les deux facteurs d'un seul coup. Une biométrie qui ne sert qu'à déverrouiller l'application contenant déjà le secret protège le conteneur ; elle n'ajoute pas de canal indépendant.
Le cas du SMS mérite un traitement distinct. Le NIST, dans sa publication SP 800-63B, classe l'OTP par SMS ou par voix en catégorie « restricted », c'est-à-dire déconseillée. Le canal n'est pas maîtrisé par le prestataire et reste exposé au détournement de carte SIM comme au relais en temps réel — voir SMS-OTP face au SIM swapping.
Le lien dynamique : l'utilisateur doit voir ce qu'il valide
Le lien dynamique est la disposition la plus structurante du texte, et souvent la plus traitée comme un détail d'implémentation. Le code d'authentification est rattaché au montant et au bénéficiaire ; toute modification de l'un ou de l'autre invalide le code.
La conséquence première est une conséquence d'interface. Si l'écran de validation affiche seulement « Confirmez-vous votre connexion ? », l'utilisateur ne dispose d'aucun moyen de détecter qu'un relais a substitué le bénéficiaire entre son navigateur et sa banque. Pour que le lien dynamique produise son effet, l'opération doit être rendue lisible dans le canal où elle est validée : montant, bénéficiaire et nature de l'action affichés là où le geste de confirmation est réellement effectué. Un lien dynamique invisible pour l'utilisateur reste un contrôle serveur ; il ne devient une preuve de consentement que lorsque la personne voit ce qu'elle approuve. C'est précisément l'écart que travaille l'authentification cognitive, en cherchant à établir une intention humaine consciente plutôt que la simple détention d'un secret.
Authentifier une session, valider une opération : deux choses différentes
Une session ouverte est un état ; une opération de paiement est un acte. Or le vol de jeton de session et le relais adverse permettent d'hériter d'une session déjà authentifiée sans jamais avoir présenté un facteur.
La conséquence pratique est simple à énoncer, plus difficile à mettre en œuvre : les actions sensibles doivent déclencher une validation propre, contextualisée, indépendante de l'état de la session. C'est la logique du step-up, appliquée non pas au niveau de l'application mais au niveau de l'action.
Les exemptions : un déplacement de la charge, pas une dispense
Le texte prévoit des exemptions — opérations de faible montant, analyse du risque de transaction, bénéficiaires de confiance, opérations récurrentes. Elles répondent à un objectif d'usage légitime : une friction systématique dégrade l'expérience sans gain de sécurité proportionné.
Leur contrepartie est rarement mesurée. Exempter, c'est accepter la charge du pilotage du risque : disposer d'une analyse défendable, journaliser la décision, savoir reconstituer longtemps après pourquoi telle opération n'a pas déclenché de SCA. C'est aussi accepter que la fraude se déplace vers les zones de moindre friction. Une politique d'exemption non instrumentée devient, à terme, une cartographie offerte aux attaquants.
De l'exigence au contrôle
| Élément de la SCA | Traduction concrète côté authentification | Question à se poser |
|---|---|---|
| Catégories distinctes | Qualifier la famille réelle de chaque facteur | Deux facteurs relèvent-ils de la même famille sans qu'on l'ait vu ? |
| Indépendance | Vérifier qu'un canal compromis ne livre pas les deux | Que reste-t-il si le téléphone est compromis ? |
| Lien dynamique | Afficher l'opération là où elle est validée | L'écran montre-t-il l'opération, ou seulement un bouton ? |
| Session ou opération | Valider l'action, pas seulement l'accès | Une session volée permet-elle d'agir sans nouvelle preuve ? |
| Exemptions | Journaliser la décision et son analyse de risque | Sait-on justifier après coup l'absence de SCA ? |
Une progression réaliste tient en quatre mouvements. Un : inventorier les facteurs par parcours et qualifier leur catégorie. Deux : traiter en priorité les couples de facteurs qui partagent un terminal ou un canal. Trois : reprendre les écrans de validation pour que l'opération y soit lisible, avant même de changer de technologie. Quatre : rendre la politique d'exemption auditable.
FAQ
La DSP2 impose-t-elle une technologie d'authentification précise ?
Non. Le texte décrit des propriétés attendues — catégories distinctes, indépendance, lien dynamique — et laisse le choix des moyens. La conséquence est que la charge de la démonstration revient au prestataire : il doit pouvoir expliquer en quoi le dispositif retenu est adapté au risque de l'opération concernée.
Un mot de passe et un code reçu sur le même téléphone constituent-ils une SCA valable ?
Les deux facteurs relèvent bien de catégories différentes, mais l'exigence d'indépendance est fragilisée dès lors que la compromission d'un terminal unique donne accès aux deux. Le point se traite en déplaçant l'un des facteurs sur un support distinct.
Faut-il redemander une SCA à chaque action dans une session déjà ouverte ?
Le texte raisonne par opération, pas par session. La bonne question n'est donc pas « l'utilisateur est-il connecté ? » mais « cette action-là a-t-elle été autorisée par une preuve rattachée à son montant et à son bénéficiaire ? ». C'est cette lecture qui protège des scénarios de session héritée.
Les exemptions dispensent-elles de tout contrôle ?
Elles déplacent le contrôle plutôt qu'elles ne le suppriment. Recourir à une exemption suppose une analyse de risque documentée, une journalisation exploitable et une capacité à justifier la décision a posteriori, notamment en cas de contestation d'une opération.
Aller plus loin : DSP2 appliquée aux parcours bancaires · la SCA en une définition