EN FR Accueil

Checklist Audit NTP pour RSSI :
pourquoi « cocher la case » ne suffit plus

Les 7 cases à cocher NTP de vos audits ISO 27001, NIS 2, PCI-DSS et DORA — leurs raisons, leurs limites, et comment atteindre une vraie conformité temporelle

Par Richard DEMONGEOT | 19 février 2026 | Temps de lecture : 12 min
À qui s'adresse cette checklist ? RSSI, responsables sécurité, auditeurs IT, responsables conformité, et toute personne en charge de la conformité temporelle dans les environnements ISO 27001, NIS 2 (et la directive NIS originale), SOC 2, PCI-DSS v4.0 ou DORA.

Dans la plupart des audits de conformité (ISO 27001, NIS 2, SOC 2, PCI-DSS, DORA), la synchronisation horaire se résume à une poignée de cases à cocher. « Les horloges sont-elles synchronisées ? » L'auditeur coche, passe au point suivant.

Le problème : ces cases à cocher ont été conçues à une époque où le NTP était considéré comme un service d'infrastructure anodin. En 2026, c'est un vecteur d'attaque documenté, exploité dans des scénarios réels de compromission. Pourtant, la majorité des RSSI traitent encore le NTP comme un service « configuré et oublié » — un angle mort dans leur posture de conformité temporelle.

Cette checklist audit NTP décortique chaque case à cocher typique, explique pourquoi elle existe, révèle ses limites, et montre ce que les RSSI et auditeurs devraient réellement vérifier pour atteindre une vraie conformité temporelle — pas seulement une conformité de façade.

La thèse de cet article : NTP sans authentification (NTS) passe les audits mais laisse votre SI exposé. La conformité sur papier n'est pas la sécurité.

1. Ce que les référentiels exigent réellement

Avant de critiquer les cases à cocher, regardons ce que les normes disent vraiment sur la synchronisation horaire et la conformité temporelle. Le constat est frappant : aucune n'exige explicitement l'authentification des sources de temps. De la directive NIS originale à NIS 2, de PCI-DSS v3.2 à v4.0 — le fossé persiste.

Référentiel Exigence Ce qui manque
ISO 27001:2022
Contrôle A.8.17
« Les horloges de tous les systèmes doivent être synchronisées avec une source de temps de référence approuvée » Aucune mention d'authentification. « Approuvée » n'est pas défini.
NIS 2
Article 21
« Mesures techniques et organisationnelles appropriées et proportionnées pour gérer les risques » NTP n'est même pas mentionné. La synchronisation tombe dans les « mesures techniques » génériques.
SOC 2
CC6.1 / CC7.2
« L'entité autorise, modifie et supprime l'accès [...] les horloges doivent être fiables pour l'audit trail » « Fiable » n'implique pas « authentifié ». La fiabilité est auto-déclarée.
PCI-DSS v4.0
Exigence 10.6
« La technologie de synchronisation temporelle est déployée et maintenue à jour » Le référentiel le plus précis, mais n'exige toujours pas NTS. Mentionne seulement « sources fiables ».
DORA
Article 11
« Détection des anomalies [...] horodatage fiable des activités » Oriente finance/résilience. L'horodatage fiable est requis mais la méthode n'est pas spécifiee.
L'angle mort réglementaire
Tous ces référentiels exigent un temps « fiable » ou « synchronisé » — aucun ne définit comment vérifier que la source de temps n'est pas compromise. C'est comme exiger « une porte fermée » sans mentionner la serrure.

Résultat : les auditeurs cochent « NTP configuré = conforme » et passent au point suivant. L'infrastructure reste exposée aux attaques sur le protocole NTP lui-même.

2. Les 7 cases à cocher — anatomie critique

Voici les 7 vérifications NTP les plus courantes dans les audits. Pour chacune : pourquoi elle existe, ce qu'elle vérifie réellement, et ce qu'elle rate.

Case 1 : « Un service NTP est configuré »

Insuffisant

Pourquoi elle existe : S'assurer que les systèmes ne dépendent pas uniquement de leur horloge interne (RTC), qui dérive inévitablement.

Limite : Vérifier que ntpd ou chronyd tourne ne dit rien sur la qualité ni la sécurité de la source. Un serveur NTP peut être configuré vers pool.ntp.org en UDP sans authentification et passer cette case.
Ce qu'il faudrait vérifier : Le service tourne ET les sources sont authentifiées par NTS (Network Time Security).

Case 2 : « Plusieurs sources NTP configurées »

Insuffisant

Pourquoi elle existe : La redondance. Si une source tombe, les autres prennent le relais. L'algorithme NTP compare aussi les sources entre elles pour détecter les « false tickers ».

Limite : 4 sources chez le même fournisseur, dans le même datacenter, sur le même AS (système autonome) = fausse redondance. Une panne réseau ou une compromission du fournisseur affecte toutes les sources simultanément.
Ce qu'il faudrait vérifier : Diversité réelle — au minimum 2 fournisseurs distincts, sur des AS différents, idéalement dans des zones géographiques séparées.

