Why we are building Time Evidence

Time Evidence is our continuous time-compliance evidence system. This is not a product sheet: it is a set of field notes, and the place where we tell the story of the project, how it has evolved, and how we got here.

The problem: a snapshot, where the auditor wants a film

When facing an auditor on time synchronization, most teams can only produce an ntpq screenshot taken on the day of the audit. That is a snapshot. It says nothing about the state of the estate the previous week, or over the past quarter.

As a result, three blind spots come back every time:

• No historical evidence: the auditor has to trust the self-declaration and sample by hand.
• No documented drift: nothing shows that a deviation was detected — neither when, nor for how long.
• No integrity guarantee: nothing proves the history was not rewritten after the fact.

Why a history is explicitly required

No serious framework settles for a clock that is "on time" on a given day. They all ask for consistency monitored over time:

• ISO/IEC 27001 — A.8.17: approved time source, active drift monitoring, correlatable logs.
• PCI-DSS 10.6 (v4.0, formerly 10.4 in v3.2.1): accepted UTC source, consistency and peering of time sources.
• NIS2, DORA: reliable logging and the ability to reconstruct incidents — which presupposes consistent, traceable timestamps over time.

What the auditor wants is the internal consistency of the estate — machines synchronized with each other, on an approved source, drift detected, logs correlatable. We detail these obligations on our UTC time traceability audit page and on the reference sheets ISO 27001 A.8.17 and PCI-DSS 10.6.

The technical choices (without giving it all away)

Time Evidence does not "redo" monitoring. It produces independent, time-stamped and method-qualified evidence of the consistency of a time infrastructure. A few decisions are already settled:

• An independent measurer, not a judge. RDEM is the instrument that measures, not a third party that self-certifies. Depending on the deployment mode, the measurement comes from external RDEM probes, from an appliance placed at the audited site, or from a lightweight agent (see the three modes below) — but in every case it does not rely on the server declaring itself on time.
• Chained integrity log, sealed reports. Each batch of measurements is written to an append-only log and signed (ed25519) by the collector agent, each entry chained to the previous one (prev_hash → chain_hash), together with the fingerprint of the generated report. Any later rewrite becomes detectable: that is what turns a chart into a piece of evidence. Since 17 July 2026, every issued report is also sealed: a detached OpenPGP signature, an RFC 3161 timestamp from external time-stamping authorities, and an OpenTimestamps proof anchored in the Bitcoin blockchain. A third party can therefore check, without taking our word for it, that the report has not changed since it was issued. Still to come: a PAdES signature embedded in the PDF itself (see project status below).
• IP-only principle. We need neither your machine names nor your inventory. We observe addresses and synchronization behaviour — not your topology. RDEM does not know your IT inventory.
• Heterogeneous anchors, not a single source. The reference is built from diversity and consensus: the measurement anchors mix third-party operators (Cloudflare, Google, Netnod, Microsoft, Apple) with our own authenticated NTS servers. RDEM also operates NTP servers (visible at ntppool.org/a/rdem-systems) and does not hide it: no anchor, ours included, is authoritative on its own.

Three measurement modes

Depending on who owns the instrument and where it runs, Time Evidence comes in three deployment modes. Technically, the appliance and the client agent share the same collector binary: the difference is where it runs and who owns it.

• External SaaS. Several RDEM probes, independent of the audited party, observe its NTP servers from distinct measurement points.
• Local appliance. An appliance deployed at the audited site measures the official NTP servers, checks itself against ≥ 5 heterogeneous public anchors and can count the NTP requests actually served to the estate.
• Lightweight client agent. A Go binary installed at the audited site runs periodic measurements (≈ 2 min), signs each batch (ed25519) and transmits it over TLS to the RDEM API for chaining, retention and evidence generation. The agent does not replace the NTP server and does not self-certify: it is a signed, identified and versioned collection point, whose measurements are qualified by the RDEM-TEM method.

A named and published method: RDEM-TEM-001

This is the most important change of recent weeks, and it says a lot about where the project is heading. Time Evidence no longer rests on "the way we happen to measure": it is built on a public methodological standard, RDEM-TEM-001 (current version: v1.5). Every report references the method and its SHA-256 fingerprint, the measurement engine (commit), the collector agent and its per-batch sealed version, the applied threshold policy (named and versioned) and the evidence appendices. That is what turns a pretty chart into a reproducible finding.

Why not wait for launch?

Because a product built for audits must be transparent about how it is designed. We chose to publicly document the reasons that led us to build Time Evidence, the technical choices made, and the lessons learned from running it on our own infrastructure — before opening it to the public. A tool that claims to produce evidence must itself be verifiable: this page is the first piece of it.

Where we stand today

The engine is already running — in production, on our own infrastructure, as drift monitoring of our internal NTP/NTS fleet. The collection and reporting API is live:

The living proof: the real-time state of our servers and their NTS certificates is already public on our NTS pool status page. Time Evidence adds, on top of that, long-term signed history, multi-probe correlation and audit-ready report generation.

What the engine measures today

These capabilities are in production on our own estate — this is what we exercise before opening the service:

• Cleartext NTP offset (UDP/123), the classic measurement.
• Authenticated NTP-over-NTS offset: the full Key Establishment (KE) → cookies → encrypted-and-authenticated request (AEAD) cycle, not just the TLS handshake. Validated in production against third-party sources — e.g. nts.netnod.se: sub-millisecond offset, stratum 1.
• Two distinct offset series per NTS target (cleartext + authenticated) — two measurements that cross-check each other.
• NTS-only servers handled properly. Servers that refuse cleartext NTP on port 123 (such as Netnod) are now monitored cleanly: NTP status "n/a" rather than "failed", offset obtained via authenticated NTS.
• Instrument health. Each probe reports its own clock state (chronyc/ntpq: offset, skew, dispersion, leap, sources), and since August how it sources its own time: authenticated NTS or cleartext NTP towards its own upstreams (chronyc authdata), not just from whom. The credibility of the measurement is part of the evidence.

What a report contains today

The report has changed a great deal since the first June version. It is no longer a simple "% compliant" banner: it is technical evidence, sealed and third-party verifiable. It is now organised around three axes kept separate:

• Time quality: measurements within tolerance, reported at the measurement level (not "per target"), with signed deviance (directional bias) and absolute deviance (magnitude).
• Instrument quality: the probe itself is qualified under RDEM-TEM-001 (§7) — a measurement from a degraded instrument does not carry the same weight as one from a healthy instrument.
• Evidence coverage: measurements expected vs received, adjusted for excused periods (declared maintenance), so as never to confuse "no data" with "out of tolerance".

To which are added:

• an executive summary per target: instrument verdict (reliable / degraded / unknown), compliance, and applied threshold (contractual threshold or 99% by default, with its source);
• a method & traceability block: RDEM-TEM-001 reference + its SHA-256, measurement engine, collector agent + version, applied policy, report fingerprint;
• responsibility attribution: an RDEM outage, an Internet cut, a stopped VM or a target drift are never mixed together — this is what separates an incident suffered from one attributable to the audited party;
• incidents preserved and qualified: the raw fact is immutable, the qualification is an append-only annotation ("declared by client, not verified"), with four confidence levels (immutable data / attribution / excused maintenance / client-justified);
• NTS certificate tracking (fingerprint, validity, rotations over the period);
• the list of deviations ≥ 25 ms and a metric definitions appendix;
• an estate appendix as a hashed CSV (SHA-256): the estate of NTP clients served by the appliance, i.e. consumption per client IP address, as proof of usage ("your equipment does use YOUR NTP servers"), together with its scope disclaimer.

Status honesty: since 17 July 2026, every report is sealed (detached OpenPGP signature, external RFC 3161 timestamp, OpenTimestamps proof anchored in Bitcoin) and third-party verifiable. We do not claim, for all that, that it is legally binding. Still to be delivered: a PAdES signature embedded in the PDF and the immutable correction table.

Project progress

This page is updated as the project reaches real milestones. No fictional roadmap: each entry is added the day it becomes true. This page will be updated regularly until launch to document the project's main steps.

• 30 September 2026 Public beta opens: Cloud Evidence (public NTP servers, no installation), Appliance (probe inside the client's network) and Appliance + NTP server (with a log of NTP clients) can be ordered on the Time Evidence page, with a real report issued during the beta, downloadable with its seals. Service free until 31 December 2026.
• 12 August 2026 The probe now says how it sources its time, not just from whom: its own upstream authentication is recorded (chronyc authdata: NTS or cleartext NTP). Instrument health now covers the quality of its own time chain.
• 5 August 2026 The NTS certificate rollover is marked, dated and bounded in the report, and computed per node: behind a single name (round-robin, anycast), each machine is tracked separately. The report also records the NTP version announced by each response.
• 4 August 2026 Upstream traceability: since 2 August, the probe records for each target the leap indicator, the root distance and the refid (the declared reference clock), over cleartext NTP as well as NTS. Since 4 August, these refids are resolved to an identity using the inventory maintained on ntp.rdem-systems.com. A reference loss announced by the target enters the report as a traceability fact, not as a non-compliance.
• 17 July 2026 Reports are sealed: detached OpenPGP signature, RFC 3161 timestamp from external time-stamping authorities, OpenTimestamps proof anchored in Bitcoin. The same day, the method reaches RDEM-TEM-001 v1.5, through successive versions published since 5 July: defensibility computed on raw data (§7bis), threat model and what the report does not establish. Earlier versions remain online.
• 5 July 2026 The report becomes a genuine audit tool: publication of the RDEM-TEM-001 v1.0 method standard (referenced, with its SHA-256, in every report), responsibility attribution (RDEM / Internet / VM / target never mixed) and incident qualification with four confidence levels (append-only annotations, "declared by client, not verified"), all manageable from the members portal. The positioning sharpens: from drift monitoring towards a continuous time-compliance evidence system.
• 3 July 2026 Added the estate appendix as a hashed CSV (SHA-256): the estate of NTP clients served and their real IPs, as proof of usage alongside the PDF.
• 2 July 2026 The collection and report-generation API goes into production (time-evidence.rdem-systems.com, integrated with the members portal). Authenticated NTP-over-NTS offset measurement (KE → cookies → AEAD cycle) brought online, validated against a third-party source (Netnod, stratum 1, sub-ms offset). Clean handling of NTS-only servers and the first version of the audit-ready report.
• 27 June 2026 Why this project exists: publication of these field notes and the first observation probes brought online on RDEM infrastructure.

What's next?

The next phase is no longer about building the client probe: the self-enrolled agent (Docker, pubkey-first identity, licence-gated) and the SaaS probe fleet already exist. It is about validating the evidence chain end-to-end at a first client, outside our own estate: this is under way, in testing at a higher-education institution. In time, Time Evidence will automatically generate historical evidence for PCI-DSS, ISO 27001, NIS2 and DORA audits. The product page is now online: Time Evidence.