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 / 10.4: 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, per-batch signed (ed25519). 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. What remains to be delivered is the third-party-verifiable layer: PAdES signing of the PDF and an RFC 3161 timestamp (see project status below). We would rather say so than over-sell it.
• 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.
• Anchored on real infrastructure. The system relies on our authenticated NTS references and our GNSS Stratum 1 — not on an improvised root of trust.

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 observe the audited party's NTP servers from independent measurement points.
• Local appliance. An appliance deployed at the audited site measures the official NTP servers, checks itself against ≥ 5 independent 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 v1.0. 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 independent 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): 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 (a demonstrated fact, not yet legally binding — that comes with the signature). 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 exhaustive list of targets with their real IPs, as proof of usage ("your equipment does use YOUR NTP servers"), together with its scope disclaimer.

Status honesty: this version produces unsigned PDFs — technical evidence, not yet legally binding. PAdES signing of the PDF and the RFC 3161 timestamp (target summer 2026), together with the immutable correction table, are the building block that will make it third-party verifiable.

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.

• 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 exhaustive list of targets 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 now about validating the evidence chain end-to-end at a first client, outside our own estate. In time, Time Evidence will automatically generate historical evidence for PCI-DSS, ISO 27001, NIS2 and DORA audits. A full product page will be published when it opens to the public.