Zegel, from scratch

Section 1Welcome — and how to read this

This is a long document, and that is on purpose. Zegel sits on top of about a hundred years of work in mathematics, law, and computer science, and you do not need to learn all of it. You only need to learn the small slice of it that explains what Zegel does for you.

The companion document, "Zegel, explained", is shorter and assumes you are comfortable with computer terms. This one assumes nothing. If a word looks technical, it gets a small box like this one the first time it appears:

You can read this document in three ways:

• Front to back. About forty minutes of slow reading. You will end up understanding the whole picture.
• Skim, then revisit. Read the headings and the "Imagine" boxes (in red) first to get the shape of the idea. Then come back to whichever sections looked confusing.
• Pick a section. Each section can stand alone. The table of contents above is a real menu.

There is a short glossary at the end. Bookmark it. The first time you meet a new word, the meaning is in the text; the second time, it is in the glossary.

Section 2The problem in plain words

Imagine you run a small Dutch business. You are not a tech company. You make invoices, you keep customer records, you run payroll, you file tax returns, you sign supplier contracts. Every one of these activities produces a file — a Word document, a spreadsheet, a PDF, an XML form for the tax office.

All of those files live somewhere — your laptop, a server, a cloud drive. They sit there. Months pass. Then one day, somebody asks you a question that sounds simple but is hard to answer:

Read that sentence again. The hard word is prove. You can show the auditor a file. But how do you prove it is the same file? You could change one digit on the invoice ten minutes before the audit and they would never know. Worse — you might not even mean to change it. A staff member might "fix a typo" in March, and now the file on disk is no longer the file you actually sent.

For most small businesses, the honest answer is: I cannot prove it. The file looks the same. The date on the file looks right. But date stamps are easy to change, file contents are easy to change, and there is no third party that has been watching all this time who can vouch for what the file looked like back in March.

A new EU law, NIS2, says many small businesses now have to be able to answer that question — and answer it convincingly. (We will explain NIS2 in detail in Section 16; for now, just know it is the law that makes this matter.)

Big banks and software companies already solve this kind of problem with internal systems that cost millions of euros. Small businesses do not have that. They use cloud drives — Google Drive, Dropbox, Microsoft OneDrive — which are American services that can show you a file's "version history" but cannot really prove anything to a Dutch auditor under EU law. The audit trail is owned by the same company that owns the storage, which is a bit like asking the suspect to be his own witness.

That is the gap Zegel fills. Zegel is a free, open-source, EU-sovereign service that lets a small business seal every important file, automatically, in a way that an auditor months or years later can verify offline, with mathematical certainty.

The rest of this document is the slow walk through how that works.

Section 3What a "file" really is

Open the folder on your computer where you keep your invoices. You see a list of files: invoice-2024-001.pdf, invoice-2024-002.pdf, and so on. Each one has an icon, a name, a size, a date.

Underneath that friendly icon, the file is just a long sequence of numbers. That is all. Every file on every computer is, at heart, a string of small numbers — millions or billions of them — sitting next to each other in a particular order.

The numbers all look the same to the disk; what makes the difference between a Word document and a photo is the order of the numbers. Programs like Microsoft Word know how to read those numbers and show you a page; image viewers know how to read a different pattern of numbers and show you a picture.

Two important consequences of this:

• "Identical" has a precise meaning. Two files are identical if their bead sequences are exactly the same, number for number, in the same order. If a single bead changes — even by one — the file is no longer identical.
• "Tampering" also has a precise meaning. If anyone changes any bead, the file has been tampered with. It does not matter whether they changed the meaning ("€1,000" to "€10,000") or just a comma or even an invisible space. The bead sequence is different, so the file is different.

Computers are surprisingly good at noticing very small changes. Humans are surprisingly bad at it. Zegel exploits this gap.

Section 4Fingerprints (also called hashes)

Here is the first idea that does most of the heavy lifting in Zegel. It is genuinely clever, and once you see it you will see it everywhere in modern technology.

A file can have millions of beads. That is too many to compare quickly, and too many to send over the internet just to check whether two files match. We need a smaller summary.

A hash function is a recipe that takes any file, no matter how big, and squishes it down to a short fixed-length code. The code is usually 32 characters or 64 characters long. It looks something like this:

8a91 c7e2 4f01 9b3d 6c5e 7a82 d044 f1bb
e23c 9117 a850 d62f 04bc 71ee 9382 5c6a

That code has a name: it is called a hash or, in plainer English, a fingerprint.

What makes a fingerprint useful

A good hash function has four magic properties. They sound abstract on first reading; bear with me.

