NIST SP 800-63-4 : éléments probants relatifs aux mots de passe, à l’authentification multifacteur (MFA) et aux clés d’accès (passkeys)

À 08 h 10, un lundi, le RSSI d’une fintech reçoit le message que redoute tout responsable de la sécurité : « Nous observons des connexions suspectes sur le portail d’administration Finance. La MFA a été approuvée, mais l’utilisateur affirme que ce n’était pas lui. »

À 08 h 25, le SOC identifie le schéma. L’attaquant n’a pas cassé le chiffrement, exploité une vulnérabilité zero-day ni contourné un pare-feu. Il a hameçonné un mot de passe, déclenché une notification push et attendu l’effet de lassitude. Une seule approbation a suffi. Le compte disposait d’un accès étendu aux exports de facturation clients, aux journaux d’audit et à un tableau de bord de règlement géré par un tiers.

À 09 h 00, le service juridique demande s’il s’agit d’une violation de données à caractère personnel au sens de GDPR. L’équipe risques demande si l’événement déclenche une notification au titre de DORA. Le conseil d’administration veut savoir si l’affirmation « MFA partout » de l’entreprise était réellement exacte. L’auditeur ISO 27001, déjà planifié pour le mois suivant, demande désormais des éléments probants sur l’authentification sécurisée, le contrôle d’accès, la journalisation et les actions correctives.

C’est pourquoi NIST SP 800-63-4 est important en 2026.

Pour les RSSI, les responsables conformité et les propriétaires métiers, NIST SP 800-63-4 n’est pas un document d’identité de plus. Il devient la référence pratique pour les politiques modernes de mots de passe, la MFA résistante au phishing, les clés d’accès (passkeys), l’authentification sans mot de passe et la gouvernance du cycle de vie des authentificateurs. Le véritable défi n’est pas de lire les recommandations. Il consiste à prouver la mise en œuvre au regard d’ISO/IEC 27001:2022, de NIS2, de DORA, de GDPR, de NIST CSF 2.0, de COBIT 2019 et des attentes d’audit interne.

La position de Clarysec est simple : les contrôles d’identité échouent lorsqu’ils sont traités comme de simples paramètres, et non comme un dispositif de gouvernance. Les mots de passe, la MFA, les clés d’accès (passkeys), les flux de récupération, les jetons de session, l’accès à privilèges, les comptes de service et les journaux d’authentification doivent être conçus comme un système de contrôle unique produisant des éléments probants.

C’est cette approche qui est utilisée dans Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur, dans la bibliothèque de politiques Clarysec et dans Zenith Controls : guide de conformité croisée. Zenith Controls ne crée pas de nouveaux contrôles. Il cartographie les attentes de contrôle d’ISO/IEC 27001:2022 et d’ISO/IEC 27002:2022 avec d’autres normes, réglementations et angles d’audit, afin que les organisations évitent les éléments probants fragmentés et les travaux de conformité redondants.

« MFA activée » n’est pas une réponse d’audit

Ces dernières années, de nombreuses organisations ont considéré que le déploiement de la MFA clôturait le sujet du risque lié à l’identité. En 2026, cette hypothèse n’est plus défendable.

Les auditeurs et les autorités de régulation posent désormais des questions plus précises :

• La MFA est-elle imposée pour tous les accès à privilèges, distants et à haut risque ?
• L’authentification est-elle résistante au phishing lorsque le niveau de risque l’exige ?
• Les clés d’accès (passkeys) ou les authentificateurs FIDO2 sont-ils gouvernés au moyen de processus d’enrôlement, de récupération, de révocation et de gestion du cycle de vie des équipements ?
• Les mots de passe sont-ils contrôlés par rapport à des listes d’identifiants compromis et courants ?
• Les changements de mot de passe sont-ils déclenchés par une compromission plutôt que par une rotation calendaire arbitraire ?
• Les utilisateurs peuvent-ils coller des mots de passe depuis des gestionnaires de mots de passe ?
• Les événements liés aux authentificateurs sont-ils journalisés et revus ?
• Les flux de récupération de compte sont-ils aussi robustes que les flux de connexion ?
• Les secrets d’API, les jetons OAuth, les clés SSH et les identifiants de comptes de service sont-ils contrôlés avec la même rigueur ?

