ISO 27001, annexe A, paragraphe 8.24 : Guide pratique sur la cryptographie et la gestion des clés à l'intention des prestataires de services informatiques

Pour la plupart des fournisseurs de services informatiques et d’ software , la certification ISO 27001 a discrètement cessé d’être un simple atout. Elle est désormais une condition sine qua non pour exercer leur activité. Les questionnaires de sécurité destinés aux clients, les appels d’offres et les évaluations des risques liés aux fournisseurs exigent de plus en plus souvent une certification en cours de validité avant qu’un contrat puisse être conclu, ce qui signifie qu’un certificat périmé ne constitue plus seulement un problème de conformité. Il s’agit désormais d’un risque pour le chiffre d’affaires.

La cryptographie est au cœur même de cette évolution. La révision de la norme de 2022 a regroupé la cryptographie et la gestion des clés au sein d’un seul et même contrôle clairement défini : l’annexe A, paragraphe 8.24, « Utilisation de la cryptographie ». Ce guide détaille les changements apportés par la révision de 2022, ce qu’exige réellement le contrôle 8.24 et comment en apporter la preuve à un auditeur avant votre prochaine visite de surveillance.

Quels sont les changements apportés à la norme ISO/IEC 27001:2022 ?

La révision de 2022 a réorganisé l’annexe A en 93 mesures de contrôle réparties en quatre thèmes. En matière de cryptographie, le changement le plus important réside dans la consolidation : les deux mesures de contrôle distinctes de l’édition de 2013 (A.10.1.1, « Politique relative à l’utilisation des mesures de contrôle cryptographiques », et A.10.1.2, « Gestion des clés ») ont été fusionnées en une seule mesure de contrôle : 8.24, « Utilisation de la cryptographie ».

Cette consolidation a une incidence sur la manière dont les équipes documentent et justifient leur programme de cryptographie. Au lieu de considérer la politique de sécurité et la gestion des clés comme deux exigences vaguement liées, la section 8.24 exige une approche cohérente : une stratégie de cryptographie bien définie et un cycle de vie géré pour les clés qui la sous-tendent, le tout étroitement lié et étayé par des preuves.

Ce qu'exige réellement la norme 8.24

La mesure 8.24 repose sur deux piliers.

La première consiste en une politique de cryptographie documentée et fondée sur les risques, qui définit les algorithmes approuvés et les niveaux minimaux de sécurité des clés. La seconde consiste en une gestion du cycle de vie des clés couvrant l'ensemble de celui-ci : génération, distribution, révocation, traitement des clés compromises, récupération des clés perdues, stockage, rotation, sauvegarde et destruction.

Le point crucial pour les entreprises du secteur des technologies de l'information et de l'software , c'est la manière dont les auditeurs vérifient cela. Ils vérifient la conformité à la clause 8.24 à l'aide de preuves opérationnelles, et non pas uniquement sur la base des déclarations de politique générale. Concrètement, cela implique l’inventaire des certificats et des clés, les registres de rotation attestant que l’intervalle défini par la politique a bien été respecté, les résultats de configuration de l’ TLS et du chiffrement, les journaux d’accès aux HSM ou aux KMS, ainsi que les registres de destruction accompagnés d’une validation. Une politique bien rédigée dont personne ne peut prouver qu’elle est respectée ne satisfera pas un évaluateur. Et comme la clause 8.24 s’applique au produit, son champ d’application inclut systématiquement la cryptographie intégrée au produit lui-même, et pas seulement l’environnement informatique interne.

Pourquoi la conformité à la norme ISO 27001 en matière de cryptographie est-elle importante pour les fournisseurs informatiques ?

La certification ISO 27001 est techniquement facultative. Dans la pratique, pour les fournisseurs de services informatiques et d’ software , elle est devenue une condition préalable commerciale de facto. Les questionnaires de sécurité, les appels d’offres et les évaluations des risques liés aux fournisseurs exigent de plus en plus souvent une certification à jour comme condition pour conclure une affaire ; ainsi, une lacune dans vos contrôles cryptographiques peut bloquer les procédures d’achat et compromettre la conclusion de contrats ; cela se répercute sur les achats de deux manières : soit cela apparaît directement dans une réponse à un questionnaire de sécurité que vous ne pouvez pas justifier, soit cela devient un cas de non-conformité qui met en péril le certificat lui-même.

Il y a également une dimension temporelle. La norme ISO 27001 étant une norme relative aux systèmes de gestion, la clause 8.24 ne fait pas l’objet d’un contrôle ponctuel suivi d’un oubli.  Les audits de surveillance procèdent à un échantillonnage du SMSI plutôt que de tester chaque contrôle ; ainsi, le point 8.24 peut être abordé ou non au cours d’une année donnée. La recertification est différente : elle confirme que le système répond à toutes les exigences de la norme, et pas seulement aux domaines échantillonnés lors de la surveillance. Dans la pratique, il est impossible de prédire quelle année la cryptographie fera l’objet d’un examen. Cette cadence récompense les organisations qui maintiennent un contrôle continu et prêt à être justifié sur la cryptographie, plutôt que celles qui s’empressent de le reconstituer avant chaque audit.

