Start your PQC transition
Try VeilNet Conflux
A quantum-resistant connection in under five minutes.
- Install conflux on each machineThe script takes this machine's build from the latest release, checks it against the release'sIn a terminal. It asks for sudo or doas only to write /usr/local/bin. On FreeBSD and OpenBSD, fetch the script with fetch or ftp, as the docs show.
curl -fsSL https://raw.githubusercontent.com/ veil-net/ conflux/ HEAD/ install.sh | sh In PowerShell, opened with Run as administrator.irm https://raw.githubusercontent.com/ veil-net/ conflux/ HEAD/ install.ps1 | iex SHA256SUMSand installs it. It starts nothing until you runconflux up. - Start the first machine
$ sudo conflux up Minted a taint for this network: brhk-2mq9-tzva-6pjs-k4xe-nw7d-qf IPv4 [e.g. 10.128.0.7/24, blank for none]: 10.128.0.1/24 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) - Join every other machine with the taint
$ sudo conflux up --taint brhk-2mq9-tzva-6pjs-k4xe-nw7d-qf --ipv4 10.128.0.2/24
- Check the handshakePing
10.128.0.1from the second machine. Every connection negotiatesSecP384r1MLKEM1024, andsudo conflux peersshows each peer it reaches.
Already installed? sudo conflux update replaces conflux with the latest release, held to the digest the release lists, and restarts the anchor on it if it is running.
Rather do it by hand? Every build is on the release page, with SHA256SUMS to check it against.
Guardian stack
The control suite for an organisation's own post-quantum network.
- Commission and renewCommission any machine to a single file. Renewal is automatic and never drops a session.Guardian · Commissioning Machines →
- Live realm controlBlock machines, change compartments and set gateway routes, live. Every action is recorded.Guardian · Realm Control →
- SSO and rolesSign in through your identity provider, or with one-time codes. Four roles, from admin to user.Guardian · Sign-In, Roles and Accounts →
- Runs anywhere, even air-gappedYour cloud, your data centre or a disconnected site. Profiles for US DoD, Australian ISM and UK baselines.Guardian · Air-Gapped Installation →
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
One command installs conflux, and one more joins a machine 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. The install scripts check each against the release's SHA256 checksums before installing it.
- 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 the organisation's root node in each realm, and the signer that signs every credential; the realm's key stays sealed in the guardian and never leaves it.
It sits on no data path, and its only part on the network is the admin node in each realm, which collects telemetry and carries out the realm's controls. 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, and an eighth with tunnel ingress
- 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 its signer sign every credential, and delivers them: manifests to operators, renewed credentials to machines. It also runs the admin node in each realm, which reads the members' telemetry and carries out blocks, compartment moves and network changes.
- 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
- Setup runs again before the upgraded stack starts, and keeps the settings and every secret.
- 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
Get the guardian stack, book an evaluation or send feedback on conflux.