Une question récurrente chez les responsables IT et les développeurs : pourquoi ne pas exiger une validation MFA uniquement sur les actions critiques — un virement, une modification de droits, un accès à des données sensibles — plutôt qu’à chaque connexion ?

La réponse courte : c’est non seulement possible, mais c’est l’approche recommandée. Ce mécanisme porte un nom technique — l’authentification renforcée contextuelle ou Step-Up Authentication — et il est devenu un pilier des architectures Zero Trust modernes. Ce qui a freiné son adoption historique, c’est une combinaison de barrières cognitives, architecturales et réglementaires qu’il faut comprendre pour les dépasser.

Le problème : la fatigue MFA

Si une application exigeait une confirmation biométrique ou un code OTP à chaque sauvegarde, chaque consultation de fichier, chaque action de routine, les utilisateurs seraient rapidement conditionnés à approuver machinalement. C’est précisément ce phénomène — la fatigue MFA — que les attaquants exploitent activement.

Le Push Bombing : une attaque qui table sur l’épuisement

La technique est simple et redoutablement efficace :

L’attaquant a obtenu vos identifiants (phishing, fuite de base de données, credential stuffing)
Il tente de se connecter à répétition, déclenchant autant de notifications push sur votre téléphone
Agacé, distrait, ou simplement épuisé par les vibrations incessantes à 23h, l’utilisateur finit par appuyer sur “Approuver”
L’attaquant entre

Microsoft, Uber, Cisco Duo ont tous documenté des compromissions majeures opérées exactement par ce vecteur. Le MFA n’a pas échoué techniquement — c’est la psychologie humaine qui a cédé.

La réponse : concentrer la friction là où elle compte

La solution n’est pas de supprimer le MFA, mais de le rendre intelligent :

Laisser l’accès aux ressources courantes fonctionner fluidement (lecture d’e-mails, consultation de documents)
Déclencher une vérification renforcée uniquement pour les actions à fort enjeu : virement, modification de contrat, changement de droits d’accès, export massif de données

L’attention de l’utilisateur est une ressource limitée. La Step-Up Authentication la préserve pour les moments où elle est véritablement indispensable.

Méthodes d’authentification : lesquelles résistent vraiment ?

Toutes les méthodes MFA ne se valent pas face aux attaques modernes.

Méthode	Résistance au Push Bombing	Résistance au phishing de jetons
Notification push standard (Approuver/Refuser)	Faible — approbation accidentelle possible	Faible
Correspondance de numéros (Number Matching)	Élevée — saisie active obligatoire	Moyenne
Code SMS / OTP	Moyenne	Faible (interceptable)
Application TOTP (Authenticator)	Élevée	Moyenne
Clé FIDO2 / Passkey / Windows Hello	Totale — pas de notification à approuver	Totale — liée au domaine

Pour les comptes critiques (direction, finance, accès administrateur), les authentificateurs FIDO2 sont la seule méthode véritablement résistante au phishing de jetons — incluant les attaques de type Kali365 décrites dans l’article précédent sur le vol de jetons OAuth.

L’authentification basée sur le risque : ne demander que ce qui est justifié

Les solutions IAM modernes (Okta, Duo, Microsoft Entra ID) ne se contentent pas d’appliquer des règles statiques. Elles évaluent en temps réel le contexte de chaque requête pour décider si une vérification supplémentaire s’impose.

Ce moteur d’évaluation contextuelle analyse notamment :

Voyage irréaliste : connexion depuis Tokyo deux heures après une session depuis Paris
Incohérence géographique : l’ordinateur est en France, le téléphone qui approuve est en Roumanie
Réseau inconnu : requête depuis un ASN (bloc d’adresses IP) jamais utilisé dans l’organisation
Motif de harcèlement : plusieurs refus rapides sur un même compte — signal d’attaque en cours

Lorsqu’un risque élevé est détecté, le système ne se contente pas de demander une MFA — il bloque les méthodes jugées insuffisantes (push standard, SMS) pour n’autoriser que les facteurs de haute assurance (FIDO2, correspondance de numéros).

À l’inverse, quand le contexte est familier (réseau d’entreprise connu, appareil géré, comportement normal), les sollicitations redondantes sont supprimées. L’utilisateur n’est interrompu que lorsque son comportement dévie de sa norme historique.