1. Same file in, same fingerprint out. Always. If you compute the fingerprint of a file today, then compute it again next year, you get exactly the same fingerprint — unless the file has changed.
2. Different file in, different fingerprint out. Even tiny changes — one extra space, a comma moved one place, a single byte flipped — produce a totally different fingerprint, not a slightly different one.
3. You cannot work backwards. Given a fingerprint, there is no clever shortcut for figuring out what file it came from. The only way is to try every possible file. There are more possible files than atoms in the universe, so that is not a real plan.
4. You cannot forge a collision. "Collision" is the word for two different files happening to produce the same fingerprint. With a good hash function, nobody on Earth can construct a pair of different files with matching fingerprints — not in a year, not in a billion years.

Hash functions are not magic; they are mathematics. But for practical purposes, those four properties hold rock-solid for the hash function Zegel uses. It is called BLAKE3.

Why this matters for you

Once you have a file's fingerprint, you have a tiny summary that you can send around easily, store cheaply, and check quickly. To prove a file is unchanged, you do not need the original file at all — you just need the fingerprint.

The plan, in one sentence:

"Take a fingerprint of every file when it is born, write the fingerprint somewhere unforgeable, and use that fingerprint later as proof of what the file used to be."

Most of the rest of this document is about that "unforgeable somewhere".

Section 5Signing — the digital wax seal

Fingerprints are useful, but not enough on their own. The problem is that anyone can compute a fingerprint of a file. Including the person who later wants to lie about what the file looked like back in March.

What we need is some way to say: "this fingerprint was computed on this date, by this agent (the Zegel program running on your computer), and nobody else could have produced this record." That extra layer is called a signature.

Forget what the word "signature" means on paper. In computers it means something quite different — and stronger. It is closer to a wax seal on a medieval letter than to a name scribbled at the bottom of a contract.

Two halves of a key

The trick is something called a key pair. When you set up Zegel for the first time, your computer generates two long random numbers, mathematically related to each other. They are:

• The private key — a number only your computer knows, kept secret on your machine. It is the wax-and- stamp combination, locked in a desk drawer only you can open.
• The public key — a number you can hand out freely, post on the internet, print on business cards. It is the recognition half: the fingerprint of your stamp.

The mathematical magic is this: anything you "sign" with your private key, anyone can verify with your public key. But nobody can forge a signature without the private key.

What "signing a fingerprint" actually does

When the Zegel agent on your computer signs a fingerprint, it runs the fingerprint and the private key through some mathematics, and out pops a long number called a signature.

The signature has three useful properties:

• Anyone can check it. Given the fingerprint, the signature, and your public key, anyone can run a quick check and the answer is either "yes, this signature was made by the holder of the matching private key" or "no, this is forged or corrupted".
• It is bound to that exact fingerprint. A signature for fingerprint A is useless on fingerprint B. You cannot lift a signature off one record and paste it onto another.
• Without the private key, nobody can produce it. Not your competitor, not a hacker, not the cloud provider, not a national intelligence agency.

The first signature scheme: Ed25519

Zegel uses a particular recipe for making signatures, called Ed25519. It is from 2011, has been studied intensively by every cryptographer on the planet, has never been broken, and is used by everything from your phone's secure boot to GitHub to most modern banking systems.

Why Ed25519? Because it is fast, the signatures are short, and the world has spent a decade trying to break it without success. That earned trust matters.

But — and this is the next section — there is a small storm coming on the horizon, and we need a backup plan.

Section 6Why we sign twice (post-quantum)

Every signature scheme is built on a piece of mathematics that today's computers are very bad at. Ed25519's security rests on a problem called the "elliptic-curve discrete logarithm problem". You do not need to know what that is. You only need to know two things about it:

1. Today's computers cannot solve it. Even all the supercomputers in the world, working together, would take longer than the age of the universe.
2. A future kind of computer might.

Quantum computers, briefly

There is a new and very strange family of machines being built, called quantum computers. They are not just "faster computers" — they work on completely different physical principles. Today, in 2026, the largest quantum computers are about the size of a car, kept colder than outer space, and can solve only tiny problems. They are research machines.

But: in around ten to twenty years, large enough quantum computers may be built to break Ed25519 and other signature schemes built on similar maths. Nobody knows the exact date. Some experts say the 2030s; some say after 2040; some say never. The honest answer is: we do not know.

Now, here is the painful part. The records you seal today need to remain provable for a long time. A Dutch tax audit can reach back seven years. An employment dispute can run twenty. A pension fund's records need to last sixty years. If any of those records is sealed only with Ed25519, and a quantum computer arrives in 2038, all of those signatures could be forged in 2038 — including ones made today. Your old "proof" becomes worthless retroactively.

This is not a theoretical worry. It has a name in the security industry: "harvest now, decrypt later". Smart adversaries are saving up encrypted messages today on the expectation of breaking them in twenty years.

The fix: a second, post-quantum signature

