Use cases

Backup proof-of-existence

Stamp every backup immediately after it completes. The token proves the restore point existed — in exactly this state — at this moment. No backup administrator can retroactively create or modify this proof.

When ransomware encrypts a system and the attacker claims to have corrupted the backups, or when an insider deletion is disputed, or when a legal hold requires proof that a backup predated an event — a CNX timestamp token is the independent witness. The backup software's own catalog timestamp can be modified by anyone with admin access. A CNX token cannot.

See the Integration guide for the post-job hook pattern for Veeam and cron-based backup tools.

Log sealing

For high-volume audit logs and SIEM archives, stamping every entry individually is impractical. The efficient pattern is Merkle root sealing: build a Merkle tree of the log entries for a period, then stamp only the root hash. One token covers thousands of entries. Any individual entry can be proven to be part of the sealed set without revealing the others — and any insertion, deletion, or modification invalidates the root.

A simpler variant: stamp the running hash of the log file at regular intervals. Each token proves the log was in this exact state at this time. Any modification between stamps is detectable on the next verification pass.

Both patterns create a tamper-evident chain across the full log archive — the forensic standard for SIEM evidence in regulatory examinations and legal proceedings.

Database export sealing

Stamp daily or monthly financial database exports at the moment of export. The token proves the snapshot existed in this state at this time — before any subsequent transactions, corrections, or adjustments were applied.

In a dispute about account balances, end-of-period positions, or regulatory reporting figures, a sealed database export is the independently verifiable snapshot. The export and its token together constitute a point-in-time record that neither party to the dispute controls.

Git and release sealing

Stamp commit hashes, release tarballs, and infrastructure state at the moment of publication. The token proves the code or configuration was in this exact state at this time.

Use cases: proving a software release predates a discovered vulnerability; proving infrastructure configuration was compliant at audit time; sealing Ansible playbooks, Terraform state, and Kubernetes manifests at deployment; creating an auditable trail of configuration changes independent of the version control system itself.

Version control systems record who changed what — but the timestamps in git are local clock values that can be set to any date. A CNX timestamp token is an independent external witness.

Evidence preservation

Timestamp incident response artifacts at the moment of collection. Disk images, memory dumps, malware samples, network packet captures, mailbox exports, log extracts — each stamped immediately on acquisition.

The token establishes the forensic chain of custody: this artifact was collected in exactly this state at this time, before any analysis, processing, or transfer. In legal proceedings or regulatory investigations, the integrity of digital evidence depends on proving it has not been modified since collection. A CNX timestamp token provides that proof independently — no party to the investigation controls the attestation.

For incident response teams: stamp first, analyse later. The timestamp token does not modify the artifact and takes seconds.

Document workflows and long-term validation

Timestamp signed PDFs and contracts at the moment of signing. The token embeds in the PDF signature structure (PAdES-T), proving the signature was applied during the certificate's validity period — so the document remains legally valid even after the signing certificate expires.

For documents that must remain valid for decades — real estate transactions, corporate filings, loan agreements, wills — the advanced pattern is PAdES-LTA (Long-Term Archive): a second timestamp token covers the first, creating a chain that extends validity through algorithm transitions. When SHA-256 is eventually deprecated, the LTA timestamp issued before that date preserves the document's evidential integrity.

See the How it works page for setup in Adobe Acrobat Pro and LibreOffice.

What the TSA is not for

• Real-time clock synchronisation — the TSA attests the time CNX received your request. It does not synchronise your servers' clocks. Use CNX Precision Time for clock synchronisation.
• Identity attestation — the TSA proves when, not who. Use digital signatures for identity.
• Encryption — the TSA provides integrity and timing proof. Use encryption for confidentiality.
• Access control — the TSA does not govern who can read records.