Get Started
POST-QUANTUM ZERO-TRUST NETWORK ACCESS

Post-quantum compliant encryption, the way it should be.

Avon is a post-quantum, zero-trust network access platform. Every connection is authenticated, every packet is verified, and every key is built from cryptography a quantum computer can't unwind later. It runs on Linux, macOS, and Windows, it's open source under the MIT license, and it does not ask you to trust the coffee-shop Wi-Fi, the ISP, the cloud provider, or the guy three hops upstream quietly mirroring your packets to cold storage.

See it move Talk to us

MIT licensed. Read the source, break it, send a PR. Security software you can't read is a brochure.

KEY EXCHANGE X25519 + ML-KEM-768
SIGNATURES Ed25519 + ML-DSA-65
TRANSPORT AES-256-GCM
LICENSE MIT
THE PROBLEM

Your traffic is being recorded today. Decryption is scheduled for later.

The encryption on your traffic today, the TLS handshake, the VPN tunnel, the padlock in the address bar, all rests on RSA and elliptic curves. A sufficiently large quantum computer factors both for breakfast.

That computer doesn't exist yet. Cool. Doesn't matter.

The attack doesn't wait for the computer. Harvest now, decrypt later (you'll also hear "store now, decrypt later" or "catch and keep," depending on which threat brief you skimmed) works like this:

  1. 01

    Copy your encrypted traffic today.

    Bulk. Cheap. Passive. Nobody notices.

  2. 02

    Sit on it.

    Storage is basically free and adversaries are annoyingly patient.

  3. 03

    Decrypt the whole archive at once.

    When a capable quantum computer shows up, 2030, 2035, whenever, read everything you sent in 2026 like it was a postcard.

The useful question is how long your data has to stay secret. Contracts, health records, source code, financial positions, the M&A email you really shouldn't have sent. If any of it still matters in ten years, a quantum computer that arrives in ten years is a problem you have today.

You don't get to encrypt that traffic again. It already left. Somebody may already have it.

The other problem: your network was never trustworthy either

Most "secure" networks still run on a fairy tale from 1995: get inside the perimeter, the VPN, the corporate LAN, the "trusted" subnet, and you're treated like family. One stolen laptop, one phished credential, one compromised contractor, and the attacker inherits that same family membership. Flat trust is a single point of catastrophic failure wearing a firewall costume.

Zero trust fixes the philosophy: never trust, always verify, every single time. Great slogan. The industry then proceeded to sell you "zero trust" products that... still trust the network, still use pre-quantum crypto, and still lock you into one vendor's cloud so hard you need a crowbar and a lawyer to leave.

So the actual problem is two problems, stacked

Time
Today's crypto has a shelf life, and adversaries are already stockpiling your ciphertext to open later.
Trust
The network you're running on assumes goodwill it has never earned.

Avon handles both. Fixing one and shipping is how you end up in a quadrant.

THE SOLUTION

Assume the network is hostile and the future is quantum. Build for both.

Avon is a network access platform where:

TRUST

Nothing is trusted because it's "inside."

Every device authenticates with its own cryptographic identity. Every flow is checked against policy at the gateway before a single packet is allowed toward anything protected. Being on the network gets you exactly nothing.

TIME

The cryptography is post-quantum from the handshake down.

Keys are established with hybrid post-quantum algorithms, so an adversary can't harvest your traffic today and decrypt it after their quantum computer arrives. The archive they're building is a very expensive collection of noise.

OWNERSHIP

You own it.

Open source, MIT licensed, self-hostable. No black boxes, no "trust us," no per-seat ransom, no vendor holding your network hostage. Read every line. Run it yourself. Fork it if we annoy you.

The name is literal: Authenticated Vector Ownership Network. Authenticated, because identity is proven, not assumed. Ownership, because your corners of the network are yours. You run the control plane, you hold the keys, you set the rules.

Own your corners.

HOW IT ACTUALLY WORKS

Two planes that gossip about you constantly. That's on purpose.

CONTROL PLANE

The bouncer with the guest list

The control plane is the brain. It runs your certificate authority, enrolls devices, brokers sessions, and pushes policy out to the edge. It is the only thing that decides who exists and who may talk to whom. It never sees your actual traffic. It checks IDs at the door and doesn't follow you inside.

DATA PLANE

The tunnel that does the heavy lifting

Gateways are the muscle. They terminate the encrypted tunnels, enforce policy on every flow, and forward traffic to the protected resources behind them. Session keys live locally on the gateway and the device, which means the data plane keeps carrying traffic even if the control plane is momentarily down. The bouncer can step out for a smoke without the party collapsing.