The cryptography community has been working on a solution for a decade. They needed signature schemes whose underlying maths is hard for quantum computers as well as classical ones. After a long competition run by an American institute called NIST, a winner was announced in 2024: a scheme called ML-DSA-65, formally standardised as FIPS 204.

Hybrid signing: belt and suspenders

Here is Zegel's actual choice. Every fingerprint gets signed twice — once with Ed25519, once with ML-DSA-65. Both signatures are saved.

The reasoning is straightforward. Imagine the worst case for each scheme:

• If Ed25519 is broken in 2040 by a quantum computer, the ML-DSA-65 signature is still good. The proof holds.
• If ML-DSA-65 turns out to have a hidden flaw and gets broken — entirely possible, since it is new — the Ed25519 signature is still good. The proof holds.
• Only if both are broken at the same time does the seal fail. That requires two completely independent cryptographic catastrophes happening at once, which is vanishingly unlikely.

This is called hybrid signing. Belt and suspenders. It costs a little more space (the second signature is bigger) and a little more time (signing twice instead of once), but it bought us decades of safety. Worth it.

Section 7A log, and why we need an outside witness

Step back. So far we have:

• A way to make a tiny fingerprint of any file (Section 4).
• A way to sign that fingerprint so it is bound to your agent and cannot be forged (Section 5).
• A second signature so it stays unbreakable for decades (Section 6).

That sounds like enough. But it is not. There is one weakness left. Here it is:

Nothing, so far. The signature only proves that whoever holds the private key signed it. It does not prove when they signed it. The wax seal is real; the date written next to it might be a lie.

To prove the when, we need an outside witness. Somebody independent who saw the seal happen, wrote it down in their own book, and would notice if you tried to slip in a back-dated record later.

That outside witness is called the log.

What a "log" is

A log is just a list of things that happened, written down in the order they happened. Not a Tolkien forest log. The same word we use in "captain's log" or "logbook" or "log file".

Examples of logs you already know:

• A diary, written one entry per day.
• A ship's logbook, every event noted in chronological order.
• A bank statement: deposits and withdrawals in time order.
• A doctor's notes about a patient's appointments.

The Zegel log is the same idea, just for sealed-file fingerprints. Every time anyone, anywhere, seals a file, the fingerprint plus its signatures lands in the log as a new entry, timestamped, in the order it arrived.

Who runs the log?

Whoever runs Zegel as a service. In the EU-sovereign deployment of Zegel, that is a Dutch foundation operating servers inside the Netherlands, governed under EU law. There is no single company in charge. Nobody has the power to silently rewrite the log — and the next section explains why that is true even in the technical sense, not just the legal one.

The log is a small organisation, but it has one critical job: when a sealed fingerprint arrives, the log records it, timestamps it, signs it, and gives back a small file called a receipt (we cover receipts in Section 10).

The log is the independent witness that solves the "when" problem.

Section 8How a log proves it cannot lie

A naïve log has an obvious weakness. What stops the people who run the log from secretly editing a past entry? Or quietly inserting a back-dated entry to do somebody a favour? Or, under pressure from a court order or a government, deleting an entry they would rather did not exist?

The honest answer for an ordinary database is: nothing stops them. A database is just a file on a hard drive. The people who run it can edit it. You have to trust them.

Zegel does not want you to have to trust the people who run the log. So Zegel uses a special kind of log, called a transparency log, with a property that sounds impossible at first:

The log can never silently rewrite, delete, or back-date a past entry. Any tampering is detectable by anyone watching, using only mathematics — not legal threats and not auditing the log's staff.

That is a strong claim. It deserves a careful explanation.

The idea: a public running fingerprint of the whole log

Imagine the log keeps not just the entries themselves, but also a single big fingerprint that summarises the entire log so far. Call that fingerprint the root.

Each new entry the log accepts is mixed into the root. So the root changes whenever a new entry is added — but it changes in a deterministic, mathematical way that anyone can re-compute.

Now here is the kicker. The root is published.

Every few minutes, the log writes its current root somewhere public — a simple website, a few mirror sites, an archive — so that anyone in the world can see what the root was at, say, 2 PM on Tuesday. This is sometimes called a checkpoint.

Why this prevents tampering

Suppose the people running the log try to silently change a past entry — maybe they want to make Tuesday's invoice fingerprint look like a different fingerprint than what was actually recorded.

To do that, they have to change the entry. But changing the entry changes the root. The new root will not match the checkpoint that was already published on Tuesday afternoon. Anyone who saved that Tuesday checkpoint can now pull out the log's records, recompute the root from scratch, and shout: "Hey! The root I saved on Tuesday says X, but your log now computes to Y. You changed something."

A transparency log is the clerk plus the weekly town crier plus the citizens with notebooks, all built into mathematics rather than into trust.

This is not new. It runs the modern web.

Transparency logs were invented by Google in 2013 to solve a very specific problem in web security (called Certificate Transparency — you do not need to know the details). They have been running continuously for over a decade, audited by universities and standards bodies, and have never been successfully tampered with.

