Le cadre KRITIS allemand pour la protection des infrastructures critiques vient de connaître sa refonte la plus importante depuis dix ans. La loi de transposition NIS2 — Gesetz zur Umsetzung der NIS-2-Richtlinie, ou NIS2UmsG — est entrée en vigueur le 6 décembre 2025, révisant substantiellement la loi BSI (BSIG) qui régit les obligations de sécurité informatique des opérateurs d’infrastructures critiques depuis 2009.
Pour les organisations opérant dans des secteurs tels que l’énergie, l’eau, la santé, les transports ou l’informatique et les télécommunications, il ne s’agit pas d’une mise à jour mineure. Le périmètre des entités réglementées, leurs obligations et les modalités de preuve de conformité ont changé de manière concrète. Cet article explique ce qui a changé, ce qui reste identique et ce que cela signifie en pratique lors du choix d’une plateforme cloud.
Ce qu’est KRITIS et ce que cela signifie désormais en vertu de la nouvelle loi
KRITIS — abréviation de Kritische Infrastrukturen — est la désignation fédérale allemande pour les infrastructures critiques. Les opérateurs d’installations relevant de KRITIS sont depuis longtemps soumis à des obligations spécifiques en matière de sécurité informatique en vertu de la BSIG, sous la supervision du BSI (Bundesamt für Sicherheit in der Informationstechnik).
En vertu de la nouvelle loi, la terminologie a évolué. La BSIG révisée ne parle plus de « Kritische Infrastrukturen » comme catégorie principale. Elle réglemente désormais les besonders wichtige Einrichtungen (entités particulièrement importantes) et les wichtige Einrichtungen (entités importantes). Les opérateurs de ce qui est désormais appelé kritische Anlagen (installations critiques) constituent un sous-ensemble du premier groupe et restent soumis aux exigences les plus strictes. Les obligations qu’ils détenaient en vertu de la BSIG précédente sont largement maintenues, mais restructurées et, dans certains domaines, renforcées.
Les secteurs couverts restent globalement les mêmes : énergie, transports, finance, santé, eau, alimentation, informatique et télécommunications, espace et gestion des déchets. Ce qui a changé, c’est la logique des seuils, certaines règles sectorielles et le périmètre global des entités concernées par le cadre — non seulement les opérateurs KRITIS, mais des dizaines de milliers d’organisations relevant des catégories NIS2 plus larges.
Un changement structurel notable : le secteur financier a été scindé en deux — Finanzwesen (Finance) et Leistungen der Sozialversicherung sowie Grundsicherung für Arbeitsuchende (Prestations sociales et revenu de base pour les demandeurs d’emploi). Les assureurs privés ne sont plus inclus. Les organisations soumises au règlement DORA de l’UE sont exemptées de certaines obligations de déclaration et d’audit de la BSIG, car les deux cadres se chevauchent considérablement.
Ce que les opérateurs d’installations critiques doivent désormais faire
Pour les opérateurs de kritische Anlagen, les obligations fondamentales — enregistrement, déclaration d’incidents, mise en œuvre de mesures techniques et organisationnelles appropriées et fourniture régulière de preuves de conformité — restent en place. Mais plusieurs détails ont changé.
L’enregistrement suit désormais deux voies. Les opérateurs KRITIS existants doivent s’enregistrer non seulement dans le portail MIP (Melde- und Informationsportal) existant, qu’ils utilisent jusqu’à présent, mais également en tant que besonders wichtige Einrichtung dans le nouveau portail BSI. La date limite pour ceux déjà enregistrés est de trois mois à compter du 6 décembre 2025 — soit le 6 mars 2026. Les nouveaux opérateurs doivent effectuer les deux enregistrements dès le départ.
Le cycle d’audit a été allongé. Auparavant, les opérateurs devaient soumettre des preuves de conformité tous les deux ans. En vertu de la nouvelle BSIG, le cycle est de trois ans. Le BSI a directement notifié aux opérateurs existants leurs nouvelles échéances individuelles.
La déclaration d’incidents suit la structure NIS2. L’obligation de déclaration KRITIS précédente est désormais entièrement intégrée dans le cadre NIS2. Les opérateurs qui déclarent via MIP n’ont pas besoin de dupliquer la déclaration dans le portail BSI — le BSI a confirmé que cet arrangement transitoire restera en place au moins jusqu’au 31 juillet 2026.
Les systèmes de détection d’attaques restent obligatoires. L’exigence de déployer des systèmes capables de détecter les événements pertinents pour la sécurité — introduite par IT-SiG 2.0 en 2021 — est maintenue en vertu de l’article 31 de la BSIG pour les opérateurs d’installations critiques spécifiquement. Le BSI a publié des lignes directrices sur ce que ces systèmes doivent être capables de faire (Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung), disponibles via la page de téléchargements du BSI.
Les points de contact partagés (GÜAS) sont supprimés. Les opérateurs qui partageaient auparavant une structure de contact commune avec leurs pairs du même secteur doivent désormais chacun maintenir leurs propres arrangements de contact directs avec le BSI.
Pourquoi le choix de la plateforme cloud est une décision de conformité KRITIS
La BSIG révisée exige explicitement que les opérateurs évaluent la fiabilité de leurs fournisseurs de technologies — y compris les plateformes sur lesquelles leurs charges de travail critiques s’exécutent. Ce n’est pas nouveau, mais c’est désormais plus formellement intégré dans le cadre. Pour l’infrastructure cloud spécifiquement, cela soulève des questions qui vont au-delà des certifications et des SLA.
Les plateformes cloud publiques hyperscale — AWS, Azure, GCP — présentent des caractéristiques structurelles difficiles à concilier avec les exigences KRITIS. Les décisions de routage des données sont prises de manière dynamique, ce qui rend techniquement difficile de garantir que les données ne quittent jamais l’Allemagne ou l’UE. Leurs systèmes internes — hyperviseurs, piles réseau — ne peuvent pas être audités de manière indépendante, ce qui crée des frictions avec les exigences d’évaluation de la chaîne d’approvisionnement. Et les fournisseurs dont le siège est aux États-Unis restent soumis au CLOUD Act (18 U.S.C. § 2713), qui peut contraindre à la divulgation de données quel que soit l’endroit où elles sont stockées — un conflit direct avec les obligations de souveraineté des données en vertu du cadre BSIG.
Rien de tout cela ne signifie qu’un hyperscaler ne peut pas faire partie de l’infrastructure d’un opérateur. Mais cela signifie que pour les charges de travail classées comme critiques, la question de la plateforme revêt un poids réglementaire, et pas seulement opérationnel.
Ce qu’il faut rechercher dans une plateforme cloud conforme
Sur la base des exigences énoncées dans la BSIG révisée et les lignes directrices du BSI, une plateforme cloud prenant en charge les charges de travail réglementées KRITIS doit démontrablement traiter plusieurs domaines :
Haute disponibilité par architecture — pas seulement un temps de disponibilité promis contractuellement, mais une redondance intégrée dans les couches de calcul, de stockage et de réseau, sans point de défaillance unique.
Déploiement sur site ou privé avec contrôle total de la résidence des données — l’opérateur doit pouvoir vérifier où les données sont traitées et stockées, sans routage externe non divulgué.
Chiffrement au repos et en transit, gestion des clés sous le contrôle de l’opérateur et segmentation réseau stricte entre les locataires.
Capacité de détection d’attaques conforme aux lignes directrices du BSI — surveillance en temps réel, détection d’anomalies et intégration avec les outils SIEM.
Journalisation d’audit complète — chaque appel d’API, chaque modification de configuration, chaque action administrative, exportable pour l’inspection du BSI et la soumission de preuves de conformité triennale.
Une chaîne d’approvisionnement logicielle auditable — des fondations open source avec une nomenclature logicielle (SBOM) publiée, afin que les opérateurs puissent effectuer l’évaluation de fiabilité requise par la loi.
Comment FishOS répond aux exigences KRITIS
FishOS, développé par Sardina Systems, est une plateforme de gestion cloud qui intègre OpenStack, Kubernetes et Ceph dans une pile automatisée unique. Elle est conçue pour un déploiement sur site et en cloud privé, ce qui signifie que les opérateurs conservent un contrôle direct sur l’endroit où leurs données résident et sont traitées — sans dépendance à une infrastructure cloud externe ou à une juridiction étrangère.
Du côté de la disponibilité, FishOS inclut un composant de surveillance de la santé propriétaire qui analyse en continu les métriques en temps réel et les données de journalisation. Selon Sardina Systems, il utilise ce qu’ils décrivent comme une approche d’« immunologie informatique » — identifiant non seulement les états défaillants mais aussi les états « malades » dégradés avant qu’ils ne provoquent des pannes. Cela se distingue des outils de surveillance conventionnels.
Du côté de la sécurité et de l’audit, FishOS fournit une journalisation d’audit centralisée couvrant les actions au niveau utilisateur et système dans toute l’infrastructure, et prend en charge l’intégration SIEM. Selon des évaluations tierces de la plateforme, FishOS inclut une capacité SIEM intégrée pour détecter et répondre aux menaces de sécurité au sein de l’environnement.
En matière de transparence de la chaîne d’approvisionnement, FishOS est construit sur des composants open source — OpenStack, Ceph, Kubernetes — avec des bases de code publiquement auditables. Sardina Systems fournit une documentation SBOM, qui soutient directement l’évaluation de la fiabilité de la chaîne d’approvisionnement requise en vertu de la BSIG révisée.
FishOS prend en charge la migration depuis VMware et d’autres plateformes héritées via son appliance FishOS Move It, en utilisant soit une approche à temps d’arrêt minimal, soit le suivi des blocs de changement (CBT) pour les environnements en production. Les deux méthodes ont fait leurs preuves sur des sites de production.
FishOS fournit la base architecturale — souveraineté sur site, auditabilité open source, haute disponibilité et outillage opérationnel — dont les opérateurs ont besoin pour construire et démontrer une infrastructure conforme.
Par où commencer avec KRITIS
Si votre organisation est potentiellement concernée par la BSIG révisée — soit en tant qu’opérateur KRITIS existant, soit en tant qu’entité nouvellement réglementée dans les catégories NIS2 — les priorités immédiates sont :
Premièrement, vérifiez si vous êtes qualifié en tant que Betreiber kritischer Anlagen en vertu de la BSI-KritisV mise à jour, ou en tant qu’besonders wichtige ou wichtige Einrichtung dans le cadre NIS2 plus large. Le BSI a publié un outil d’auto-évaluation à cette fin.
Deuxièmement, si vous êtes déjà enregistré dans MIP en tant qu’opérateur KRITIS, lancez l’enregistrement dans le nouveau portail BSI en tant que besonders wichtige Einrichtung avant le 6 mars 2026.
Troisièmement, évaluez votre infrastructure actuelle par rapport aux exigences techniques des articles 30 et 31 de la BSIG — en particulier concernant la détection d’attaques, la journalisation d’audit et la documentation de la chaîne d’approvisionnement.