NIST SP 800-63-4 oriente les organisations vers une assurance de l’identité numérique fondée sur les risques, la robustesse des authentificateurs et les éléments probants de cycle de vie. Pour la modernisation des mots de passe, cela signifie abandonner les pratiques obsolètes telles que les changements périodiques imposés lorsqu’il n’existe aucun indice de compromission, tout en renforçant la longueur, le filtrage des mots de passe compromis, la limitation de débit, le stockage sécurisé et les contrôles de récupération. Pour la MFA et les clés d’accès (passkeys), cela signifie se concentrer sur l’assurance des authentificateurs, la résistance au phishing, l’enrôlement sécurisé, l’association au compte, la révocation et l’auditabilité.

Zenith Blueprint décrit ce basculement dans Controls in Action, Step 19, Technological Controls I, à propos de l’authentification sécurisée :

L’authentification est la première et la plus critique ligne de défense entre un acteur malveillant et vos systèmes, données et services. Si l’authentification est faible, tout le reste — chiffrement, surveillance, segmentation — peut être contourné. Le contrôle 8.5 garantit que les mécanismes d’authentification sont conçus de manière sécurisée, appliqués de façon cohérente et résistants aux méthodes d’attaque connues.

Cette phrase résume l’audit d’identité en 2026. La question n’est plus : « Avez-vous des mots de passe et de la MFA ? » La question est : « Pouvez-vous prouver que votre architecture d’authentification est fondée sur les risques, résistante aux méthodes d’attaque connues, appliquée de manière cohérente et surveillée ? »

Construire le système de contrôle autour de l’identité, des informations d’authentification et de l’authentification sécurisée

La manière la plus utile de traduire NIST SP 800-63-4 en éléments probants ISO/IEC 27001:2022 consiste à traiter l’identité comme un système de contrôle interconnecté.

Au moyen de Zenith Controls, Clarysec identifie trois domaines de contrôle ISO/IEC 27002:2022 centraux pour l’alignement avec NIST SP 800-63-4 : 5.16 Gestion des identités, 5.17 Informations d’authentification et 8.5 Authentification sécurisée. Dans l’Annexe A d’ISO/IEC 27001:2022, il s’agit de A.5.16, A.5.17 et A.8.5.

La distinction est importante. A.5.16 pose la question : « Qui dispose d’une identité ? » A.5.17 pose la question : « Comment la preuve de cette identité est-elle protégée ? » A.8.5 pose la question : « Comment l’authentification est-elle réalisée de manière sécurisée dans les systèmes ? »

Lorsque les organisations échouent aux audits, c’est souvent parce qu’elles mettent en œuvre une couche sans les autres. Elles déploient des clés d’accès (passkeys), mais ne peuvent pas présenter d’éléments probants de révocation. Elles imposent la MFA, mais pas pour une console d’administration héritée. Elles définissent des règles de mots de passe, mais ne filtrent pas les mots de passe compromis. Elles désactivent un compte utilisateur, mais oublient les sessions actives ou les jetons de récupération.

Dans Zenith Blueprint, Controls in Action, Step 22, Organizational controls, Clarysec présente A.5.17 comme un sujet de cycle de vie :

Si l’identité est la question « Qui êtes-vous ? », alors l’authentification est la preuve. Le contrôle 5.17 est le point où la théorie rejoint la confiance. Il exige que les informations d’authentification soient gérées de manière sécurisée pendant tout leur cycle de vie, afin que les méthodes et identifiants utilisés pour vérifier l’identité ne deviennent pas eux-mêmes le maillon faible.

