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 avant le 17 octobre 2024. Elle s'applique à deux catégories d'organisations :

  • Entités essentielles (annexe I) : énergie, transport, banque, infrastructures de marchés financiers, santé, eau potable, eaux usées, infrastructures numériques (DNS, TLD, cloud, datacenters, CDN, prestataires TIC), administration publique, espace.
  • Entités importantes (annexe II) : services postaux et de messagerie, déchets, fabrication (chimie, alimentation, dispositifs médicaux, informatique, électronique, machines, véhicules), fournisseurs numériques (places de marché, moteurs de recherche, réseaux sociaux), organismes de recherche.

Dans les deux catégories, l'article 21 impose une obligation de gestion des risques qui — lue en 2026 avec les guides techniques de l'ENISA — couvre de facto l'authentification et l'intégrité des sources temporelles. Un NTP non authentifié ne peut pas soutenir de manière crédible les obligations de traçabilité qui découlent de la directive.

2. L'article 21 et le temps : l'obligation implicite

L'article 21(2) énumère dix catégories de mesures que les entités essentielles et importantes doivent mettre en œuvre. Trois d'entre elles ancrent l'obligation NTP :

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 — admissible uniquement si les horodatages sont authentifiés et monotones.

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 ; mitigée par des sources amont authentifiées.
  • Détournement BGP contre du NTP public — l'incident Quintin Lin (2015) et la recherche ultérieure montrent que les manques RPKI affectent aussi les flux temporels critiques.
  • Échec silencieux en stratum 16 — une source qui perd la synchronisation reporte stratum 16 ; sans alerte, l'opérateur croit que le temps s'écoule alors qu'il est en réalité figé.

5. Checklist NIS 2 NTP — 10 contrôles

#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 sur 13 moisPolitique de gestion des logs ; rétention alignée sur le délai de rapport final (art. 23).
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 la seule couche d'authentification standardisée et prête pour la production :

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.
  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 ce Validateur de Conformité pour produire des preuves machine-lisibles à 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)(c)A.8.17Art. 11Req. 10.6
Source authentifiéeArt. 21(2)(e)A.8.17 (implicite)Art. 9(3)Req. 10.6.2
Supervision et alerteArt. 21(2)(g)A.8.16Art. 10Req. 10.4
Rétention journauxArt. 23A.8.15Art. 12Req. 10.7
Diversification supply-chainArt. 21(2)(d)(e)A.5.19, A.5.21Art. 28Req. 12.8

Un dossier unique de preuves satisfaisant la checklist NIS 2 ci-dessus couvre typiquement la portion temporelle des quatre référentiels simultanément. 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é. En 2026, les régulateurs et l'ENISA considèrent la synchronisation temporelle authentifiée comme une mesure de base : sans elle, les journaux d'audit, les chronologies d'incidents et les preuves forensiques ne sont pas défendables.

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

NIS 2 s'applique aux entités essentielles (énergie, transport, banque, santé, infrastructures numériques, administration publique) et aux entités importantes (services postaux, déchets, chimie, alimentation, fabrication, fournisseurs numériques, recherche). Toutes doivent documenter comment leur infrastructure temporelle soutient les obligations de notification d'incident sous les délais de 24h / 72h / 1 mois imposés par 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 moyen standardisé d'authentifier les sources temporelles NTP à grande échelle. Compte tenu des attaques documentées (KoD spoofing, MITM sur NTP public, pollution de pool), un auditeur considérera probablement le NTP non authentifié comme un risque disproportionné pour une entité essentielle au titre de l'article 21(2)(e) — sécurité de la chaîne d'approvisionnement.

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

Les auditeurs demandent typiquement : (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) rétention de 13 mois des logs NTP pour couvrir le délai du rapport final de l'article 23.

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

ISO 27001:2022 (A.8.17) et DORA (art. 11) exigent tous deux un horodatage fiable et synchronisé. NIS 2 ajoute une obligation horizontale de gestion des risques (art. 21) et renforce les délais de notification d'incident (art. 23). Une organisation qui cartographie une fois les preuves NTP peut typiquement satisfaire les trois référentiels avec un jeu de contrôles unique — à condition que l'authentification, la redondance et la supervision soient documentées.