Reduce broad network exposure
Prefer named resources and exact routes to full-subnet authorization.
SOLUTION JOURNEYS
Start with the access boundary you need to change.
Whether you are replacing broad network access, adding device trust, or protecting privileged paths, Oten Access starts by identifying the subject, device, resource, policy, and enforcement boundary.
System role: Solution architecture
WORKFORCEPrivate resource accessIdentity + Device
OPERATIONSJIT production accessScoped authority
GOVERNANCECorrelated evidenceDecision + Outcome
DEPLOYMENTSelf-hosted controlExplicit ownership
HYBRID WORKFORCE
Private access from anywhere, with trust that does not depend on location.
Oten Endpoint establishes device identity and posture; Access Policy limits the resource; an encrypted data path connects directly or through relay fallback; and Oten Gateway defines the resource-side enforcement boundary for application policy.
Who this is for
IT and security teams supporting employees and contractors who work across offices, homes, and untrusted networks.
The problem today
A traditional VPN authenticates once and then exposes the whole subnet. A healthy laptop and a compromised one look identical to the network, and access does not react when device posture slips mid-session.
Enroll
Bind the employee and approved device to the organization, with visible approval and next-step state.
Verify
Qualify posture evidence and show failed, stale, unsupported, or unknown checks with remediation.
Discover
Expose only policy-authorized applications, services, and resource names.
Connect
Apply resource policy, then establish an encrypted direct or relayed path without implying relay is insecure.
Respond
A meaningful trust change can warn, restrict, or block affected resources according to supported enforcement behavior.
Audit
Correlate user, device, resource, policy version, path, decision, and enforcement result.
Separate user and device trust
Successful authentication does not turn an unknown or stale device into a device with current qualified trust.
Make denial actionable
Show the safe reason, affected resource, last evidence, and remediation path.
PRIVATE APPLICATIONS
Replace public exposure with resource-side enforcement.
Oten Gateway protects named private applications near the resource. Identity, qualified device context, route policy, and session context determine whether a request can reach the approved upstream.
Who this is for
Teams running internal web apps, admin consoles, and APIs that today sit behind a VPN, or worse, a public URL with a login page.
The problem today
Publishing an app so remote users can reach it widens the attack surface, while a VPN drops users onto the network next to the app instead of scoping them to the single route they actually need.
Identify the resource
Define the private application, route, protocol, sensitivity, and approved upstream contract.
Qualify the subject and device
Use configured identity assurance and current device evidence as separate policy inputs.
Evaluate route policy
Compute a resource-specific decision under an immutable policy version and current session context.
Enforce near the resource
Oten Gateway removes untrusted identity headers and forwards only an authorized request.
Confirm the outcome
Record the policy version, route, decision reason, enforcement result, and current session state.
Trust inputs
Identity assurance, qualified device state, resource context, route, session, and policy version.
Components
Oten Endpoint, the Oten Access Control Plane, Oten Gateway, and the configured identity provider.
Next step
Review Private App Access and the Gateway resource-side enforcement boundary.
Review Private App Access →DEVOPS & SRE
Scope production access by resource, role, and time.
The target journey moves engineers from standing privilege toward JIT access from a device with current qualified trust, with approval, short-lived authority, protocol-specific session controls, and an immutable review trail.
Who this is for
Platform, SRE, and infrastructure engineers who reach production SSH, databases, and Kubernetes, often through standing accounts and shared keys.
The problem today
Long-lived credentials and always-on privileged accounts mean one leaked key or stolen laptop can touch production, and after-the-fact logs rarely tie an action back to a specific person, device, and approval.
Request
Select the SSH, database, Kubernetes, or internal tooling resource and the required role and duration.
Approve
Apply separation of duty, approval expiry, risk, and device requirements without silent self-approval.
Issue
Broker a short-lived certificate or credential scoped to the resource and role.
Connect
Use the supported native or proxied flow without disclosing a standing secret where possible.
Monitor
Capture metadata or session evidence under an explicit privacy and retention policy.
Revoke and review
End authority at TTL or supported revoke, then correlate request, approval, device, credential, and session outcome.
JIT instead of standing access
Privilege exists only for the approved resource, role, and time window.
Device Trust as an additional gate
A correct role cannot override a device that fails the production resource's required policy.
Break-glass with stronger evidence
Emergency access increases authentication, notification, audit, and post-event review.
REGULATED ORGANIZATIONS
Connect access, endpoint, and evidence in one trust model.
Oten Access is designed to correlate user identity, device evidence, resource policy, privileged-session context, and data-control events. This can improve auditability, but it does not create compliance without the organization's own policy, configuration, operation, and legal governance.
Who this is for
Security, risk, and compliance owners in regulated sectors assembling evidence for ISO 27001, SOC 2, or GDPR control objectives.
The problem today
Access, endpoint, and data controls live in separate tools, so producing one trail that shows who reached what, from which device, under which policy, and whether enforcement actually applied, stays slow and manual.
Device assurance
Enrollment, posture, evidence freshness, restriction, and quarantine, subject to the verified platform matrix.
Least-privilege policy
Resource-, protocol-, role-, and time-scoped access. Customer policy design remains an operational responsibility.
Privileged access evidence
JIT, approval, credential, and session controls with explicit scope and privacy boundaries.
Data controls
Endpoint data-in-use enforcement coordinated with Oten Protector by supported platform and channel.
Decision and enforcement audit
Correlates policy version, reasons, targeted enforcement points, acknowledgements, and outcome.
Deployment governance
Managed, self-hosted, and distributed data-plane boundaries require a responsibility and residency model.
SELF-HOSTED DEPLOYMENT
Control where policy runs and where traffic flows.
The self-hosted architecture separates Control Plane services from distributed Data Plane Groups near resources. Customer control includes responsibility for state, keys, capacity, observability, backup, restore, upgrade, and incident operation.
Who this is for
Organizations that must keep policy decisions and traffic inside their own infrastructure for sovereignty, data residency, or contractual reasons.
The problem today
A self-hosted control plane is not a single container. Without redundant services, key custody, and tested backup and restore, the system that grants access can become the single point that revokes it.
Control services
Deploy, scale, patch, monitor, and recover policy, management, Signal, Relay, and supporting state.
Database, cache, and queue
Design HA, backup, restore, upgrade, and data integrity for each required dependency.
Signing and encryption keys
Define custody, separation of duties, backup, rotation, trust-bundle rollout, and emergency recovery.
Signal and Relay capacity
Plan regional endpoints, firewall policy, metadata handling, authentication, availability, and throughput.
Gateway Data Plane
Place nodes near resources with explicit Configuration Profiles, Data Plane Groups, and Failover Sets.
Identity and audit integrations
Operate IdP availability, federation policy, audit export, SIEM capacity, retention, and access control.
- Stable DNS and load-balancer endpoints across defined failure domains.
- Tested backup and restore, key recovery, compatibility, and rolling upgrade.
- Metrics, logs, alerts, failure injection, rollback, and security patch ownership.
- A support window and responsibility matrix that covers every production dependency.
Next in Oten Access
Continue the technical evaluation.
Map Oten Access to your environment.
Review your identity provider, endpoint fleet, private resources, enforcement boundaries, and rollout dependencies with the Oten team.