ISO/IEC 27001 n'est pas une loi. C'est une norme volontaire de certification : aucun texte ne vous impose de l'obtenir, ce sont vos clients et vos donneurs d'ordre qui le font. Elle ne prescrit aucune technologie et ne contient nulle part la phrase « déployez de la MFA ». Ce qu'elle demande est plus exigeant : démontrer que votre dispositif d'authentification découle d'une analyse de risque, qu'il s'applique partout où vous avez déclaré qu'il s'appliquait, et que vous le vérifiez.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. Le contenu exact d'une certification dépend du périmètre que vous déclarez et de l'appréciation de l'organisme certificateur retenu.
Une norme volontaire, un effet contractuel bien réel
La confusion est fréquente, y compris dans des directions générales : ISO/IEC 27001 est parfois présentée comme une « obligation réglementaire ». Elle ne l'est pas. Elle décrit un système de management de la sécurité de l'information : on identifie des risques, on décide de mesures, on les met en œuvre, on les contrôle, on corrige, et on recommence. L'amélioration continue est le cœur du dispositif, bien plus que la liste de mesures elle-même.
Cette liste existe pourtant, dans l'annexe A de la norme : contrôle d'accès, gestion des identités, informations d'authentification, droits d'accès privilégiés, journalisation, sécurité des relations avec les fournisseurs. Elle est volontairement générique ; c'est ISO/IEC 27002, guide de mise en œuvre, qui détaille ce que chaque mesure recouvre.
L'absence d'obligation légale ne change rien à la pression réelle : en appel d'offres, la certification est devenue une case à cocher, à côté des exigences de NIS2, DORA ou du Cyber Resilience Act. La différence, c'est qu'ici l'auditeur ne vérifie pas une conformité à un texte : il vérifie votre cohérence avec vos propres déclarations.
L'auditeur ne demande pas « avez-vous de la MFA ? »
Beaucoup d'équipes préparent l'audit comme un contrôle d'inventaire. L'entretien réel ressemble plutôt à trois questions enchaînées, dont la troisième est celle qui fait mal.
« Pourquoi ce dispositif-là, sur cet accès-là ? »
La norme raisonne par les risques. Une méthode d'authentification n'est ni bonne ni mauvaise dans l'absolu : elle est proportionnée ou non au risque identifié sur l'actif concerné. Si votre analyse de risque qualifie l'accès à la base de production de « critique » et que cet accès repose sur un second facteur relayable, l'écart n'est pas technique, il est logique. Vous avez écrit vous-même le risque que votre mesure ne couvre pas.
C'est aussi pourquoi un dispositif capable d'attester d'une intention humaine au moment d'une action sensible, comme le facteur cognitif, se documente bien : il répond à un risque nommé — la validation obtenue sous manipulation — plutôt qu'à une case générique.
« Est-ce appliqué partout où vous l'avez déclaré ? »
Une politique qui couvre la quasi-totalité des accès ne couvre pas la quasi-totalité du risque : elle vaut l'écart. L'auditeur échantillonne, et il échantillonne rarement le parcours vitrine.
« Comment le savez-vous ? »
C'est la question décisive. Une mesure sans preuve de fonctionnement n'existe pas au sens du management de la sécurité. Un extrait de journal, une revue d'habilitations datée, un compte rendu d'audit interne : sans cela, la mesure est une intention.
Le piège de la déclaration d'applicabilité
La déclaration d'applicabilité liste les mesures retenues, celles écartées, et la justification de chaque choix. Elle est rédigée tôt, souvent dans un moment d'optimisme, puis elle vieillit mal.
Deux échecs classiques. Le premier : une rédaction trop ambitieuse. Écrire que l'authentification forte s'applique « à tous les accès distants » vous engage sur ceux des prestataires, des astreintes et des outils d'administration — pas seulement sur le VPN des salariés. Le second : une exclusion qui n'est plus vraie. Une mesure écartée parce que « nous n'hébergeons pas de données clients » devient un écart majeur le jour où une nouvelle offre en héberge.
Traitez ce document comme un contrat que vous signez contre vous-même : chaque phrase y sera lue littéralement.
Cinq angles morts qui reviennent à chaque audit
| Angle mort | Ce que l'auditeur cherche à établir | Ce qui fait échouer la démonstration |
|---|---|---|
| Comptes de service | Qui les possède, comment leurs secrets sont renouvelés, comment leur usage est tracé | Un compte technique sans propriétaire identifié, avec un secret jamais changé |
| Comptes d'urgence | Que l'accès de secours est encadré, scellé et revu après chaque usage | Un compte de secours partagé, connu de trop de monde, jamais audité |
| Accès des prestataires | Que la sécurité des relations avec les fournisseurs se traduit en contrôles techniques réels | Des comptes tiers créés à la demande, jamais fermés à la fin de la mission |
| Réinitialisation de compte | Que le parcours de récupération offre le même niveau de garantie que la connexion | Un support qui rouvre un accès sur reconnaissance vocale ou sur un simple courriel |
| Journalisation | Que les traces sont exploitables et corrélables plusieurs mois après les faits | Des journaux collectés mais non conservés, ou impossibles à relier à une personne |
Le quatrième point mérite une attention particulière : c'est très souvent le maillon le plus faible d'un dispositif par ailleurs solide. Une authentification robuste qui se contourne par le helpdesk n'est pas une authentification robuste, et un auditeur expérimenté le teste.
Par où commencer
- Relire la déclaration d'applicabilité ligne à ligne, en confrontant chaque formulation à la réalité du parc, avant que l'auditeur ne le fasse.
- Cartographier les accès par criticité, pas par outil : c'est le niveau auquel la norme raisonne.
- Inventorier les comptes non nominatifs — service, urgence, prestataires, automates — et leur affecter un propriétaire.
- Reprendre les parcours de récupération pour les aligner sur le niveau de la connexion.
- Vérifier que les journaux permettent de reconstituer une action contestée plusieurs mois plus tard.
- Faire passer un audit interne sur l'authentification seule, avec échantillonnage réel : vous verrez ce que l'organisme certificateur verra.
FAQ
ISO/IEC 27001 impose-t-elle l'authentification multifacteur ?
Non, pas littéralement. La norme demande un contrôle d'accès et une gestion des informations d'authentification adaptés au risque. L'authentification multifacteur est la réponse la plus courante, mais c'est votre analyse de risque qui doit justifier le choix retenu, accès par accès.
Peut-on être certifié en conservant du SMS-OTP ?
C'est possible si l'usage est documenté, cantonné à des accès dont le risque le justifie, et assumé dans l'analyse. Cela devient difficile à défendre sur des opérations sensibles, d'autant que le référentiel NIST SP 800-63 classe l'OTP par SMS ou par voix comme déconseillé.
La certification couvre-t-elle nos prestataires ?
Non, elle couvre votre système de management sur le périmètre déclaré. En revanche, la mesure relative à la sécurité des relations avec les fournisseurs vous oblige à encadrer leurs accès et à pouvoir en rendre compte, y compris techniquement.
ISO/IEC 27002 sert-elle à quelque chose si l'on vise la certification ?
Oui. La norme certifiable énonce les mesures ; le guide de mise en œuvre explique ce qu'elles recouvrent. C'est le document à ouvrir quand on hésite sur ce qu'exige réellement une mesure de droits d'accès privilégiés ou de journalisation.
Aller plus loin : pilier : authentification cognitive · ISO 27001 chez les éditeurs SaaS · gérer les accès à privilèges · grille d'évaluation d'un fournisseur