Ready for the PQC transition
VeilNet gives an organisation a post-quantum network that runs in its own estate.
Guardian stack and conflux
VeilNet deploys both in the organisation's own estate, on request.
- Guardian stackThe guardian stack is the organisation's control suite. It commissions, renews and controls every machine.
- ConfluxConflux runs on every machine. Every connection uses ML-KEM key exchange and ML-DSA identities.
- Realm credentialVeilNet mints the organisation's realm credential and delivers it on hard media.
- TelemetryTelemetry from every machine stays in the organisation's estate.
Conflux pre-release
The pre-release joins machines to the instance VeilNet hosts, so it needs no guardian.
Verify each of the seven builds againstSHA256SUMS, then follow the install notes.- Linuxx86-64conflux-linux-amd64DOWNLOAD ↓
- LinuxARM64conflux-linux-arm64DOWNLOAD ↓
- macOSApple siliconconflux-darwin-arm64DOWNLOAD ↓
- Windowsx86-64conflux-windows-amd64.exeDOWNLOAD ↓
- WindowsARM64conflux-windows-arm64.exeDOWNLOAD ↓
- FreeBSDx86-64conflux-freebsd-amd64DOWNLOAD ↓
- OpenBSDx86-64conflux-openbsd-amd64DOWNLOAD ↓
Start with two commands
$ sudo conflux up
IPv4 [e.g. 10.128.0.7/24, blank for none]: 10.128.0.1/24
Minted a taint for this network:
brhk-2mq9-tzva-6pjs-k4xe-nw7d-qf
Starting.
anchor anchor6btpa3gn6w4stipba4hekzho7caw6srfyy5puvbz7mfanaiept5a
overlay fd80:c4b9:99ae:4411:c531:fd4f:754f:f08a/48
ipv4 10.128.0.1/24
interface anchor0
taint brhk-2mq9-tzva-6pjs-k4xe-nw7d-qf
credential valid until 2026-10-06T06:35:43Z (29d 23h)
service active (systemd: conflux.service, enabled at boot)$ sudo conflux up --taint brhk-2mq9-tzva-6pjs-k4xe-nw7d-qf --ipv4 10.128.0.2/24
SecP384r1MLKEM1024.VeilNet covers all PQC transition needs
Harvest-now-decrypt-later applies to data in transit today: customer, payment, citizen, classified and operational data crossing services, clouds, sites and partners. VeilNet removes that exposure with ML-KEM key establishment on every connection.
- Roadmap
- Crypto-inventory
- Algorithm selection rationale
Every connection uses ML-KEM for key establishment and ML-DSA for identity, the NIST FIPS 203 and 204 algorithms.
NIST FIPS 203 and 204 algorithms; Guardian's identity layer runs Keycloak in strict FIPS mode.
- Roadmap
- Crypto-inventory
- Algorithm selection rationale
Post-quantum key establishment and identity run on every connection today, ahead of the first hard dates at the end of 2030 and 2031.
Milestones sit at the end of the year each source names. NIST's draft IR 8547 also deprecates 112-bit RSA and elliptic-curve algorithms after 2030 and disallows them after 2035.SourcesUS EO 14412EU roadmapUK NCSCASDITSM.40.001NIST IR 8547
- Roadmap
- Crypto-inventory
- Algorithm selection rationale
VeilNet is one overlay, adopted as an architecture pattern. It protects every flow without upgrading each component's TLS stack or waiting on several vendors' roadmaps.
- Roadmap
- Crypto-inventory
- Algorithm selection rationale
VeilNet complements existing crypto-inventory and PKI work; it does not replace them.
- Roadmap
- Crypto-inventory
- Algorithm selection rationale
VeilNet is mapped to the frameworks and mandates of financial services, government, defence and critical infrastructure.
Sector frameworks and mandates
- PCI DSS
- ISO/IEC 27001
- EU DORA
- Supervisory guidance
Cloud-native microservices, under heavy third-party risk scrutiny.
- Roadmap
- Crypto-inventory
- Algorithm selection rationale
Each organisation runs its own realm tree. Every node verifies admission for itself, from a signed credential chain.
- Reference architecture
- ADR
Guardian is self-hosted in the organisation's own cloud account, data centre or disconnected site. It holds the realm root key and signs every credential locally.
- Reference architecture
- ADR
Sub-realms are cryptographic tenant boundaries. Compartment labels segment nodes within a realm.
- Reference architecture
- ADR
Access policy is defined centrally in Guardian and enforced locally at every endpoint.
- Reference architecture
- ADR
No gateway, vendor cloud or coordination server sits in the traffic path. Established nodes keep connecting if the control plane is unreachable.
- Reference architecture
- ADR
Guardian can run with no outbound network access, so classified, OT and remote sites do not depend on an external service.
- Reference architecture
- ADR
Applications use the overlay unmodified through a virtual interface, and the userspace proxy runs unprivileged in containers.
- Reference architecture
- ADR
Each connection opens with TLS 1.3 using a hybrid key-exchange group, SecP384r1MLKEM1024 by default.
- Threat model
- RFC review
Traffic is sealed end to end between nodes, with ML-KEM key establishment and AES-256-GCM encryption.
- Threat model
- RFC review
Every node holds an ML-DSA-87 identity and proves it with a signature bound to each session.
- Threat model
- RFC review
Realms use NIST category 5 by default. Category 3 realms use X25519MLKEM768 and ML-DSA-65.
- Threat model
- RFC review
Session keys are ephemeral and are rotated every ten minutes.
- Threat model
- RFC review
Each realm tree has one parameter set, fixed at genesis. The protocol does not negotiate algorithms, so there is no downgrade path.
- Threat model
- RFC review
The pre-release joins machines to a realm VeilNet hosts. Two machines are enough to observe the traffic between them.
- Proof of concept
- Test results
A self-hosted Guardian runs in the organisation's lab or cloud account, and test nodes are commissioned under a root the organisation holds.
- Stand up a GuardianIn the organisation's own cloud account, data centre or disconnected site. It holds the realm root key.Guardian · Getting Started →
- Commission test nodesEach node holds its own ML-DSA-87 identity and a credential signed by the organisation's Guardian.Guardian · Commissioning Machines →
- Check what each connection negotiatedEach connection logs the key exchange it used.Anchor · Post-Quantum Cryptography →
- Proof of concept
- Test results
Each connection opens with a TLS 1.3 handshake whose key share names SecP384r1MLKEM1024, and logs the key exchange it negotiated.
- Proof of concept
- Test results
Builds are published for Linux, macOS, Windows, FreeBSD and OpenBSD, with SHA256 checksums to check them against.
- Proof of concept
- Test results
Guardian is built for restricted environments. It can run with no outbound network access and is built for accreditation against US DoD, Australian ISM and UK baselines.
A guardian is software the organisation deploys, not a console VeilNet operates. It runs alongside the organisation's root node, which holds the realm's key and mints every credential; the key never leaves it.
It sits on no data path, and its only part on the network is a telemetry observer in each realm. If it becomes unavailable, the network continues to operate: a machine due to renew retries every minute until it is restored, and only a prolonged outage would let a credential lapse.
- The front door is the only published port
- port
- Default credential life, renewed at two thirds of it
- days
- One stack on one host, each service with one job
- services
- Admin, manager, auditor and user, in descending order of privilege
- roles
7 services, one front door
- Front door
- The only published port. Operators and nodes both reach the guardian through it, over TLS.
- Identity
- Decides who may operate the guardian: standalone with one-time codes, the default, or brokered to the organisation's identity provider. Before any sign-in it shows the compliance profile's system-use notice, which must be accepted first.
- Operator console
- Where sub-realms are minted, machines are commissioned and revoked, the people who sign in are managed, and the network's telemetry is shown. Sign-in tokens never reach the browser.
- API server
- Has the co-located root node mint credentials, and delivers them: manifests to operators, renewed credentials to machines. It also runs the observer in each realm that reads the members' telemetry.
- State and audit store
- The record of every realm, machine, renewal and account change: who created each realm, who commissioned or revoked each machine, and who changed each account. Every write to it is audited.
- Telemetry intake
- Accepts health, counters and flow records from every machine, each reporting with a collector credential of its own.
- Metrics store
- Keeps that telemetry, flow records included, for ninety days, for the console.
Admin, manager, auditor, user
- AdminEverything a manager can, shape the realm tree by minting, renaming and archiving sub-realms, and manage the people who sign in.
- ManagerRun the fleet: commission any node, download a manifest again, and revoke.
- AuditorRead everything, including every renewal and why any was refused, every machine's flow records and the access review of accounts, and act on nothing.
- UserDeploy machines with the credentials handed to them, and read the fleet's telemetry, flow records aside.
No role changes the deployment's settings from the console: they are changed on the host, under the organisation's own change control.
Commission, renew, revoke
Certificates, air gaps, profiles, upgrades
- Certificates
- TLS from the guardian's own certificate authority, from the organisation's PKI, or from a public ACME authority.
- Air-gapped
- Build the stack on a connected host, carry its images across, and hand the realm credential over separately. Nothing in the running stack needs to reach VeilNet.
- Compliance profiles
- Configuration profiles for US DoD, Australian ISM and UK MOD and NCSC baselines, each showing its own system-use notice before sign-in.
- Upgrades
- Upgrades migrate the guardian's own records in place: every row survives, and no machine is re-commissioned. Setup runs again before the upgraded stack starts.
- Open source
- Every third-party component in the stack is permissively licensed open source.
- Operator responsibilities
- The host's own hardening, encrypted volumes, time, PKI and SIEM. The guardian is a stack, not a host.
- Evidence pack
- Accreditation submission
Guardian ships with a compliance register that maps its controls to NIST SP 800-53, ready to include in an evidence pack.
- Evidence pack
- Accreditation submission
Guardian writes audit records to a dedicated volume, ready for a SIEM pipeline. Each connection logs the key exchange it negotiated.
- Evidence pack
- Accreditation submission
Guardian's identity layer runs Keycloak in strict FIPS mode, standalone with one-time codes or brokered to the organisation's identity provider.
- Evidence pack
- Accreditation submission
Machines renew themselves at two thirds of their credential's life without dropping a session. Revoking stops renewal; a signed block is the faster stop.
- Evidence pack
- Accreditation submission
Every machine reports full OpenTelemetry data, down to each individual flow, into the Guardian's own metrics store and console.
- Evidence pack
- Accreditation submission
Talk to the founder
Contact the founder for access to the guardian stack, an evaluation or feedback on the pre-release.