Une clé d’accès (passkey) n’est pas conforme parce qu’elle existe. Elle devient défendable lorsque vous pouvez montrer comment elle est enrôlée, associée au compte, protégée, récupérée, révoquée, journalisée et revue.

Moderniser les mots de passe sans perdre la traçabilité d’audit

De nombreuses entreprises disposent encore de politiques de mots de passe rédigées pour un modèle de menace différent. « Douze caractères, symboles, changement tous les 90 jours » est familier, mais la familiarité n’est pas la résilience.

NIST SP 800-63-4 renforce une approche plus moderne : mots de passe et phrases de passe plus longs, filtrage par rapport aux mots de passe compromis ou couramment utilisés, limitation de débit, réinitialisation sécurisée, absence de changement périodique arbitraire sauf suspicion de compromission, et contrôles ergonomiques prenant en charge les gestionnaires de mots de passe. Cela ne signifie pas que chaque organisation doit réécrire toutes ses politiques du jour au lendemain. Cela signifie que les exigences relatives aux mots de passe doivent être fondées sur les risques, techniquement appliquées et rapprochées des éléments probants ISO 27001.

La bibliothèque de politiques PME de Clarysec fournit aux petites organisations un référentiel de base pratique, améliorable à mesure qu’elles gagnent en maturité. La Politique de gestion des comptes utilisateurs et des privilèges - PME indique :

Les mots de passe doivent satisfaire aux exigences de complexité (par exemple, au moins 12 caractères, alphanumériques avec symboles) et être modifiés au moins tous les 90 jours.

Il s’agit d’un point de départ utile et opposable pour les PME. Toutefois, un projet de modernisation NIST SP 800-63-4 en 2026 doit examiner si une expiration fixe à 90 jours reste appropriée pour chaque système, en particulier lorsque la MFA, le filtrage des mots de passe compromis, une longueur de mot de passe robuste et des workflows de réinitialisation déclenchée par compromission sont en place. En pratique, de nombreuses organisations conservent le référentiel de base pendant la transition, puis ajoutent un avenant de modernisation des mots de passe approuvé dans le cadre du traitement des risques et de la Déclaration d’applicabilité.

Pour les environnements d’entreprise, la Politique de gestion des comptes utilisateurs et des privilèges de Clarysec fournit un point d’ancrage de gouvernance plutôt que d’inscrire chaque règle de mot de passe en dur dans la politique :

Tous les comptes utilisateurs doivent appliquer la complexité et l’expiration des mots de passe conformément à la politique de mots de passe de l’organisation.

Cette formulation permet au RSSI de mettre à jour la politique de mots de passe pour l’aligner sur NIST SP 800-63-4 sans réécrire l’ensemble du cadre de gestion des accès.

Un dossier pratique d’éléments probants pour la modernisation des mots de passe doit inclure :

• La politique de mots de passe actuelle et l’avenant de modernisation approuvé.
• La configuration de l’IdP indiquant la longueur minimale, la longueur maximale et les caractères autorisés.
• Les éléments probants montrant que les gestionnaires de mots de passe sont autorisés, y compris la fonctionnalité de collage lorsque cela est pertinent.
• La configuration du filtrage des mots de passe compromis, faibles et courants.
• La politique de limitation de débit ou de verrouillage pour les attaques par devinette en ligne.
• Le workflow de réinitialisation des mots de passe exigeant une vérification d’identité adéquate.
• L’architecture de stockage des hachages de mots de passe pour les applications qui stockent des identifiants.
• Le registre des exceptions pour les systèmes hérités incapables de prendre en charge les paramètres modernes.
• La procédure de réinitialisation déclenchée par compromission, articulée avec la réponse aux incidents.
• Les éléments probants de communication et de sensibilisation des utilisateurs.

L’objectif n’est pas de gagner un débat sur une longueur de mot de passe. L’objectif est de démontrer que l’authentification par mot de passe est contrôlée, mesurable et intégrée au SMSI.

Faire passer la MFA et les clés d’accès (passkeys) du « second facteur » à l’assurance

