Ressources · 11

Identités et récupération de compte : gouverner le cycle complet

Une méthode pour relier création, évolution, privilèges, récupération et fermeture des comptes à des preuves vérifiables.

Mis à jour le 23 octobre 2026 · 9 min

Illustration · scène fictive

Ce que ce guide permet

Relier chaque compte à une personne ou un service
Réduire les privilèges permanents
Sécuriser les demandes de récupération
Révoquer vite sans bloquer la continuité

Contrôle express

Qui autorise la création et le changement de rôle ?
Un ancien facteur peut-il réinitialiser seul le compte ?
Les comptes partagés sont-ils traçables ?
Les privilèges expirent-ils ?
La perte d’un téléphone a-t-elle été exercée ?

Méthode pas à pas

01
Inventorier identités et dépendances
Recensez comptes humains, techniques, partagés, fédérés et d’urgence. Reliez-les aux applications, propriétaires, méthodes d’authentification et données accessibles.
Livrable : registre identité, compte, système et propriétaire.
02
Relier le cycle de vie aux événements
Définissez les déclencheurs de création, mobilité, absence, changement de rôle, départ et suppression. Mesurez les délais entre événement et modification effective.
Livrable : matrice événement et action.
03
Réduire les privilèges
Séparez usage quotidien et administration, limitez la durée des droits élevés et revoyez les accès selon le risque du service.
Livrable : catalogue des rôles et exceptions datées.
04
Durcir la récupération
Utilisez plusieurs preuves indépendantes, un canal sûr, une temporisation adaptée et une escalade humaine pour les demandes inhabituelles.
Livrable : arbre de décision de récupération.
05
Préparer perte et compromission
Prévoyez révocation des sessions, facteurs et appareils, communication au support, accès de secours et conservation proportionnée des traces.
Livrable : runbook de verrouillage et reprise.
06
Exercer et améliorer
Testez un départ urgent, une perte de téléphone et une tentative d’usurpation. Vérifiez les décisions, délais, preuves et impacts sur le travail.
Livrable : compte rendu et plan de correction.

Exemple d’application

Situation illustrative

Un administrateur perd son appareil d’authentification pendant une astreinte. Le support vérifie une preuve prévue à l’avance, fait approuver la récupération par un second responsable et invalide les sessions concernées.

Décision et preuve attendue

L’exercice vérifie la continuité du service et conserve la trace de la demande, de l’approbation, du facteur remplacé et de la revue après incident.

Indicateurs de pilotage

Indicateur	Ce qu’il mesure	Première action
Comptes attribués	Comptes reliés à un propriétaire actif	Traiter les comptes sans responsable
Délai de révocation	Temps entre événement et suppression des accès	Automatiser les étapes fiables
Privilèges temporaires	Accès élevés avec durée et justification	Faire expirer les droits par défaut
Récupérations vérifiées	Demandes ayant suivi toutes les preuves attendues	Analyser chaque contournement

Erreurs fréquentes

Utiliser des questions personnelles comme preuve forte
Laisser le support contourner la MFA sans double contrôle
Oublier les comptes techniques
Conserver des privilèges après une mission

Questions fréquentes

La MFA suffit-elle ?

Non. Elle réduit certains risques, mais le cycle de vie, la récupération, les sessions et les privilèges peuvent rester vulnérables.

Faut-il interdire tous les comptes partagés ?

Préférez des identités individuelles. Lorsqu’un compte partagé reste indispensable, documentez sa justification, limitez son accès et rendez chaque usage attribuable.

Que tester en premier ?

La perte du facteur principal et le départ urgent d’une personne disposant d’accès élevés révèlent rapidement les dépendances réelles.

Identités : facteurs, sessions et récupération

Une méthode d’authentification se juge avec son enrôlement, sa récupération et les sessions qu’elle ouvre. Le nom « passkey », l’usage d’un téléphone ou la présence d’un capteur biométrique ne démontrent pas, seuls, le niveau d’assurance de tout le service.

Repères issus de NIST SP 800-63B-4, finalisé en juillet 2025, et de WebAuthn Level 3, devenu recommandation W3C le 25 août 2026. Les AAL décrivent une transaction d’authentification ; ils ne sont ni une note de produit ni une certification obtenue en cochant ce tableau. Leur application dépend du périmètre du service et de son analyse de risque.

Sources consultées le 2026-10-22.

Deux clés de sécurité non marquées dans un laboratoire cyber vide — Illustration fictive générée par IA : deux clés non marquées dans un laboratoire vide. L’aspect d’une clé ne prouve ni sa non-exportabilité ni son niveau d’assurance.

Comparer huit méthodes sans confondre les garanties