How the two work together (the part most vendors hand-wave)

The design decision we're actually proud of: session keys are negotiated over the authenticated control channel. There is no raw UDP handshake. Post-quantum keys and certificates are big. Stuffing them into a UDP handshake means fragmentation, amplification-attack surface, and cookie gymnastics. Avon sidesteps the whole circus. The device authenticates to the control plane over mutually-authenticated TLS, the control plane brokers a session with a gateway, both sides derive their tunnel keys through that trusted channel, and only then does encrypted data start flowing over UDP.

The result: the expensive, fragile part happens once, over a channel that's already proven who everyone is. The cheap, fast part, moving your packets, happens over a lean tunnel that never had to survive a fragmented quantum handshake on the open internet.

THE BOUNCER AND THE MUSCLE

Two planes. One of them never sees your traffic.

The bouncer decides who's in. The muscle moves the packets. Neither one has to trust the network.

The AVON platform has 7 components.

  • Device — hostile network. The agent, on Linux, macOS, or Windows. It generates its own hybrid keys and the private half never leaves it.
  • Hostile network — hostile network. Coffee-shop Wi-Fi, the ISP, the cloud provider, and whoever is mirroring packets to cold storage. Trusted for nothing.
  • Controller — control plane. The bouncer. Enrolls devices, brokers sessions, pushes policy to the edge. Never carries your traffic.
  • Certificate Authority — control plane. Issues each device a hybrid Ed25519 + ML-DSA-65 certificate. On Linux it verifies and pins a TPM attestation quote.
  • Admin API — control plane. Mints enrollment tokens, approves pending devices, authors Cedar policy, revokes.
  • Gateway — data plane. The muscle. Terminates post-quantum tunnels and evaluates Cedar policy on every flow, in the data path.
  • Protected resource — data plane. Whatever policy explicitly permits this device to reach. By default, nothing.
01 / 07

A token is minted

An admin mints an enrollment token: single-use or count-limited, expiring, and optionally requiring a human to approve the device. A leaked token is a small, time-boxed, revocable problem.

FROM NOBODY TO TRUSTED

Provisioning a device, start to "it just works"

A device starts out unknown and is refused at a closed gateway. An admin mints a single-use, expiring enrollment token, which is delivered to the device. The device generates a hybrid classical and post-quantum key pair internally, sends only a certificate signing request to the certificate authority, and receives a signed certificate. If approval is required, the device waits in a pending state until an admin approves it. The gateway then opens only for this device, and only to the one resource policy permits; the other resources stay unreachable.

01 / 07

Nobody

A device nobody has heard of knocks on a closed gate. Nothing happens. The network has never heard of it and doesn't care.

Keys never leave the device. On Linux, they never leave the chip.

  1. 01

    Get a token.

    An admin mints an enrollment token. Tokens are single-use or count-limited, they expire, and they can require explicit approval before the device is allowed in. A leaked token is a small, time-boxed, revocable problem.

  2. 02

    The device enrolls.

    The agent generates its own hybrid key material, builds a certificate signing request, and hands it to the control plane with the token. The CA issues the device a real certificate. The private keys never leave the device. On Linux they can be sealed to the machine's TPM so they can't even leave the chip.

  3. 03

    Approval (optional but recommended).

    If the token requires it, the device sits in a "pending" state, connected to nothing, until a human approves it. Enrollment is not admission.

  4. 04

    It connects.

    The agent authenticates, the control plane brokers a gateway session, keys get derived, the tunnel comes up, and policy decides what the device can actually reach. Which, by default, is nothing, until you say otherwise.

Policy: default-deny, with receipts

Access is governed by policy compiled from Cedar, which has a grammar, a verifier, and a spec, so nobody has to guess what a rule means at 3 a.m. The rules are simple to reason about: deny overrides allow, and an explicit permit is required to reach anything. A tenant with no policy yet is permissive (so you can actually stand it up without fighting it), and the moment you author your first policy, it flips to zero-trust default-deny. Every flow is evaluated at the gateway, in the data path, against the current policy snapshot.

POST-QUANTUM, EXPLAINED

Post-quantum encryption, explained like you have things to do

What "post-quantum" means

Cryptography built on math problems that quantum computers are not known to break. Classic public-key crypto (RSA, elliptic curves) dies to Shor's algorithm on a big enough quantum machine. Post-quantum algorithms are designed on different problems (lattices, mostly) that survive it.

