Un attaquant ne se bat pas contre votre meilleure défense : il cherche la plus faible. Sur une chaîne d'authentification, c'est presque toujours le parcours de récupération — celui qu'on conçoit pour dépanner un utilisateur pressé, et qu'on audite rarement. Voici comment en établir le niveau réel.
Pourquoi ce parcours définit le niveau du système
Le raisonnement est arithmétique. Si l'accès nominal exige une méthode liée à l'origine, mais que le parcours « j'ai perdu mon appareil » aboutit à un code envoyé par e-mail, alors le coût d'entrée pour un attaquant n'est pas celui de la méthode forte : c'est celui de la boîte mail.
Cela produit une situation courante et coûteuse : une organisation déploie des passkeys, communique sur le passage au sans mot de passe, et conserve un secours qui annule le bénéfice. Le dispositif principal n'est pas en cause ; c'est la porte de service qui est restée ouverte.
Étape 1 — Recenser tous les chemins de reprise, y compris humains
Un parcours de récupération n'est pas seulement une page « mot de passe oublié ». Recensez :
- la réinitialisation en libre-service ;
- l'enrôlement d'un nouvel appareil ;
- les codes de secours imprimés ou stockés ;
- l'intervention du support interne ;
- l'intervention du support de l'éditeur ;
- la procédure d'urgence — celle qui existe « en cas de blocage », souvent non documentée ;
- les comptes de secours administrateur (break-glass).
Le dernier point mérite une attention particulière : ces comptes existent précisément pour contourner les contrôles. Leur protection est rarement au niveau de leur pouvoir.
Étape 2 — Qualifier chaque chemin par ce qu'il exige réellement
Pour chaque chemin, notez ce que l'on doit détenir ou savoir pour aboutir, puis demandez-vous ce qu'un attaquant peut obtenir sans vous.
| Élément demandé | Difficulté pour un attaquant | Remarque |
|---|---|---|
| Nom, date de naissance, matricule | faible | figure dans des fuites ou sur les réseaux sociaux |
| Adresse e-mail professionnelle | faible | souvent déductible du format de l'entreprise |
| Code envoyé par SMS | modérée | vulnérable au SIM swapping |
| Code envoyé par e-mail | variable | équivaut à la sécurité de la boîte mail |
| Réponse à une question secrète | faible | souvent devinable ou trouvable |
| Confirmation par le manager | modérée | dépend d'un contrôle humain, sensible à la manipulation |
| Vérification en présentiel | élevée | coûteuse mais robuste |
| Identité attestée (portefeuille eIDAS 2) | élevée | déplace la preuve vers un tiers qualifié |
Critère d'analyse : le chemin le plus faible qui aboutit définit le niveau du parcours. Pas la moyenne, pas l'intention.
Étape 3 — Tester le facteur humain, pas seulement l'interface
C'est l'angle mort de la plupart des audits. Le support est formé pour aider, sous pression de temps, et l'attaquant exploite exactement cela.
Testez le scénario suivant sur votre propre organisation, avec l'accord de la direction : un interlocuteur se présente comme un collaborateur en déplacement, invoque une urgence vérifiable (réunion imminente, dossier à rendre), fournit les informations publiques attendues, et demande une réinitialisation.
Ce qu'il faut observer : le support peut-il aboutir ? Quelle vérification l'en empêche ? Cette vérification est-elle contournable par insistance ou par escalade hiérarchique invoquée ?
Un support qui ne peut pas techniquement réinitialiser sans une preuve indépendante est plus robuste qu'un support à qui l'on demande d'être vigilant. La consigne dépend d'un jugement ; la contrainte technique, non.
Étape 4 — Vérifier le réenrôlement, qui est le même problème déguisé
Reprendre la main sur un compte et enrôler un nouvel appareil sont deux formes d'un même acte : rétablir un lien de confiance sans le facteur habituel.
Vérifiez donc si l'enrôlement d'un nouvel appareil exige une preuve du même niveau que celle qu'il remplace. Dans le cas contraire, il suffit d'enrôler un appareil pour disposer ensuite d'une méthode forte — obtenue par un chemin faible. Ce point rejoint la question plus générale de l'enrôlement comme plafond de sécurité.
Étape 5 — Décider un plancher, et l'écrire
Un audit qui se termine par une liste d'observations ne change rien. Il doit produire une règle opposable, du type : aucun chemin de reprise ne peut aboutir avec une preuve plus faible que le facteur principal du parcours concerné.
Cette règle a des conséquences concrètes qu'il faut accepter :
- certains utilisateurs seront bloqués temporairement, et c'est le comportement attendu ;
- le support devra pouvoir dire non, donc être couvert par une procédure ;
- il faut prévoir un chemin robuste et réaliste — présentiel, référent identifié, identité attestée — sinon la règle sera contournée dès la première urgence.
C'est un arbitrage entre disponibilité et sécurité, à trancher explicitement plutôt qu'à subir. La méthode d'arbitrage est détaillée dans l'article sur la friction proportionnée.
Ce que cet audit ne couvre pas
Il qualifie les chemins de reprise, pas la solidité du facteur principal ni la gestion des sessions. Un parcours de secours irréprochable n'empêche ni le relais d'une méthode rejouable, ni le vol d'un jeton après authentification : ces points relèvent du protocole de test de la MFA.
FAQ
Peut-on supprimer complètement les parcours de récupération ?
Non, et ce ne serait pas souhaitable : un système sans reprise possible produit des blocages d'activité et des contournements officieux. L'objectif est un secours au bon niveau, pas son absence.
Les codes de secours imprimés sont-ils une bonne solution ?
Ils ont un mérite — ils ne dépendent d'aucun canal interceptable — et un défaut : leur stockage échappe au contrôle. Ils conviennent à des populations restreintes et formées, moins à un déploiement général.
Comment traiter les comptes break-glass ?
Comme des actifs critiques : nombre minimal, secrets scellés physiquement, usage systématiquement tracé et alerté, revue périodique. Leur intérêt tient à leur rareté, donc à la surveillance de leur usage.
Un support externalisé change-t-il l'analyse ?
Oui, sur deux points : la procédure devient contractuelle, et la vérification d'identité repose sur un tiers dont vous devez pouvoir auditer les pratiques. NIS2 et DORA attendent précisément ce type de maîtrise de la chaîne de sous-traitance.
Aller plus loin : pilier : authentification cognitive · tester sa MFA · panorama du passwordless · choisir une solution