Security

Trust identities, not addresses.

Carrier addresses change and relay IPs can be redirected. Nexus Atlas anchors trust in cryptographic identities while keeping the hosted traversal relay outside the customer payload boundary.

Noise IKX25519ChaCha20-Poly1305
Security model

Three independent trust decisions.

The control plane publishes availability. The signed map authenticates that publication. Each relay then proves the static identity named by the map.

01

Endpoint identity

Atlas peers authenticate their static keys through the tunnel handshake. A changing carrier address does not change who the node is.

02

Relay identity

Every relay uses a pinned static key. Redirecting its IP is insufficient to impersonate the server.

03

Map authority

The relay map is Ed25519-signed with an offline key and checked against the public key built into Atlas.

Metadata boundary

What a hosted traversal relay can—and cannot—observe.

“Encrypted” should not be used as a substitute for a precise data-boundary explanation.

The relay can observe

  • Outer source address and port
  • Authenticated node identity
  • Destination node identity
  • On a relay-to-relay path, the relay that handed over the frame
  • Session timing and liveness
  • Forwarded byte counters

The relay cannot observe

  • Inner IP packets
  • Application payloads
  • Video or sensor contents
  • Command-and-control messages
  • Decrypted Atlas tunnel traffic
Exit boundary

An exit is the far end of the tunnel, not a relay.

A hosted exit carries a device’s traffic on to the internet. How hosted exits are chosen

  • It decrypts the traffic it carries to the internet.So it sees what any internet gateway sees — destination addresses, timing and volume, and the contents of anything not protected by its own encryption, such as TLS.
  • Relays stay outside the payload; an exit is inside it by definition.Which is why private estates can run their own.
Control-plane resilience

A directory outage does not become a tunnel outage.

Atlas separates discovery from ongoing data-plane operation and retains a last-known-good trust anchor locally.

01

Outside-in verify

A relay is tested from outside before the control plane publishes it.

02

Sign offline

Canonical relay-map data is signed by a key that is not available to the serving control plane.

03

Cache verified

Clients store the last valid map and reject older signed maps as rollbacks.

04

Authenticate relay

The selected address must still prove possession of the relay identity named in the map.

Scope note. This page describes hosted Nexus Atlas Traversal relays, which forward opaque Atlas datagrams. Atlas multi-hop mesh routing is a separate forwarding mode with hop-by-hop protection and a different trust boundary.
Get early access

Bring us the network you cannot control.

Apply as a pilot partner if you have a deployment ready to test, or start evaluating Nexus Atlas Traversal as a future customer. Tell us enough to understand the endpoints, carriers, regions, and operational constraints involved.

01

Pilot partner

Run an early deployment with direct engineering contact and help shape priorities through real-world feedback.

02

Customer evaluation

Research architecture, security, deployment options, and commercial fit before committing to a pilot.

Already enrolled? Open the console
Early-access applicationUsually answered by the product team

Your application is sent to the Nexus Atlas product team. You can also email office@nexusatlas.io.