Oten Access

CONTRACTOR AND BYOD ACCESS

Grant one approved resource without enrolling an unmanaged device into the network.

Bound external access by identity, sponsor, resource, session, device evidence available for the supported mode, and an explicit expiry date.

System role: Customer solution owner + Oten solution architecture

Evaluation depends on: Requires a bounded component, platform, protocol, integration, migration, rollback, and evidence scope.

Plan an evaluationReview platform support
The Access Control Plane makes policy decisions; Oten Endpoint and Oten Gateway enforce at opposite sides; Signal coordinates paths and Relay only forwards encrypted fallback traffic.

Start with the operating failure, not a feature list.

Who this is for

Application owners, procurement, and security teams onboarding contractors, partners, and bring-your-own-device users for a narrow business task.

The problem today

External users receive a VPN account, broad network reachability, or a permanently public application because full device management is unavailable.

Operational consequence

Sponsor ownership, device assurance, expiry, and data handling become unclear, and access often survives the contract or task.

Desired outcome

External authority is scoped to the named resource and session mode, with sponsor ownership, bounded evidence, expiry, and actionable denial.

Decision boundary

Define the subject, device, resource, protocol, policy version, enforcement points, confirmation requirement, and recovery owner.

The Oten journey stays connected from evidence to outcome.

  1. Sponsor

    Name the internal owner, external identity, resource, purpose, and end date.

  2. Choose the mode

    Use the verified agent, browser, clientless, or managed-device journey appropriate to the resource.

  3. Apply policy

    Require the identity, device evidence available for that mode, session constraints, and resource route.

  4. Monitor

    Record access, renewal, denial, policy change, and sponsor activity.

  5. Expire

    Remove authority at the approved end date or earlier sponsor revocation.

Components and integrations retain distinct authority.

Required Oten components

Access Control Plane, Oten Gateway for application enforcement, Oten Endpoint where an agent journey is permitted, and identity services for the external subject.

Required integrations

External identity federation, sponsor workflow, application owner, device management where applicable, data policy, and audit export.

Known limitation

An unmanaged or browser-only device cannot inherit evidence and enforcement available only through a qualified managed Endpoint.

Migration preserves a tested way back.

  1. Select one resource

    Choose a bounded external workflow with a named owner and expiry.

  2. Verify the access mode

    Test identity, device limitations, session behavior, denial, and data handling.

  3. Move the cohort

    Replace the VPN or public route for the selected users only.

  4. Close legacy authority

    Remove old accounts and routes after sponsor and rollback checks.

Use the evaluation to collect proof, not impressions.

  • Sponsor, resource, purpose, and expiry linkage.
  • Agent, browser, and unmanaged-device limitations.
  • Unauthorized resource discovery.
  • Session and download behavior.
  • Sponsor revoke and automatic expiry.
  • Legacy account and route removal.

Next in Oten Access

Continue the technical evaluation.

Turn this journey into a bounded proof of concept.

Define success, limitation, failure, recovery, and rollback evidence before changing the production access boundary.

Plan an evaluationReview the architecture