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.
Find every quantum-vulnerable connection.
Continuously monitor every connection on your network, see which key exchanges are post-quantum, hybrid or classical, and export the results as a CycloneDX CBOM.
Explore DiscoverThe PQC inventory: the share of service pairs that are quantum-safe, the critical risks, the mix of risk across 31 service pairs, the servers refusing post-quantum key exchange, and services becoming quantum-safe as they change.
Protect one service, or the whole network.
Protect a single service, a whole machine or your entire network with post-quantum encryption, in any cloud, on any host and over any link.
Explore ProtectNodes: every machine in every realm, its role, overlay address and days left on its credential, with newly commissioned machines arriving at the top.
Manage the network, every identity and PQC TLS.
See the traffic every node reports, manage the identity of every machine, and issue and test post-quantum TLS 1.3 with the conflux toolkit, all on infrastructure you own.
Explore ManageOne node's metrics: its uptime, reachability, connections, peers and neighbours as its realm's admin node last heard them, counters since it started, and history charts of its connections, peers, messages and frames that run on as it reports.
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.
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.