Zegel uses the same proven design — described in an international standard called RFC 6962 — but applied to file fingerprints instead of website certificates. Same mathematics, same robustness, different audience.

Section 9The Merkle tree, gently

Last bit of mathematics, then we are done with the heavy concepts. This one has a name that sounds intimidating — Merkle tree — but the idea is delightful and easy.

We need a way to compute that "running summary fingerprint" we just talked about (the root) so that:

• The root depends on every entry in the log.
• Adding a new entry updates the root cheaply.
• You can prove a specific entry is in the log by sending only a few small numbers — not the entire log.

The trick was figured out in 1979 by a cryptographer named Ralph Merkle, and the construction is named after him.

The construction, slowly

Imagine you have a list of eight fingerprints, one for each sealed file. We will call them F1, F2, …, F8. These are the "leaves" of the tree.

Now do this:

1. Take the first two fingerprints, F1 and F2. Stick them together (literally — number after number) and run the combined string through the hash function. You get a new fingerprint. Call it F12.
2. Do the same for F3 and F4 → F34.
3. Same for F5 and F6 → F56. F7 and F8 → F78.
4. Now you have four fingerprints (F12, F34, F56, F78). Pair them up the same way: F12+F34 → F1234. F56+F78 → F5678.
5. Two fingerprints left. Pair them: F1234+F5678 → F12345678.
6. One fingerprint remaining. That is the root.

The whole thing forms an upside-down tree:

                       ROOT
                      ╱    ╲
                F1234        F5678
                ╱  ╲          ╱  ╲
              F12   F34     F56   F78
              ╱╲    ╱╲      ╱╲    ╱╲
             F1 F2 F3 F4   F5 F6 F7 F8

Every leaf is a sealed file's fingerprint. Every parent node is the fingerprint of its two children's fingerprints stuck together. The root summarises the whole list.

The two superpowers of this shape

Superpower 1: change anything, the root changes.

Suppose somebody tries to alter F4 — change one bead. F34 is now wrong, because F34 was computed from F3 and the old F4. F1234 is now wrong, because F1234 was computed from F12 and the old F34. And the root is wrong. The damage propagates all the way up. There is no way to alter a leaf without changing the root.

That is the property we needed for transparency.

Superpower 2: short proofs that any specific entry is in the log.

Suppose six months from now you want to prove that F4 — the fingerprint of your March invoice — is genuinely entry number four in the log. The log does not need to send you all eight fingerprints. It only needs to send you:

• F3 (so you can recompute F34).
• F12 (so you can then recompute F1234).
• F5678 (so you can then recompute the root).

Three fingerprints. From those three plus your own copy of F4, you can recompute the root yourself. If your computed root matches a checkpoint published by the log six months ago, you have just mathematically proved that F4 was in the log six months ago.

Three fingerprints, even for a log of eight entries. For a log of one billion entries, the proof grows to about thirty fingerprints. Always tiny. That is the magic.

Why this matters in practice

When the Zegel log accepts your sealed fingerprint, it does not just store it in some database. It folds it into the Merkle tree, computes a fresh root, signs that root, and gives you back the bits you need to prove inclusion six months later — without needing to talk to the log again.

That last bit is important. Audits often happen years after sealing. The log might be slow that day, or unreachable, or even gone. Your proof should still work. With Merkle proofs, it does.

Section 10The receipt — your portable proof

When the log finishes folding your fingerprint into its Merkle tree, it bundles up everything you would ever need to prove that fact later, and sends the bundle back to you. That bundle is called a receipt.

The receipt is a small file — a few kilobytes, maybe — that you save next to the original file. So if the original file is called invoice-2024-001.pdf, the receipt is called something like invoice-2024-001.pdf.zegel-receipt.json.

What is inside the receipt?

• The fingerprint (BLAKE3 hash) of the file. So whoever has the receipt can later recompute the fingerprint from the file itself and check they match.
• Both signatures — the Ed25519 one and the ML-DSA-65 one — that the agent put on the fingerprint.
• The position the entry was given in the log (e.g. "entry number 1,328,997").
• The Merkle inclusion proof: the thirty-or-so neighbour fingerprints needed to recompute the root.
• The log's own signed checkpoint (called a Signed Certificate Timestamp, or SCT) saying "I saw this fingerprint at this exact moment".
• The log's public key.

Together, those pieces are everything anybody could need to prove, offline, six months or six years from now, that this exact file existed at this exact moment, and has not been altered since.

The receipt is portable

You do not need to ask the log for permission later. You do not need an internet connection. You do not need Zegel's servers to be running. The receipt is self-contained.

Hand the file plus the receipt to anyone — a notary, an auditor, a court, a regulator — and they can verify it on a laptop with no network. The verifier they need is a free open-source program; we will look at it in Section 13.

