Certificate validation without internet time (air-gapped)

Certificate validation without internet time in an air-gapped network means checking X.509 certificate validity periods, revocation data and signatures on encryption gateways against a clock you run locally, not against public time servers. Every validity check compares dates in the certificate with the gateway’s own clock, so how much you can trust that clock becomes part of your security design.

For OT and critical infrastructure operators moving site-to-site and edge-to-cloud links to post-quantum cryptography, this is easy to overlook. New algorithms change key sizes and handshakes. The question of “what time is it?” stays the same, and in an isolated network it is your problem to solve.

How do encryption gateways check certificate validity when there is no internet time source?

They use their local system clock as the “current time” input to RFC 5280 path validation. Without internet access, that clock has to be fed by a local reference such as a GNSS-disciplined server, a PTP grandmaster or a manually set real-time clock.

RFC 5280 (X.509 certificate path validation) takes the current date and time as an explicit input. For each certificate in the chain, the validator checks that this time falls between notBefore and notAfter. If revocation is checked with CRLs, the same clock decides whether a CRL is still current, by comparing it with the CRL’s nextUpdate field. Online status checking (OCSP) is usually not available in an air gap, so CRLs distributed by hand or through an internal repository are the norm.

None of this changes with post-quantum signatures. The IETF LAMPS working group’s specification describes the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The certificate profile, and with it the validity check, stays standard X.509.

Where the gateway gets its time

In practice, an isolated gateway’s clock comes from one of four places: an on-site NTPv4 server (RFC 5905) disciplined by a GNSS receiver, an IEEE 1588 Precision Time Protocol grandmaster already used for protection or metering, a battery-backed real-time clock (RTC) with no external discipline, or manual setting during maintenance visits. Only the first two give continuous correction. The last two drift, and an RTC whose battery has failed may boot with a default date years in the past.

What happens to a post-quantum IPsec or TLS tunnel when the gateway clock drifts?

Encryption already in progress keeps running, but the next authentication that involves a certificate can fail. Which way it fails depends on whether the clock is running ahead or behind.

The post-quantum key exchange itself (for example ML-KEM) does not use time at all. The time dependency sits in the authentication step: when an IKEv2 or TLS peer presents a certificate, the receiving gateway runs the RFC 5280 checks against its own clock. A failed check usually shows up as an authentication error at the next re-authentication or new connection. Existing security associations do not fail on their own.

Rekey frequency decides how quickly the problem becomes visible. With daily re-authentication, a time fault can sit unnoticed for hours. With handshakes every few minutes, it surfaces almost immediately. That is easier to diagnose, but it also means a bad time source can take down links across a site within minutes.

Should air-gapped OT sites use a local GPS-based NTP or PTP time source for certificate validation?

A local GNSS-disciplined reference is usually the most practical choice, provided it is treated as one input among several, with holdover and plausibility checks, and not as unquestioned truth. NTP accuracy is more than enough for certificate checks. PTP is only needed when process requirements already call for it.

Satellite timing is attractive because it needs no network connection to the outside world. Its weakness is well documented. EASA notes that, due to the extremely weak radio signal and lack of authentication mechanism, the system is prone to jamming and spoofing. Interference has also grown measurably:

• The number of global positioning system (GPS) signal loss events increased by 220% between 2021 and 2024 according to IATA’s data from the Global Aviation Data Management Flight Data eXchange (GADM FDX). (IATA via EASA, 2025)
• In Lithuania, recorded GNSS interference went from 556 cases in March 2024 to 890 in October 2024 and 1185 in January 2025. (Council of the European Union, document 9198/25, 22 May 2025)

Jesper Rasmussen, EASA Flight Standards Director, put it this way: “GNSS disruptions are evolving in terms of both frequency and complexity.” Aviation data does not map one-to-one onto a substation or pumping station. Still, the receivers on those sites listen to the same signals.

US guidance points in the same direction. CISA states that “increasing the security and resiliency of PNT functions is one of CISA’s top priorities”, and its acquisition guidance recommends that organisations adopt multiple PNT sources and employ high quality holdover. It also asks operators whether they have identified a holdover time for each time-reliant system and application. For certificate validation, that holdover time should be set against your certificate and CRL margins, which is covered below.

