The evidence chain

A compliance record that its holder can quietly edit afterwards proves very little. If we asked you to accept that an incident was reported on 3 October, while only we can look inside the database, we would be asking you to take our word for it. A market surveillance authority, a customer or a notified body should not have to.

That is why CRA-Portal seals its log outside its own system every day. This page explains how that works, what does and does not leave our systems, and how you can check it yourself without taking anything from us on trust.

Step 1: every event gets a fingerprint

When an incident is reported, a document is uploaded or a notification is filed, the portal writes a line about it in a log that only ever grows. Lines are never changed or deleted; the database itself refuses that, not just the software.

For every line we compute a fingerprint: a 64-character number that follows entirely from the content of that line. Change one letter in a description, and the fingerprint is unrecognisably different.

Step 2: the lines are chained together

Each fingerprint is computed partly from the previous one. That forms a chain. Anyone who alters a line halfway through must recompute every fingerprint after it, or the chain visibly breaks.

That makes tampering visible to anyone who walks the chain, but it is not yet complete proof: in theory, whoever runs the database could recompute the whole chain. That is what step 3 is for.

Step 3: the log is sealed outside our system

Periodically we take all fingerprints since the previous seal and compress them into a single number, a Merkle root. That one number represents the entire series. We then send that number outside, along two independent routes.

A qualified timestamp (RFC 3161). An independent timestamping authority signs a statement that this number existed at this moment. Within the EU, such a timestamp is strong evidence under eIDAS. The flip side: you are trusting that one party.

An anchor in the Bitcoin blockchain (OpenTimestamps). The same number goes to the public OpenTimestamps calendar servers. They bundle thousands of such numbers worldwide into one number and place that in a Bitcoin transaction. Once it is in a block, it is fixed across tens of thousands of computers worldwide. Nobody can change it any more: not us, and no administrator with access to our systems.

The two cover each other’s weakness. The timestamp is immediate and legally strong within the EU; the Bitcoin anchor takes hours but requires no trust in any third party. That is why we use both, for every seal.

What does not leave our systems

Only that one number. No incident descriptions, no documents, no names, no company data. Without your own records the number is meaningless: nothing can be derived from it and nothing can be computed back out of it.

That is a deliberate choice, not a detail. Whatever ends up in a public chain can never be erased. Personal data and trade secrets therefore do not belong there, and with us they never get there. We pay no transaction fees and hold no cryptocurrency; we ride along on a bundle assembled by the calendar servers.

How to check it yourself

You do not have to take our word for anything. For every line in your record you can request a proof in the portal. It contains the line, a short computation path of fingerprints, and the reference to the seal.

1. Recompute the path. That is standard work under RFC 6962; it yields exactly the sealed number, or something else if anything was changed.
2. Verify the timestamp with ordinary tools, for example openssl ts -verify. You get OK or FAILED, using the certificate of the timestamping authority, not anything of ours.
3. Verify the Bitcoin anchor with the standard OpenTimestamps client, or look up the block with any block explorer.

If the computation path arrives at the number recorded in that block, your line demonstrably existed before that block. If something was changed afterwards, the path arrives at a different number and that shows immediately. None of these checks goes through us.

What this means for your record

• A date that holds up. For an incident report or a technical document, you can demonstrate that it already existed at that moment, in that form.
• Visible if changed afterwards. Anything altered after sealing is demonstrable, and cannot be hidden even by us.
• Without disclosing your data. The proof consists of numbers. You can demonstrate a single line without revealing the rest of your record.

Current status

The evidence chain has been running in production since 13 October 2026. The log is sealed daily, and confirmation from the Bitcoin blockchain is collected every four hours. The first anchors are recorded in Bitcoin block 971206. If a seal fails to appear, that is an incident that raises an alarm on our side; a chain that quietly stops is the only scenario that could undermine this system, and that is precisely what is monitored.

Want to know how we protect your data more generally? See Data security and confidentiality. Questions about the proof, or would you like to work through an example with your own advisers? Get in touch.