Case 3 : « Le stratum est acceptable (1-3) »

Insuffisant

Pourquoi elle existe : Le stratum indique la distance par rapport à la référence atomique/GPS. Stratum 1 = directement connecté. Plus le chiffre est bas, plus la source est théoriquement fiable.

Limite : Le stratum est une valeur auto-déclarée par le serveur. Sans authentification, rien n'empêche un attaquant d'annoncer stratum 1 tout en servant un temps falsifié. Le stratum mesure la distance, pas l'intégrité.
Ce qu'il faudrait vérifier : Le stratum est bas ET la source est authentifiée. Seul NTS garantit que le serveur qui annonce stratum 2 est bien celui qu'il prétend être.

Case 4 : « L'offset est dans la tolérance acceptable »

Insuffisant

Pourquoi elle existe : Un offset (écart) faible prouve que l'horloge locale est bien synchronisée avec la référence. Typiquement < 100 ms pour la conformité, < 1 ms pour les environnements critiques.

Limite : L'offset est une photographie à l'instant T. Une attaque time shifting progressive (quelques millisecondes par heure) ne déclenchera aucune alerte mais décalera l'horloge de plusieurs secondes en quelques jours. Sans monitoring continu, l'offset « bon » du jour de l'audit ne garantit rien.
Ce qu'il faudrait vérifier : Monitoring continu de la dérive avec alertes. Historique de l'offset sur 30 jours minimum, pas seulement la valeur instantanée.

Pas le temps de gérer le monitoring NTP ? Nos équipes supervisent votre synchronisation 24/7.

Découvrir l'infogérance →

Case 5 : « Les règles firewall UDP/123 sont documentées »

Nécessaire

Pourquoi elle existe : Le port UDP 123 est un vecteur connu d'amplification DDoS. Les règles doivent limiter l'accès aux seules sources NTP autorisées pour éviter l'exploitation et le trafic non sollicité.

Limite : Cette case est nécessaire mais pas suffisante. Même avec un firewall strict, le trafic NTP autorise circule en clair. Un attaquant positionné entre le client et le serveur (MITM) peut modifier les paquets NTP sans que le firewall ne détecte quoi que ce soit.
Ce qu'il faudrait vérifier : Règles firewall strictes + authentification NTS. Le firewall protège le périmètre ; NTS protège le contenu.
!

Case 6 : « Les logs NTP sont conservés »

Insuffisant

Pourquoi elle existe : Les logs de synchronisation permettent de prouver à posteriori que les horloges étaient synchronisées au moment des événements audités. Essentiel pour la valeur probante forensique.

Limite : Des logs de synchronisation NTP non authentifié prouvent seulement que le système croyait être synchronisé. Si la source était compromise, les logs confirment la synchronisation... avec un temps falsifié. En forensique, c'est un argument à charge, pas à décharge.
Ce qu'il faudrait vérifier : Logs de synchronisation + preuve d'authentification NTS active. La commande chronyc authdata doit montrer Mode = NTS et NAK = 0 (aucun rejet).
!

Case 7 : « La documentation de la configuration NTP est à jour »

Nécessaire

Pourquoi elle existe : La traçabilité. Savoir quels serveurs NTP sont utilisés, qui les gère, et quand la configuration a été revue pour la dernière fois.

Limite : Un document bien rédigé qui décrit une configuration NTP non sécurisée reste... un document qui décrit une configuration non sécurisée. La documentation ne compense pas l'absence de mesures techniques.
Ce qu'il faudrait vérifier : La documentation mentionne explicitement si NTS est actif ou non, et pourquoi. L'absence de NTS doit être un choix documenté et justifié avec une analyse de risque, pas un oubli.

3. Le vrai niveau de risque selon votre posture

Toutes les infrastructures ne sont pas exposées de la même façon. Voici une échelle de risque selon votre situation actuelle :

Faible NTS actif + multi-fournisseurs + monitoring
Modéré NTP classique + multi-sources + firewall strict
Élevé NTP classique + source unique + pas de monitoring
Critique Pas de NTP ou NTP vers sources inconnues

La majorité des infrastructures auditées se situent dans la zone « Élevé » : NTP est configuré (la case est cochée), quelques sources sont définies, mais sans authentification ni supervision continue.

Les 3 attaques que « cocher la case » ne prévient pas

Attaque Mécanisme Impact business Bloquée par NTS ?
Time shifting (MITM) Modification des paquets NTP en transit pour décaler l'horloge de la cible Certificats TLS expirés acceptés, Kerberos/2FA cassé, fenêtres de trading faussées Oui
Replay (injection de temps passé) Rejeu d'anciens paquets NTP pour ramener l'horloge en arrière Revalidation de certificats révoqués, contournement d'expirations, fraude temporelle Oui
KoD spoofing Envoi de faux paquets Kiss-o'-Death pour forcer l'arrêt de la synchronisation Dérive progressive des horloges, désynchronisation des clusters, rupture de correlation SIEM Oui
Le paradoxe de l'audit NTP legacy
Un système NTP classique peut être parfaitement configuré, passer toutes les cases à cocher de l'audit, et rester vulnérable aux trois attaques ci-dessus. La conformité et la sécurité ne sont pas synonymes.