There is also a governance angle. IEC 62443-3-3 SR 2.11 (Timestamps) requires reliable timestamps for audit records, and at higher security levels its requirement enhancements cover internal time synchronisation and protection of time source integrity. Running one time architecture for both audit logs and certificate validation avoids two clocks that disagree during an incident review.

Practical safeguards for a GNSS reference

Configure the NTP layer to refuse large offsets instead of stepping silently. RFC 5905 defines a panic threshold for exactly this purpose. Use at least two independent references, for example a second receiver at another site reached over the protected inter-site link, so that NTP’s selection algorithm can reject an outlier. Make sure an alarm on “GNSS lost, running on holdover” reaches the people who operate the gateways, not only the people who look after the time server.

Can Network Time Security (NTS) protect time synchronisation in an isolated OT network?

Yes, for NTP client-server traffic. NTS authenticates the time server and protects the integrity of time packets, but it relies on TLS certificates itself, so you need an internal CA and a bootstrap plan. It does not cover PTP, and it cannot correct a reference that is wrong to begin with.

RFC 8915 defines NTS as two sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies. That design suits an isolated network well: no internet services are involved, and the server stays stateless.

The catch is circular. Validating the NTS-KE server’s TLS certificate requires a roughly correct clock, which is the very thing NTS is meant to deliver. RFC 8915 addresses the link explicitly: NTP time replies are expected to be consistent with the NTS-KE TLS certificate validity. In an air gap, the usual way out is to issue the NTS server certificate from an internal CA with a validity window wide enough to cover an RTC that has drifted or been reset, and to make sure gateways do not quietly fall back to unauthenticated NTP when NTS-KE fails.

For PTP, NTS is not yet a finished standard. An IETF draft extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4 to cover the Precision Time Protocol. Until that matures, PTP networks rely on IEEE 1588’s own optional security mechanisms and on network segmentation.

How should certificate lifetimes for ML-DSA gateway certificates be chosen when sites are offline for long periods?

Work backwards from operational reality. The certificate lifetime, and every CRL nextUpdate interval, must be longer than the longest period a site can go without renewal, plus a margin for clock error. Within that limit, shorter is better.

Internet guidance on short-lived certificates assumes automated renewal over a reachable network. An unmanned OT site that is visited twice a year cannot follow that model. If a CRL expires while the site is unreachable and revocation checking is mandatory, tunnels fail at the next authentication even though no certificate has been compromised.

A practical sizing method

Start with the maximum realistic offline interval, including delays such as a missed maintenance window. Add the renewal lead time, meaning how early you start replacing certificates before expiry. Add a clock-error margin that matches your holdover performance. Then backdate notBefore slightly so that a gateway whose clock is somewhat behind still accepts a freshly issued certificate. Apply the same calculation to CRL nextUpdate. Keep the CA hierarchy layered: long-lived offline roots, shorter-lived issuing CAs, and gateway certificates sized by the method above.

Two external factors shape these choices. The first is size. FIPS 204 lists ML-DSA-65 with a 1952-byte public key and a 3309-byte signature (NIST, 2024). Larger chains and CRLs affect handshake size and the effort of moving revocation data into an air gap by hand. The second is the migration timeline. Under NIST IR 8547, NIST will instead deprecate all quantum-vulnerable digital signature algorithms after 2030 and disallow their use under NIST standards after 2035 (NIST, 2026). Long-lived certificates that still depend on RSA or ECDSA, including the classical half of a composite, should not run past those dates.

How do these pieces fit together in an OT encryption architecture?

Treat time as shared infrastructure: one authenticated, monitored source per site, with holdover. Certificate and CRL lifetimes are then sized to how long that source can hold acceptable time and how long the site can stay unreachable.

Gateways built for isolated environments make this easier because they add no outside dependencies of their own. QPN, for example, sends no telemetry, has no cloud dependency and supports air-gapped networks as well as links over the public internet. QPN combines classical and ML-KEM post-quantum key agreement into one session key and renews both handshakes every two minutes. In designs like this, the time questions above are about the trust and authentication layer around the gateway, not about the confidentiality of the traffic itself.

The decisions that matter can be made before the first post-quantum tunnel goes live: where each site gets its time, what happens when GNSS is lost, how a gateway with a reset clock is brought back, and how long the longest-isolated site can run before a certificate or CRL expires.