Comparer huit méthodes sans confondre les garanties
Méthode et référence	Propriété et conditions	Secours et dépendances	Preuve à demander
Mot de passe saisi NIST · Authenticators and password requirements	Facteur de connaissance ; un faux site peut relayer ou capturer le secret.	Dépend du gestionnaire de mots de passe et du parcours de remplacement du secret.	Politique de longueur, blocage des secrets compromis et essai du parcours de remplacement.
Code TOTP recopié NIST · Authenticators and password requirements	Preuve de possession d’un secret partagé ; sa saisie manuelle ne lie pas le code à la session légitime.	Prévoir la perte du générateur et la protection des graines ou sauvegardes du fournisseur.	Enrôlement autorisé, protection du secret et révocation ; ne pas qualifier tout OTP de résistant au phishing.
Code SMS ou vocal NIST · Authenticators and password requirements	Canal hors bande PSTN, soumis à restrictions dans le cadre NIST ; le code saisi n’est pas résistant au phishing.	Le numéro, l’opérateur et les changements de carte ou de ligne font partie des dépendances.	Justification du canal, signaux de risque, alternatives et procédure de changement du numéro.
Approbation push simple NIST · Authenticators and password requirements	Une approbation sans liaison cryptographique au nom ou au canal du vérificateur ne démontre pas la résistance au phishing.	Le téléphone perdu et la réinscription de l’application doivent être traités.	Protocole réel, intention de l’utilisateur et contrôles d’enrôlement ; le mot « push » seul ne suffit pas.
WebAuthn synchronisable avec UV NIST · Syncable Authenticators W3C · WebAuthn Level 3	Preuve cryptographique liée au service ; la vérification utilisateur (UV) doit être exigée et contrôlée quand requise. Les clés synchronisables sont exportables au sens NIST.	Le compte de synchronisation, ses appareils et sa récupération entrent dans le périmètre de confiance.	Exigences de la synchronisation et de l’UV. Une méthode synchronisable ne convient pas à AAL3, qui interdit l’export des clés.
WebAuthn lié à un appareil avec UV NIST · Authentication Assurance Levels W3C · WebAuthn Level 3	Liaison au service et vérification utilisateur. « Lié à l’appareil » ne démontre pas à lui seul une protection matérielle non exportable.	La perte de l’appareil exige un autre moyen autorisé ou un parcours de récupération contrôlé.	Propriétés du stockage, UV, preuve de non-exportabilité si nécessaire et tests des clients réellement utilisés.
Clé WebAuthn sans UV NIST · Authenticators and password requirements W3C · WebAuthn Level 3	Liaison au service, mais possession seule dans ce cas. Un toucher ou un indicateur de présence (UP) ne prouve pas une vérification utilisateur (UV).	Préparer une seconde méthode autorisée et la révocation de la clé perdue.	Vérification des indicateurs UP/UV et combinaison de facteurs requise par le service ; ne pas inférer MFA du seul format matériel.
Biométrie considérée seule NIST · Authenticators and password requirements	Dans le cadre NIST, la biométrie s’utilise avec un authentificateur physique en MFA ; ce n’est pas un secret ni un mécanisme autonome suffisant.	Prévoir une alternative non biométrique et protéger les données biométriques selon leur sensibilité.	Lieu de comparaison, rôle d’activation et alternative accessible ; distinguer comparaison biométrique et preuve cryptographique.

Trois niveaux AAL : exigences et recommandations distinctes

Trois niveaux AAL : exigences et recommandations distinctes
Niveau et facteurs	Résistance et export des clés	Durée globale de réauthentification	Inactivité
AAL1 Un facteur peut suffire dans ce niveau.	Résistance au phishing non imposée par ce niveau ; export de clé permis.	30 jours au plus : recommandation SHOULD.	Pas de plafond chiffré dans ce repère ; définir la politique du service.
AAL2 Deux facteurs distincts.	Une option résistante au phishing doit être proposée ; export de clé permis sous les conditions applicables.	24 heures au plus : recommandation SHOULD ; une limite globale définie reste obligatoire.	1 heure au plus : recommandation SHOULD.
AAL3 Authentificateur cryptographique et facteur supplémentaire ou d’activation.	Résistance au phishing et clé privée non exportable requises.	12 heures au plus : exigence SHALL.	15 minutes au plus : recommandation SHOULD.

Les valeurs ne sont pas des durées à recopier aveuglément dans un cookie. Le NIST distingue limite globale et inactivité, puis décrit les règles de réauthentification. Une application peut retenir des durées plus courtes selon ses risques. IAL concerne la preuve d’identité et FAL la fédération : un AAL ne remplace pas ces deux dimensions. NIST §2 →

Mots de passe : sept repères précis du NIST

Facteur unique: Minimum 15 caractères requis.
Dans une MFA: Minimum 8 caractères requis si le mot de passe n’est utilisé que dans un processus multifacteur.
Longueur acceptée: Accepter une longueur maximale d’au moins 64 caractères est recommandé.
Composition: Pas de mélange imposé de types de caractères.
Renouvellement: Pas de changement périodique arbitraire ; imposer un changement en cas de preuve de compromission.
Secrets à refuser: Comparer aux listes de mots de passe courants, attendus ou compromis.
Aide à la saisie: Permettre les gestionnaires et le remplissage automatique ; autoriser le collage est recommandé.

NIST §3.1.1.2 →

Récupération : quatre classes, avec leurs conditions

