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.

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

Publié le 20 avril 2026 · Par Richard DEMONGEOT, RDEM Systems · 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élai	Artefact	Dépendance temporelle
24 heures	Alerte précoce	La détection d'« incident significatif » dépend de seuils de supervision temporalisés.
72 heures	Notification avec évaluation initiale	Corrélation de logs multi-services pour établir le périmètre.
1 mois	Rapport final	Chronologie 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ôle	Preuve
1	Au moins 4 sources temporelles amont	Fichier de configuration NTP avec 4+ lignes `server` ; document de justification.
2	Sources dans au moins 2 systèmes autonomes (AS) distincts	Extraits whois / registres de routage associant IP et opérateurs.
3	Au moins une source authentifiée (NTS ou clé symétrique)	Configuration active + procédure de gestion des clés.
4	Hiérarchie de strates documentée	Schéma d'architecture : Stratum 1 → Stratum 2 interne → clients.
5	Supervision de l'offset, du jitter, du reach	Tableau de bord 90 jours (Prometheus/Grafana, Zabbix, Datadog).
6	Alerte sur stratum ≥ 16 et false-ticker	Export des règles d'alerte + historique des alertes passées.
7	Playbook d'incident pour défaillance de source temporelle	Runbook documenté avec RACI et escalade.
8	Rétention des logs sur 13 mois	Politique de gestion des logs ; rétention alignée sur le délai de rapport final (art. 23).
9	Traçabilité des changements de configuration NTP	Trace ticketing pour chaque modification `ntp.conf` / `chrony.conf`.
10	Audit périodique contre cette checklist	Rapport 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 :

Bénéfices NTS alignés sur NIS 2. Authentification cryptographique de chaque paquet temporel (AEAD), absence de replay, pas de décalage MITM, configuration zéro pour les clients chrony 4.x ou ntpsec. L'effort de déploiement est typiquement d'une journée pour une petite infrastructure ; l'argument de proportionnalité est trivial à porter.

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 :

Schéma d'architecture (PDF ou export draw.io).
ntp.conf / chrony.conf de chaque niveau de strate.
Export 90 jours d'offset / jitter / reach par client.
Fichier des règles d'alerte et tickets d'incidents passés.
Procédure de gestion des clés (rotation des certificats NTS : qui, quand, comment).
Politique de rétention des logs et échantillon réel (13 mois en arrière).
Journal des changements de configuration NTP.
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

Exigence	NIS 2	ISO 27001:2022	DORA	PCI-DSS v4.0
Horloges synchronisées	Art. 21(2)(c)	A.8.17	Art. 11	Req. 10.6
Source authentifiée	Art. 21(2)(e)	A.8.17 (implicite)	Art. 9(3)	Req. 10.6.2
Supervision et alerte	Art. 21(2)(g)	A.8.16	Art. 10	Req. 10.4
Rétention journaux	Art. 23	A.8.15	Art. 12	Req. 10.7
Diversification supply-chain	Art. 21(2)(d)(e)	A.5.19, A.5.21	Art. 28	Req. 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.

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

Mesurer jitter, offset, latence → ntp-tester.eu
Diagnostiquer firewall / port 123 / démon NTP → check-ntp.net
Architecture de référence entreprise → ntp.rdem-systems.com