Defined Networking secures three distinct communication paths, each with its own trust boundary:

• Endpoint to endpoint. Encrypted peer-to-peer tunnels between the hosts you enroll, carrying your own application traffic.
• Endpoint to the Defined Networking service. The management channel over which an enrolled host receives its certificate, network configuration, and firewall policy.
• Administrator to the Defined Networking service. The web dashboard and public API used to manage networks, hosts, roles, and policy.

Out of scope: the security of your own applications, the operating systems on the endpoints you manage, and the correctness of firewall policy you author for your own network.

Defined Networking operates a hosted control plane for Nebula, an open-source overlay networking protocol. The data plane and control plane are architected with different security properties.

The control plane, operated by Defined Networking, is a multi-tenant API service running in AWS, backed by an encrypted database and an encrypted cache. It issues certificates, distributes configuration, and serves the dashboard and public API. An internal Certificate Authority service performs all private-key operations backed by AWS KMS hardware-based encryption.

The data plane runs on your endpoints. The Defined Networking client, dnclient, runs on each enrolled host and embeds the Nebula library. Hosts build direct, mutually authenticated, encrypted tunnels to one another. Defined Networking operates managed lighthouses that help hosts discover each other’s current network addresses and traverse NAT, and that can relay packets between two hosts when no direct path exists.

Managed lighthouses are optional, and are enabled or disabled per network. A network can optionally use lighthouses you run yourself, on infrastructure you control, in which case Defined Networking operates no part of that network’s data plane.

Your application traffic flows directly between your hosts wherever a direct path is available, and never passes through the Defined Networking API. When two hosts have no direct path between them, packets can be relayed through the managed lighthouse service, or optionally through relays that you run yourself. Relayed traffic remains end-to-end encrypted between your two hosts. When traversing the lighthouse hosted by Defined Networking, Defined Networking can observe packet timing and volume, but not contents.

Your endpoints generate and hold the keys that encrypt your traffic. Defined Networking holds your network’s certificate authority, the connection metadata its lighthouses observe, and your account configuration.

The private keys used to encrypt your traffic are generated on your endpoint at enrollment and never leave it. At enrollment, dnclient generates its own key pairs locally using the operating system’s cryptographic random source and transmits only the public keys to the Defined Networking API. Private keys are written to local state files created with 0600 permissions, and on Windows with an equivalent restrictive ACL.

Each host holds two key pairs, with separate purposes:

• A data plane key pair, used for key agreement in the Nebula handshake described in section 3. It establishes the encrypted tunnels between your hosts, and is never used to authenticate to the Defined Networking service.
• A control plane key pair, used to sign the management requests described in section 4. It authenticates the host to the Defined Networking service, and plays no part in encrypting your traffic.

Both are generated on the host, both match the curve your network was created with, and Defined Networking receives only their public halves. Separating them means the credential that authenticates a host to the service is not the credential that protects its traffic, so neither role can be exercised with the other’s key.

Because session keys are derived directly between two endpoints, Defined Networking does not possess the material required to decrypt your application traffic.

Defined Networking operates the certificate authority for each network. The following are within its custody:

• Your network’s CA private key, stored only as ciphertext encrypted under an AWS KMS key, and decrypted transiently inside the CA service to sign the certificates and configuration responses delivered to your hosts. As the operator of your CA, Defined Networking is technically capable of issuing a certificate for a new host in your network. This is inherent to any managed-PKI model. Section 7 describes the controls around it and the audit trail you can see.
• Your network’s trust bundle. A host’s Nebula configuration is delivered by the Defined Networking service and includes the set of CA certificates that host will trust. That set is not static: it changes when a CA is rotated. Whoever can alter the trust bundle a host receives can add a certificate authority to it, and the host will then accept certificates issued by that authority. Section 4 describes the signature that protects the configuration against alteration.
• Connection metadata. Managed lighthouses learn which of your hosts are online, their public IP address and port, and which hosts query for which peers. Lighthouses terminate their own Nebula tunnels with your hosts to exchange this control information; they do not carry host-to-host application traffic on the direct path.
• Relayed ciphertext. When two hosts cannot establish a direct path, packets can be relayed through a Defined Networking relay. The relay forwards the encrypted payload of a tunnel it is not a party to, and holds no session keys for it. Relaying exposes traffic volume and timing, but not content.
• Account and configuration data: host names, group and role assignments, IP allocations, firewall policy, user accounts, and your audit log.

The connection metadata and relayed ciphertext above apply only to networks using the managed lighthouse service. On a network running its own lighthouses, neither reaches Defined Networking; the certificate authority, trust bundle, account, and configuration data still do.

Traffic between your endpoints is protected by the Nebula protocol: a mutually authenticated, certificate-based tunnel established with a Noise Protocol Framework handshake.

Tunnels are established using the Noise IX handshake pattern. Both parties present a certificate during the handshake, and each verifies the other against your network’s certificate authority before any application data flows. Key agreement uses Curve25519 or NIST P-256, depending on the curve your network was created with. Bulk encryption uses AES-256-GCM, with SHA-256 as the hash.