Le défi technique : les jetons JWT sont immuables

Pour comprendre pourquoi la Step-Up Authentication nécessite une architecture dédiée, il faut comprendre un mécanisme fondamental des applications modernes : les jetons JWT (JSON Web Tokens).

Quand un utilisateur se connecte, le fournisseur d’identité émet un JWT signé cryptographiquement, qui contient ses droits d’accès. Ce jeton circule entre le navigateur, les microservices et les APIs. Son intégrité est garantie par la signature : personne ne peut modifier son contenu sans casser la cryptographie.

Problème : si un utilisateur effectue un défi MFA supplémentaire pour une action critique, le système ne peut pas simplement “noter” cette élévation dans le JWT existant. Toute modification briserait la signature. Il faut donc une architecture parallèle pour gérer cet état d’élévation temporaire.

Architecture de référence (AWS)

Une implémentation robuste combine :

Amazon Cognito comme fournisseur d’identité OAuth 2.0
API Gateway + Lambda Authorizer comme intercepteur de toutes les requêtes
DynamoDB comme registre de sessions enrichies, avec TTL automatique (expiration après 24h par défaut)

Le flux fonctionne ainsi :

L’utilisateur appelle /transfert — l’API retourne un 401 Unauthorized
L’application initie le défi MFA via /initiate-auth
L’utilisateur valide le code OTP ou biométrique
DynamoDB enregistre l’élévation avec le jti (identifiant unique du JWT) comme clé
L’application rejoue la requête initiale — le Lambda Authorizer confirme l’élévation, la fonction s’exécute

Le jeton JWT original n’est jamais modifié. L’état d’élévation existe en dehors de lui, lié à lui par son identifiant unique.

La norme RFC 9470 : un protocole standardisé pour le Step-Up

Jusqu’en 2023, les implémentations de Step-Up étaient propriétaires et non interopérables. L’IETF a publié en septembre 2023 la RFC 9470 — OAuth 2.0 Step Up Authentication Challenge Protocol, qui standardise ce mécanisme.

La norme définit comment un serveur de ressources communique précisément à un client ce qu’il manque pour accéder à une fonction protégée. Deux paramètres clés :

`acr_values` — la force requise

Le serveur renvoie un 401 avec un en-tête précisant le niveau d’authentification exigé :

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_user_authentication",
                  acr_values="phishing-resistant"

Le client sait alors exactement quelle méthode demander au fournisseur d’identité. Si ce dernier ne peut pas satisfaire l’exigence, il retourne unmet_authentication_requirements.

`max_age` — la fraîcheur requise

Pour les actions particulièrement sensibles (consultation de données médicales, signatures électroniques), il ne suffit pas que l’utilisateur se soit authentifié ce matin — il faut garantir qu’il est présent devant l’écran maintenant :

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_user_authentication",
                  max_age="600"

Le client est forcé de déclencher une ré-authentification active (prompt=login), court-circuitant le SSO, et le nouveau jeton contiendra un auth_time mis à jour que le serveur peut vérifier.

Zero Trust et ANSSI : l’authentification transactionnelle comme doctrine

La Step-Up Authentication n’est pas une option avancée pour grandes entreprises — elle est au cœur de la doctrine Zero Trust recommandée par l’ANSSI.

Le modèle traditionnel de sécurité périmétrique accorde une confiance implicite à tout utilisateur connecté au réseau interne ou via VPN : une fois authentifié, il peut naviguer librement. Zero Trust supprime cette confiance implicite. L’identité doit être prouvée continûment, en fonction de la ressource accédée.

L’ANSSI recommande un modèle de contrôle d’accès ABAC (Attribute-Based Access Control) qui évalue dynamiquement trois dimensions pour chaque requête :

Pilier	Questions posées	Exemples d’attributs
Sujet	Qui est-il ? Quel est son rôle ?	Fonction, département, historique
Contexte	Depuis quel appareil et réseau ?	Conformité de l’OS, géolocalisation, EDR actif
Ressource	Quelle est la criticité de l’action ?	Données personnelles, finances, accès admin

