The top of Hacker News today is a story about Apple's git still trusting certificates from eMudhra, a certificate authority that has been compromised. A thousand points, three hundred and seventy comments, and almost all of the argument is about cryptography: which root, which chain, which OCSP responder.
But the failure being described is not cryptographic. It is chronological.
A certificate was revoked. The revocation did not take effect everywhere. Somewhere between the decision and the enforcement there is a window — hours, days, months — during which the compromised credential is still trusted by software that has already been told it is not. That window is the entire incident. And the only way to know how wide it was is if somebody recorded the moment the decision was made and the moment it reached each verifier.
Nobody did. So the window is now being estimated from memory, in public, by strangers.
Two sentences, one of which is worth money
There is a version of this that applies to every company reading this, not just Apple:
"We rotated the root key."
"We rotated the root key on 2026-10-14 at 09:12 UTC, and here is a timestamp token from an independent authority that binds that hash to that minute."
The first sentence is a memory. It is probably true. It is worth nothing to anyone who does not already trust you — which is precisely the set of people who ask.
The second is an asset. It survives the departure of everyone who remembers it, the reorg that dissolves the team that did it, and the lawyer who asks, two years later, whether the control was operating in Q4.
Courts figured this out a long time before engineers did. The business-records exception to the hearsay rule turns on contemporaneity: a record made at or near the time, by someone with knowledge, in the regular course of business. Not "a record that says it happened." A record made then. The law has been pricing timestamps for a century. Most engineering organizations still keep their evidence in a Slack message.
Backdating is a crime in most jurisdictions for a reason: dates are the cheapest thing to fake and the most valuable thing to fake. Which means a date nobody else can verify is not evidence. It is a courtesy.
Your own clock is the weakest link
Ask a team to prove they rotated a credential and watch what they produce. It will be one of these:
- A Slack message. Editable by its author, timestamped by a platform the company administers, in a workspace where an admin can delete it and the audit trail of the deletion lives in the same account.
- A log line. Written by a host whose clock is set by NTP, in a timezone someone configured years ago, on a machine where root can rewrite both the log and the clock.
- A git commit. Whose author and committer dates are supplied by the person making the commit, via environment variables, and which git will happily set to any value you like.
- A ticket that was closed. Which records intent and completion, not effect.
None of these are lies. That is what makes them dangerous. They are claims that could have been manufactured by the person presenting them, which means a skeptical third party — auditor, acquirer, insurer, opposing counsel — has to treat them as if they were. The finding is not that people fabricate dates. It is that self-reported time is indistinguishable from fabricated time, and the cost of that ambiguity lands on you exactly when you can least afford it.
There is a second, quieter problem. Internal time is not even monotonic. Clocks drift, leap seconds happen, log pipelines reorder events, and a container that boots with the host's clock skewed will produce a perfectly consistent history of something that happened in the wrong order. You do not have a timeline. You have several, and they disagree.
Three mechanisms that actually bind content to a time
The good news is that this is a solved problem, and the solutions are old, boring, and mostly free.
1. A timestamp token (RFC 3161). You hash the artifact, send the hash to a Time Stamping Authority, and get back a signed token that says: this hash existed at this second. The TSA signs with a certificate whose only purpose is signing time. You can verify it offline, years later, without contacting anyone. FreeTSA exists; commercial TSAs cost less than a coffee per thousand stamps. This standard is older than most of the companies using it.
2. An append-only transparency log. Sigstore's Rekor, or Certificate Transparency if you are stamping certificates. You add an entry, you get back an inclusion proof, and the log's structure means an entry cannot be quietly removed — only contradicted, publicly, by a signed tree head. The property that matters is not cryptography. It is that other people hold copies.
3. Independent custody. A customs stamp. A courier scan. A bank statement. A notarized copy. A signed delivery receipt from a counterparty who has no incentive to help you look better. These are the best timestamp servers in existence, because their entire business model is being trusted by two parties who do not trust each other.
Notice what all three have in common: the time is asserted by someone who is not you.
The three-question test
Before you call anything "evidence," run it through this:
- Does anyone else hold a copy? If the only copy is in an account you control, it is a note to self.
- Could you change it without them noticing? If yes, it is a note to self with extra steps.
- Can you prove the date without asking me to trust you? If no, it is a note to self that will be read aloud in a meeting you are not in.
Three noes is the default state of most compliance evidence. It is also why compliance evidence so often fails to convince anyone who was not already convinced.
What to stamp, in one afternoon
You do not need to timestamp everything. You need to timestamp the things that will be asked about after an incident, when nobody remembers and everybody is defensive:
- Credential rotations — the exact minute the old key stopped working, not the day the ticket closed. The Apple case is what happens when these two are assumed to be the same event.
- Restore drills — start, end, and the size of the data-loss window. A drill without a duration is an anecdote.
- Access reviews — who was removed, and when the removal took effect at the system, not in the spreadsheet.
- Data exits — when data left the building, and to where. The exit is the date that matters, not the deletion.
- Policy changes — the published date and the enforcement date. Revocation that has not propagated is a policy, not a control.
The mechanics take an afternoon. Hash the artifact. Get a token or a log entry. Store the receipt somewhere that is not the same account, not the same cloud, and ideally not the same company. Write down where the receipt lives, because a receipt you cannot find is a receipt you never had.
The uncomfortable part
Timestamping cuts both ways, and everyone who has thought about it for more than a minute knows this.
The moment you can prove when you did something, you can also prove the gap between when you knew and when you acted. That gap is the thing every incident report is quietly about. It is why teams avoid timestamping, and why a company with no logs feels safer than one with good ones: it is not safer from failure, it is safer from discovery.
That trade is real, and I am not going to pretend otherwise. But it is a trade you make once, consciously, or you make it by default every time you let a claim stand in for a record. The default version is the one where you find out what your timeline was during the deposition.
What this layer actually holds
Every artifact in this series assumes a date. The exposure scan is a snapshot of an afternoon. The trust-anchor inventory is a claim about what is live right now. The drill card has a date field, and a filled card is only worth more than a blank one because of the handwriting and the date next to it. The drift layer says artifacts decay; the only way to measure a decay rate is to have two dated observations.
None of it survives if the date is your word.
Tomorrow: the witness layer. Who else holds a copy, why "we have it" and "someone else has it" differ by exactly one subpoena — and why the most durable backup in your company is probably an email you sent to a customer.
If you are sitting on a similar deadline right now — a rotation nobody can date, a restore drill with no duration, a policy change whose effective date is still being argued about — say so in the comments. We keep a one-page date-stamp register for exactly that situation, and I will send it over. No form, no email list.
Top comments (0)