Every host holds a certificate issued by your network’s CA that binds its public key to its overlay IP address, its name, and the groups it belongs to. Certificates are signed with Ed25519 on Curve25519 networks, or ECDSA P-256, and carry an explicit validity window.

Nebula certificates are not X.509. Nebula defines its own certificate format, carrying only the fields an overlay network needs: a name, the addresses and unsafe networks the host may use, its groups, a validity window, the issuing CA, and the public key. They are not TLS certificates, they cannot be obtained from a public web certificate authority, and they are validated only against the certificate authority for your own network. A Nebula certificate is meaningful inside one overlay network and nowhere else.

There is no shared secret and no static credential common to your fleet. Compromise of one host does not yield credentials for another.

Each endpoint enforces a firewall on its tunnel interface. Both inbound and outbound actions default to drop, and an invalid configured action falls back to drop rather than allow. Rules are evaluated on protocol, port, issuing CA, local CIDR, and the peer’s certificate groups, name, or remote CIDR — identity taken from the certificate, not from a spoofable network address. Connection tracking re-validates established flows when the rule set version changes, so a policy change takes effect on existing connections rather than only on new ones.

Nebula, which implements the data plane described in this section, is open source. So are dnapi, the library that implements the management channel described in section 4, and the mobile client. A security team can review the handshake, certificate parsing and validation, firewall enforcement, and the signing and verification of management messages in source rather than relying on this document. The dnclient desktop and server packages are not open source.

The management channel between an enrolled endpoint and the Defined Networking service is mutually authenticated at the message layer with public-key signatures, in addition to TLS at the transport layer.

An administrator creates a host in the dashboard and receives a single-use, time-limited enrollment code. The client redeems that code once, and in the same operation generates its own key pairs and sends only public keys to the API. The API returns the host’s signed certificate, its network configuration, and a bundle of trusted public keys that the client pins for verifying future responses from the service.

After enrollment, every management request is signed by the host with its own private key — Ed25519 or ECDSA P-256 — over a wrapper containing the request type, payload, and a timestamp. The API verifies that signature against the public keys registered for that host. An unverifiable signature is rejected as unauthorized before the request reaches any handler.

The channel is mutual. Responses that deliver configuration or certificates are signed by the service using your own CA key, and dnclient verifies that signature against the trusted keys it pinned at enrollment, discarding any response that fails verification.

The signature covers the entire configuration document, including the trust bundle. The set of trusted certificate authorities is the most sensitive element of a host’s configuration, since it determines which certificates that host will accept, and Defined Networking treats delivering it as a privileged operation that carries its own authentication rather than relying on transport security alone. A configuration document whose signature does not verify is discarded and never installed. Updates to the trusted keys themselves travel the same path and are verified against the keys the client already holds, so the trust set can only advance from a key the host already trusts.

This authentication is layered on top of the TLS authentication and encryption provided by the HTTPS API, not a substitute for it. TLS protects the exchange in transit; the configuration signature means that a party who terminated or intercepted TLS still could not deliver a trust bundle, a firewall policy, or a certificate that the client would accept without a key the client already trusts.

When a client rotates to a new key, the service ratchets forward on first use of that key and prunes the keys it supersedes.

That ratchet matters if a host’s private key is ever duplicated, as it would be when an enrolled host is cloned. Two hosts then share a single identity, but only until the next update: the first to complete one moves the identity onto a new key, and the key they shared is pruned. As far as the API is concerned, only one of them carries the identity from that point on. The other holds a key the service no longer recognizes, and cannot authenticate again without re-enrolling.

No service can prevent a private key from being copied, since every copy is identical and legitimate. The ratchet does not stop a host from being cloned; it ensures a clone cannot quietly persist alongside the original.

Deleting or blocking a host in the dashboard rejects its management requests and stops further certificate issuance to it. Revocation also propagates to peers: Defined Networking distributes a certificate blocklist of blocked fingerprints in the Nebula configuration pushed to every host in your network and to the managed lighthouses, so a blocked host’s certificate is refused by its peers at their next configuration refresh, rather than only at certificate expiry.

Administrative access to the dashboard and public API is passwordless, multi-tenant, and scoped by role.

There are no user passwords to phish, reuse, or breach. Sign-in uses an emailed magic link, or an OIDC identity provider where your organization has configured single sign-on. Redeeming a magic link yields a session; a second factor is then required to obtain an authorization token that can act on the account. Supported second factors are WebAuthn security keys and platform authenticators, and TOTP.

Credential	Lifetime	Purpose
Magic link	1 hour	Single-use email proof of address
Session token	90 days	Identifies the user; insufficient alone to act
Authorization token	16 hours	Issued after a second factor; authorizes actions

Sensitive operations — deleting an organization, changing an authenticator — additionally require re-authentication within a short window.

Tokens are 32 bytes drawn from the platform cryptographic random source, base64url-encoded with a type prefix so a leaked token is identifiable by kind. Care is taken that a token never appears in plaintext in the service’s own records, including internal service logs. A token’s string representation is a SHA-256 hash of its value, so even incidental logging emits the hash rather than the token itself. The hash is still enough to correlate events involving the same token, without recording anything that could be replayed. Session state lives on the server with a fixed expiry rather than inside the token itself, so a token carries no account data of its own and revoking a session takes effect on the next request.

