PCI DSS requirement 10.4.3 asks to:

Examine systems configurations to verify that the time server(s) accept time updates from specific, industry-accepted external sources (to prevent a malicious individual from changing the clock)...

Why are only external time sources acceptable? If I restrict access to the internal time source then where is the danger? I need to use an internal time source. Can you suggest ideas for compensating controls for this requirement?

3 Answers 3


This is no different from other aspects of network and system configuration. PCI is mostly concerned with separation of duties, so the sysadmin is not also the dba and is not also the developer, and with auditability, so that changes are recorded and approved and implementation matches policy. So sites can run internal NTP servers. Demonstrate that there is a formal policy for their use, that they are under sufficient custody to be accurate and reliable, that changes to their config go through change management, and that the hosts in PCI space cant be made not to use the approved internal source.


If your internal NTP time server is using a GPS receiver the time sync from the GPS receiver is technically using a satellite as an external time-source which would be considered a valid external time source even though you aren't using an external NTP server.

Everything Johna B mentioned is also correct but there are also other ways to create compensating controls depending on the type of environment you have.

One compensating control for ensuring accurate time would be having an second system (not managed by the person who manages the time server) checking and logging the time from the different internal time server(s) at random time periods no less than every 60 seconds to ensure that the time-server(s) haven't been tampered with and to alert the staff if a change or drift in clocks occurs. This would ensure that the time from one of the internal time sources has not been tampered with and gives you something of an audit trail for the clock. Likewise recording all access to the time servers and ensuring they are properly secured, have external logging, and all other standard PCI controls will still need to be in place on these systems.

The PCI-DSS 3.2 10.4.1.a does specify that the clocks need to be in sync with International Atomic Time.

As always PCI is not a law and your QSA has the final say on approving your ROC.

Update: In addition to sebastian nielsen's recommendation below there are also a wide range of other timing solutions which could both be synced to International Atomic Time and also be 100% internal for quite a long time with very accurate time results. Many of the solutions sold by providers like this one could be used in a number of different ways:


  • 1
    No, 2 internal time servers would not be accepted as compensating control, as theres no means to be sure this stays in sync with external world time. See my answer. 10.4.3 is about ensuring the time servers stay sync with world/real time, not about separation of duties. Commented Aug 25, 2016 at 0:50
  • Stratum 1 time sources via gps satellites counts as the outside world even though the server would be considered internal and not receiving an externally networked data source. In theory a company could have four internal atomic time sources (HP used to sell these) as a compensating control. Still comes back to the QSA either way. Commented Aug 25, 2016 at 1:13
  • Thats what I said too. I interpreted your compensating control as having no external connectivety/sync at all, which would mean you had no way of knowing if the time was correct, unless as I said, you had some very accurate internal time source, that is once synced to a external source manually. But then, that time source could be sealed with tamper resistant seals. Commented Aug 25, 2016 at 2:33

The reason that you need to sync the timeserver to a external source, is just that, auditability. As others here have pointed out, a GPS receiver is a valid external source. Using a GPS receiver or a time radio source is in fact, a preferred way to managed time servers in air-gapped scenarios, as this means no sensitive data can leak out from the air-gapped area, and no malicious data can leak into the air-gapped area.

Yes, a malicious adversiary might be able to modify the time inside the air-gapped area by sending false GPS or radio signals, but nothing more.

It does NOT say that you need to let time server connections out from the PCI DSS boundary, it just says you need to, in some way keep the clock in sync with world time.

The reason you cannot just "run your own, internal, air-gapped timeserver" with no means to receive anything from the outside at all, is because imagine a breach occurs. Then you cooperate with law enforcement, and the hacker is caught. Imagine then that all your logs are fully in sync internally, but your internal timeserver is 1 minute off from external time.

And now, the criminal have a aliby, lets say the hacker was, according to official records, detained by the police for suspected drunk driving but then was found innocent, at the exact time the breach occured.

Now, your evidence is basically invalid, because it shows something that couldn't happen.

Thats why you need to sync your time server to a external source. Which external source is used, does not matter, as long as its "industry-accepted", eg a common way to sync timeservers, that will be sound from a law-enforcement perspective.

If you ABSOLUTELY must keep the PCI DSS area air-gapped for some reason, lets say inside a thick vault, you can provide time services anyways, by having a external time receiver (that receives signals from a GPS receiver or similiar), that will then output PPS (Pulse per second) via a laser that are pulsed into a small window* in the vault, and inside the vault, you have a receiver, that will sync the internal time server. (and thus, the internal time server will only step forward on laser pulse, and if external time server drift from world time, it will correct by sending faster or slower pulses)

*This window must also be made in a way so it does not compromise the security of the vault.

Note that you also need a means to initially sync the internal time server if you go on this route.

This has nothing to do with separation of duties. Separation of duties are required only if you handle such a amount of transactions that make this neccessary.

If a single-man company process credit card details, single-duty will be accepted, but only for a small amount of transactions, where the risk of corruption is low.

What Trey Blalock said about having 2 internal time servers logging each other, not managed by the same system admins, would not get accepted as compensating control, because you have no means to ensure this time is correctly in sync with world time. Yes, you could sync them from a external source manually, but that would mean the time server in the meantime, drift from world-time.

One compensating control would however be to have a OCXO (Oven compensated crystal oscillator) that is once synced to external time, before brought into the PCI DSS area. This OCXO could also be sealed with tamper-resistant seals.

But note that also a OCXO drift with time, and needs to be periodically checked and resynced.

  • I didn't say anything about 2 time servers I said 2 servers, one for time and second one for audit. Commented Aug 25, 2016 at 2:20
  • @TreyBlalock Yeah, but the second server would then effectively become a time server that is synced from the primary server, so it could log the differences. But still, that would do nothing to accuracy if you don't sync from a external source like GPS or radio transmitter or another time server. In other words, if your "audit server" logs a correction of -1 seconds, how do you know if the correction -1 sec was because the time server was off, or if the correction -1 sec is malicious. Thats the problem. Commented Aug 25, 2016 at 2:30
  • It explicitly cannot be synced otherwise the logs would NEVER differ. Commented Aug 25, 2016 at 2:32
  • @TreyBlalock eeh? The second server reads the primary server. When the primary server is off the secondary server, the secondary server will log this difference, and then sync itself to the primary server, so the secondary server could know if the primary server was later reset. By following the log on the secondary server, you would be able to find out exactly both what the time of the primary, and the time on the secondary server was, at any time. Commented Aug 25, 2016 at 2:36
  • Un-related clocks. No-syncing. Just auditing. You can audit all timeservers globally this way if you want. There are projects that do this. Commented Aug 25, 2016 at 2:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .