Security architecture
Trust boundaries, credential purpose, policy integrity, bounded authority, privacy, failure behavior, and Continuous Trust semantics.
Review the security model →TRUST CENTER
Separate security architecture from assurance evidence.
The Security Architecture page explains how Oten Access is designed to behave. The Trust Center organizes the evidence required to evaluate Oten's software supply chain, disclosure process, release handling, deployment responsibilities, privacy boundaries, and external assurance scope.
System role: Security engineering + Organizational security owner
Evaluation depends on: Public evidence is scoped to the exact product, service, release, report, and validity period it covers.
IDENTITYOten or enterprise IdPUser assurance
PDPAccess Control PlaneDecision + desired state
SOURCE PEPOten EndpointDevice evidence
DESTINATION PEPOten GatewayResource policy
RESOURCEPrivate applications & servicesScoped access
Assurance is organized around inspectable artifacts.
Vulnerability disclosure
Reporting scope, safe handling expectations, acknowledgement flow, coordinated disclosure, and advisory linkage.
Review disclosure guidance →Security advisories
Affected versions, severity, impact, mitigation, fixed versions, and verification guidance for published product security issues.
Open advisories →Signing and verification
Release identity, artifact verification, update trust, rollback protection, and key-compromise response requirements.
Review verification requirements →Privacy and data handling
Purpose, collection boundaries, access control, retention, residency, deletion, subprocessors, and incident responsibilities.
Review data handling →Platform and release scope
The exact Agent, Gateway, Control Plane, operating-system, protocol, and enforcement combinations qualified for an evaluation.
Review support boundaries →Release trust extends from source change to installed component.
- Define protected source control, review, build, dependency, and release responsibilities.
- Bind each distributable to a version, build identity, platform signing identity, checksum, and release record.
- Verify update manifests, payload integrity, compatibility, staged rollout, and rollback behavior independently.
- Publish supported-release and critical-update expectations with affected-version scope.
- Make signing-key rotation, compromise, revocation, and trust-bundle recovery explicit.
- Provide software bill of materials and dependency evidence only for the exact release they represent.
Customer and Oten responsibilities change by deployment model.
Managed services
The service agreement must identify availability, incident communication, data handling, subprocessor, regional, access-control, backup, and recovery scope.
Self-hosted control
The customer owns the control-service infrastructure, durable state, keys, observability, upgrades, backups, disaster recovery, and supporting dependencies defined in the deployment design.
Distributed enforcement
The customer owns Endpoint and Gateway placement, platform prerequisites, network reachability, resource definitions, policy operation, certificates, staged rollout, and local recovery.
Assurance language names the exact assessed boundary.
Next in Oten Access
Continue the technical evaluation.
Evaluate security behavior and assurance evidence separately.
Start with the trust model, then require artifacts that match your exact deployment and release scope.