# Zero Trust in Octelium > Octelium documentation. Canonical page: . Zero trust is a security model in which network location does not create implicit trust. Access to protected resources is explicitly authenticated and authorized according to least privilege, using identity, resource state, device posture, and other contextual signals rather than assuming that a request is trustworthy because it originates from an internal network. [NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final) formalizes the main principles and logical architecture of zero trust. Zero trust is not a product category or a single protocol. It is a security model that can be implemented through different architectures and enforcement mechanisms. This page maps the principles and logical architecture described by NIST SP 800-207 to concrete Octelium mechanisms. Each section links to the relevant documentation so that the architecture and behavior can be examined directly. *Diagram: ZeroTrust.* [View the diagram on the canonical HTML page](https://octelium.com/docs/octelium/latest/overview/zero-trust). ## How Octelium Applies Zero Trust - **Resources are protected directly.** Protected applications, APIs, SSH servers, databases, Kubernetes clusters, DNS services, TCP/UDP applications, protected public resources, and managed containers are represented by *Services*. Access is authorized against the *Service* and its request context rather than inferred from access to the network containing the upstream resource. Read more about *Services* [here](https://octelium.com/docs/octelium/latest/management/core/service/overview.md). - **Network location does not create implicit trust.** Connecting to an Octelium *Cluster* or reaching a *Service* does not itself grant access. Human and workload subjects are represented as *Users* and access the *Cluster* through *Sessions*. Human *Users* can authenticate through OpenID Connect or SAML 2.0 *IdentityProviders* and built-in *Authenticators*, while workloads can authenticate through OAuth2 client credentials, bearer access tokens, authentication tokens, or OIDC assertions from external workload identity systems such as GitHub Actions, cloud providers, and Kubernetes clusters. Read more about *IdentityProviders* [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md), *Credentials* [here](https://octelium.com/docs/octelium/latest/management/core/credential.md), and *Sessions* [here](https://octelium.com/docs/octelium/latest/management/core/session.md). - **Communication is secured regardless of network location.** Private client-based access is carried through encrypted WireGuard or QUIC tunnels, while public clientless access uses HTTPS and standard web authentication flows. The same *Service*, identity, *Policy*, and audit model applies whether the request originates from a private client connection or a public clientless access path. Read more about how Octelium works [here](https://octelium.com/docs/octelium/latest/overview/how-octelium-works.md). - **Access is explicitly authorized through a policy enforcement and decision architecture.** Requests pass through the *Service*'s identity-aware proxy, [*Vigil*](https://octelium.com/docs/octelium/latest/reference/components.md#vigil), which acts as the policy enforcement point (PEP). Vigil builds the request context and sends it to [*Octovigil*](https://octelium.com/docs/octelium/latest/reference/components.md#octovigil), which acts as the policy decision point (PDP), for an authorization decision. This architecture maps directly to the logical PEP/PDP model described by NIST SP 800-207. Read more about the request lifecycle [here](https://octelium.com/docs/octelium/latest/overview/how-octelium-works.md). - **Access decisions use dynamic context.** *Policies*, written in [CEL](https://cel.dev/) or [OPA](https://www.openpolicyagent.org/), can evaluate the *User*, *Group* memberships, *Session*, *Device*, authentication state, *Service*, *Namespace*, geolocation, request context, and arbitrary attributes supplied by external systems such as SIEM, threat intelligence, on-call management, and other security or operational tools. Read more about *Policies* [here](https://octelium.com/docs/octelium/latest/management/core/policy.md) and extending access control with attributes [here](https://octelium.com/docs/octelium/latest/management/core/policy.md#extending-access-control). - **Device state and posture can contribute to authorization.** When a *Session* is associated with a *Device*, *Policies* can use current Device information as part of the access decision. Where posture information is available, policy decisions can also incorporate signals from device-management, endpoint-security, or posture systems rather than relying only on user identity. Read more about *Devices* [here](https://octelium.com/docs/octelium/latest/management/core/device.md). - **Authentication and authorization are continuously reevaluated.** *Session* access tokens are not treated as sufficient stateless proof of authorization. Octelium resolves current *Session*, *User*, *Group*, *Device*, and policy state during authorization, so rejecting or deleting a *Session*, disabling a *User*, or changing *Policies* can affect subsequent access without waiting for a long-lived token to expire. Authentication strength is tracked through authenticator assurance levels (AAL), and *Users* can be required to re-authenticate using FIDO2/WebAuthn/Passkey, TPM 2.0, or TOTP *Authenticators*. Read more about *Sessions* [here](https://octelium.com/docs/octelium/latest/management/core/session.md) and *Authenticators* [here](https://octelium.com/docs/octelium/latest/management/core/authenticator.md). - **Access activity is continuously logged and exported.** Octelium emits structured access *Logs* for allowed and denied access at the granularity supported by each *Service* mode. Logs can identify the *User*, *Session*, *Device*, *Service*, authorization result, matching *Policy* and rule, and protocol-specific request or connection information such as HTTP paths and methods, database queries, Kubernetes operations, SSH session information, DNS requests, and TCP/UDP flow metadata. Logs are emitted in real time to OpenTelemetry OTLP receivers for integration with observability, logging, and SIEM systems. Read more [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md). ## Additional Least-Privilege Mechanisms The following Octelium capabilities are not separate NIST tenets, but they further reduce authorization scope, standing access, and credential exposure. - **Application-layer-aware authorization.** Because many *Services* are implemented as application-aware identity-aware proxies, *Policies* can authorize requests using protocol-specific context. This can include HTTP method, path, headers, query parameters, and serialized JSON body fields; database query context; Kubernetes API verb, resource, namespace, and API version; SSH user; DNS request information; and other mode-specific fields. Read more about L7-aware Policies [here](https://octelium.com/docs/octelium/latest/management/core/policy.md#l7-aware-policies). - **Dynamic secretless access.** *Users* can access protected APIs, SSH servers, PostgreSQL and MySQL databases, Kubernetes clusters, and mTLS-protected resources without receiving the upstream API key, password, private key, kubeconfig, or client certificate private key. Upstream credentials are stored as *Secrets* and used dynamically by the *Service* when authenticating to the upstream, so long-lived upstream application credentials do not need to be distributed to *Users* or workloads. Read more [here](https://octelium.com/docs/octelium/latest/management/core/service/secretless.md). - **No inherent superuser or implicit administrative privilege.** Octelium intentionally has no built-in "admin" or "superuser" *User*. Access to every *Service*, including the API Server itself, must be explicitly granted through *Policies* and can be constrained by identity, time, authentication state, device state, resource context, and request context. Read more [here](https://octelium.com/docs/octelium/latest/management/core/user.md#privileged-users). - **Context-aware dynamic configuration and routing.** Authorization is not the only behavior that can be selected from request context. Octelium can dynamically choose upstreams, upstream accounts and credentials, protocol-specific configuration, and routing behavior using CEL or OPA expressions evaluated from the current request context. Read more about dynamic configuration [here](https://octelium.com/docs/octelium/latest/management/core/service/dynamic-config.md). - **Sandboxed execution with identity-based access through Cordium.** [Cordium](https://octelium.com/docs/cordium/latest/overview/intro.md) is an open-source, self-hosted sandbox platform built on Octelium. Processes running inside Cordium *Workspaces*, including developer tools, automated workloads, and AI agents, can access authorized Octelium *Services* through Workspace identity without distributing upstream API keys, SSH keys, database passwords, or other application credentials into the sandbox. ## What Zero Trust Is Not Zero trust is not defined by a single technology or product label. - **Network segmentation alone is not zero trust.** Segmentation and microsegmentation can be useful enforcement mechanisms inside a zero trust architecture, but network location or membership in a network segment must not by itself create implicit trust. - **MFA alone does not create a zero trust architecture.** Strong authentication is an important input to access decisions, but successful authentication should not automatically grant broad or unrelated access. Authorization still needs to be explicit, least-privileged, and based on the resource and current context. - **VPN connectivity alone is not zero trust.** A secure tunnel can be one transport mechanism inside a zero trust architecture, but establishing the tunnel should not itself grant broad network access. Octelium uses encrypted tunnels for private client-based access while still authorizing access against individual *Services* and *Policies*. ## Where to Go Next - **See the architecture:** [How Octelium Works](https://octelium.com/docs/octelium/latest/overview/how-octelium-works.md) walks through the identity-aware proxy model, the request lifecycle, the PEP/PDP separation, private and clientless access paths, and the control plane. - **See the enforcement model:** [*Policies* and access control](https://octelium.com/docs/octelium/latest/management/core/policy.md) documents the policy-as-code model, request context, Policy evaluation behavior, and L7-aware authorization. - **Understand the resource model:** [*Services*](https://octelium.com/docs/octelium/latest/management/core/service/overview.md), [*Users*](https://octelium.com/docs/octelium/latest/management/core/user.md), [*Sessions*](https://octelium.com/docs/octelium/latest/management/core/session.md), and [*Devices*](https://octelium.com/docs/octelium/latest/management/core/device.md) document the resources used in access decisions. - **Try it yourself:** the [quick installation guide](https://octelium.com/docs/octelium/latest/overview/quick-install.md) installs a full *Cluster* on a Linux VM, and the implementation is available in the [Octelium source repository](https://github.com/octelium/octelium).