Une règle ABAC typique : un virement supérieur à 5 000 € initié depuis un réseau public déclenche obligatoirement une authentification FIDO2, quelle que soit la durée de la session en cours.

L’ANSSI met en garde contre une adoption précipitée du Zero Trust : elle doit être progressive, complémentaire aux protections périmétriques existantes, et reposer sur une cartographie préalable exhaustive des applications, utilisateurs, données et flux — sans quoi les politiques d’accès conditionnel seront mal calibrées.

RGPD et CNIL : les limites à ne pas franchir

La collecte de données contextuelles en temps réel — géolocalisation, empreinte d’appareil, comportement utilisateur — constitue un traitement de données personnelles soumis au RGPD.

Quelques points d’attention relevés par la CNIL :

Base légale : l’intérêt légitime de l’entreprise ne suffit pas toujours, surtout dans les relations de travail. Les obligations légales sectorielles (NIS2, secteur bancaire) constituent une base plus solide.
Proportionnalité : exiger l’installation d’une application d’entreprise sur le téléphone personnel d’un salarié nécessite un encadrement contractuel explicite. L’application ne doit collecter que les données strictement nécessaires à l’authentification.
Sous-traitance : les fournisseurs d’identité SaaS (Okta, Auth0, Cognito) sont des sous-traitants au sens de l’article 28 du RGPD. Un DPA (Data Processing Agreement) formalisé est obligatoire.

L’horizon suivant : CAEP et les signaux partagés (SSF)

La Step-Up MFA à la transaction est l’état de l’art actuel. Mais il reste un angle mort : si, cinq minutes après une authentification biométrique réussie, l’appareil de l’utilisateur est compromis — que se passe-t-il ?

Avec une architecture classique, le jeton reste valide jusqu’à son expiration. La fenêtre de tir peut durer des heures.

CAEP (Continuous Access Evaluation Profile) et SSF (Shared Signals Framework) — deux standards IETF en cours de déploiement — répondent à cette limite en instaurant des flux d’événements en temps réel entre les composants de sécurité du SI :

L’agent EDR détecte une anomalie sur un poste → signal CAEP émis
Le fournisseur d’identité reçoit le signal → révocation immédiate des jetons OAuth, avant leur expiration naturelle
L’utilisateur est déconnecté de toutes ses sessions actives en quelques secondes

CAEP permet également d’initier un Step-Up MFA en plein milieu d’une session, sans attendre qu’un utilisateur clique sur une action critique. Si le contexte change (connexion via un Wi-Fi public inconnu détectée), la session est gelée et une ré-authentification immédiate est exigée.

C’est la concrétisation complète du principe Zero Trust : la confiance n’est jamais acquise une fois pour toutes, elle est calculée et réévaluée en permanence, transaction par transaction, signal par signal.

Ce que ça implique concrètement pour une petite structure

Pour une TPE ou PME utilisant Microsoft 365 ou Google Workspace, les actions accessibles aujourd’hui :

Activer l’accès conditionnel avec des politiques différenciées selon la criticité des actions (disponible en M365 Business Premium)
Déployer la correspondance de numéros dans Microsoft Authenticator pour éliminer l’approbation accidentelle
Prévoir des clés FIDO2 pour les comptes à hauts privilèges (direction, finance, admin IT) — environ 50-70 € par clé
Documenter les règles ABAC minimales : quelles actions déclenchent une vérification supplémentaire, pour quels rôles, depuis quels réseaux

La sophistication de l’architecture peut croître avec la taille et les risques de l’organisation. L’important est de poser les bases : ne pas traiter tous les accès comme identiques, et concentrer les contrôles là où les enjeux sont réels.

Vous souhaitez évaluer la maturité de votre gestion des accès ou réfléchir à la mise en place d’une politique d’authentification adaptée à votre organisation ? Un diagnostic peut identifier les points de fragilité prioritaires.

Sources : IETF RFC 9470 (OAuth 2.0 Step Up Authentication Challenge Protocol, septembre 2023) ; ANSSI, “Recommandations sur l’architecture Zero Trust” ; CNIL, recommandations sur l’authentification et la protection des données des salariés ; Duo Security, documentation RBFS ; OpenID Foundation, CAEP/SSF specifications.