Qu'exige PCI-DSS v4.0 Exigence 10.6 pour NTP ?

L'Exigence 10.6 est l'obligation principale : « Les mécanismes de synchronisation horaire assurent des réglages temporels cohérents sur l'ensemble des systèmes ». Elle se décompose en trois sous-exigences : 10.6.1 impose la synchronisation des horloges système via une technologie dédiée ; 10.6.2 prescrit des serveurs de temps centraux désignés, restreint les sources autorisées à les mettre à jour, et exige que les systèmes internes ne reçoivent le temps que de ces serveurs désignés ; 10.6.3 exige que les paramètres et données de synchronisation soient protégés contre l'altération et que les changements soient tracés.

NTP est-il explicitement nommé dans PCI-DSS 10.6 ?

PCI-DSS v4.0 utilise l'expression « technologie de synchronisation horaire » plutôt que de nommer NTP. Les guides publiés par le PCI SSC et les analyses d'experts indiquent clairement que NTP (ou son équivalent Microsoft W32Time, configuré en mode NTP) est la réponse de fait ; aucun autre stack de synchronisation horaire de niveau production n'est utilisé couramment dans les environnements de données titulaires (CDE) audités. Les auditeurs acceptent universellement les preuves NTP/chrony pour 10.6.

Que signifie « source externe acceptée par l'industrie » dans 10.6.2 ?

10.6.2 exige que les serveurs de temps désignés « n'acceptent de mises à jour que de sources externes spécifiques et acceptées par l'industrie ». En 2026, l'ensemble accepté inclut typiquement : les instituts métrologiques nationaux (NIST, PTB, NPL, INRIM, OP, LNE), les serveurs Stratum 1 disciplinés par GNSS opérés par des prestataires d'infrastructure reconnus, les sources compatibles NTS (Cloudflare, Netnod). La sélection aléatoire dans le pool public NTP n'est pas considérée comme acceptée à ce sens — elle peut être utilisée en aval du serveur désigné, pas comme source primaire.

Comment protéger les paramètres de synchronisation au titre de 10.6.3 ?

Trois couches : (1) Système de fichiers — chrony.conf / ntp.conf appartenant à root, mode 0640 ou plus strict, jamais accessible en écriture au monde. (2) Gestion des changements — chaque modification ouvre un ticket avec relecture, historique conservé sur la fenêtre d'audit PCI. (3) Authentification du canal — NTS (RFC 8915) pour la source amont du serveur désigné, garantissant qu'un attaquant en chemin ne peut injecter une mise à jour falsifiée.

Quelles preuves un QSA attend-il pour 10.6 ?

Demandes typiques du QSA lors de l'évaluation sur site ou à distance : (1) schéma réseau montrant les serveurs de temps désignés et la frontière entre CDE et sources externes ; (2) configuration en production des serveurs désignés ; (3) configuration en production d'un échantillon de systèmes internes montrant qu'ils pointent uniquement sur les serveurs désignés ; (4) liste des sources externes approuvées avec justification ; (5) tickets de gestion des changements des douze derniers mois ; (6) échantillon de l'état de synchronisation NTP (chronyc tracking, w32tm /query /status) collecté pendant la fenêtre d'évaluation.

PCI-DSS NTP | Exigence 10.6 Synchronisation horaire

Publié le 12 mai 2026 · Par Richard DEMONGEOT, RDEM Systems · Audience : RSSI d'environnements de données titulaires (CDE) dans le périmètre, QSA, ISA préparant des évaluations PCI-DSS v4.0 / v4.0.1.

Sommaire

1. Périmètre : quand 10.6 s'applique-t-il au CDE ?
2. 10.6.1 — Technologie de synchronisation en service
3. 10.6.2 — Serveurs désignés et sources approuvées
4. 10.6.3 — Protection des paramètres et données
5. Topologie de référence pour un CDE conforme 10.6
6. Pièces de preuve pour l'évaluation QSA
7. v3.2.1 (10.4 historique) → v4.0 (10.6) — différences
8. Réutilisation inter-référentiels

1. Périmètre : quand 10.6 s'applique-t-il au CDE ?

L'Exigence 10 de PCI-DSS v4.0 — « Journaliser et superviser tous les accès aux composants système et aux données titulaires » — s'applique à chaque composant système de l'environnement de données titulaires (CDE). L'Exigence 10.6 est le sous-ensemble synchronisation horaire. Elle s'applique à :

Chaque système traitant, stockant ou transmettant des données de compte ;
Chaque service de sécurité supportant ces systèmes (collecte de logs, SIEM, IDS/IPS, pare-feux, hôtes de rebond) ;
Chaque système qu'un attaquant pourrait utiliser pour accéder aux systèmes dans le périmètre (postes d'administration, bastions) ;
Les serveurs de temps des prestataires de services connectés lorsqu'ils tombent dans le périmètre CDE évalué.

L'obligation principale se lit :

10.6 Les mécanismes de synchronisation horaire assurent des réglages temporels cohérents sur l'ensemble des systèmes.