4. Le fossé conformité vs sécurité

Pour comprendre le problème, il faut visualiser le fossé entre ce que l'audit vérifie et ce dont l'infrastructure a besoin :

Ce que l'audit vérifie Ce que la sécurité exige
« NTP est-il configuré ? » Les sources de temps sont-elles authentifiées ?
« L'offset est-il acceptable ? » L'offset est-il surveillé en continu avec historique et alertes ?
« Plusieurs sources ? » Les sources sont-elles sur des AS, fournisseurs et géographies distincts ?
« Le firewall filtre UDP/123 ? » Le contenu des paquets NTP est-il intègre et non modifiable en transit ?
« Les logs sont conservés ? » Les logs prouvent-ils une synchronisation authentifiée, pas juste une synchronisation ?
Analogie pour les RSSI
L'audit NTP classique, c'est comme vérifier qu'une lettre est arrivée par la poste sans vérifier l'identité de l'expéditeur. Le courrier est là, le cachet de la poste est visible, mais rien ne prouve que c'est le bon expéditeur qui l'a envoyée.

NTS = le recommandé avec accuse de réception et pièce d'identité.

Pour tout RSSI gérant la conformité temporelle dans un environnement ISO 27001, NIS 2, PCI-DSS ou DORA, ce fossé représente un risque inacceptable pour l'intégrité des horodatages et les chaînes de preuve forensique. En savoir plus sur le fonctionnement technique de NTS.

Vous préparez un audit ISO 27001 ou NIS 2 ? Nous pouvons déployer NTS sur votre infrastructure avant l'audit.

Contactez-nous →

5. Matrice de décision pour l'auditeur

Si vous êtes RSSI, auditeur, responsable sécurité ou DSI, voici la grille d'évaluation que nous recommandons pour la partie NTP de vos audits de conformité temporelle :

Critère Non-conforme Conforme (minimum) Robuste (cible 2026)
Service NTP Absent ntpd/chronyd actif chronyd + NTS
Authentification Aucune Aucune (toléré) NTS actif (RFC 8915)
Sources 0-1 source 4+ sources 4+ NTS, 2+ fournisseurs
Diversité AS Non vérifiée 1 AS unique 2+ AS distincts
Monitoring Aucun Check ponctuel Continu + alertes
Forensique Pas de preuve Logs NTP basiques Logs NTS + authdata
Objectif 2026
Si votre infrastructure est dans la colonne « Conforme (minimum) », vous passez les audits aujourd'hui. Mais les référentiels évoluent, les attaques aussi. Viser la colonne « Robuste » maintenant, c'est anticiper les exigences de demain — et surtout, protéger réellement votre SI.

6. Plan d'action concret

Passer de « conforme sur papier » à « sécurisé en pratique » ne nécessite pas de révolution. Voici les étapes :

Étape 1 : Audit de l'existant (30 minutes)

Utilisez notre validateur NTP en ligne pour tester la réponse de vos serveurs. Vérifiez le stratum, l'offset et la joignabilité. Pour un diagnostic plus complet, notre outil de diagnostic NTP identifie les problèmes de daemon et de configuration.

Étape 2 : Activer NTS sur vos sources

Remplacez vos sources NTP classiques par des sources NTS authentifiées. RDEM Systems propose une infrastructure NTS sur 8 TLD et 3 datacenters — les détails de configuration sont disponibles sur notre page NTS dédiée.

Règle d'or : diversifiez vos sources
Quel que soit le fournisseur NTS que vous choisissez (y compris nous), ne mettez jamais tous vos œufs dans le même panier. Combinez au moins 2 fournisseurs NTS distincts pour éliminer tout point de défaillance unique.

Étape 3 : Mettre en place le monitoring

Supervisez en continu l'offset, le statut NTS et la joignabilité de chaque source. Configurez des alertes sur :

Étape 4 : Documenter pour l'audit

Mettez à jour votre documentation de sécurité pour refléter le passage à NTS. L'auditeur doit pouvoir vérifier :

Vous n'avez pas le temps de gérer tout ça ?

RDEM Systems prend en charge tout ou partie de votre infrastructure NTP/NTS : déploiement, monitoring 24/7, documentation audit-ready.

Découvrir nos services d'infogérance → Voir notre infrastructure NTS →

Besoin d'un devis ? ntp@rdem-systems.com

Le mot de la fin

Les cases à cocher NTP de vos audits ne sont pas inutiles. Elles posent les bonnes questions — « est-ce configuré ? », « est-ce redondant ? », « est-ce documenté ? ».

Le problème, c'est qu'elles ne posent pas la question essentielle :

« Pouvez-vous prouver que le temps que vous recevez n'a pas été falsifié ? »

Sans NTS, la réponse est non. En 2026, cette réponse n'est plus acceptable.

NTP sans NTS = conformité de façade.
NTP avec NTS = sécurité réelle.

Testez votre infrastructure maintenant : Validateur NTP | Diagnostic NTP | Infrastructure NTS