Why "hybrid" and not just "post-quantum"

The post-quantum algorithms are newer and less battle-scarred than the classical ones. So Avon doesn't bet the farm on either. It combines them. Break the classical half and you still hit a post-quantum wall; break the post-quantum half (unlikely, but humor us) and you still hit the classical one. You'd have to break both to read anything. This is the same "belt and suspenders" approach the serious standards bodies recommend, because nobody sane deploys brand-new crypto with zero fallback.

A device and a protected resource sit on opposite sides of a hostile network where passive listeners copy every packet. A hybrid key exchange fuses an X25519 key and an ML-KEM-768 key into one shared secret, and a tunnel forms. Packets travel as sealed, counted capsules. A listener copies capsules into an archive labelled "decrypt in 2034". When a captured capsule is replayed at the gateway, the replay window rejects it and it shatters. In 2034 a quantum computer is pointed at the archive and the archive turns to noise. Meanwhile the tunnel rekeys mid-stream and a live SSH session keeps running without interruption.

01 / 07

Hostile ground

A device on one side, a protected resource on the other, and in between a network full of quiet listeners copying everything that passes. They are patient. Storage is cheap.

Copy it now. Decrypt it never.

What Avon actually uses (the specifics, because you'll ask)

RoleClassicalPost-quantumWhy
Key exchangeX25519 + ML-KEM-768The NIST-standardized lattice KEM, formerly "Kyber." Combined into one shared secret. Harvesting the handshake gets you nothing to decrypt later.
Signatures / identityEd25519 + ML-DSA-65The NIST-standardized signature scheme, formerly "Dilithium." Every device and service identity is signed with both.
Bulk transportAES-256-GCM or ChaCha20-Poly1305Symmetric ciphers that quantum computers only mildly inconvenience. Grover's algorithm effectively halves the key strength, which is why the key is a very roomy 256 bits. Your actual packets ride on this.
PLAIN-ENGLISH VERSION

The keys that unlock your traffic are built so that "harvest now, decrypt later" ends with "...decrypt later, get static." The archive an adversary is quietly building today doesn't become readable when the quantum computer arrives. That is the whole job of this project.

THE TUNNEL

For the packet nerds

Avon's data-plane transport is a purpose-built protocol (internally: ATP/2) that looks like ESP's disciplined cousin.

  • Tight fixed-size header

    Type, flags, a receiver index, and a counter, followed by an authenticated-encrypted payload. No sprawling per-packet overhead.

  • Replay window

    A captured packet replayed back at the gateway is recognized by its counter and dropped.

  • Automatic rekeying

    On a timer and on a packet-count ceiling, with an overlap window so a rekey doesn't drop your long-lived SSH session mid-command.

  • Anti-spoofing

    A session may only source packets from the overlay addresses and routes it actually owns. Lie about your source address and your packet hits the floor.

  • Forgeries are noise

    Corrupted or forged packets fail authentication at the gateway and never reach the protected network. There is no mitigation step because there is nothing to mitigate. As far as the network is concerned the packet never existed.

THE TEST HARNESS

All of the above is exercised by an end-to-end test harness that carries real HTTP, SSH, Postgres, and UDP traffic through the tunnel, forces a rekey mid-session, and actively replays and corrupts packets to prove they get dropped. The harness exercises the security properties, and the happy path gets tested along the way.

FEATURES

All of them, and how you actually use them

IDENTITY

Cryptographic device identity

Every device gets its own certificate with hybrid post-quantum keys. No shared secrets, no "the WiFi password is on the whiteboard." Identity is proven per device, per connection.

How you use it It's automatic at enrollment. You mint a token; the device does the rest.

POLICY

Zero-trust access control (Cedar)

Fine-grained, deny-by-default policy evaluated on every flow at the gateway. Write rules against devices, groups ("pods"), destinations, ports, and protocols. Deny overrides allow, always.

How you use it Author policies through the admin API / console. No policy = locked down.

Straight talk The admin authoring path is under active work; the gateway enforcement it drives is already proven end-to-end.

TUNNELS

Post-quantum tunnels

Every tunnel is encrypted with hybrid PQC key exchange and modern AEAD ciphers, with replay protection and automatic rekeying.

How you use it It's the default and the only mode. There is no "turn off the good crypto" toggle, because why would we build that.

AGENTS

Cross-platform agents

Native agents for Linux, macOS, and Windows, using each platform's real data plane: TUN on Linux, utun on macOS, WinTun on Windows. Shipped as .deb / .rpm, a signed .pkg, and an MSI installer.

How you use it Install the package, drop in an enrollment token, done. The agent creates the tunnel interface and enforces a fail-closed firewall, so if the tunnel drops, traffic to protected networks doesn't quietly leak out the default route.

CUSTODY

Hardware-backed key custody

On Linux, device keys can be sealed to a TPM 2.0. The private key material is generated and held by the security chip and never touches disk in the clear. The device can produce a genuine TPM attestation quote that the control plane verifies and pins, so a cloned data directory on a different machine can't impersonate the real device.

How you use it Enroll with the TPM key provider on supported Linux hardware.

Straight talk Hardware-backed custody is real and proven on Linux today. On macOS (Keychain) and Windows (CNG) the hardware providers are still being built. Until they land, treat those platforms as software key custody. We'd rather tell you that than let you find out during an audit.

VERIFICATION

Device attestation & continuous verification

Sessions aren't validated once at login and then trusted forever. Device posture and identity are checked continuously, and a revoked device is pushed off promptly: the control plane closes its sessions and tells both the gateway and the device, rather than waiting for a token to lazily expire.

How you use it Revoke a device from the admin surface. It's cut off within seconds.

SELF-HOSTED

Self-hostable control plane

You run the CA, the control plane, the gateways, and the admin API. Your keys, your infrastructure, your rules. Kubernetes-first, with a Helm chart, and it also runs fine in plain Docker Compose for smaller footprints.

How you use it Deploy the stack, generate your infrastructure certificates, bring it up. First run is a documented handful of commands.

ROUTING

Subnet routing (agentless reach)

A device can act as a subnet router, advertising the CIDRs behind it, so you can reach resources on networks where you can't install an agent on every box.

How you use it Configure the advertised routes on the router agent; policy still governs who's allowed through it.

RESILIENCE

It survives reality

The data plane keeps forwarding through a control-plane outage. Tunnels tolerate lossy, high-latency networks. Rekeys don't drop live sessions. All of it is exercised by the test harness.

How you use it Nothing to configure. It's how the planes are split.

Straight talk Fast recovery from a gateway restart is still on the list. Today an agent re-establishes on its idle-timeout rather than instantly. It's on the roadmap and it's honestly documented in the repo.

OPEN SOURCE

MIT licensed. The permissive one.

Use it, modify it, ship it in your commercial product, self-host it, fork it, embed it. Go nuts, just keep the copyright notice.

Why does that matter for a security product specifically?

  • You can read the crypto.

    "Trust us, it's secure" is how you end up on a breach-notification mailing list. Avon's cryptography, protocol, and policy engine are all right there. Audit them. Get your paranoid friend to audit them.

  • No vendor lock-in, no ransom pricing.

    Your network access shouldn't have an off-switch that your vendor controls and re-prices annually.

  • You own your corners. For real.

    Self-host the whole thing. The acronym is a description.

Read the source, file issues, send pull requests. The test harness refuses to report a pass it didn't earn. Hold us to the same standard.

View the source
MANAGED DEPLOYMENT

Somebody else's on-call rotation.

Stringer is the managed deployment of Avon, run by the people who wrote it. Same code you can read on GitHub, with our pager instead of yours.

Explore Stringer →
FAQ

Short and sharp

Do I need a quantum computer to care about this?
No. You need data that has to stay secret for more than a few years and an adversary who owns a hard drive. Both already exist.
Is this just another VPN?
A VPN typically gives an authenticated device the run of a network. Avon gives an authenticated device access to exactly what policy allows, over post-quantum tunnels, with per-flow enforcement. Different threat model, different century.
Is it actually production-ready?
It's open source and under active development, and we're candid in the repo about what's proven versus what's still baking. The data plane and post-quantum tunnel are exercised end-to-end by a test harness that refuses to fake a pass. Read the project status; we wrote it for grown-ups.
Can I self-host all of it?
Yes. That's the intended deployment. Kubernetes/Helm or Docker Compose.
What's it licensed as?
MIT. Use it, ship it, fork it. Keep the notice.
What if I find a bug in the crypto?
Excellent. Tell us. That's the whole reason it's open.

Stop encrypting for a threat model that expired in 2015.

The network isn't trustworthy. Your current crypto has a countdown on it. Somebody may already be saving your traffic for later. Avon is the boring, verifiable, self-hostable answer to all three, with cryptography built for the decade you're actually going to live in.

Own your corners.

Request a walkthrough Read the source