La formule « réglages cohérents » est décisive : le QSA regarde les résultats, pas la technologie. Un CDE où tous les systèmes sont à ±50 ms d'une référence externe vérifiée passe ; un CDE qui fait tourner chrony mais avec un hôte à +180 s de dérive échoue — même si « NTP est configuré partout ».

2. 10.6.1 — Technologie de synchronisation en service

10.6.1 — Les horloges et le temps des systèmes sont synchronisés via une technologie de synchronisation horaire.

La réponse d'implémentation est quasi-systématiquement NTP, plus Windows W32Time configuré en client NTP (Type=NTP). Le QSA attend :

Le démon de synchronisation est installé et activé au démarrage sur chaque système dans le périmètre ;
Il synchronise activement — chronyc tracking ou w32tm /query /status retourne un stratum inférieur à 16 et une valeur reach non nulle ;
Si le démon est configuré mais que le système échoue à se synchroniser, c'est un constat — même si la configuration est correcte sur papier.

Commandes pratiques utilisées par le QSA. Linux : chronyc tracking, chronyc sources, timedatectl status. Windows : w32tm /query /status, w32tm /query /peers. ESXi : ntpq -p. Une sortie propre fait partie des preuves ; un « Last Successful Sync Time » périmé ne suffit pas.

3. 10.6.2 — Serveurs désignés et sources approuvées

10.6.2 — Les systèmes sont configurés sur l'heure correcte et cohérente comme suit : un ou plusieurs serveurs de temps désignés sont en service ; seuls le ou les serveurs centraux désignés reçoivent le temps de sources externes ; le temps reçu de sources externes est basé sur le Temps Atomique International (TAI) ou le Temps Universel Coordonné (UTC) ; les serveurs désignés n'acceptent de mises à jour que de sources externes spécifiques et acceptées par l'industrie ; lorsqu'il existe plusieurs serveurs désignés, ils sont en relation de peering entre eux pour maintenir l'exactitude horaire ; les systèmes internes ne reçoivent le temps que des serveurs centraux désignés.

Cette sous-exigence est dense. Six vérifications pour le QSA :

#	Vérification	Preuve
1	Un ou plusieurs serveurs de temps désignés existent	Schéma d'architecture + nom DNS/IP du serveur central.
2	Seuls les serveurs désignés reçoivent le temps externe	Règle firewall n'autorisant la sortie UDP/123 que depuis l'IP du serveur désigné ; `chrony.conf` sur tous les autres systèmes pointant en interne.
3	La source externe est TAI/UTC	Liste documentée des sources NTP amont ; toutes les sources standard qualifient (NTP transporte du TAI/UTC).
4	Uniquement des sources externes acceptées par l'industrie	Document liste approuvée ; typique : NIST, PTB, Cloudflare NTS, Netnod, INRIM, OP, LNE, ou un Stratum 1 GNSS opéré par un prestataire d'infrastructure réputé.
5	Plusieurs serveurs désignés en peering mutuel	chrony.conf avec directive `peer` (ou membres de pool configurés pour peering) ; démontré par `chronyc sources` qui montre des entrées peer.
6	Les systèmes internes ne reçoivent que des serveurs désignés	chrony.conf / configuration w32tm sur un échantillon d'hôtes internes ; chacun liste uniquement les serveurs désignés, pas de sources publiques.

Ce que « source externe acceptée par l'industrie » signifie en pratique

Le PCI SSC n'a pas publié de liste exhaustive. La convention appliquée par les QSA en 2026 :

Accepté (typique). Instituts métrologiques nationaux (NIST, PTB, NPL, INRIM, OP, LNE pour la France), serveurs Stratum 1 opérés par Cloudflare / Google / Netnod / Apple / un hébergeur réputé, sources NTS-capables (RFC 8915), membres du pool utilisés en aval d'un serveur désigné.

Non accepté (constats fréquents). Membres aléatoires de pool.ntp.org comme source directe du serveur désigné (pas d'authentification, pas de SLA, pas d'audit) ; routeurs ISP grand public ; IP de métadonnées AWS 169.254.169.123 sans documentation liant l'origine TAI/UTC ; serveurs dont l'opérateur ne peut être identifié.

4. 10.6.3 — Protection des paramètres et données

10.6.3 — Les paramètres et données de synchronisation horaire sont protégés.

Sous-exigence courte mais qui se déclenche à trois niveaux :

Système de fichiers. chrony.conf ou ntp.conf appartenant à root, mode 0640 ou plus strict, situé hors de tout partage lisible par le monde. Sur Windows, les clés de registre W32Time protégées par l'ACL par défaut plus l'application par stratégie de groupe.
Gestion des changements. Chaque modification de configuration ouverte par ticket, relue, historique conservé sur au moins la fenêtre d'évaluation (typiquement 12 mois).
Authentification du canal. Le canal amont du serveur désigné doit résister à l'altération. En 2026, NTS (RFC 8915) est la seule réponse standardisée ; les clés symétriques sont acceptées si la rotation et le stockage sont documentés (ce dernier point échoue souvent en 10.6.3 — clés en clair dans le dépôt de configuration : constat classique).

5. Topologie de référence pour un CDE conforme 10.6

