Source-side enforcement
Oten Endpoint applies local controls using qualified device and policy state.
Identity-first access with continuous device trust
Stop granting network access to devices you can no longer trust.
Oten Access limits each user to the private applications, infrastructure, and privileged actions they are authorized to use, then re-evaluates that authority when identity, device posture, policy, or enforcement state changes.
One decision context across Oten Endpoint, the Oten Access Control Plane, and Oten Gateway, with versioned policy and confirmed enforcement at both boundaries.
Resource-side enforcement
Oten Gateway evaluates the connection near the protected destination.
Versioned policy
Components act on explicit desired state rather than ambiguous configuration drift.
Confirmed outcome
Enforcement results and material state changes inform the next evaluation.
The access gap
The access gap appears after login.
Identity is necessary, but it is not enough when device posture changes, network access is broad, or resource authority survives longer than the conditions that created it.
A stolen credential is used from an unknown or compromised device.
- What fails today
- Authentication proves the account, not the device's current security state.
- Oten outcome
- User identity and qualified device identity remain separate mandatory policy inputs.
A VPN user can see an entire subnet.
- What fails today
- Network reachability becomes implicit authority and increases the blast radius of one compromised endpoint.
- Oten outcome
- Access is scoped to named applications, routes, protocols, roles, and time windows.
Endpoint security detects risk, but access continues.
- What fails today
- Endpoint, network, privileged-access, and gateway decisions follow separate automation paths.
- Oten outcome
- Qualified endpoint evidence can trigger a new bounded decision and a confirmed response at required enforcement points.
Production access depends on standing secrets.
- What fails today
- Long-lived keys and shared administrator accounts create durable privilege and weak attribution.
- Oten outcome
- Authority can be constrained by resource, role, protocol, approval, and time to live.
Sensitive data crosses endpoint boundaries.
- What fails today
- Cloud-only controls cannot govern every plaintext workflow on an authorized endpoint.
- Oten outcome
- Supported endpoint controls and persistent-protection architecture extend policy to defined data-in-use workflows.
Product model
Three layers. One decision context.
Oten Access separates local device authority, policy evaluation, and resource-side enforcement while connecting them through versioned state and confirmed outcomes.
Shared context: identity · device · session · resource · policy
Qualify and enforce at the device
Oten Endpoint
Oten Endpoint collects relevant device evidence, maintains local desired and last-known-good state, and applies source-side controls through endpoint-owned enforcement services.
Explore Oten Endpoint →Evaluate policy and distribute state
Oten Access Control Plane
The Oten Access Control Plane combines identity, qualified device context, resource context, and versioned policy to compute access decisions and distribute desired state.
Explore the Control Plane →Protect the resource boundary
Oten Gateway
Oten Gateway enforces identity and device-aware access near private resources. Compatible Gateways can share an explicit Failover Set for equivalent policy and resource scope.
Explore Oten Gateway →Continuous Trust in practice
A developer is connected to production when a mandatory protection signal disappears.
The response is a closed loop from named evidence to a protocol-specific action and a confirmed outcome. A decision alone is not reported as successful enforcement.
- 01
Observe
Oten Endpoint reports the named protection signal, source, observation time, and current policy generation.
- 02
Qualify
Stale, conflicting, unsupported, or unreachable evidence remains explicit and cannot become a pass.
- 03
Decide
The Control Plane evaluates the production database policy and issues a resource- and protocol-scoped response.
- 04
Enforce
Oten Endpoint and Oten Gateway apply the supported control for that session mode.
- 05
Confirm
Each required enforcement point reports Applied, Partial, Failed, or Unknown.
- 06
Recover
Access returns only after remediation produces fresh evidence, a new decision, and the required confirmation.
Active network, HTTP, WebSocket, SSH, database, and other sessions have different re-evaluation, revoke, and confirmation behavior.
Review protocol-specific behavior →Product evidence
One access decision. Evidence at every enforcement point.
Inspect the context, policy version, distribution state, and confirmed outcome at the component that owns each part of the decision.
EndpointSee what the device can prove and what it can enforce.
Endpoint status distinguishes observed evidence, qualified posture, current policy version, local enforcement state, and degraded or recovery conditions.
Review Endpoint architecture →Conceptual product view using synthetic data.
Control PlaneMake the decision context inspectable.
Policy evaluation exposes the subject, device, resource, policy version, decision, reason, distribution, and confirmation state without placing the Control Plane in the application path.
Review Control Plane responsibilities →Conceptual product view using synthetic data.
GatewayEnforce close to the resource.
Gateway status shows the protected resource, active policy version, connection decision, enforcement confirmation, and compatible Failover Set membership where configured.
Review Gateway architecture →Conceptual product view using synthetic data.
Four access outcomes to evaluate
Review all capabilities →Endpoint + Control PlaneDevice Trust
Qualify device evidence for identity-aware policy decisions.
↗Endpoint + Control PlaneZero Trust ConnectivityEstablish encrypted access paths under explicit identity, device, and resource policy.
↗Control Plane + GatewayPrivate App AccessProtect private applications at the resource boundary without broad network exposure.
↗Endpoint + Control Plane + GatewayPrivileged AccessApply stronger context and narrower policy to sensitive administration paths.
↗Extending the trust context
Endpoint Defense and Data Protection can contribute additional evidence and enforcement through their defined product dependencies.
Review capability dependencies →Architecture boundaries
Separate control from the encrypted application path.
The Oten Access Control Plane evaluates and distributes policy. Endpoint and Gateway enforce at their boundaries. Signal coordinates control state, while Relay is used only as an encrypted fallback path when direct connectivity is unavailable.
Policy and desired stateCoordinationApplication trafficOptional encrypted fallback
Deployment choices
Place control and enforcement where your operating model requires.
Deployment changes ownership, failure domains, key custody, data handling, and recovery obligations. Those responsibilities must be explicit before an evaluation becomes a production design.
Managed Control Plane
Oten operates the control services while the customer deploys Endpoint and Gateway components under an agreed responsibility and data-handling boundary.
Self-hosted Control Plane
The customer owns service availability, state, keys, observability, backup, upgrades, and disaster recovery under an explicit responsibility matrix.
Distributed Gateway Data Plane
Policy remains centralized while Data Plane Groups run near protected resources and explicit Failover Sets define compatible runtime takeover.
Evaluation paths
Evaluate Oten Access for your role.
01CISO and Security Architecture
Review trust boundaries, failure behavior, and evidence expectations.
→02IT and Endpoint OperationsEvaluate enrollment, posture, remediation, update, and recovery ownership.
→03Platform Engineering and SREPlan resource-scoped infrastructure and privileged access.
→04SOC and Incident ResponseConnect evidence, policy, guarded response, and confirmation.
→05Compliance and RiskSeparate security architecture from organizational assurance evidence.
→06Procurement and Data ProtectionInspect deployment scope, support boundaries, and evidence requirements.
→Technical resources
Continue with the question you need to answer.
01Platform support
Define the exact release, operating system, resource, protocol, and enforcement scope.
→02Trust CenterSeparate security architecture from disclosure, release, privacy, and assurance evidence.
→03Solution journeysChoose a migration path with failure, rollback, limitation, and evaluation evidence.
→FAQ
Questions security and platform teams ask first.
Is Oten Access a VPN replacement?
Oten Access is designed to replace broad network-level trust with resource-scoped, identity and device-aware access. Whether it replaces an existing VPN depends on the resources, protocols, user journeys, and verified platform coverage in your environment.
Does application traffic pass through the Control Plane?
No. The Oten Access Control Plane evaluates policy and distributes versioned desired state. Application traffic remains in the data plane between Oten Endpoint and Oten Gateway, using a direct encrypted path when available or an encrypted Relay fallback when required.
What happens when device posture changes?
A qualified material change can trigger policy re-evaluation. The next decision may maintain, narrow, degrade, deny, revoke, recover, or restore access according to policy, evidence freshness, and enforcement state.
What is the difference between Signal and Relay?
Signal coordinates control state and connection setup; it does not carry application payload. Relay forwards encrypted traffic only when a direct Endpoint-to-Gateway path is unavailable. Oten Gateway remains the resource-side enforcement point.
How does Gateway failover work?
Oten groups compatible Gateways into a defined Failover Set for equivalent resource scope and policy assumptions. A shared Gateway Deployment, Configuration Profile, or Data Plane Group does not create takeover authority by itself.
How do I verify platform and protocol support?
Use the Product Availability and Platform Support page to define the exact operating system, Oten component versions, resource type, protocol, enforcement action, dependency, limitation, and last verified date for an evaluation. Architecture-level capability descriptions do not replace that scoped support contract.
Technical briefing
Define a technical evaluation around measurable evidence.
Map your identity provider, endpoint fleet, private resources, enforcement boundaries, supported protocols, failure tests, and rollback path with the Oten team.
Do not include passwords, secrets, personal data, or sensitive network details in your request.