Une politique de mots de passe ANSSI part de l’analyse de risque. Elle définit les moyens d’authentification, la robustesse attendue, la récupération des comptes et les contrôles de déploiement. Le guide ANSSI publié le 8 octobre 2021 et le NIST SP 800-63B-4 final de juillet 2025 sont des références distinctes : leurs prescriptions ne doivent pas être fusionnées en une prétendue « norme ANSSI 2024 ».
Ce guide propose une trame et une méthode de déploiement pour le RSSI, la DSI et le support. Rattachez les règles à votre PSSI et à la cartographie du SI, afin d’identifier les applications qui appliquent réellement la politique et celles qui nécessitent une adaptation.
1. Quelles références utiliser ?
L’ANSSI recommande notamment d’analyser les risques, de privilégier l’authentification multifacteur et le facteur de possession, d’adapter la robustesse au contexte et d’utiliser un coffre-fort de mots de passe. Son guide concerne l’authentification des personnes auprès des machines. Une connexion à un service peu sensible et un accès d’administration ne présentent pas les mêmes menaces.
Le NIST SP 800-63B-4 fixe, dans son propre périmètre, un minimum de 15 caractères pour un mot de passe utilisé comme facteur unique ; lorsqu’il est uniquement utilisé dans une authentification multifacteur, le minimum est de huit caractères. Il exclut les règles de composition imposées et le changement périodique systématique, mais exige un changement en présence d’éléments de compromission. Il prévoit aussi une liste de blocage des secrets courants, attendus ou compromis lors de leur création ou modification.
Ces éléments ne deviennent pas automatiquement des obligations légales françaises. Dans votre fiche de décision, indiquez le document, la section, la version et le contexte retenus. Une exigence contractuelle, sectorielle ou interne peut compléter le socle ; vérifiez sa compatibilité au lieu de reprendre une valeur isolée dans un tableau.
2. La fiche de décision par application
| Champ | Question à résoudre |
|---|---|
| Application et propriétaire | Qui valide les besoins et qui réalise le réglage ? |
| Population | Utilisateurs, administrateurs, prestataires et accès de secours concernés |
| Risques | Attaque en ligne, vol de base, hameçonnage, perte d’un facteur, abus du support |
| Référence | Texte et section soutenant chaque paramètre retenu |
| Authentification | Facteurs, exigences du secret et restrictions d’accès |
| Récupération | Vérification de l’identité et traitement des sessions existantes |
| Compatibilité | Limites de l’application et dépendances avec l’annuaire |
| Exception | Mesure compensatoire, responsable et date de réexamen |
| Vérification | Scénario, résultat observé et preuve sans secret |
Cette fiche permet de distinguer le choix approuvé du choix réellement déployé. Une règle configurée dans l’annuaire ne couvre pas nécessairement les comptes locaux, les applications anciennes ou les accès des prestataires. Réconciliez les inventaires avant de déclarer le périmètre couvert.
3. Longueur, génération et phrases de passe
La longueur ne suffit pas à déterminer la robustesse : une suite longue mais prévisible reste exposée aux dictionnaires et aux variantes connues. Une phrase constituée de mots tirés aléatoirement se distingue d’une citation, d’une chanson ou d’une phrase personnelle facilement devinable. Les exemples publics ne doivent jamais être repris comme secrets réels.
Documentez la méthode de génération, les caractères acceptés et les contraintes d’utilisation. N’attribuez pas un nombre de bits d’entropie à un mot de passe choisi par une personne en vous fondant seulement sur sa longueur. Un calcul théorique suppose notamment un tirage aléatoire dans un ensemble défini ; il ne décrit pas automatiquement le comportement des utilisateurs.
L’application doit accepter les secrets robustes qu’elle demande, sans troncature silencieuse. Vérifiez les parcours de création, connexion, modification et récupération : une limite différente dans l’un de ces écrans peut rendre le compte inutilisable. Proposez un gestionnaire approuvé par l’organisation et expliquez le mécanisme de partage autorisé lorsqu’un secret technique doit être administré en équipe.
4. Authentification multifacteur et récupération
Lorsqu’un accès ne peut pas suivre le parcours MFA prévu, la fiche d’exception avec mesure compensatoire et échéance permet d’en délimiter le compte, le risque, l’approbateur et la date de fermeture.
Choisissez les facteurs selon le risque, la résistance à l’hameçonnage, les contraintes des utilisateurs et les capacités du service. Examinez les accès distants, les comptes privilégiés et les applications contenant des données sensibles. Deux secrets de même nature ne constituent pas nécessairement deux facteurs distincts.
La perte du téléphone ou du facteur de possession doit avoir un parcours prévu. Le support doit pouvoir rétablir l’accès après une vérification adaptée sans contourner systématiquement la protection. Conservez les opérations de récupération pertinentes dans les journaux de sécurité, sans enregistrer les codes ni les secrets.
Un dispositif résistant à l’hameçonnage ne protège pas automatiquement un compte dont le parcours de secours est faible. Testez donc aussi les méthodes alternatives, le changement du numéro de téléphone, l’ajout d’un facteur et la révocation des sessions après une suspicion de compromission.
5. Stockage côté serveur et secrets applicatifs
Les mots de passe ne doivent pas être conservés en clair. Le concepteur doit choisir un mécanisme de stockage résistant aux attaques hors ligne, avec sel et fonction adaptée, selon les références techniques applicables et les capacités du système. Les paramètres de coût doivent être validés et maintenus ; une liste de chiffres présentée comme universellement « obligatoire en 2026 » ne remplace pas cette analyse.
Évitez également les secrets dans les journaux, tickets, captures et dépôts de code. Pour les clés et comptes techniques, identifiez le propriétaire, les permissions, les dépendances et la procédure de remplacement. Leur cycle de vie n’est pas identique à celui du mot de passe mémorisé par un utilisateur. Coordonnez la rotation avec les services consommateurs pour ne pas provoquer une interruption non maîtrisée.
Pour chaque identité non humaine, le registre des comptes de service relie l’application, les permissions, le propriétaire et la prochaine décision de revue ; la rotation du secret ne suffit pas à établir ce cycle de vie.
6. Trame de politique à adapter
1. OBJET ET PÉRIMÈTRE
2. RÉFÉRENCES : document, version, section et domaine d'application
3. RÈGLES PAR CATÉGORIE D'UTILISATEUR
- Authentification retenue et robustesse justifiée
- Création et blocage des secrets inacceptables
4. AUTHENTIFICATION MULTIFACTEUR ET MÉTHODES DE SECOURS
5. STOCKAGE CÔTÉ SERVEUR ET PROTECTION DES SECRETS
6. CYCLE DE VIE : attribution, récupération, révocation, compromission
7. COMPTES À PRIVILÈGES ET ACCÈS PRESTATAIRES
8. SECRETS APPLICATIFS : propriétaire, dépendances, remplacement
9. EXCEPTIONS, INSTRUCTION DU SUPPORT ET RESPONSABILITÉS
10. VÉRIFICATION ET RÉVISION SELON LES RISQUES
Passer de la trame aux réglages réellement déployés
Commencez par une application pilote et relevez ses paramètres actuels avec son responsable : création de compte, authentification, réinitialisation, accès d’administration et récupération après perte d’un facteur. Distinguez ce qui dépend de l’annuaire central de ce qui reste propre à l’application. Une règle approuvée dans la PSSI ne prouve pas que tous les services utilisent effectivement ce réglage.
Préparez une fiche de déploiement avec la référence retenue, le paramètre cible validé par le RSSI, le responsable technique, les contraintes de compatibilité et le résultat attendu. Le support vérifie que les utilisateurs pourront suivre la procédure de récupération ; le métier choisit un créneau qui limite les interruptions. Les exceptions doivent avoir un propriétaire, une justification technique et une date de réexamen.
Dans un exemple fictif, l’équipe active un nouveau parcours d’authentification sur un outil RH. Avec un compte de démonstration, elle vérifie la connexion normale, le refus d’un accès incorrect et la récupération prévue lorsqu’un facteur est perdu. Elle contrôle aussi que le changement n’interrompt pas un traitement de service dépendant de l’application. Le compte rendu conserve les résultats et les références des événements de journalisation, sans enregistrer de secret.
Avant d’étendre le déploiement, le RSSI et l’exploitation examinent les écarts et valident les corrections. Le scénario d’indisponibilité du service d’identité rejoint le plan de continuité d’activité : qui peut intervenir, par quel accès de secours et avec quelle trace de l’intervention ? Cette vérification transforme la trame de politique en consignes que les équipes peuvent appliquer et maintenir.
7. Contrôler les comptes privilégiés et les départs
Séparez l’usage courant de l’administration et limitez les droits à ce qui est nécessaire. Lorsqu’un collaborateur change de rôle, supprimez les permissions devenues inutiles ; lors de son départ, vérifiez les comptes locaux, sessions actives, accès fournisseurs et secrets partagés qu’il pouvait connaître. Fermer seulement sa messagerie ne couvre pas nécessairement ces accès.
Les accès de secours doivent avoir un propriétaire, une protection, une procédure d’utilisation et une revue après intervention. Vérifiez leur disponibilité lorsque l’annuaire est indisponible, sans exposer leurs secrets dans une documentation largement partagée. Le télétravail sécurisé et les interventions externes doivent être couverts par les mêmes règles d’attribution et de révocation.
Pour rendre cette vérification exploitable, constituez un dossier de revue des accès privilégiés reliant chaque droit à son besoin, à son évaluateur et à la décision. Le dossier distingue le retrait demandé, la modification réalisée et la preuve que l’accès concerné a effectivement disparu.
Lorsqu’une relation de travail change, la feuille de rapprochement RH-habilitations relie l’événement aux comptes de chaque application, aux exceptions et à la preuve du retrait effectif.
Pour les identités d’urgence, le script d’exercice des comptes de secours Entra vérifie l’accès, les alertes et la revue après usage dans une fenêtre contrôlée, sans publier les secrets.
FAQ
Quelle longueur minimale faut-il retenir ?
Retenez une règle adaptée au périmètre et à la référence choisie. Le NIST distingue notamment 15 caractères en facteur unique et huit au minimum lorsque le mot de passe n’est utilisé qu’en MFA. N’attribuez pas ces chiffres à l’ANSSI ni à l’article 32 du RGPD, qui impose des mesures appropriées au risque.
Faut-il changer tous les mots de passe tous les trois mois ?
Le NIST SP 800-63B-4 exclut le renouvellement périodique systématique des mots de passe utilisateurs et impose le changement en cas d’éléments de compromission. Pour une politique française, distinguez cette référence des recommandations ANSSI, du contexte des comptes et des exigences particulières applicables. La compromission doit aussi déclencher l’examen des sessions et des usages non autorisés.
Un gestionnaire est-il « certifié ANSSI » ?
Vérifiez le produit, la version, le périmètre et la décision dans le catalogue officiel. Une décision concernant une version d’un produit ne s’étend pas automatiquement à un autre logiciel de la même famille. La qualification ou certification d’un composant ne valide pas toute votre politique d’authentification.
Comment savoir si la politique fonctionne ?
Contrôlez un échantillon d’applications avec leurs responsables : connexion, récupération, retrait des droits et accès de secours. Conservez les résultats et les écarts, puis vérifiez les corrections. La politique doit permettre à une autre équipe de reproduire ces opérations sans connaître les secrets des utilisateurs.