Section 11The whole sealing flow, step by step

We finally have all the pieces. Let us put them together. What follows is everything that happens when the Zegel agent seals a single file. It happens in about half a second on your computer; we will walk through it in slow motion.

Step 0: idle

The Zegel agent sits quietly on your computer, watching a few folders you told it to watch (your invoice folder, your contracts folder, etc.). It uses negligible resources. You will not even notice it is there.

Step 1: a new file appears

You save a new invoice. The agent notices the new file. It opens the file (read-only — it never changes anything) and runs BLAKE3 over the contents. Out comes a fingerprint.

Step 2: classical signature

The agent runs the fingerprint through your private Ed25519 key. Out comes a signature. This binds the fingerprint to "the agent that holds this key" — which is your computer, which is you.

Step 3: post-quantum signature

The agent runs the same fingerprint through your private ML-DSA-65 key. Out comes a second signature. Belt and suspenders, as we discussed in Section 6.

Step 4: submission to the log

The agent now bundles the fingerprint plus both signatures into a small message and sends it over a secure HTTPS connection to the Zegel log.

Stop and notice what crosses the wire here. The file itself does not leave your computer. Only the fingerprint does. Even if the log is hacked, the contents of your invoice are not on the log's servers — they never were.

Step 5: inclusion in the Merkle tree

The log accepts the message, checks that the signatures are valid (so it does not just write any random nonsense), and folds the new fingerprint into its Merkle tree as a fresh leaf. A new root is computed.

Step 6: receipt

The log signs an SCT — its own promise, with its own private key, that it saw this fingerprint at this time — and bundles it with the inclusion proof and the new root into a receipt. The receipt comes back to your computer.

The agent saves the receipt next to the original file. The file is now sealed. The agent goes back to idle.

The whole process took less than a second, used a tiny amount of network traffic, and did not interfere with anything you were doing.

What you actually see on screen

Nothing, by default. Sealing is silent. If you open the Zegel agent's status window, you will see a quiet log of sealings done — typically a few hundred per day for a medium-sized business — and a tally. The interactive visualisation at zegel.org/demo.html is a slowed-down picture of all six steps, so you can watch them happen.

Section 12What you actually do, day to day

Almost nothing. That is the point. After installation, Zegel is invisible.

Setup, once

1. You install the Zegel agent on the laptop or server that holds the files. Twenty minutes, the first time.
2. You point it at the folders you want sealed. Most people pick: invoices, contracts, payroll, customer records.
3. It generates a fresh key pair — your private Ed25519 and ML-DSA-65 keys live on your machine, locked. The matching public keys are registered with the log.
4. You write the recovery phrase down on paper and put it in a drawer. The recovery phrase lets you regenerate your private keys if the laptop dies. (We will not cover key recovery in detail here; just know it is a thing and you should treat the phrase like a bank PIN.)

Every day after that

You make invoices, write contracts, run payroll, file tax forms — your normal work. The agent silently seals each new or modified file. You do not click anything.

If you change a file legitimately

Suppose you fix a typo in a contract three days later. That is a different file now (one bead changed → totally different fingerprint). The agent seals it again, as a fresh record. The log now contains two entries for that contract: the original, and the corrected version. Both seals are valid; both timestamps are honest. Six months later an auditor can see both, in order, with the times they happened.

This is exactly the right behaviour. Zegel does not stop you from changing files. It just makes the history undeniable.

If a file changes that should not have

Say a junior staff member accidentally edits an old invoice to "fix" a number. The file's fingerprint changes. The agent seals the modified version (because it is now a new file, as far as the agent is concerned). The original receipt — the one for the unmodified invoice — is still valid, and still proves what the original looked like. Six months later, when the audit happens, the auditor can show both versions and see exactly when the change happened.

In other words: Zegel does not prevent mistakes. It makes them impossible to hide. That is enough for NIS2.

Section 13What an auditor actually does

Six months after the fact, an auditor — a tax inspector, an internal compliance officer, an outside accountant — asks for proof of a specific file.

Here is what they do, step by step. It takes about ten seconds on a normal laptop.

1. You hand them the file (e.g. invoice-2024-001.pdf) and the matching receipt (invoice-2024-001.pdf.zegel-receipt.json) on a USB stick or as an email attachment.
2. They run a free program called the Zegel verifier on their laptop. They type zegel verify invoice-2024-001.pdf and press enter.
3. The verifier computes the BLAKE3 fingerprint of the current file on disk.
4. It compares the fresh fingerprint to the fingerprint stored in the receipt. If they match, the file is the same file that was sealed.
5. It checks both signatures (Ed25519 and ML-DSA-65) using your public keys. If they verify, the seal is genuine.
6. It walks the Merkle inclusion proof from the receipt up to the recorded root, and checks that the root in the receipt is one the log has actually published. If yes, the entry is genuinely in the log.
7. It prints a result: VERIFIED · sealed 2024-03-14 09:18:42 UTC or FAIL · content mismatch since seal.

