VeilNet
Sovereign post-quantum networking

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.

Book a demoTry VeilNet Conflux
CNSA 2.0ASD 2030EU PQC roadmap
ML-KEM-1024ML-DSA-87AES-256-GCMReinforcement learningDecentralisation
01Discover

Find every quantum-vulnerable connection.

Continuously inventory the cryptography on every connection, rank each one by quantum risk under NIST or CNSA 2.0 policy, and get a prioritised migration plan and a CycloneDX CBOM.

Explore Discover
The migration plan: 17 changes for 17 pairs at risk, ten on servers and seven application updates, in order, with the share of at-risk traffic each fixes and the quantum-safe share by day.
The inventory: every service pair observed, with its protocol, key exchange, risk, the side that must change, how many nodes saw it and when, filtered by risk, remediation and protocol.
Discover's overview: quantum readiness at 49% of 39 cryptographic pairs, the quantum-safe share by day, observer coverage, remediation by side, the quantum-safe share by protocol, the key exchange groups in use and the top exposures.
Guardian console · DiscoverOverview · Inventory · Migration planView all 5 Discover screens
02Protect

Protect a single service or your entire network.

Apply post-quantum encryption to a single service, an entire host or your whole network, across any cloud, site or link. Monitor every node, realm and flow from one console.

Explore Protect
Telemetry: nodes reporting, connections now, how nodes are reached, peers known, each node's current readings and last hour, and the largest flows.
Nodes: every node commissioned, with its overlay address, status, how it is reached, peers, days left on its credential, owner and whether it observes traffic.
Protect's overview: 15 of 17 nodes reporting, the node credentials needing attention, renewals in the last day, connections now, the nodes needing attention, the realm credential and the network map of every realm.
Guardian console · ProtectOverview · Nodes · TelemetryView all 7 Protect screens
03Manage

Manage every identity and certificate.

Control who can sign in and what each role can do. Issue, renew and revoke post-quantum certificates from your own ML-DSA certificate authorities, on infrastructure you own.

Explore Manage
Certificates: 24 issued by two authorities, each with its key, time left, status and where it is served.
People: every console account with its role, state, last sign-in and the nodes it owns.
Manage's overview: six accounts, 24 certificates issued, 18 of 20 valid certificates on ML-DSA keys, two authorities, the accounts needing attention, the roles, how people sign in, the certificates to renew and who owns what.
Guardian console · ManageOverview · People · CertificatesView all 5 Manage screens
04Audit

Prove every control with signed evidence.

Test the controls the guardian enforces every hour, mapped to six frameworks including SOC 2, ISO 27001 and the ASD ISM, and give auditors signed evidence packs they can verify independently.

Explore Audit
Evidence: the evidence packs built, the keys that sign them, and every evidence item to download on its own.
Tests: automated checks of guardian's own records, each with its status, area, exceptions, owner and deadline.
Audit's overview: six frameworks with how many requirements guardian maps and how many tests fail or need attention, the tests needing attention, the access review in progress, auditor requests and recent evidence packs.
Guardian console · AuditOverview · Tests · EvidenceView all 6 Audit screens
04 — Global connectivity

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.

EDGE SITESCLOUD REGIONSMOBILE · TACTICALAIR-GAPPED ENCLAVEFIELD · SERIAL · RADIODATA CENTRE
Swipe to see every site

Any infrastructure

Public cloud, on-premises, edge and embedded hosts. VeilNet installs where systems already run, with no new appliances.

Any link

Fibre, broadband, 4G and 5G, satellite, serial and field radio. Nodes connect directly or relay for each other, across NAT and changing networks.

Any distance

Sites on different continents join one network, sealed end to end with post-quantum cryptography. Air-gapped enclaves run as realms of their own.

Start with an evaluation

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.

01
AssessIdentify cryptographic dependencies, assess current architectures and understand where post-quantum requirements affect systems, services and network infrastructure.
02
DesignEvaluate architectural options, define security requirements and develop a practical pathway for introducing post-quantum security across cloud, on-premises and distributed environments.
03
ValidateRun technical evaluations and proofs of concept in representative environments to validate architecture, security controls, performance and operational requirements.
Air-gapped environments supportedNo data leaves the estate

05 — Questions

Frequently asked questions.

What VeilNet protects, where it sits in the stack, and what changes on your machines when you run it.

Still have a question?

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.

Talk to usRead the docs

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.