Oten Access

CAPABILITY DEPENDENCIES

Capabilities unlock in the dependency order of trust.

Oten does not place deep enforcement ahead of identity, device trust, and a reliable control path. This sequence is organized by security outcome and technical dependency, not by an unconnected feature checklist.

  1. Phase1

    DEPENDENCY 1

    Device Trusted

    Enroll, identify, manage, and evaluate the posture of each device before it becomes an access subject.

    • Shared Agent foundation and secure IPC
    • Device enrollment and inventory
    • Posture evidence and group policy
    • Role-based administration and audit
    • Health Score validation and reason model
  2. Phase2

    DEPENDENCY 2

    Zero Trust Connectivity

    Connect trusted devices to authorized resources through an encrypted, identity-aware overlay.

    • WireGuard data plane and resource routing
    • Signal, STUN, and encrypted relay fallback
    • Internal DNS and default-deny resource policy
    • OIDC native-client enrollment with PKCE
    • Setup Key and Linux connect-only journey
    • Gateway foundation
  3. Phase3

    DEPENDENCY 3

    Verified Access

    Enforce private application, infrastructure, and privileged access near the resource.

    • Identity-aware reverse proxy
    • Resource and route policy matrix
    • Signed Configuration Profile and group rollout
    • Explicit Data Plane Group and Failover Set topology
    • JIT certificates and brokered credentials
    • PAM server and Agent integration
  4. Phase4

    DEPENDENCY 4

    Protected Endpoint

    Bring endpoint-security and data-protection evidence into the shared trust context.

    • Platform-native sensors and normalized telemetry
    • Detection, response, and guarded isolation
    • Application and local network controls
    • Endpoint data-in-use Policy Enforcement Point
    • Oten Guard and Oten Protector integration
  5. Phase5

    DEPENDENCY 5

    Autonomous Defense

    Correlate cross-product evidence and execute bounded, recoverable response playbooks.

    • Cross-product correlation and investigation
    • Threat hunting and security evidence graph
    • Guarded SOAR and response playbooks
    • Closed-loop access, endpoint, and data response
    • Enforcement confirmation and evidence-based recovery

SECURITY EVIDENCE

External claims require evidence and an accountable owner.

Device Trust

Confirm platform-specific enrollment, identity, posture, and Health Score behavior.

Connectivity

Validate direct and relayed path behavior across NAT, firewall, capacity, and reconnect conditions.

Gateway

Validate route modes, signed rollout, node eligibility, fencing, failover, and session behavior.

Active revocation

Publish behavior and closed-loop latency by network, L7, WebSocket, SSH, database, Kubernetes, and PAM mode.

Self-hosted

Publish install, upgrade, backup, restore, responsibility, support, availability, and residency boundaries.

Hybrid cryptography

Define algorithm negotiation, downgrade resistance, key lifecycle, interoperability, and scoped assurance evidence for X25519 and ML-KEM.

This sequence describes technical dependencies only. It does not present release state, schedule, or delivery commitments. For term definitions, use the Technical Glossary.

Discuss rollout dependencies in your environment.

Review the identity, device evidence, policy integrity, and enforcement foundations required for the access outcomes you need.

Review capability dependenciesExplore technical architecture