That is the whole audit interaction. No interaction with you. No call to Zegel's servers. No subscription. Just a small free program and the two files.

What the auditor concludes

If the verifier says VERIFIED, the auditor has just learned three things, with mathematical certainty rather than your word for it:

1. The file you handed them is exactly the file that was sealed by the Zegel agent on your machine on 14 March 2024.
2. The seal was made by the agent that holds your private keys — i.e. by you or your authorised system.
3. The Zegel transparency log saw the seal happen at that moment and has not silently rewritten its history since.

If the verifier says FAIL, that is also information: the file has been changed since sealing. The auditor can usually look at the modification dates on disk, or ask for the original sealed receipt, and reconstruct what happened.

Either outcome is far better than today's normal answer of "I think it's the same file, can you just believe me?"

Section 14What Zegel is not

A list of things Zegel does not do. Each is an honest limit, not a hidden feature.

Zegel does not encrypt your files

Encryption means scrambling a file's contents so that only the holder of a key can read them. Zegel does not do that. Your files stay in their normal form — readable by Word, Excel, your PDF reader, whatever you use. Zegel only fingerprints and signs; it does not lock.

If you also want encryption, that is a separate concern. Whole-disk encryption (BitLocker, FileVault) handles it cheaply for laptops; tools like Cryptomator or VeraCrypt handle individual files.

Zegel does not back up your files

A backup is a second copy of the file in a different location. If your laptop is stolen or the hard drive dies, the file itself is gone — and Zegel cannot bring it back. The receipt without the file proves nothing.

You still need a backup strategy. Cloud drives, NAS boxes, or proper backup services all work fine. (And, since backups also need integrity, Zegel can seal those too.)

Zegel does not prove a file is correct

If you sign a fraudulent invoice, Zegel will happily seal the fraudulent invoice. The seal proves the document is unchanged since 14 March; it does not prove the document is truthful, legal, or complete. Zegel is a witness, not a judge.

Zegel does not stop deletion

Anyone with access to your computer can delete a file. The receipt, on its own, does not let you recover the file — the receipt is just the seal, not the document. Again, this is a backup problem, not a sealing problem.

Zegel is not a magic compliance pill

NIS2 has many requirements. File-integrity proof is a significant one of them, and Zegel is designed for that one. Other NIS2 requirements (incident reporting, network monitoring, supplier due diligence, etc.) need other tools. The architecture document is honest about this.

Zegel does not talk to your bank or the tax office

The log is independent. It does not file your tax return for you, does not notify your bank when you sign a contract, and does not pre-warn the auditor that you exist. It quietly keeps a witness record. The rest of the world only finds out about it when somebody chooses to verify a receipt.

Section 15Why "EU-sovereign" matters

Zegel describes itself as EU-sovereign. That is a piece of jargon worth unpacking, because it is a real decision and not marketing copy.

What it means

"EU-sovereign" means three concrete things:

1. Operated in the EU. The Zegel log servers run on infrastructure physically located in the European Union, owned by EU companies and EU non-profits.
2. Governed under EU law. The organisation running the service is an EU legal entity, subject to GDPR, NIS2, EU contract law, and EU courts.
3. Free of US-extraterritorial reach. No part of the system is owned, operated, or financially controlled by a US company. This matters because of a US law called the CLOUD Act, which gives US authorities the power to compel US companies to hand over data — even data stored on EU servers, even data belonging to EU citizens. A truly EU-sovereign service is outside CLOUD Act reach.

Why this matters for the audit

For NIS2 and similar EU regulations, an auditor often has to ask: "Where does the evidence live? Whose laws govern it?" If the answer is "Amazon S3 in Virginia", that is legally messy. If the answer is "an EU non-profit operating out of Amsterdam", that is clean.

Many small Dutch businesses today seal nothing, but if they do try to keep "version history" or "audit logs", those often live on an American cloud service, which complicates the legal story unnecessarily. Zegel removes the complication.

What this does NOT mean

EU-sovereign is not the same as "secret" or "isolated from the world". The Zegel log is publicly readable; anyone in the world can audit it. The cryptography is internationally standardised. The code is open source. EU-sovereign just means the operating organisation is anchored in EU jurisdiction.

Section 16NIS2, the law behind all this

We have mentioned NIS2 several times. Time to explain it properly.

What it is

NIS2 — full name "Network and Information Security Directive 2" — is an EU law that came into effect across the Union in late 2024. Each member state, including the Netherlands, has now translated it into national law (in Dutch: the Cyberbeveiligingswet, or CBW).

NIS2 says: many businesses, not just big ones, must take cybersecurity seriously and prove they are doing so.