Programmatic access uses organization-scoped API keys carrying an explicit permission set, enforced per endpoint. Key secrets are stored only as a hash, so a secret is shown once at creation and cannot be recovered afterward by anyone, Defined Networking included. A lost key is replaced rather than retrieved.

The API is multi-tenant, with organization-scoped access enforced on every request. Authorization is declared per handler rather than assumed: each endpoint states which actor types it accepts — user, API key with named permissions, OIDC user, or enrolled host — and requests from an actor outside that set are rejected centrally before the handler runs.

Administrative changes are recorded in an audit log you can read, covering users, hosts, roles, networks, API keys, certificate authorities, tags, organizations, routes, identity providers, and domains, with the actor and event type for each entry.

• Transport. HTTPS only; plaintext HTTP is redirected. Strict-Transport-Security is set to one year, including subdomains.
• Response headers. Content-Security-Policy: default-src 'none', X-Content-Type-Options: nosniff, and X-Frame-Options: DENY.
• CORS. Explicit origin allowlists, with a deliberate deny-by-default when no origins are configured.
• Abuse controls. A sliding-window rate limiter, per-organization limits, and a request body size cap.

Network membership can be tied to a live identity-provider session rather than granted indefinitely at enrollment.

Where your organization configures endpoint single sign-on, a user authenticates to your identity provider through dnclient, and the resulting host certificate is issued with a validity window that never exceeds the authorized access window. When that window closes, the certificate expires and peers stop accepting the host.

Host certificate lifetime is always bounded by the signing CA’s own expiry, and can be shortened, reducing the window in which a compromised host remains accepted by its peers. The blocklist described in section 4 closes that window ahead of expiry.

All private-key operations for your certificate authority run in a dedicated service backed by AWS KMS.

A CA private key exists in plaintext only transiently, in the memory of the CA service, while signing. At rest it is stored solely as a KMS ciphertext blob. Encryption and decryption are bound to an encryption context containing the key type, the owning organization ID, and the CA certificate itself. KMS enforces that a ciphertext can only be decrypted by presenting the identical context, so a ciphertext belonging to one tenant cannot be decrypted in the context of another, even given access to the stored blob.

Certificates are issued only through the CA service, which logs every encrypt and decrypt operation with a request ID and the organization ID, producing a correlatable record of CA key use. CA rotation is supported, allowing your network to move to a new CA without re-enrolling every host at once. Certificate authorities appear as first-class objects in your audit log.

The Defined Networking service runs on AWS, with infrastructure defined as code and reviewed through the same process as application changes.

Public traffic terminates on a load balancer enforcing a TLS 1.2 and 1.3 policy with managed certificates. Traffic is re-encrypted from the load balancer to application instances, rather than traversing the private network in plaintext. Cache traffic is encrypted in transit.

The production database has storage encryption enabled, uses identity-based database authentication, and has deletion protection enabled. The cache has at-rest encryption enabled. Sensitive application secrets — identity-provider client secrets and TOTP seeds — are additionally encrypted with KMS at the application layer, bound to an encryption context naming the organization and the specific provider or user, so they are not readable from a database dump alone.

The production database uses automated backups: a daily snapshot plus continuous incremental backup, giving point-in-time restore across a 30-day retention window.

Application instances run in private subnets. Only the load balancer is exposed to the internet. Defined Networking operates its own internal Nebula network for administrative access to production infrastructure, so the same certificate-based, default-deny model described in section 3 governs its own operators.

The service is built to industry-standard operational practice, with internal logging, monitoring, and alerting across its infrastructure and application components. Alerts reach an on-call rotation, so issues are addressed as soon as they are detected. This telemetry serves Defined Networking’s own operations and is not customer-facing; the audit log described in section 5 is the customer-visible record of activity in your organization.

Function	Primitive	Where used
Tunnel handshake	Noise IX	Endpoint to endpoint
Key agreement	Curve25519 or NIST P-256 ECDH	Endpoint to endpoint
Tunnel encryption	AES-256-GCM	Endpoint to endpoint
Handshake hash	SHA-256	Endpoint to endpoint
Certificate signature	Ed25519 or ECDSA P-256 with SHA-256	Network CA to host
Management request signature	Ed25519 or ECDSA P-256 with SHA-256	Endpoint to service
Management response signature	Network CA key via KMS-backed CA service	Service to endpoint
Transport security	TLS 1.2 / 1.3	Administrator and endpoint to service
CA key wrapping	AWS KMS with encryption context binding	Control plane at rest
API key storage	bcrypt	Control plane at rest
Token generation	32 bytes, platform CSPRNG	Control plane
Token log representation	SHA-256	Control plane logging

If you believe you have found a security issue in the Defined Networking service or in Nebula, please report it to security@defined.net. Machine-readable contact details are published at /.well-known/security.txt.

• Data Processing Agreement
• Subprocessors
• Service Level Agreement
• Privacy Policy

For questions this document does not answer, or to request security documentation for a vendor review, contact Defined Networking.

Last updated: 2026-09-02