Oten Access

ZERO TRUST CONNECTIVITY

Connect to the required resource, not the entire network.

Oten uses an encrypted overlay to connect User Device Nodes, Server Nodes, and resource routes. Direct paths are preferred when network conditions allow; an encrypted relay path is a fallback when NAT or firewall constraints prevent direct connectivity.

System role: Oten Endpoint + Connectivity Services

Evaluation depends on: Requires Device Trust, resource definitions, and Access Policy.

Policy and desired stateCoordinationApplication trafficOptional encrypted fallback
The Oten Access Control Plane evaluates and distributes policy. Signal coordinates setup. Endpoint and Gateway enforce access while application payload remains in the data plane.

Control, signaling, and traffic have separate responsibilities.

Management / Control

Enrollment, node and resource inventory, Mesh IP, internal DNS, route policy, configuration, and audit. It does not carry application payloads.

Signal

Presence and candidate exchange help authenticated nodes establish or re-establish a path. Signal is not an application proxy.

Data

WireGuard-encrypted traffic follows an authorized direct or relayed path. The data plane does not invent business policy.

Relay

A fallback service forwards encrypted packets when direct connectivity is not feasible. Relay is not Oten Gateway.

Resource policy precedes path selection.

  1. Resolve

    The Agent resolves an internal name or resource from policy-authorized discovery data.

  2. Evaluate

    The Control Plane evaluates the user, device, resource, protocol, and current conditions.

  3. Configure

    The Agent receives scoped peer, route, DNS, and authorization state with bounded validity.

  4. Gather

    Authenticated nodes gather network candidates and exchange path information through Signal.

  5. Connect

    A direct UDP path is attempted when feasible; relay fallback is used only when configured and required.

  6. Explain

    The Agent reports Direct or Relayed state, relevant trade-offs, and policy-safe troubleshooting reasons.

User devices and headless nodes use different enrollment journeys.

Interactive user device

OIDC Authorization Code with PKCE → device registration → posture evaluation → signed policy/configuration → Connected, Restricted, or Blocked.

Headless or server node

A Setup Key bootstraps enrollment only. The enrolled Server Node receives its own identity and key; revoking the Setup Key does not implicitly revoke existing nodes.

Resource scope

Exact hosts and named services are preferred over broad subnets. Routing nodes provide paths; they do not automatically become resources available to users.

The access path exposes actionable state.

  • Connecting or gathering candidates.
  • Direct encrypted path.
  • Relayed encrypted path with a clear performance trade-off.
  • Resource not authorized by policy.
  • Device posture does not satisfy the requested resource.
  • Internal DNS or route resolution failed.
  • Relay is unavailable and no direct path is feasible.
  • Policy or configuration is stale or expired.
  • Authority has been revoked; active-flow behavior is resource- and implementation-specific.

FAQ

Questions security and platform teams ask first.

Is the encrypted overlay itself a Zero Trust system?

No. Tunnel encryption protects the data path. Zero Trust requires identity- and resource-focused policy, device context, bounded decisions, and enforcement that does not grant trust merely because a node is on a network.

Does relay fallback decrypt application traffic?

The architecture is designed so relay forwards end-to-end encrypted packets without decrypting the application payload. Relay metadata, authentication, rate limits, and operational boundaries still require explicit security treatment.

Does relay fallback guarantee connectivity everywhere?

No. It improves connectivity under common NAT and firewall constraints, but does not justify a 100% connectivity claim. Availability, capacity, protocol support, and local network policy still affect the outcome.

Separate resource authorization from network reachability.

Review the system boundaries, direct and relayed paths, and the failure behavior that keeps connectivity claims evidence-safe.