L’incident du lundi matin a commencé par une fatigue MFA. C’est pourquoi les auditeurs demandent de plus en plus si la MFA est résistante au phishing, et pas seulement si elle existe.

Les méthodes MFA traditionnelles telles que les SMS, les OTP par courriel, les applications TOTP et les notifications push peuvent réduire le risque, mais elles ne se valent pas. Les clés d’accès (passkeys) et les authentificateurs FIDO2/WebAuthn offrent une résistance plus forte au phishing, car l’authentification est liée à l’origine légitime et repose sur la cryptographie à clé publique. Pour les utilisateurs à haut risque, les administrateurs à privilèges, les approbateurs financiers, les développeurs disposant d’un accès à l’environnement de production et les chemins d’accès à distance, la MFA résistante au phishing doit être traitée comme l’état cible, sauf exception documentée et approuvée.

La Politique relative aux communications sécurisées et à l’authentification multifacteur (MFA) de Clarysec pour les entreprises définit le référentiel de base :

Authentification multifacteur (MFA) : tous les accès au réseau et aux systèmes d’information de l’organisation, en particulier les accès à privilèges ou les accès à distance, doivent exiger une authentification multifacteur (MFA) (par exemple, mot de passe plus jeton OTP ou facteur biométrique). Les solutions d’authentification multifacteur (MFA) doivent être alignées sur les bonnes pratiques du secteur (par exemple, codes à usage unique fondés sur le temps ou clés matérielles) et configurées pour protéger contre tout accès non autorisé.

Pour les PME, la Politique de contrôle d’accès - PME indique :

Les comptes à privilèges doivent utiliser l’authentification multifacteur (MFA) lorsque celle-ci est prise en charge.

La mention « lorsque celle-ci est prise en charge » donne aux PME une trajectoire de mise en œuvre réaliste, mais elle crée également une obligation d’audit. Si un système à privilèges ne prend pas en charge la MFA, l’organisation doit documenter les contrôles compensatoires, tels que les restrictions réseau, la gestion des accès à privilèges (PAM), les bastions d’administration, les sessions plus courtes, la surveillance, la conservation en coffre-fort et un plan de migration.

Zenith Blueprint, Controls in Action, Step 19, est explicite sur le sens de l’évolution :

Lorsque cela est possible, l’authentification par mot de passe seul doit être évitée, en particulier pour les comptes administrateur, les consoles cloud, les outils d’accès à distance et tout système exposé à Internet. La MFA, au moyen d’un second facteur comme une clé matérielle, une application mobile ou la biométrie, est désormais un référentiel minimal, et non un luxe.

Les clés d’accès (passkeys) s’inscrivent naturellement dans ce récit. Un déploiement de clés d’accès ne doit pas être présenté comme une simple évolution technologique. Il doit être documenté comme un traitement des risques contre le phishing, le credential stuffing, la fatigue MFA, la réutilisation des mots de passe et la compromission de compte.

Le modèle d’éléments probants sur les clés d’accès (passkeys) attendu par les auditeurs

Les clés d’accès (passkeys) peuvent être synchronisables, liées à un appareil, adossées à du matériel, intégrées à une plateforme ou itinérantes selon l’authentificateur et l’écosystème. L’assurance dépend de l’enrôlement, du niveau de confiance de l’appareil, de la récupération, de l’association au compte et de la révocation. Un projet de clés d’accès dépourvu d’éléments probants peut créer une ambiguïté d’audit, même lorsque la technologie est robuste.

Utilisez ce modèle pour préparer un déploiement de clés d’accès compatible avec les exigences d’audit.

Cela s’aligne directement sur ISO/IEC 27001:2022. Les clauses 4.1 à 4.4 exigent que les organisations comprennent le contexte, les parties intéressées, le domaine d’application du SMSI et les processus opérationnels. Les clauses 5.1 à 5.3 exigent le leadership, la politique, les rôles organisationnels et la responsabilité. Les clauses 6.1.2 et 6.1.3 exigent un processus répétable d’appréciation des risques de sécurité de l’information et de traitement des risques, incluant la sélection des contrôles, la comparaison avec l’Annexe A, une Déclaration d’applicabilité et l’approbation du risque résiduel par le propriétaire du risque. La clause 6.2 exige des objectifs mesurables de sécurité de l’information.

