Post-quantum,
without the rebuild
Build post-quantum readiness into your network architecture. VeilNet provides post-quantum secure connectivity across distributed cloud, on-premises and edge environments, with cryptographic agility, local policy enforcement and control over your infrastructure and keys.
Post-quantum security, enforced at every node
VeilNet combines post-quantum cryptography with cryptographic identity and distributed policy enforcement. Every endpoint holds its own keys and enforces network policy, including in disconnected environments.
Three generations of zero trust.
Then a new category.
Each generation fixed the one before it and kept a centre of its own: a gateway, a vendor's cloud, a coordination server. VeilNet has none. It's post-quantum on every connection, and it runs entirely in-house.
Tunnel into the network
- IPsec
- OpenVPN
- WireGuard
- Weak point
- An internet-facing gateway, and the whole network behind it once inside.
- Sovereignty
- In-house.
- Post-quantum
- Retrofitted, where it exists.
Hide services behind a cloud
- cloudflared
- Twingate
- Weak point
- Every connection runs through the vendor's cloud. If it's down, so is access.
- Sovereignty
- Rented. Identity and policy live in the vendor's console.
- Post-quantum
- Retrofitted, where it exists.
Connect machines directly
- Tailscale
- NetBird
- ZeroTier
- Weak point
- A coordination server decides membership, and relay servers carry what NAT blocks.
- Sovereignty
- The vendor's, unless the control plane is self-hosted.
- Post-quantum
- Retrofitted, where it exists.
Take the centre out
- No centre to target. Any machine relays for the others, and can't read what it carries.
- Entirely in-house, from the root of trust to every node.
- Required on every connection: ML-KEM-1024 and ML-DSA-87.
Products are placed by their core architecture. Self-hosting changes who runs the centre, not whether there is one.
One network. Any infrastructure.
A single software overlay virtualises the TCP/IP stack across Layers 1–3, creating a secure virtual network on the infrastructure you already run.
Create a single Layer 2 network across sites, systems and workloads, wherever they are, over the networks they already use.
Each node is identified, authenticated and connected using cryptographic identity. Membership is a signed credential chain that every node checks for itself, and addresses are derived from identity, so sites and systems join without a coordination server or changes to the nodes already there.
- Multi-region cloud — Connect environments across regions through a unified virtual network
- Edge and remote infrastructure — Reconnect and reroute automatically when links drop or networks change
- Adaptive routing — Take the best direct or relayed path, up to five hops, and switch when it fails
Publish internal services to authorised users, systems and partners on your VeilNet network. Access is governed by cryptographic identity and network policy, and traffic is encrypted end to end to the node publishing the service.
Services remain private to the network while supporting standard TCP and UDP traffic. Access can be provisioned and revoked through network membership and identity policy.
- Identity-based access — Authorise users, systems and suppliers through cryptographic identity
- Private service exposure — Make internal services reachable through the virtual network
- Local policy enforcement — Apply membership and access policy at each node
- Host isolation — Publish services from a userspace network stack, so the host itself never joins the overlay
- TCP and UDP services — Publish any TCP or UDP service, not only HTTP
Run the same secure networking across cloud, on-premises, edge and remote environments, over IP networks or, where there is none, over point-to-point serial links.
VeilNet extends the same cryptographic identity, network policy and security architecture across diverse infrastructure.
- Cloud and data centre — Connect AWS, GCP, private cloud and on-premises environments
- Defence and edge — Connect deployed, remote and intermittently connected systems
- Non-IP links — Connect nodes point to point over serial and other byte-stream links, with no IP network underneath
- Long-life infrastructure — Apply modern security architecture across systems with extended operational lifecycles
Full control across the network stack.
VeilNet operates within the organisation's infrastructure and security architecture, providing control across network identity, cryptographic infrastructure, security policy and connected systems.
Your guardian is your root of trust. It, the realms beneath it and every node run on infrastructure you control, under your own change management, and nothing above it can dissolve your realm, read its traffic or stop its nodes.
Guardian services manage node enrolment, delegated authority, network membership and security policy across distributed systems.
Key management follows one PKI tree, from the genesis through your guardian to every node. Each node's identity is an ML-DSA-87 key. Traffic is sealed with AES-256-GCM under session keys from ephemeral ML-KEM-1024 keys that rotate every ten minutes, each signed by the node's identity, giving forward secrecy in ten-minute windows.
Connected systems communicate directly across available network infrastructure, with end-to-end encryption protecting data in transit.
VeilNet runs in cloud-native, on-premises, edge, disconnected and air-gapped environments. A network that never leaves one site needs nothing public, and every node keeps enforcing policy with no connection upstream.
Run by its nodes.
No coordination server.
A VeilNet realm is run by its own nodes. Any node whose credential carries a capability can act on the rest of the realm, and every node checks the signed control against the root of trust before it acts. There is no server to host, rent or attack.
- An admin node with the block capability issues a block.
- It passes the block over its links.
- Link by link, it reaches every other node.
- Every node cuts off the blocked node.
Cut a lost or compromised node off from the whole realm in one action, without having to reach it. Lift the block at any time, or let it end on its own.
Isolate a suspect node in quarantine, or move it between environments, instantly and with no restart. It stays reachable for control wherever it goes.
Bring a site's networks onto the overlay, or take them off, remotely. The router keeps the change across restarts.
Check any node's status, routes and counters on demand, with no agent and no polling. Its peers and its traffic stay private.
Quantum resistance in less than a millisecond.
Every packet is encrypted end to end with AES-256-GCM, under keys agreed with hybrid ML-KEM-1024, a post-quantum key exchange. On a 16-vCPU test host, a round trip across the overlay takes 0.79 ms at the median, and one TCP stream runs at 92% of the most the host can encrypt.
Nine-tenths of the ceiling, direct or relayed
The ceiling is the most one core of the test host encrypts with AES-256-GCM, and the share counts every byte the cipher processes. Low-latency mode is tuned for latency, not throughput.
| Path | Share of ceiling |
|---|---|
| File transfer | 93.3% |
| Direct, one TCP stream | 91.6% |
| Through two NATs, hole-punched | 90.9% |
| Through one relay | 90.0% |
| Direct, four TCP streams | 89.8% |
| Forwarded host traffic | 77–78% |
| Low-latency mode | 61.5% |
A relay adds about a third of a millisecond
Ping round trips, including the kernel's routing into and out of the overlay on both hosts. Low-latency mode sends frames as QUIC datagrams.
| Path | p50 | p90 | p99 |
|---|---|---|---|
| Direct | 0.79 | 1.12 | 1.43 |
| Low-latency mode | 0.75 | 1.01 | 1.25 |
| Through one relay | 1.1 | 1.56 | 1.96 |
| Path | Cold | Warm |
|---|---|---|
| Direct | 0.489 | 0.329 |
| Low-latency mode | 0.433 | 0.291 |
| Through one relay | 0.650 | 0.463 |
End-to-end encryption is about 5% of the latency
anchor's own work along the path, translation, switching, queueing and end-to-end encryption, is about 0.015 ms of CPU per packet. The rest is QUIC, system calls and threads waking up.
| Stage | Cold | Warm |
|---|---|---|
| QUIC, kernel UDP and the network | 0.226 | 0.162 |
| Network stack and address translation | 0.123 | 0.071 |
| Hand-offs inside anchor | 0.064 | 0.060 |
| TUN write | 0.048 | 0.018 |
| End-to-end encryption | 0.026 | 0.020 |
| Virtual switch and queues | 0.007 | 0.004 |
Each peer pair gets a core of its own
More streams between the same two anchors add nothing, because one pair's traffic passes through one encryption pipeline. Separate pairs run on separate cores.
| Case | Share of one core's ceiling |
|---|---|
| One peer pair | 92% |
| One anchor, two peers | 147% |
| Three pairs at once | about 200% |
Test setup. Measured in September 2026 on one 16-vCPU QEMU virtual machine running Linux 7.0, with AES-NI and no PCLMULQDQ, so AES-GCM's GHASH runs in software. Sixteen anchors ran in Docker containers on seven bridge networks, behind three NAT translators (one symmetric) and two relays, at anchor commit 4965e6e9 in its default configuration.
Move from PQC strategy to implementation.
Talk to us about assessing cryptographic architectures, validating post-quantum approaches and developing a practical transition roadmap across distributed infrastructure.