Il est utile de savoir comment un certificat peut effectivement être perdu : une non-conformité majeure n’entraîne pas son annulation immédiate. Les organismes de certification fixent un délai précis pour remédier au problème, et la suspension ou le retrait n’interviennent que si celui-ci n’est pas résolu. Le risque commercial réside moins dans le fait d’« avoir échoué à un audit » que dans le fait d’« avoir passé un trimestre avec une non-conformité majeure non résolue que nous avons dû divulguer ».

Comment la norme 8.24 correspond aux contrôles cryptographiques réels

Le point de contrôle 8.24 n'est pas isolé. Il s'inscrit dans un ensemble de domaines de contrôle concrets dont les évaluateurs s'attendent à ce qu'ils fonctionnent de manière coordonnée dans l'ensemble du périmètre certifié.

Une politique documentée en matière de cryptographie et de gestion des clés (annexe A, point 8.24)

Fondamentalement, la norme 8.24 préconise la mise en place d’une politique spécifique à chaque domaine, définissant les algorithmes approuvés, les longueurs minimales de clés et les règles relatives au cycle de vie. Cette politique doit être directement liée à l’évaluation des risques du SMSI, de sorte que chaque décision cryptographique puisse être rattachée à un risque documenté plutôt qu’à une simple préférence.

Le cycle de vie des clés cryptographiques (annexe A, point 8.24)

C'est au niveau du cycle de vie que la cryptographie forte présente le plus souvent des failles. Les auditeurs s'attendent à ce que la génération, la distribution, la rotation et la destruction des clés et des certificats soient centralisées, y compris celles intégrées aux software livrés, le tout s'appuyant sur une piste d'audit complète. La révocation, la gestion des clés compromises, la récupération des clés perdues, le stockage sécurisé et la sauvegarde complètent le tableau.

Confidentialité et intégrité des données (annexe A, points 5.14, 8.20 et 8.21 ; données à caractère personnel, point 5.34)

La cryptographie a pour but de protéger les données. Selon la section 8.24, la cryptographie est le mécanisme ; les contrôles qui créent l’obligation relèvent d’autres sections. L’annexe A, sections 5.34 (transfert d’informations) et 8.20–8.21 (sécurité des réseaux et des services réseau), régissent le chiffrement en transit. Les certificats délivrés par PKI sécurisent les données des clients au repos et en transit dans l’ensemble du périmètre certifié. Pour les fournisseurs de solutions « software », ce périmètre s’étend généralement aux environnements SaaS multi-locataires, dans lesquels de nombreux clients partagent la même infrastructure.

Cryptographie des produits (annexe A, points 8.25, 8.26 et 8.28)

Si la cryptographie fait partie intégrante de vos produits, c’est au niveau du cycle de vie de développement sécurisé (8.25), des exigences de sécurité des applications (8.26) et du codage sécurisé (8.28) que les auditeurs vérifient si les choix relatifs aux algorithmes et à la longueur des clés, définis dans votre politique 8.24, sont effectivement pris en compte dans le code source. Les contrôles des fournisseurs portent sur les bibliothèques héritées ; ceux-ci concernent votre propre code.

Authentification sécurisée (annexe A, point 8.5)

La section 8.5 de l'annexe A aborde la question de l'authentification dans le contexte de la cryptographie. L'authentification par certificat réduit le recours aux secrets partagés et aux mots de passe statiques, tant pour les accès clients que pour les accès administratifs, en remplaçant les identifiants, qui peuvent facilement faire l'objet de fuites, par des identités bien plus difficiles à utiliser à mauvais escient.

Supplier and inherited cryptography (Annex A 5.21, 8.8)
Modern software inherits cryptography from libraries and third parties. Annex A 8.24 requires a key management system to handle key revocation, compromised keys. Every one of those duties is owed per key, and a per-key duty presupposes knowing which keys exist. For Annex A 8.8, an accurate asset inventory is a prerequisite for effective vulnerability management. Annex A 5.21 extends the question into the ICT supply chain, where the components are someone else’s code. Read together, the inventory is not a stated requirement; it is the only practical way to evidence four that are.

Statement of Applicability traceability (Clause 6.1.3)
Finally, Clause 6.1.3 ties it all back to governance. Centralized reporting that maps cryptographic controls to documented risk treatment decisions gives auditors a clear, traceable line from a control to the risk it addresses.

Se préparer à l'audit : ce que les auditeurs examinent

Lorsqu'un évaluateur atteint le niveau 8,24, il recherche des preuves, et non des intentions. Voici les domaines qu'il examine systématiquement :

