Security
Security at Defined Networking
Your hosts connect to each other over direct, end-to-end encrypted tunnels, authenticated by certificates and governed by a default-deny firewall. The private keys that encrypt your traffic are generated on your endpoints and are never sent to us. The security whitepaper covers the design in full technical detail.
How the service is secured
Your traffic is end-to-end encrypted
Hosts build direct, mutually authenticated tunnels to each other using the Noise protocol, with AES-256-GCM. Where no direct path is available, packets can be relayed through our managed lighthouse service, and stay encrypted end to end between your hosts the whole way.
Your private keys never leave your endpoints
Each host generates its own key pairs locally at enrollment and sends us only the public keys. We do not hold the material needed to decrypt your traffic.
Identity comes from certificates, not IP addresses
Every host carries a certificate binding its public key to its name, address, and groups. Firewall rules are written against that identity, so access does not depend on where a machine happens to sit on the network.
The host firewall denies by default
Inbound and outbound both default to drop. Hosts reach only what you have explicitly allowed, and a policy change is re-evaluated against connections that are already open.
Nebula is open source
Our clients are built on Nebula, the open-source overlay networking protocol that carries your traffic. Nebula, the dnapi library that talks to our API, and the mobile client are all open source, so your security team can audit the cryptography we describe rather than take our word for it.
Certificate authority keys are backed by AWS KMS
Your network's CA key is stored only as ciphertext encrypted under KMS, bound to an encryption context naming your organization, and decrypted transiently for signing operations tied to your organization in the system.
Common questions
No. Session keys are derived directly between your two endpoints during the Nebula handshake, and the private keys involved are generated on your hosts and never sent to us. We do not hold the material required to decrypt your application traffic. We do see connection metadata, such as which hosts are online and the addresses they connect from, along with the timing and volume of any traffic relayed through our managed lighthouse service, and we operate the certificate authority for your network.
Tunnels are established with the Noise IX handshake pattern. Key agreement uses Curve25519 or NIST P-256, bulk encryption uses AES-256-GCM, and the handshake hash is SHA-256. Certificates are signed with Ed25519 or ECDSA P-256.
Sometimes. Whenever a direct path between two hosts is available, they connect peer-to-peer and their traffic does not touch our infrastructure. When no direct path is available and your network is configured to use our managed lighthouse service, packets between those two hosts can be relayed through it. Relayed traffic stays end-to-end encrypted between your hosts: the relay forwards the encrypted payload of a tunnel it is not a party to and holds no session keys for it, so we can observe the timing and volume of that traffic but never its contents in plaintext. The managed lighthouse service is optional and is enabled or disabled per network: you can instead run your own lighthouses on infrastructure you control, in which case we operate no part of that network's data plane and nothing is ever relayed through us.
Blocking or deleting a host in the dashboard immediately stops it from receiving new certificates or configuration, and adds its certificate fingerprint to a blocklist that we distribute to every other host in your network and to the managed lighthouses. Its peers refuse it at their next configuration refresh rather than waiting for its certificate to expire.
Yes. Administrative access is passwordless, using an emailed magic link or your OIDC identity provider, with WebAuthn security keys or TOTP as a second factor before any action can be taken. Network access for endpoints can also be tied to a live identity-provider session, so a host certificate expires when the authorized access window closes.
Documents and contacts
Read the security whitepaper
The full technical description of our trust model, key custody, certificate authority operations, and platform security.