Who it applies to

Roughly: any organisation in a list of "important" or "essential" sectors with at least 50 employees or €10 million in turnover. Sectors include energy, transport, banking, health, drinking water, digital infrastructure, public administration, postal services, waste management, food production, manufacturing of critical products, digital providers, and research.

But — and this is the bit small businesses miss — even small suppliers to those sectors fall under NIS2 indirectly, because the directly-regulated entities have to do "supplier due diligence". So if you are a 5-person IT firm that builds software for a hospital, your hospital customer is now legally required to ask you for evidence of your security practices, or stop buying from you.

What it requires

NIS2 has many sections, but the ones relevant to Zegel boil down to:

• Detect, log, and prove. You must keep records of what happened on your systems, in a way that cannot be tampered with.
• Prove integrity of stored data. Where you process or store information that matters, you must be able to detect tampering and demonstrate to a regulator that you can do so.
• Show your evidence on demand. Within tight time limits (24 to 72 hours for incident reporting), and the evidence has to stand up to inspection.

Today, almost no Dutch SMB can do those three things for its everyday business documents. Zegel is the cheapest realistic way to fix that for documents specifically.

Penalties

NIS2 penalties are real. For "essential" entities, fines can reach €10 million or 2% of global turnover (whichever is higher). For "important" entities, €7 million or 1.4%. Personal liability for directors is explicitly written into the law.

Most small businesses will never see a fine like that, but they may well lose contracts because their customers (regulated entities) cannot keep doing business with them without integrity evidence. The risk is more often "you quietly stop being chosen" than "you get fined directly".

Section 17A complete worked example

Let us run a full, realistic story end to end. No hand- waving. We are going to seal a real-feeling invoice and then audit it six months later.

The setup

"Maaike's Bakery Wholesale BV", a small Dutch supplier to a hospital chain, has installed the Zegel agent on the laptop where invoices are produced. The agent is watching one folder: ~/Werk/Facturen. Maaike's keys were generated at install time and the public keys were registered with the Zegel log.

Day 1, 14 March 2024, 09:18

Maaike clicks "Save as PDF" on this month's invoice for the hospital. Word produces factuur-2024-03-14-ZH-OostNL.pdf, 287 KB. The agent notices it within a tenth of a second.

Sealing, in real numbers

1. The agent computes the BLAKE3 fingerprint of the file: a2 7f 1b … 4e 9c (32 bytes, written as 64 hex characters).
2. The agent signs the fingerprint with Maaike's private Ed25519 key. Result: 64 bytes of signature.
3. The agent signs the fingerprint with Maaike's private ML-DSA-65 key. Result: 3,309 bytes of post-quantum signature.
4. The agent posts a small JSON message to the log over HTTPS. Total size of the message: about 4 KB.
5. The log validates the signatures, accepts the entry, assigns it index 13,491,028, folds it into the Merkle tree, computes the new root, signs the SCT.
6. The log returns a receipt: about 5 KB. The agent saves it as factuur-2024-03-14-ZH-OostNL.pdf.zegel-receipt.json.

Total elapsed time: 0.42 seconds, mostly network round- trip. Maaike sees nothing. She is already on the next email.

Six months later, 18 September 2024

The hospital chain asks Maaike's for a complete record of March deliveries, in support of an internal NIS2 audit that has just been triggered by a regulator visit.

Maaike packs up the March folder — twenty-three PDFs and twenty-three matching receipts — onto a USB stick. Forty- six small files. She hands the stick to the hospital's auditor, Hans.

The audit, on Hans's laptop

Hans plugs in the stick. He has the Zegel verifier installed (free, takes thirty seconds to install). He runs:

zegel verify ./Maart-2024/*.pdf

For each of the twenty-three files, the verifier runs through the steps from Section 13. About four seconds later, Hans has twenty-three lines of output:

[OK] factuur-2024-03-14-ZH-OostNL.pdf
    sealed 2024-03-14 09:18:42 UTC · index 13,491,028
[OK] factuur-2024-03-15-ZH-OostNL.pdf
    sealed 2024-03-15 11:02:09 UTC · index 13,512,401
…
[OK] 23 files verified · 0 failures

Hans now knows, with mathematical certainty (not Maaike's word for it), that:

• Each invoice is unchanged since the moment it was sealed.
• Each invoice was sealed by the agent on Maaike's laptop on the date and time shown.
• The Zegel log saw all twenty-three sealings happen and has published checkpoints since that confirm none have been silently revised.

The audit interaction takes Hans about ninety seconds. No phone calls to Zegel's servers, no sign-up, no subscription, no fees.

The "what if" branch

Suppose, instead, that one of Maaike's old invoices had been "tidied up" by an intern in May — a corrected total, a different VAT number. The verifier would output:

[FAIL] factuur-2024-03-22-ZH-OostNL.pdf
    content hash mismatch since seal
    sealed fingerprint: a2 7f 1b … 4e 9c
    current fingerprint: b5 03 91 … 7d 11

Hans would now know the file had been altered after sealing. From there, the conversation goes elsewhere — he and Maaike work out what happened. But the fact of the alteration is not in dispute, and the original sealed version of the invoice is still recoverable from the log entry's metadata.

Compare this to the world without Zegel, where Hans could not have spotted the change at all, and Maaike might not have noticed the intern's edit until much later. NIS2's actual goal is precisely to make alterations visible.

Section 18Glossary

Every word introduced in this document, in alphabetical order, with its plainest definition.

Agent

The small Zegel program running on your computer that watches folders and seals new files automatically.

BLAKE3

The specific hash function (fingerprint recipe) Zegel uses. Modern, fast, free, designed in 2020.

Checkpoint

A periodic public announcement of the log's current Merkle root. Lets outsiders detect tampering.

CLOUD Act

A US law allowing US authorities to compel US companies to hand over data, even if stored abroad. The reason "EU-sovereign" matters.

Ed25519

The classical signature scheme Zegel uses. Decade-old, battle-tested, fast.

EU-sovereign

Operated in the EU, governed under EU law, free of US extraterritorial reach.

File

A long sequence of small numbers stored on a computer. Two files are "the same" only if the numbers match exactly.

Fingerprint / hash / digest

A short fixed-length code that uniquely summarises a file. Same file → same fingerprint, every time. Any change → totally different fingerprint.

Hash function

The recipe that turns a file into a fingerprint.

Hybrid signing

Signing each fingerprint twice — once with a classical scheme (Ed25519), once with a post-quantum scheme (ML-DSA-65) — so the seal survives if either scheme is ever broken.

Inclusion proof

A small bundle (about thirty fingerprints, even for a billion-entry log) that mathematically proves a specific entry is in the log.

Key pair (public and private)

Two related numbers. Private one stays on your computer, makes signatures. Public one is shared freely, used to verify signatures.

Log

An ordered list of records. In Zegel, the list of all sealed fingerprints in the order they arrived.

Merkle root

The single fingerprint at the top of the Merkle tree that summarises the whole log.

Merkle tree

A tree-shaped arrangement of fingerprints where every parent summarises its two children. Lets you prove "my entry is in this list" with a tiny slice.

ML-DSA-65 (FIPS 204)

The post-quantum signature scheme Zegel uses as its second signature. Standardised by NIST in 2024.

NIS2 (Cyberbeveiligingswet)

The 2024 EU law that requires many small and medium businesses to be able to prove the integrity of their records. The reason Zegel exists.

Post-quantum

Cryptography believed to remain secure even against future quantum computers.

Quantum computer

An experimental kind of computer based on different physical principles. Cannot be built large enough today to threaten cryptography, but might be in 10–30 years.

Receipt

The small file the log gives back after accepting a seal. Contains everything needed to verify the seal offline forever.

RFC 6962

The international standard describing the type of transparency log Zegel uses. Originally written for Certificate Transparency on the web in 2013.

SCT (Signed Certificate Timestamp)

The log's signed promise that it saw a particular fingerprint at a particular time.

Signature (digital)

A number produced by running a fingerprint through a private key. Verifiable by anyone with the matching public key, unforgeable without the private key.

Tamper-evident

The property that any alteration leaves a detectable trace. Different from "tamper-proof", which would mean "alteration is impossible". Zegel is tamper-evident, not tamper-proof.

Transparency log

A log built so that any tampering with past entries can be mathematically detected. The proven design Zegel uses for its witness role.

Verifier

The free open-source program an auditor runs to check a file against its receipt. Works offline.

Section 19Where to go next

You now know the whole shape of Zegel. Some next steps, depending on who you are:

If you run a small Dutch business

Read about NIS2 at digitaltrustcenter.nl to see whether you are in scope, directly or as a supplier. If you are, the cheapest first step is to seal your invoices, contracts, and payroll. The Zegel agent is free and runs on Windows, macOS, and Linux.

If you are an auditor

Read the architecture document (architecture.md) and the use-cases document (use-cases.md). Try the verifier on a few files of your own; the source is public, so you can audit the verifier itself. The longer technical companion to this document is "Zegel, explained".

If you are a developer

The repository is at github.com/HWqs/zegel. The cryptography lives in common/src/lib.rs; the agent in agent/; the log in ingest/; the verifier in verify/. End-to-end demo runs in CI on every push.

If you are simply curious

Open zegel.org/demo.html and walk through the live visualisation step by step. After reading this document, you will see exactly what each step is doing, and why.

Thank you for reading. If something here is confusing, that is a bug — please write to info@zegel.org and tell us what got muddled, so the next reader has it easier than you did.