• Une politique de cryptographie documentée qui s'applique à la fois aux systèmes internes et aux produits commercialisés, définissant les algorithmes approuvés, les longueurs minimales de clé et les conditions dans lesquelles le chiffrement est obligatoire.
• Preuves relatives au cycle de vie des clés : les registres, et non les procédures : registres de rotation attestant que l'intervalle prévu par la politique a été respecté, registres de destruction comportant une signature de validation, registres d'activité par clé, ainsi que les dates d'activation et de désactivation.
• Déclaration relative à la traçabilité de l'applicabilité qui justifie l'inclusion de la clause 8.24 et établit un lien avec l'évaluation des risques sous-jacente.
• Respect des obligations légales et juridictionnelles, y compris les contrôles à l'exportation et les considérations relatives à la localisation des données.
• Un inventaire à jour des certificats et des clés, indiquant les titulaires et les dates d'expiration, y compris les clés intégrées dans les versions d'software .
• Contrôles d'audit interne portant sur les 8,24 contrôles, dont les conclusions sont examinées par la direction dans le cadre du cycle du SMSI.
• Conformité de la configuration à la politique. Les évaluateurs comparent les algorithmes et les longueurs de clé autorisés par votre politique à ce qui est réellement déployé. Un écart entre la politique et la réalité constitue une non-conformité, même si la politique et la configuration sont chacune justifiables en soi.

Le point commun, c'est la propriété et la traçabilité. Chaque affirmation que vous avancez au sujet de la cryptographie doit s'appuyer sur un élément concret qu'un auditeur peut examiner.

Comment Keyfactor vous aider

La réunion du 24 août porte essentiellement sur la visibilité, les règles applicables et la gestion rigoureuse des clés à grande échelle. La plateforme de Keyfactorcorrespond parfaitement aux domaines de contrôle mentionnés ci-dessus.

• AgileSec établit l'inventaire des composants cryptographiques qui permet de garantir la fiabilité des fournisseurs et fournit des preuves sous forme de « Déclaration d'applicabilité » pour les composants intégrés ou tiers.
• EJBCA fournit l'PKI e nécessaire à la confidentialité et à l'intégrité des données garanties par des certificats, ainsi qu'une gestion centralisée du cycle de vie des clés, y compris celles intégrées aux appareils « software » livrés.
• Keyfactor Command assure le respect de la politique, offre une visibilité sur le cycle de vie des clés, gère l'inventaire des certificats et des clés, et génère des rapports de traçabilité conformes à la « Déclaration d'applicabilité ».

Une fois regroupées, ces fonctionnalités constituent un système unique de référence en matière de cryptographie, capable de fournir les preuves exactes exigées par un auditeur ISO 27001, sans que les équipes aient à les rassembler manuellement.

Conclusion et prochaines étapes

Le message qui se dégage de la version 8.24 est clair : le contrôle privilégie la propriété, la traçabilité et les preuves plutôt que les déclarations de principe. La certification dépend moins de la présence des mots justes dans un document que de la capacité à démontrer, sur simple demande, comment votre cryptographie est régie et comment vos clés sont gérées.

La prochaine étape concrète est simple. Évaluez votre politique actuelle en matière de cryptographie et votre inventaire de clés au regard de la section 8.24 avant votre prochain audit, et centralisez les justificatifs plutôt que de les répertorier dans des feuilles de calcul dispersées.

Prêt à découvrir comment la cryptographie automatisée et la gestion du cycle de vie des clés s'inscrivent dans le cadre de l'annexe A, paragraphe 8.24 ? Demander une démo.

Vous avez des questions sur la cryptographie dans le cadre de la norme ISO 27001 ? Nous avons les réponses.

What is ISO/IEC 27001 Annex A 8.24?
Annex A 8.24, Use of Cryptography, is the ISO 27001:2022 control governing how an organization uses cryptography. It requires a documented, risk-based cryptography policy and a managed key lifecycle, verified through operational evidence rather than policy statements alone. Annex A itself states the control in a single sentence; the detailed expectations sit in ISO/IEC 27002:2022, which auditors use as the yardstick.

What changed for cryptography in the 2022 revision?
The 2022 revision restructured Annex A into 93 controls across four themes. It consolidated the 2013 edition’s separate cryptography and key management controls into a single control, 8.24.

Does 8.24 cover cryptography inside the products we ship?
Yes. For software and IT service companies, the scope of 8.24 routinely includes cryptography embedded in the product itself, not only the internal IT environment.

What does a compliant cryptography policy need to include?
It should be a topic-specific policy defining approved algorithms, minimum key lengths, and the conditions under which encryption is mandatory. It must be tied to the ISMS risk assessment and cover both internal systems and shipped products.

What key lifecycle evidence do auditors expect?
Auditors expect demonstrated procedures for key generation, secure storage, rotation, and destruction, not just a written policy. A current certificate and key inventory with named owners and expiry dates supports this.

How often is 8.24 tested?
Because ISO 27001 is a management-system standard, 8.24 is tested at annual surveillance audits and in full at the three-year recertification.

Why does ISO 27001 certification matter commercially?
Certification has become a de facto commercial prerequisite for IT and software vendors. Security questionnaires, RFPs, and supplier risk assessments increasingly require current certification, so a lapsed certificate can directly threaten revenue.

How does 8.24 relate to the Statement of Applicability?
The Statement of Applicability must justify including 8.24 and link it to the underlying risk assessment. Centralized reporting that maps cryptographic controls to documented risk treatment decisions supports auditor review under Clause 6.1.3.