Operational consequence
The system that grants access can become the point that cannot revoke it, while backup, upgrade, and key-recovery responsibilities remain unowned.
SELF-HOSTED ZERO TRUST
Keep control in your environment without hiding the operational responsibility.
Separate policy services, coordination services, durable state, keys, and distributed enforcement, then assign availability and recovery ownership for every dependency.
System role: Customer solution owner + Oten solution architecture
Evaluation depends on: Requires a bounded component, platform, protocol, integration, migration, rollback, and evidence scope.
IDENTITYOten or enterprise IdPUser assurance
PDPAccess Control PlaneDecision + desired state
SOURCE PEPOten EndpointDevice evidence
DESTINATION PEPOten GatewayResource policy
RESOURCEPrivate applications & servicesScoped access
Start with the operating failure, not a feature list.
Who this is for
Organizations that require customer-operated control services for sovereignty, data residency, contractual, or infrastructure reasons.
The problem today
A self-hosted access system is treated as one container even though policy, state, keys, Signal, Relay, Gateway, identity, audit, and recovery fail differently.
Desired outcome
Customer-operated services use explicit failure domains, durable state, key custody, observability, backup, restore, upgrade, rollback, and distributed Gateway boundaries.
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.
Model
Map services, state, keys, traffic, trust boundaries, data regions, and owners.
Build
Deploy redundant services and dependencies across the defined failure domains.
Integrate
Connect identity, resources, audit, certificates, Signal, Relay, Endpoint, and Gateway.
Test
Run backup, restore, upgrade, rollback, partial failure, lease expiry, and key-recovery scenarios.
Operate
Monitor capacity, health, security, drift, release compatibility, and incident actions.
Components and integrations retain distinct authority.
Required Oten components
Customer-operated Access Control Plane services, state, Signal, Relay, Oten Endpoint, Oten Gateway, and required supporting infrastructure.
Required integrations
Identity provider, database, cache or queue where required, KMS or HSM, certificates, load balancing, DNS, observability, backup, SIEM, and protected resources.
Known limitation
Customer operation changes the responsibility boundary; it does not remove the need for supported versions, tested recovery, capacity planning, or Oten component compatibility.
Migration preserves a tested way back.
Build a nonproduction failure domain
Deploy the full dependency and ownership model.
Restore before onboarding
Prove state and key recovery into a clean environment.
Pilot one Gateway group
Validate policy, Signal, Relay, direct paths, LKG, and audit.
Expand by explicit boundary
Add regions and Failover Sets only after failure evidence passes.
Use the evaluation to collect proof, not impressions.
- Dependency and responsibility inventory.
- Backup and clean-environment restore.
- Key rotation and recovery.
- Control, Signal, Relay, and Gateway failure injection.
- LKG expiry and restrictive convergence.
- Upgrade, rollback, and compatibility verification.
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.