Cela signifie qu’un déploiement de clés d’accès doit apparaître dans le SMSI comme :

• Un traitement des risques pour le vol d’identifiants et le phishing.
• Un objectif, par exemple : « 90 % de l’accès à privilèges migré vers une MFA résistante au phishing d’ici le T3. »
• Une justification de Déclaration d’applicabilité liée à A.5.16, A.5.17 et A.8.5.
• Une mise à jour de la Politique de contrôle d’accès.
• Un cas d’usage de journalisation et de surveillance.
• Un dossier d’éléments probants d’audit.

Dans Zenith Blueprint, phase Risk Management, Step 13, Risk Treatment Planning and Statement of Applicability, Clarysec décrit la SoA comme un pont :

La SoA est effectivement un document de liaison : elle relie votre appréciation et votre traitement des risques aux contrôles réels dont vous disposez. En la complétant, vous vérifiez également si vous avez omis des contrôles.

Pour NIST SP 800-63-4, ce pont est l’endroit où les décisions relatives aux mots de passe, à la MFA et aux clés d’accès (passkeys) deviennent auditables.

Cartographie de conformité croisée pour ISO 27001, NIS2, DORA, GDPR, NIST CSF et COBIT

Les éléments probants relatifs à l’identité prennent de la valeur lorsqu’un même jeu de contrôles satisfait plusieurs obligations.

NIS2 Article 21 exige des entités essentielles et importantes qu’elles mettent en œuvre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, reflétant le risque, l’état de l’art, le coût de mise en œuvre, la taille et l’impact des incidents. Article 21(2) inclut l’analyse des risques, les politiques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le développement sécurisé, l’évaluation de l’efficacité des contrôles, l’hygiène cyber et la formation, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs et, le cas échéant, l’authentification multifacteur ou continue. Article 20 fait de l’approbation par la direction, de la supervision et de la formation à la cybersécurité une obligation de gouvernance.

DORA fait entrer le même sujet d’identité dans la résilience opérationnelle financière. Les entités financières couvertes doivent maintenir un cadre documenté de gestion des risques liés aux TIC avec responsabilité de l’organe de direction, contrôles de protection et de prévention, contrôle d’accès, authentification, surveillance, détection d’anomalies, continuité, réponse, rétablissement et formation. Les Articles 8 à 10 sont particulièrement pertinents pour l’identification des actifs TIC et des dépendances, la protection des systèmes TIC, le contrôle d’accès, l’authentification forte, la surveillance et la détection. Les Articles 17 à 19 relient les mêmes éléments probants à la gestion et au signalement des incidents liés aux TIC.

GDPR s’applique partout où des données à caractère personnel sont traitées dans son champ territorial et matériel. Article 5(1)(f) exige que les données à caractère personnel soient traitées avec une sécurité appropriée. Article 5(2) exige la responsabilité. Article 32 exige des mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. Un mot de passe volé ou un authentificateur compromis peut devenir une violation de données à caractère personnel s’il entraîne un accès non autorisé à des données à caractère personnel.

NIST CSF 2.0 ajoute une couche de management utile. Sa fonction GOVERN exige que les exigences légales, réglementaires et contractuelles de cybersécurité, y compris les obligations de confidentialité, soient comprises et gérées. Les profils CSF aident les organisations à comparer les états actuel et cible et à créer des plans d’action priorisés.

COBIT 2019 et les approches d’audit ISACA demandent si les contrôles d’identité et d’accès soutiennent les objectifs de gouvernance, si les pratiques de management sont définies, si la robustesse de l’authentification correspond au risque et si le fonctionnement des contrôles est étayé par des éléments probants.

