After eMudhra: a post-quantum PKI tree with your organisation at the root

On Saturday 17 October, a security researcher known only as Wayne sent a short message to Apple, Google, Microsoft, Mozilla and eMudhra: “We have a problem here.” It was signed eight times, once with each of eight private keys belonging to eMudhra, a certificate authority that every major browser trusted.

Nobody had broken in to get them. The keys had been worked out from eMudhra's own public certificates, on an ordinary laptop, in less than a second. One of them, as the researcher Scott Helme found, was the number 4.

The response was fast. Chrome was blocking the affected certificates in under two hours, and Firefox in under three. Apple and Microsoft followed within days, and the root certificate that signed them is on its way out of the major trust stores. As far as anyone can tell, no harm was done. Google found no sign in the public certificate logs that the keys had been used, and eMudhra says none of them had issued a certificate to anyone.

Still, it's worth asking how eight small numbers could have let someone impersonate any website on earth. The answer says a lot about how trust works on the internet, and about why your own network shouldn't work the same way.

What went wrong

eMudhra is one of the companies the web trusts to vouch for websites. In April 2025 it created a batch of new signing keys in a formal key ceremony, on certified hardware security modules. According to eMudhra, a flaw in that ceremony produced a second, weak set of keys alongside the real ones, and the weak keys ended up in eight certificates.

A real key of this kind is a random number more than a hundred digits long. These were all smaller than 256, so finding any one of them took 256 guesses at most. Anyone holding them could have issued certificates that browsers would accept for any website: your bank, your email, your company's sign-in page.

It's an easy mistake to make and a catastrophic one to miss. Why it was catastrophic comes down to how PKI works.

PKI in two minutes

PKI, or public key infrastructure, is how two strangers on the internet come to trust each other. It rests on key pairs. You keep a private key secret and share the public key that goes with it. Anyone with the public key can check something signed with the private key, but nobody can make that signature without the private key.

A certificate is a signed statement that a public key belongs to someone: “this key belongs to yourbank.example”. The signature comes from a certificate authority, or CA. A CA's root key is its most valuable key, so the CA locks it away offline and uses it only to sign a few intermediate keys. The intermediates do the everyday signing.

Your phone and your laptop ship with a list of root certificates they trust, called a trust store. When you visit a website, your browser follows its certificate up the chain, from the website to an intermediate to a root, checking each signature on the way. If the chain ends at a root in the trust store, the padlock appears.

The weakest link

Here's the catch. A trust store holds well over a hundred roots, run by organisations all over the world, and any one of them can vouch for any website. Your bank picked one CA, but your browser will accept a certificate for your bank from any of them. You didn't choose that list, and you're only as safe as its weakest member.

When a member fails, the fix is a scramble:

• Browser makers push out block lists.
• Operating systems ship updated trust stores.
• Websites with perfectly good certificates under the removed root have to replace them.

Anything that doesn't get updates, from an old app to the device on the factory floor, keeps trusting the bad keys until someone patches it.

That's not a criticism of anyone's engineering. It's the price of a system built to let anyone on earth check anyone else, and for the public web it's a fair trade. For the network your organisation runs on, it isn't. You don't need the whole world to be able to vouch for your machines. You need exactly one party to: you.

And then there's quantum

eMudhra's keys were weak by accident. A large enough quantum computer would make every key like them weak. The algorithms behind today's certificates, eMudhra's included, are exactly the kind a quantum computer is expected to break, by working out a private key from its public key. That's why NIST published ML-DSA, a post-quantum signature standard, in 2024, and why it has proposed retiring today's algorithms from 2030.

Moving the whole web to post-quantum certificates will take years. Your own network doesn't have to wait.

A PKI tree of your own

A private PKI turns the model around. Instead of borrowing the web's trust store, your organisation runs its own root, and only machines it has vouched for get in. Nobody else's key counts, so a CA failing somewhere else on the internet can't put anything into your network.

VeilNet is built on one. Every machine on a VeilNet network has its own identity, a post-quantum key. A key on its own grants nothing, though, because anyone can make one. What lets a machine in is its credential, VeilNet's name for a certificate: a statement, signed by your organisation, that this machine belongs.

The credentials form what we call the post-quantum PKI tree:

• Your organisation's key sits at the top.
• Beneath it, you can add sub-realms, one for each site or team. Each has its own key, signed by the level above.
• Your machines sit at the bottom.

Every link in the tree is an ML-DSA signature, and the default is NIST's highest security level.

Before two machines exchange any data, each checks the other's chain, link by link, back to your key at the top. There's no central server to ask, and no trust store full of strangers. A machine whose chain doesn't lead to your key is refused, however good its certificate looks.

Every credential expires, and machines renew their own, so there's no pile of long-lived certificates waiting to be misused. You have two ways to remove a machine:

• Revoke it, and its credential is never renewed, so it drops out for good.
• Block it, and it's shut out at once, as the block spreads from machine to machine.

There's no waiting for a browser update. Your network enforces it for itself.

Compartments, signed in

Getting into the network is only half the job. Most organisations also need walls inside it: production kept apart from the test lab, one unit kept apart from another. VeilNet builds those walls with taints.

A taint is a label for a compartment, such as prod or lab. The rule is simple: two machines can exchange data only if one of them carries every taint the other does. For example:

• Give two units' machines the labels alpha and bravo, and they can't reach each other.
• Give a liaison's laptop both labels, and it can reach both units. The units still can't reach each other.

What makes taints strong is where they live. A machine's taints are written into its credential and signed along with everything else, so a machine can't put itself in a compartment or talk its way into a new one. Moving a running machine to another compartment takes a signed order from your guardian. A taint is as strong a wall as the credential that carries it.

The guardian: your post-quantum PKI suite

All of this runs from the guardian, VeilNet's control suite. The guardian is the PKI suite that runs your tree: it issues and manages every ML-DSA certificate in it. It runs on your own infrastructure, and it can run with no connection to the outside world at all.

• Your root stays sealed. Your organisation's realm key is handed over once, on hard media. From then on it lives sealed inside the guardian, and is unsealed for one signature at a time. No machine on the network ever holds it.
• Issue certificates from a console. Commission a machine, and the guardian creates its identity and signs its credential with ML-DSA. The machine's operator installs a single file.
• Delegate to every site and team. Mint a sub-realm for each one, signed by your realm, with a hard wall between them.
• Renewal runs itself. Machines renew their own credentials through the guardian, and the renewal record shows every renewal and every refusal.
• Revoke and block in one step. Remove a lost or stolen machine for good, and shut it out at once.
• Compartments in the console. Choose a machine's taints when you commission it, and move running machines between compartments later.
• Runs where you do. On your own host, in your own data centre, even fully air-gapped.

A private PKI isn't magic. If your own root key is mishandled, your network is exposed. That's exactly why the guardian keeps it sealed and unseals it only to sign. What changes is who's in the circle. With the web's PKI, it's every CA your devices trust. With VeilNet, it's you.

See it for yourself

eMudhra's keys will be cleaned up, and the web will be a little more careful for a while. Your organisation's network can be careful by design, and post-quantum from the root up.

Read how the post-quantum PKI tree works or what the guardian does. You can also book a demo, and we'll walk you through commissioning your first machines. Or write to sovereign@veilnet.net.