La forme que la plupart des QSA jugent immédiatement défendable :

           ┌─────────────────────────────────────────┐
           │  Externe (sources acceptées par l'industrie) │
           │  ───────────────────────────────────────  │
           │  • NIST time.nist.gov     (UDP 123)         │
           │  • Cloudflare NTS         (UDP 4460 NTS)    │
           │  • Netnod NTS             (UDP 4460 NTS)    │
           │  • Stratum 1 GNSS         (UDP 123)         │
           └─────────────────┬───────────────────────┘
                             │ Sortie UDP 123 / 4460 restreinte
                             │ aux serveurs désignés seulement (FW)
                             ▼
           ┌─────────────────────────────────────────┐
           │  Serveurs de temps centraux désignés      │
           │  ───────────────────────────────────────  │
           │  ntp-cde-a.internal  (chrony 4.x, NTS)    │
           │  ntp-cde-b.internal  (chrony 4.x, NTS)    │
           │  ── peering mutuel ──                     │
           └─────────────────┬───────────────────────┘
                             │ UDP 123 interne uniquement
                             │ vers ntp-cde-a/b
                             ▼
           ┌─────────────────────────────────────────┐
           │  Systèmes dans le périmètre CDE           │
           │  ───────────────────────────────────────  │
           │  Apps paiement · BDD · Pare-feux · SIEM   │
           │  Bastions · IDS · Authentification        │
           └─────────────────────────────────────────┘

Deux serveurs désignés (10.6.2 exige le pluriel), en peering mutuel, alimentés uniquement par des sources externes acceptées par l'industrie, avec un cloisonnement firewall strict entre couches.

6. Pièces de preuve pour l'évaluation QSA

À rassembler dans pci-dss/req-10.6/ avant l'évaluation :

Schéma. La topologie à trois niveaux ci-dessus avec hostnames et IPs réels.
Config des serveurs désignés. chrony.conf des deux serveurs désignés, anonymisée.
Échantillon interne. chrony.conf / export W32Time d'un échantillon représentatif de systèmes dans le périmètre (bases de données, serveurs applicatifs, pare-feux, bastions).
Règles firewall. Export des règles de sortie restreignant UDP/123 et UDP/4460 (NTS) aux serveurs désignés uniquement.
Document sources approuvées. Une page listant chaque source amont et la justification « acceptée par l'industrie ».
État de synchronisation. Sortie de chronyc tracking et chronyc sources sur chaque serveur désigné, datée dans la fenêtre d'évaluation.
Preuve NTS. Si NTS est utilisé, preuve de validité des certificats et procédure de rotation.
Historique des changements. Export ticketing couvrant les changements de configuration NTP des 12 derniers mois.
Rapport de test. Sortie du Validateur NTP en ligne contre chaque source externe — stratum, offset, refID — collectée dans la fenêtre d'évaluation.

7. v3.2.1 (10.4 historique) → v4.0 (10.6) — différences

PCI-DSS v3.2.1 plaçait l'exigence de synchronisation horaire en 10.4 avec trois sous-exigences. v4.0 l'a renumérotée en 10.6 et a durci le texte :

Aspect	v3.2.1 (10.4)	v4.0 (10.6)
Numérotation	10.4 / 10.4.1 / 10.4.2 / 10.4.3	10.6 / 10.6.1 / 10.6.2 / 10.6.3
Restriction sources externes	Implicite	Explicite : « sources externes acceptées par l'industrie »
Peering	Implicite	Explicite : « les serveurs de temps sont en peering mutuel »
Protection des paramètres	Une sous-exigence	Deux angles distincts : ACL + gestion des changements
Date d'effet	—	v4.0 obligatoire le 31 mars 2025

Si votre dossier de preuves v3.2.1 est solide, la transition v4.0 est essentiellement un re-étiquetage plus une liste documentée « sources approuvées » et la vérification explicite du peering.

8. Réutilisation inter-référentiels

Un dossier de preuves conforme 10.6 ferme les exigences temporelles des grands référentiels sans artefact supplémentaire :

Exigence	PCI-DSS v4.0	ISO 27001:2022	NIS 2	DORA
Source désignée/approuvée	Req. 10.6.1, 10.6.2	A.8.17	Art. 21(2)(c)	Art. 11
Canal authentifié	Req. 10.6.2 (acceptée par l'industrie)	A.8.17 (implicite)	Art. 21(2)(e)	Art. 9(3)
Protection des paramètres	Req. 10.6.3	A.8.24 (gestion clés)	Art. 21(2)(h)	Art. 10
Rétention des journaux	Req. 10.7	A.8.15	Art. 23	Art. 12

Voir aussi : Référentiel ANSSI / OIV / loi REC pour le cadre français.

Valider vos serveurs désignés en 2 minutes

Testez chaque source amont de votre liste de sources approuvées. Le validateur capture stratum, offset, refID et joignabilité dual-stack — la sortie va directement dans le dossier QSA.

Lancer le validateur → Checklist d'audit complète

PCI-DSS NTP — Exigence 10.6Guide de conformité synchronisation horaire