Le même rapport IdP d’accès conditionnel peut soutenir le contrôle d’accès ISO 27001, la MFA NIS2, l’authentification DORA, la responsabilité de sécurité GDPR et l’avancement du profil cible NIST CSF.

Construire un dossier d’éléments probants sur les authentificateurs en un après-midi

Un RSSI, un responsable conformité ou un responsable informatique peut créer rapidement un dossier d’éléments probants à forte valeur en se concentrant sur un système à haut risque, par exemple une console cloud, une plateforme financière, un portail d’administration client ou un environnement de déploiement en production.

D’abord, définissez le champ d’application. Identifiez le propriétaire métier, la classification des données, les groupes d’utilisateurs, les rôles à privilèges, les chemins d’accès à distance, les authentificateurs actuels, les données à caractère personnel concernées et les dépendances vis-à-vis de tiers. Cela soutient les clauses 4.1 à 4.4 d’ISO/IEC 27001:2022, car le périmètre, les exigences des parties intéressées et les dépendances doivent être compris.

Ensuite, capturez les paramètres d’authentification actuels. Exportez ou capturez la politique de mots de passe, l’application de la MFA, la configuration des clés d’accès (passkeys) ou FIDO2, les règles d’accès conditionnel, le délai d’expiration de session, les méthodes de récupération, les comptes d’accès d’urgence et le statut de l’authentification héritée. Si le système utilise une authentification locale, documentez la raison et définissez une trajectoire de migration.

Troisièmement, comparez avec un état cible clair :

• Mots de passe filtrés pour les identifiants faibles, courants et compromis.
• Aucun accès par mot de passe seul pour les systèmes à privilèges, distants ou exposés à Internet.
• MFA résistante au phishing pour les administrateurs et les utilisateurs à haut risque.
• Enrôlement et récupération sécurisés.
• Révocation des authentificateurs lors du départ ou de la perte d’un appareil.
• Journalisation des authentifications réussies et échouées, de l’utilisation de la MFA et des changements d’authentificateur.
• Alertes en cas de déplacement impossible, d’échecs répétés, de nouvel enrôlement d’authentificateur et de connexions à risque.

Quatrièmement, joignez les éléments probants de politique. La Politique de contrôle d’accès - PME exige :

Des identifiants utilisateurs uniques sont requis ; les comptes partagés sont interdits.

Pour les éléments probants relatifs au cycle de vie des comptes, la Politique de gestion des comptes utilisateurs et des privilèges - PME indique :

Les journaux de création de compte, de désactivation de compte et de modification des privilèges doivent être conservés de manière sécurisée pendant au moins 12 mois.

Pour la journalisation de l’authentification, la Politique de journalisation et de surveillance - PME de Clarysec précise :

Journaux d’authentification : tentatives de connexion réussies et échouées, durée de session, utilisation de la MFA

Pour les mises en œuvre d’entreprise, la Politique de journalisation et de surveillance exige la journalisation des éléments suivants :

Tentatives d’authentification et d’accès des utilisateurs

Cinquièmement, mettez à jour la Déclaration d’applicabilité. Marquez A.5.16, A.5.17 et A.8.5 comme applicables et ajoutez des notes telles que :

• Soutient les attentes NIST SP 800-63-4 relatives au cycle de vie des authentificateurs.
• Soutient les attentes NIS2 Article 21 relatives au contrôle d’accès et à la MFA.
• Soutient les exigences DORA de gestion des risques liés aux TIC en matière d’authentification et de surveillance.
• Soutient la sécurité et la responsabilité prévues par GDPR Article 32 pour l’accès aux données à caractère personnel.
• Exception : le portail de règlement hérité ne prend pas en charge FIDO2. Les contrôles compensatoires incluent la restriction VPN, la surveillance des sessions à privilèges, le plan de remédiation fournisseur et la revue mensuelle des accès.

