Post-quantum,
without the rebuild
Post-quantum readiness, built into the network architecture. VeilNet provides post-quantum secure connectivity across distributed cloud, on-premises and edge environments, with cryptographic agility, local policy enforcement and full organisational control of infrastructure and keys.
Post-quantum, NIST-standard cryptography
ML-KEM for key establishment and ML-DSA for cryptographic identity and authentication, from the NIST Post-Quantum Cryptography standardisation process, with AES-256-GCM for authenticated encryption.
Crypto-agile, end to end
VeilNet seals traffic as close to the physical link as software can reach, beneath IP and everything built on it. Every protocol and application above is protected, whatever cryptography it uses or none at all, so nothing has to change to run on VeilNet.
Identity and policy at every node
Every node's identity is an ML-DSA key, checked before any connection opens. Membership, routing and compartment rules are signed, spread peer to peer and enforced by every node for itself, with no central controller.
Sovereign and self-hosted
Cryptographic identities and network security functions operate within organisation-controlled infrastructure, across cloud, on-premises, edge, restricted and disconnected environments, with security policy enforced locally.
Works everywhere. Connects everything.
VeilNet is software, so it runs wherever the organisation's systems do: cloud regions, data centres, edge sites, vehicles and field equipment. Every node joins the same post-quantum network, wherever it is in the world and whatever link it has.
The network is more than one layer.
Move from PQC strategy to implementation.
VeilNet engineers support the assessment of cryptographic architectures, the validation of post-quantum approaches and the development of a practical transition roadmap across distributed infrastructure.
Frequently asked questions.
What VeilNet protects, where it sits in the stack, and what changes on your machines when you run it.
The docs describe exactly what the protocol does, down to each key and frame. For anything else, a VeilNet engineer will take you through it.
Layers 2 and 3. VeilNet gives every machine a virtual Ethernet segment that carries ordinary IP packets, so it sits beneath TCP, UDP, TLS and everything built on them. The overlay is IPv6, and IPv4 travels inside it at addresses you choose.
The network layer is Layer 3, where IP lives. A TLS proxy, whether a sidecar beside each workload or a gateway in front of many, terminates TCP connections at Layer 4 and wraps them in TLS. It protects only the connections it can terminate, and nothing that travels outside TCP.
No. Applications see a network interface and ordinary IP addresses, as on any LAN. There are no proxy settings, no certificates to install and no libraries to swap, and machines behind a subnet router keep their existing addresses.
On a machine with VeilNet's network interface, anything that runs over IP: TCP, UDP, QUIC, ICMP and every protocol built on them, from HTTP and gRPC to SSH, DNS, voice and video. On a container or unprivileged host, proxy mode publishes any TCP or UDP service.
It is carried unchanged inside VeilNet's post-quantum layer. Nothing in the path decrypts it, so the application's own TLS and certificate pinning keep working end to end, and the connection gains post-quantum protection underneath.
Both work at Layer 1. They need dedicated fibre, or for QKD a satellite link, and special hardware at each end, and they protect one link at a time. VeilNet is software on the machines, VMs and containers you run, and seals traffic end to end over the internet, cloud, satellite, radio or a serial cable.
It doesn't have to. VeilNet runs beneath your TLS and over links already protected by MACsec or optical encryption, so existing controls stay in place. Where IPsec gateways only join sites together, VeilNet can take their place, because each machine checks its peers itself and no gateway sits in the path.
ML-KEM-1024 for key establishment and ML-DSA-87 for identity, the NIST FIPS 203 and 204 algorithms, with AES-256-GCM for encryption. That is NIST category 5, the default; category 3 realms use ML-KEM-768 and ML-DSA-65. Post-quantum key exchange is required on every connection, with no classical fallback.
No. It is software for the machines, VMs and containers you already run: Linux, Windows, macOS, FreeBSD and OpenBSD, on amd64 or arm64. Where there is no IP network at all, it can run over a serial cable.
A machine on the network that can run it acts as a subnet router, and the rest of the realm reaches the others through it. The link from the router to each of those machines is classical, so keep it inside a site you control.