Sovereign post-quantum networking

Post-quantum,
without the rebuild

VeilNet protects every link an organisation runs against quantum decryption, from a single field radio to a whole cloud estate. You run all of it on your own infrastructure, and we never sit in the data path.

CNSA 2.0ASD 2030EU PQC roadmap
ML-KEM-1024ML-DSA-87AES-256-GCMReinforcement learningDecentralisation
01 — The deadline

RSA and ECC
are expiring

Today's encryption runs on RSA and elliptic-curve cryptography. A cryptographically relevant quantum computer breaks both.

Traffic captured today decrypts the moment that machine exists. Governments call this harvest now, decrypt later, and have already set the migration deadlines.

Fig. 01 — Mandated transition windowsCapture is happening now
Today20302035
United States
NSA CNSA 2.0

Required across national security systems by the early 2030s.

Australia
ASD — by 2030

One of the earliest deadlines anywhere: government systems by 2030.

European Union
Coordinated roadmap

Member states are migrating together, high-risk systems first, with milestones around 2030.

These deadlines already show up in procurement. A network with no post-quantum plan will start losing tenders well before 2030.

02 — Capabilities

One install protects everything behind it

One overlay virtualises TCP/IP stack layers 1 to 3, so the protection doesn't depend on the physical network underneath. Because it lives in software above the wire, it can go wherever you need it, and that opens up three things most networks can't do.

Every site joins one Layer 2 network. To the machines on it, it feels like a single office LAN, wherever they actually are.

There's no hub or coordination server to run and keep alive. Each machine works out its own address from its cryptographic identity, so adding a site doesn't mean touching the ones already there.

  • Multi-region cloud without peering contracts to manage
  • Edge compute that keeps working over an unreliable link
  • Multipath relay spreads traffic across several routes at once

Publish an internal service to exactly the people who need it, without opening a single port to the internet or putting it behind yet another gateway.

Traffic comes in through a sandboxed interface, so a compromised service can't take the host with it. UDP works properly too, not only HTTP.

  • A service mesh with no sidecars and no control plane to run
  • Supplier access that ends the moment an identity is revoked
  • Real UDP support, which most zero-trust proxies still get wrong

Serial cables, HF and VHF radio, satellite bearers, industrial buses older than the web. Most of it will never get a post-quantum upgrade.

VeilNet doesn't need an IP network underneath. Give it any link that can carry bytes, and the equipment on either end can stay exactly as it is, for as long as it stays in service.

  • Deployed forces and vessels on radio bearers, not satellite backhaul
  • Substations, rail signalling and water treatment on serial links
  • A compliance answer for equipment with a twenty-year service life
AUNZUSCAGBSecurity without boundary
03 — Sovereignty

The trust, control and data
stay in-house.

Most secure-networking products put the vendor between you and your own network. Your identities live in their console, your nodes are managed from their cloud, and your security lasts as long as the subscription does.

With VeilNet, every layer runs on your own infrastructure: the root of trust, the realms under it, the guardian service that manages the nodes, and the nodes themselves. We don't run anything in between, and there's nothing of ours your network needs in order to keep working.

Full sovereignty
YOUR INFRASTRUCTURE, END TO END01Root of trustML-DSA-87 · GENERATED AND HELD OFFLINE, IN A SAFE02Guardian serviceSELF-HOSTED MANAGEMENT — ENROL, DELEGATE, SUPERVISE, REVOKE03Realms and sub-realmsA REALM PER BUSINESS UNIT OR SITE — ORG CHART IS THE NETWORK04NodesTHE OVERLAY ITSELF — PEER TO PEER, NO TRAFFIC VIA A THIRD PARTYNODENODENODENODENODEREVOKED

It isn't only the private keys. The root of trust, the realms, the guardian service and every node run on your hardware, under your own change control. We don't host any of it, and you decide when anything is upgraded.

The guardian enrols nodes, delegates authority to sub-realms, watches over them and revokes them. It's software you deploy, not a console we operate, so an outage or a policy change on our side never reaches your network.

Traffic goes straight between your machines. There's no account of ours to suspend or dashboard to break into, and nothing for anyone to subpoena from us, because none of it passes through us.

Each node's address comes from its identity. You don't need an address plan or a server handing out addresses, and there's no single component whose failure takes the whole network down with it.

It never phones home, checks a licence or sends telemetry. A classified network stays classified, and keeps working when the internet doesn't.

04 — Security

Compartments,
not permission lists

Subnet and IP allow-lists assume a machine keeps its address and someone keeps the list up to date. That stopped being true a while ago. Workloads autoscale, containers are replaced every few minutes, addresses get reused, and a single fleet runs across several clouds and edge sites. The list is stale before anyone reviews it, and it never said what those addresses were for anyway.

VeilNet identifies machines by purpose instead: prod, dev, a supplier, a vessel. A new instance starts with its identity already in place, so it has the right access from the moment it boots and loses it the moment it's revoked. Nobody rewrites rules or redesigns subnets as the fleet grows.

Identity decides the access boundary
PermittedMultipathRefusedBuild estateIdentity-aware network

Access is decided by identity, in the network itself. A subnet only knows where a machine sits, not what it is or who runs it. Here every connection is checked against the cryptographic identity that opened it, so micro-segmentation is built into the network instead of bolted on as firewall rules. On this map, Sydney reaches Toronto over three paths at once, through London, Cape Town and Singapore. Build machines never show up on any route, and direct links between production sites are refused.

01
Identity is native to the network

Each identity is an ML-DSA-87 key that chains back to your root of trust, not a number handed out by a directory. The same key signs the ML-KEM exchange that encrypts the connection, so one credential covers both authentication and encryption.

02
Policy is enforced locally

Every machine checks access for itself, so there's no coordination server in the loop and nothing central to take offline. Add or remove a label and the change applies everywhere straight away.

03
No path to exploit

The ML-DSA/ML-KEM handshake checks identity before anything replies, so a scanner gets nothing back to fingerprint, let alone attack. Micro-segmentation then keeps each compartment to the peers it was given, and nothing else.

Start with an evaluation

Find out how the transition starts

Most organisations don't yet know which systems can be upgraded, which can't, and what it will cost. We'll work that out with you and give you a written, priced plan.

01
Quantum readiness assessmentWhere you're exposed today, and which systems have no upgrade path at all. You keep the report whether or not you buy anything.
02
A costed upgrade pathwayWhat to replace, what to wrap, and in what order.
03
An evaluation set, shipped outPre-built nodes, configured and ready to plug in. We'd suggest putting them on your most awkward link first, since that's where the difference shows.
Air-gapped welcomeNo data leaves the estate