Enfin, préparez un dossier intitulé « Dossier d’éléments probants d’authentification - T2 2026 » avec les extraits de politiques, l’appréciation des risques, l’enregistrement de traitement, l’extrait de SoA, la configuration IdP, le rapport de couverture MFA et clés d’accès (passkeys), la liste des utilisateurs à privilèges, le registre des exceptions, les journaux d’enrôlement et de révocation, l’échantillon de test de départ, les requêtes SIEM, les captures d’écran d’alertes, l’extrait du playbook de réponse aux incidents et la communication de sensibilisation des utilisateurs.

C’est la différence entre « nous utilisons la MFA » et « nous pouvons prouver la gouvernance de l’authentification sécurisée ».

Comment différents auditeurs testeront les mêmes contrôles d’identité

Un programme d’identité mature anticipe différents angles d’audit.

L’auditeur ISO 27001 commencera par le système de management. Il demandera comment les risques liés à l’identité ont été évalués, pourquoi les contrôles ont été sélectionnés, comment ils apparaissent dans la SoA, si les politiques sont approuvées, si les responsabilités sont attribuées et si les éléments probants démontrent le fonctionnement dans la durée. Il testera la cohérence entre le registre des risques, la Politique de contrôle d’accès, les paramètres IdP et les journaux.

Zenith Blueprint, phase Controls in Action, Step 19, Audit Checklist for Controls 8.1 to 8.5, décrit la demande d’audit pratique :

Les auditeurs s’informeront des paramètres de complexité des mots de passe et de leur mode d’application (GPO Active Directory, politiques IdP, etc.). Présentez la documentation sur le déploiement de la MFA, les personnes auxquelles elle s’applique, les endroits où elle est imposée et les systèmes protégés.

Un auditeur DORA ou NIS2 se concentrera sur la gouvernance, la résilience et le risque systémique. Il pourra demander les éléments relatifs à la supervision par le conseil d’administration ou l’organe de direction, la couverture des systèmes critiques, les obligations d’authentification des tiers, les tests de continuité et les éléments probants montrant que les procédures de récupération ne peuvent être déclenchées que par du personnel authentifié.

Un évaluateur GDPR se concentrera sur les données à caractère personnel. Il demandera si l’authentification protège les données à caractère personnel contre l’accès non autorisé, si l’accès est limité à ce qui est nécessaire, si les journaux soutiennent l’évaluation des violations et si l’organisation peut démontrer sa responsabilité.

Un évaluateur orienté NIST peut utiliser les profils NIST CSF 2.0 pour comparer les états actuel et cible. Il attendra un plan d’action priorisé couvrant la gouvernance, la politique, le contrôle d’accès, la détection et les résultats de réponse.

Un auditeur COBIT 2019 ou ISACA évaluera si les pratiques d’identité et d’authentification soutiennent les objectifs de gouvernance, la conception des contrôles, le fonctionnement des contrôles, la séparation des tâches, l’accès à privilèges et la surveillance. La marque de clé d’accès utilisée lui importera peu. Il s’intéressera au fait que le contrôle soit gouverné, mesuré, attribué à un responsable et amélioré.

Ne pas oublier le départ, la récupération et les identités non humaines

De nombreux programmes d’authentification paraissent solides au moment de la connexion et faibles partout ailleurs.

Le départ est un point de défaillance courant. La Politique d’intégration et de départ de Clarysec inclut spécifiquement :

la révocation des jetons d’authentification MFA/SSO, des cartes à puce ou des certificats

Cette clause doit être testée. Sélectionnez trois utilisateurs sortants et prouvez que les comptes, sessions, appareils MFA, clés d’accès (passkeys), certificats et méthodes de récupération ont été révoqués dans les délais. Si vous ne pouvez pas prouver la révocation des jetons, votre contrôle de départ est incomplet.

La récupération est un autre point faible. Si un centre de services peut réinitialiser la MFA après deux questions simples, l’attaquant ciblera la récupération par le centre de services plutôt que la connexion. Les procédures de récupération doivent exiger une vérification forte, la journalisation des tickets, une approbation pour les utilisateurs à privilèges, une notification à l’utilisateur et la surveillance de l’activité post-récupération.