Code conservé à l’avance: Au moins 64 bits aléatoires dans le cadre NIST ; conservation hors ligne par l’abonné, stockage haché côté service et invalidation après usage.
Code envoyé à la demande: Les codes émis par SMS ou voix sont valides au plus 10 minutes ; ceux envoyés par email au plus 24 heures. Vérifier les adresses et appliquer les exigences du niveau visé.
Contact de récupération: Organiser les adresses de contacts et les contrôles associés ; la relation humaine ne remplace pas les conditions techniques du parcours.
Nouvelle preuve d’identité: Option pour les comptes dont l’identité avait été vérifiée. Si aucune preuve d’identité n’a été réalisée, ne pas prétendre « revérifier » une identité inconnue.

Remplacer un mot de passe oublié en utilisant un autre authentificateur encore valide relève de l’association d’un nouveau moyen, pas nécessairement d’une récupération de compte. Documenter les notifications, délais, révocations et responsabilités évite de transformer le support en contournement. NIST §4 →

Relier authentification, session et incident

Relier authentification, session et incident
Étape	Contrôle concret proposé	Preuve observable
Enrôler	Vérifier qui autorise l’ajout du moyen et notifier le titulaire par un chemin connu.	Trace de l’ajout, moyen associé et justification de l’autorisation.
Authentifier	Vérifier le protocole, le domaine attendu et les facteurs exigés avant d’ouvrir l’accès.	Résultat d’essai sur les clients retenus, avec les indicateurs de présence et de vérification séparés.
Gérer la session	Définir expiration globale, inactivité, réauthentification des actions sensibles et invalidation à la déconnexion.	Essais de session expirée, déconnexion et accès après révocation.
Signaler la perte	Identifier l’authentificateur concerné, préserver les traces utiles et décider des invalidations selon la compromission suspectée.	Chronologie du signalement et résultat du contrôle d’accès après traitement.
Récupérer	Appliquer un parcours documenté, notifier et empêcher qu’une ancienne session ajoute un nouveau moyen sans contrôle approprié.	Scénario de récupération réussi et scénario de contournement refusé.
Sortir du service	Retirer les moyens et accès devenus inutiles ; traiter aussi les sessions, appareils et autorisations de synchronisation pertinents.	État des moyens révoqués, accès supprimés et dépendances résiduelles.

WebAuthn : vérifier la réponse côté service

Le serveur doit notamment rapprocher le challenge, l’origine autorisée, l’empreinte du RP ID et la signature de la cérémonie attendue, puis contrôler les indicateurs requis. UP indique une présence ; UV indique une vérification utilisateur. BE et BS décrivent l’éligibilité et l’état de sauvegarde de l’identifiant, sans certifier à eux seuls le dispositif de synchronisation. Utilisez une bibliothèque maintenue et les procédures complètes des sections 7.1 et 7.2 du standard. WebAuthn Level 3 →

Inclure les personnes qui utilisent un autre parcours

Le critère WCAG 2.2 3.3.8, de niveau AA, encadre les tests cognitifs lors de l’authentification avec des exceptions et mécanismes d’aide précis. Vérifiez concrètement gestionnaire de mots de passe, collage, libellés, clavier, annulation et solution de secours. Une option non biométrique doit rester disponible dans le cadre NIST ; la rendre utilisable fait partie de la conception. WCAG 2.2 · 3.3.8 →

Poursuivre avec la gouvernance des identités →

Références primaires et périmètre

Dates de publication et consultation sont distinctes. Les propositions de tests et preuves sont éditoriales ; les textes normatifs liés font foi. Les documentations de fournisseur décrivent leur propre produit et n’attestent pas un niveau AAL de votre application.

NIST SP 800-63B-4 · final publication · Publication : 2025-07-31
NIST · Authentication Assurance Levels · Publication : 2025-07
§2.1–2.3
NIST · Authenticators and password requirements · Publication : 2025-07
§3.1.1; §3.2.3; §3.2.5
NIST · Authenticator Event Management · Publication : 2025-07
§4.1; §4.2; §4.6
NIST · Session Management · Publication : 2025-07
§5
NIST · Syncable Authenticators · Publication : 2025-07
Appendix B
W3C · WebAuthn Level 3 · Publication : 2026-08-25 · W3C Recommendation
§6.1; §7.1–7.2
W3C · Accessible Authentication (Minimum) · Publication : 2024-12-12
WCAG 2.2 · 3.3.8 · AA

Extensions : permissions et accès

Une authentification robuste ne décrit pas les accès de l’extension

La résistance au phishing ne dispense pas d’examiner ce qui fonctionne dans le navigateur une fois la session ouverte. Le manifeste donne des pistes sur cookies, scripts, débogage et identité, sans démontrer à lui seul une collecte.

Tester les extensions autorisées sur un profil dédié aux opérations sensibles.
Pour identity, examiner les scopes OAuth et destinataires ; cette permission n’énumère pas les droits du fournisseur d’identité.
Distinguer révocation de session, révocation de jetons, désactivation d’extension et retrait d’un composant natif.

Consulter le répertoire et les exemples de manifestes →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Références officielles

Date de consultation des références : 23/10/2026. La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.