EN FR Accueil

Exigences NIS 2 sur le NTP :
Synchronisation Temporelle pour Entités Essentielles & Importantes

Traduction de l'article 21 en infrastructure NTP authentifiée

Publié le 20 avril 2026 · Par Richard DEMONGEOT, RDEM Systems · À propos de l’auteur · Audience : RSSI, DPO et auditeurs d'entités essentielles et importantes au sens de la directive (UE) 2022/2555.

1. Qui est concerné — entités essentielles vs importantes

La directive (UE) 2022/2555 — la directive NIS 2 — est entrée en vigueur le 16 janvier 2023 ; les États membres devaient la transposer au plus tard le 17 octobre 2024. Elle distingue deux catégories d'entités, essentielles et importantes (art. 3) :

  • Annexe I (secteurs hautement critiques) : énergie, transports, banque, infrastructures des marchés financiers, santé, eau potable, eaux usées, infrastructures numériques (IXP, DNS, registres de TLD, cloud, datacenters, CDN, services de confiance, communications électroniques), gestion des services TIC (interentreprises), administration publique, espace. Les grandes entités sont essentielles, les moyennes importantes (sous réserve des exceptions de l'art. 3(1)(b) à (g)).
  • Annexe II (autres secteurs critiques) : services postaux et d'expédition, gestion des déchets, produits chimiques, denrées alimentaires, fabrication (dispositifs médicaux, informatique, électronique, équipements électriques, machines, véhicules à moteur, autres matériels de transport), fournisseurs numériques (places de marché, moteurs de recherche, réseaux sociaux), organismes de recherche. Entités importantes.

Dans les deux catégories, l'article 21 impose une obligation de gestion des risques. La directive ne nomme pas le temps ; son règlement d'exécution demande des horloges synchronisées, et le guide technique de l'ENISA recommande un NTP authentifié et plusieurs sources de temps. Un NTP non authentifié se défend mal comme socle d'une piste d'audit.

2. L'article 21 et le temps : quatre mesures où l'heure compte (notre lecture)

L'article 21(2) énumère dix catégories de mesures que les entités essentielles et importantes doivent mettre en œuvre. Quatre mesures où l'heure compte (notre lecture) :

3. Les délais de l'article 23 supposent un temps fiable

L'article 23 impose une cadence stricte de notification d'incident au CSIRT compétent :

DélaiArtefactDépendance temporelle
24 heuresAlerte précoceLa détection d'« incident significatif » dépend de seuils de supervision temporalisés.
72 heuresNotification avec évaluation initialeCorrélation de logs multi-services pour établir le périmètre.
1 moisRapport finalChronologie forensique — une chronologie dont les horodatages peuvent être contestés affaiblit le rapport.

4. Menaces contre un NTP non authentifié

NTP est l'un des plus anciens protocoles non authentifiés encore largement utilisés. Classes d'attaques documentées qu'une entité essentielle doit considérer sous l'article 21 :

  • Décalage temporel off-path — un MITM sur UDP/123 injecte des timestamps qui décalent la victime de quelques minutes à plusieurs années, invalidant certificats TLS, jetons MFA et journaux d'audit.
  • Kiss-of-Death spoofing — un paquet KoD forgé force un client à se détourner d'une source légitime, l'orientant vers un serveur contrôlé par l'attaquant.
  • Pollution de pool — injection d'un volontaire hostile dans pool.ntp.org ; contrée en choisissant des opérateurs connus et plusieurs sources indépendantes, pour que la sélection écarte la mauvaise. L'authentification prouve qui répond, pas que l'heure est juste.
  • Détournement BGP contre du NTP public — une route détournée vers un serveur de temps public livre une heure contrôlée par l'attaquant ; la validation d'origine des routes (RPKI) réduit ce risque sans le supprimer, et le NTS rend les réponses falsifiées détectables.
  • Échec silencieux en stratum 16 — une source qui perd la synchronisation se signale non synchronisée (LI=3, strate 16 à l'affichage, souvent 0 dans le paquet) ; sans alerte, l'opérateur croit l'heure disciplinée alors qu'elle dérive librement.

5. Checklist NIS 2 NTP — 10 contrôles que nous recommandons

#ContrôlePreuve
1Au moins 4 sources temporelles amontFichier de configuration NTP avec 4+ lignes server ; document de justification.
2Sources dans au moins 2 systèmes autonomes (AS) distinctsExtraits whois / registres de routage associant IP et opérateurs.
3Au moins une source authentifiée (NTS ou clé symétrique)Configuration active + procédure de gestion des clés.
4Hiérarchie de strates documentéeSchéma d'architecture : Stratum 1 → Stratum 2 interne → clients.
5Supervision de l'offset, du jitter, du reachTableau de bord 90 jours (Prometheus/Grafana, Zabbix, Datadog).
6Alerte sur stratum ≥ 16 et false-tickerExport des règles d'alerte + historique des alertes passées.
7Playbook d'incident pour défaillance de source temporelleRunbook documenté avec RACI et escalade.
8Rétention des logs (nous recommandons 13 mois)Politique de gestion des logs. NIS 2 ne fixe aucune durée de conservation ; le rapport final de l'art. 23 est dû un mois après la notification de l'incident.
9Traçabilité des changements de configuration NTPTrace ticketing pour chaque modification ntp.conf / chrony.conf.
10Audit périodique contre cette checklistRapport d'audit interne annuel signé par le RSSI ou le DPO.

6. Pourquoi NTS (RFC 8915) est la réponse proportionnée

L'article 21(1) exige que les mesures soient proportionnées au risque. En 2026, NTS (Network Time Security, RFC 8915) est le seul mécanisme standardisé qui authentifie le NTP sans clé pré-partagée, donc utilisable avec des serveurs publics :

Les sources publiques NTS incluent Cloudflare, Netnod, NIST et le service NTS de RDEM. Pour les hiérarchies internes, chrony 4.x joue à la fois le rôle de client et de serveur NTS — un seul binaire couvre les deux rôles.

7. Dossier de preuves pour l'auditeur

Rassemblez ces artefacts dans un dossier unique avant l'audit :

  1. Schéma d'architecture (PDF ou export draw.io).
  2. ntp.conf / chrony.conf de chaque niveau de strate.
  3. Export 90 jours d'offset / jitter / reach par client. Pour les serveurs de temps eux-mêmes, un historique que l'auditeur vérifie sans vous croire sur parole : le rapport mensuel scellé de conformité NTP (Time Evidence) de RDEM Systems, mesuré de l'extérieur et scellé à son émission.
  4. Fichier des règles d'alerte et tickets d'incidents passés.
  5. Procédure de gestion des clés (rotation des certificats NTS : qui, quand, comment).
  6. Politique de rétention des logs et échantillon réel (13 mois en arrière).
  7. Journal des changements de configuration NTP.
  8. Revue annuelle signée des 10 contrôles ci-dessus.

Utilisez notre Checklist Audit NTP pour RSSI pour structurer la revue, et le validateur pour vérifier chaque source de temps publique à la demande.

Exemple concret issu du terrain : comment une dérive de 4,2 s sur 12 serveurs a été ramenée sous 50 ms — illustration directe des artefacts du dossier de preuves ci-dessus.

8. Mise en correspondance : NIS 2, ISO 27001, DORA, PCI-DSS

ExigenceNIS 2ISO 27001:2022DORAPCI-DSS v4.0
Horloges synchroniséesArt. 21(2)(b)A.8.17RTS (UE) 2024/1774, art. 12(2)(f)Req. 10.6
Source authentifiée (notre lecture)Art. 21(2)(h)A.8.17 (implicite)— (non précisé)Req. 10.6.3 (protection des paramètres ; aucune authentification exigée)
Supervision et alerteArt. 21(2)(b)A.8.16Art. 10Req. 10.4
Rétention journaux— (directive) ; 2024/2690 point 3.2.5 (période prédéfinie par l'entité)A.8.15RTS 2024/1774, art. 12(2)(a)Req. 10.5.1 (10.7 en v3.2.1)
Diversification supply-chainArt. 21(2)(d)A.5.19, A.5.21Art. 28Req. 12.8

Un même dossier de preuves, construit sur notre checklist, alimente la partie temporelle des quatre référentiels ; il ne vaut pas conformité. Voir : ISO 27001 Contrôle 8.17 · PCI-DSS Exigence 10.6 · Référentiel ANSSI / OIV. Pour les plateformes de négociation et entreprises d'investissement, l'obligation comparable est MiFID II — synchronisation des horloges (RTS 25).

Si produire et maintenir ce dossier en interne n'est pas réaliste, RDEM Systems le livre en service managé — l'audit de traçabilité vers UTC couvre la chaîne documentée vers UTC et la revue périodique.

Votre besoin n'est pas la conformité NIS 2 ? Utilisez l'outil adapté :

Questions fréquentes

La directive NIS 2 impose-t-elle explicitement le NTP ?

L'article 21 de la directive NIS 2 ne nomme pas le NTP. Il exige des « mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées » pour gérer les risques de cybersécurité. Le guide technique de mise en œuvre de l'ENISA recommande un NTP authentifié et plusieurs sources de temps : sans une heure synchronisée digne de confiance, les journaux d'audit, les chronologies d'incidents et les preuves forensiques se défendent mal.

Quelles entités NIS 2 sont concernées par la conformité NTP ?

NIS 2 couvre les secteurs de l'annexe I (secteurs hautement critiques : énergie, transports, banque, infrastructures des marchés financiers, santé, eau, infrastructures numériques, gestion des services TIC, administration publique, espace) et de l'annexe II (autres secteurs critiques : services postaux, gestion des déchets, produits chimiques, denrées alimentaires, fabrication, fournisseurs numériques, recherche). À l'annexe I, les grandes entités sont essentielles et les moyennes importantes (sous réserve des exceptions de l'art. 3(1)(b) à (g)) ; les entités de l'annexe II sont importantes. Nous recommandons de documenter comment l'infrastructure temporelle soutient les délais de 24 h / 72 h / un mois de l'article 23.

NTS est-il obligatoire sous NIS 2 ?

NTS (Network Time Security, RFC 8915) n'est pas explicitement imposé, mais c'est le seul mécanisme standardisé qui authentifie le NTP sans clé pré-partagée, donc utilisable avec des serveurs publics. Compte tenu des attaques documentées (KoD spoofing, MITM sur NTP public, détournement BGP d'un serveur de temps public), un auditeur peut contester un NTP non authentifié au titre de l'article 21(2)(d) — sécurité de la chaîne d'approvisionnement — et (h) — cryptographie ; le guide technique de mise en œuvre de l'ENISA recommande un NTP authentifié.

Quelles preuves un auditeur NIS 2 attend-il pour la synchronisation temporelle ?

Nous recommandons de préparer : (1) schéma d'architecture de la hiérarchie temporelle, (2) liste des sources amont avec strate et méthode d'authentification, (3) tableau de bord de supervision montrant offset/jitter/reach sur 90 jours, (4) règles d'alerte sur stratum-16 et false-ticker, (5) playbook d'incident pour défaillance de source temporelle, (6) une politique de conservation des logs documentée. NIS 2 ne fixe aucune durée (le rapport final de l'art. 23 est dû un mois après la notification de l'incident) ; 13 mois est notre recommandation, pas une exigence.

Comment NIS 2 s'articule-t-il avec ISO 27001 et DORA sur la synchronisation temporelle ?

ISO 27001:2022 (A.8.17) et DORA (règlement délégué (UE) 2024/1774, art. 12(2)(f)) exigent des horloges synchronisées. NIS 2 ajoute une obligation horizontale de gestion des risques (art. 21) et renforce les délais de notification d'incident (art. 23). Un même dossier de preuves, construit sur notre checklist, alimente la partie temporelle des trois référentiels — à condition que l'authentification, la redondance et la supervision soient documentées ; il ne vaut pas conformité.