L’identité non humaine est le troisième angle mort. Zenith Blueprint Step 22 indique clairement que les informations d’authentification incluent les « mots de passe, codes PIN, clés cryptographiques, gabarits biométriques, cartes à puce, jetons, certificats, jetons OAuth, clés SSH, secrets d’API ». Les attaquants utilisent fréquemment des jetons d’API, des clés de comptes de service et des autorisations OAuth pour persister. Traitez ces identifiants au titre de A.5.17, avec conservation en coffre-fort, propriété, rotation, révocation et journalisation.

À quoi ressemble une bonne maîtrise en 2026

Un environnement mature de contrôles d’identité en 2026 présente les caractéristiques suivantes :

• Le conseil d’administration ou l’organe de direction comprend le risque lié à l’identité et approuve l’orientation.
• La politique de mots de passe est modernisée, ergonomique et techniquement appliquée.
• L’accès par mot de passe seul est éliminé pour les systèmes à privilèges, distants et exposés à Internet.
• Les clés d’accès (passkeys) ou les authentificateurs FIDO2 sont priorisés pour les accès à haut risque.
• Les exceptions MFA sont documentées, approuvées, limitées dans le temps et compensées.
• L’enrôlement, la récupération et la révocation des authentificateurs sont contrôlés.
• Le départ inclut la révocation des comptes, jetons, certificats, sessions et clés d’accès (passkeys).
• Les journaux d’authentification incluent les réussites, les échecs, l’utilisation de la MFA, la durée de session et les changements d’authentificateur.
• Les cas d’usage SIEM détectent le credential stuffing, les déplacements impossibles, les enrôlements suspects et la fatigue MFA.
• La SoA explique pourquoi A.5.16, A.5.17 et A.8.5 s’appliquent.
• Les cartographies NIS2, DORA, GDPR et NIST CSF sont enregistrées une seule fois et réutilisées.
• Les éléments probants sont collectés en continu, et non assemblés dans l’urgence avant l’audit.

C’est ainsi que NIST SP 800-63-4 devient plus qu’un document de référence. Il devient un système de contrôle vivant qui soutient la sécurité, la protection des données, la résilience et la préparation à l’audit.

Transformer les contrôles d’identité en éléments probants prêts pour l’audit

Si votre organisation met à jour ses règles de mots de passe, déploie une MFA résistante au phishing, introduit des clés d’accès (passkeys) ou se prépare à des questions d’audit ISO 27001, NIS2, DORA ou GDPR, ne commencez pas uniquement par la configuration des outils.

Commencez par le modèle d’éléments probants.

Clarysec peut vous aider à :

• Cartographier les attentes NIST SP 800-63-4 relatives aux mots de passe, à la MFA et aux clés d’accès (passkeys) avec ISO/IEC 27001:2022.
• Construire une politique de cycle de vie des authentificateurs et un dossier d’éléments probants.
• Mettre à jour les politiques de contrôle d’accès, de MFA, de journalisation, d’intégration et de départ.
• Préparer une Déclaration d’applicabilité qui relie le risque lié à l’identité aux contrôles.
• Utiliser Zenith Blueprint pour structurer les étapes de mise en œuvre et la préparation à l’audit.
• Utiliser Zenith Controls pour cartographier les contrôles d’identité entre NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 2019.

Le meilleur moment pour découvrir une récupération faible, une révocation de clé d’accès manquante ou une application MFA incomplète se situe avant l’incident, avant l’autorité de régulation et avant que l’auditeur ne pose la question.

Faites de votre prochaine revue de contrôle d’accès une revue des éléments probants NIST SP 800-63-4. Téléchargez les politiques Clarysec pertinentes, explorez Zenith Blueprint et utilisez Zenith Controls pour transformer la mise en œuvre des mots de passe, de la MFA et des clés d’accès (passkeys) en un récit de conformité pratique, proportionné et prêt pour l’audit.