Fortinet alternative

The open source, self-hosted alternative to Fortinet ZTNA

Octelium is a free and open source, self-hosted zero trust access platform. It provides identity-based, layer-7 aware access control on a per-request basis, dynamic secretless access, and a unified architecture for both client-based and clientless access, on infrastructure you already operate rather than on an appliance.

  • Free and open source
  • No appliance or per-agent licensing
service.yaml
A ServiceEach protected resource is a Service, implemented by an identity-aware proxy.
A Service. Each protected resource is a Service, implemented by an identity-aware proxy.
kind: Service
metadata:
  name: erp
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: http://10.0.6.40:8080
A Policy. Access is authorized per request, from identity, device posture and the request itself.
kind: Policy
metadata:
  name: finance
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.user.spec.type == "HUMAN"
            - match: '"finance" in ctx.user.spec.groups'
            - match: ctx.device.status.osType == "WINDOWS"
A Windows desktop. Browser-based RDP with the upstream credential injected, so no desktop client is installed.
kind: Service
metadata:
  name: win-desk
spec:
  mode: RDP_WEB
  isPublic: true
  config:
    upstream:
      url: rdp://10.0.9.11
    rdp:
      auth:
        user: Administrator
        domain: WORKGROUP
        password:
          fromSecret: rdp-password
service-private.yaml
A private resourceA resource in any private network, reached over the tunnel through a single stable route.
A private resource. A resource in any private network, reached over the tunnel through a single stable route.
kind: Service
metadata:
  name: erp
spec:
  mode: HTTP
  config:
    upstream:
      url: http://10.0.6.40:8080
The same resource, clientlessly. One added field publishes the very same Service over HTTPS, with no client on the device.
kind: Service
metadata:
  name: erp
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: http://10.0.6.40:8080
A resource in a remote site. The upstream is resolved from the side of a connected host, so a branch needs no inbound port.
kind: Service
metadata:
  name: branch-nas
spec:
  mode: TCP
  port: 445
  config:
    upstream:
      url: tcp://192.168.10.20:445
      user: branch-gw
policy-posture.yaml
Device and identityDevice posture, session type and group membership are attributes in the same expression.
Device and identity. Device posture, session type and group membership are attributes in the same expression.
kind: Policy
metadata:
  name: managed-only
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.user.spec.type == "HUMAN"
            - match: ctx.session.status.type == "CLIENT"
            - match: ctx.device.status.osType in ["WINDOWS", "MAC"]
            - match: '"employees" in ctx.user.spec.groups'
The request itself. Method, path, headers and serialized JSON body are all part of the request context.
kind: Policy
metadata:
  name: erp-read-only
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.http.method == "GET"
            - match: ctx.request.http.path.startsWith("/reports")
            - match: '"finance" in ctx.user.spec.groups'
An explicit denial. Deny rules are evaluated ahead of allow rules, which keeps an exception readable.
kind: Policy
metadata:
  name: contractors
spec:
  rules:
    - effect: DENY
      condition:
        match: '"contractors" in ctx.user.spec.groups'
    - effect: ALLOW
      condition:
        match: '"employees" in ctx.user.spec.groups'
Secretless access

Credentials that are never distributed

Application-layer credentials are stored in the Cluster as Secrets and injected into the upstream connection once a request is authorized. This removes credential sprawl for teams and, increasingly, for workloads and AI agents.

Read the secretless access guide
ssh.yaml
SSHNo private keys or passwords are distributed, and no PKI has to be operated.
SSH. No private keys or passwords are distributed, and no PKI has to be operated.
kind: Service
metadata:
  name: bastion
spec:
  mode: SSH
  port: 22
  config:
    upstream:
      url: ssh://10.0.2.14
    ssh:
      user: deploy
      auth:
        privateKey:
          fromSecret: bastion-key
PostgreSQL. The upstream password stays in the Cluster, and the Service forces the database user.
kind: Service
metadata:
  name: pg-prod
spec:
  mode: POSTGRES
  port: 5432
  config:
    upstream:
      url: postgres://10.0.4.21:5432
    postgres:
      user: analytics_ro
      database: analytics
      auth:
        password:
          fromSecret: pg-password
      sslMode: REQUIRE
Mutual TLS. Client certificates for mTLS-protected TCP upstreams are held and presented by the Cluster.
kind: Service
metadata:
  name: broker
spec:
  mode: TCP
  port: 8883
  config:
    upstream:
      url: tls://10.0.8.30:8883
    tls:
      clientCertificate:
        fromSecret: broker-client-cert
idp.yaml
Secretless workload identityWorkloads authenticate with OIDC assertions issued by the platform running them.
Secretless workload identity. Workloads authenticate with OIDC assertions issued by the platform running them.
kind: IdentityProvider
metadata:
  name: github-actions
spec:
  oidcIdentityToken:
    issuerURL: https://token.actions.githubusercontent.com
    audience: https://example.com
A workload User. A server, a container or an agent is a User with the same groups, Policies and audit trail.
kind: User
metadata:
  name: backup-agent
spec:
  type: WORKLOAD
  groups:
    - infrastructure
An LLM gateway. Model providers are reached through the same identity, Policies and auditing as everything else.
kind: Service
metadata:
  name: openai
spec:
  mode: LLM
  isPublic: true
  config:
    upstream:
      url: https://api.openai.com
    llm:
      protocol: OPENAI
      auth:
        bearer:
          fromSecret: openai-api-key
Visibility and auditing

Real-time visibility at the application layer

OpenTelemetry-ready, application-layer aware, structured auditing and visibility emitted to your OpenTelemetry OTLP receivers, where they can be exported to your log management and SIEM tools.

Read about visibility and auditing
AccessLogOTLP
ALLOWlinus@acme.compg-prod.dbPOSTGRESquery: select id, email from users limit 50
ALLOWci-runnerprod-k8sKUBERNETESverb=list resource=pods namespace=production
DENYagent-07tools-mcpMCPtools/call name=transfer policy=mcp-tools
ALLOWjane@acme.combastionSSHsession recorded, upstream user=deploy
ALLOWagent-07openaiLLMCHAT_COMPLETIONS model=gpt-5-mini tokens=1284
octeliumctl
octeliumctl apply ./cluster
$ octeliumctl apply ./cluster
Secret: rdp-password Updated
Secret: bastion-key Updated
IdentityProvider: entra-id Updated
Policy: managed-only Created
Group: employees Created
Group: finance Updated
Service: erp Created
Service: win-desk Created
Service: pg-prod.db Created
Namespace: db Created
Cluster Core resources successfully applied
 7 resources created
 3 resources updated

 ClusterConfig updated
Comparison

Octelium and Fortinet ZTNA, capability by capability

Both products are described from the same structured capability dataset used across this site, with the same evidentiary standard applied to each. Emerging and experimental features are marked as partial regardless of vendor.

Capability comparison

Dataset reviewed August 2026

A curated view of the dataset, including the rows where Octelium is stronger, the rows where it is not, and the rows where the two are equivalent. The complete capability matrix, with search and filters, is one click away.

Architecture

Architecture

Octelium
Kubernetes-native identity-aware proxy/gateway architecture in which policy evaluation is separated from enforcement, with client-based WireGuard/QUIC access, clientless BeyondCorp access, declarative resources, and self-hosted control/data planes.
Fortinet FortiClient ZTNA
FortiGate appliance/gateway plus FortiClient EMS posture management and FortiClient endpoint agent. Hardware/software security fabric architecture.

Authentication

OpenID Connect

Octelium
Yes
Fortinet FortiClient ZTNA
Yes

SAML 2.0

Octelium
Yes
Fortinet FortiClient ZTNA
Yes

Native FIDO2 / Passkey

Native means implemented by the platform itself, not merely delegated to an external IdP.

Octelium
NativeFIDO2/Passkey/WebAuthnN with attestation and hardware-resistant authenticator checks
Fortinet FortiClient ZTNA
No

Workload Identity

Octelium
OIDC assertions / workload identity
Fortinet FortiClient ZTNA
No

SCIM Provisioning

Automated user/group lifecycle provisioning via SCIM, beyond just login-time IdP federation.

Octelium
SCIM 2.0 compliant
Fortinet FortiClient ZTNA
FortiAuthenticator / EMS; SCIM support varies by component

Authorization & Policy

Policy Model

Octelium
Layer-7 aware ABAC with policy-as-code via CEL and OPA
Fortinet FortiClient ZTNA
Fortinet tags, groups, EMS posture, firewall/security fabric policy, and RBAC-style administration.

Policy-as-Code

Octelium
CEL + OPA
Fortinet FortiClient ZTNA
No

Per-Request Authz

For L7 products, this means each HTTP/gRPC/API/K8s request can be evaluated. For overlays, session/connection policy is not counted as per-request. This modeling choice structurally favors L7 gateways over network overlays.

Octelium
Yes
Fortinet FortiClient ZTNA
NoPrimarily session/network/security-policy oriented.

L7-Aware Policies

Octelium
HTTP, gRPC, K8s, DB, SSH, mTLS-related context
Fortinet FortiClient ZTNA
Partial

Zero Standing Privilege / JIT

Indicates strong architectural support for minimizing standing privilege; not an absolute claim that privileged access cannot exist.

Octelium
StrongDesigned to minimize static privilege through identity/policy-scoped access.
Fortinet FortiClient ZTNA
No

Access Requests / Approvals

First-class request-and-approve / break-glass workflows (reviewers, time-bound grants), as opposed to static policy alone.

Octelium
Access requests + approvalsFirst-class access request and approval workflow, in addition to policy/identity-scoped access that can be time-bound.
Fortinet FortiClient ZTNA
No

Device Posture

Octelium
TPM/FIDO2/device attributes
Fortinet FortiClient ZTNA
FortiClient EMS

L7 Protocol Awareness & Secretless Access

HTTP / HTTPS

Octelium
L7-aware + secretless credential injection
Fortinet FortiClient ZTNA
Partial

SSH

Octelium
Secretless / embedded SSH patterns
Fortinet FortiClient ZTNA
No

PostgreSQL

Octelium
Secretless + query-aware policy/logging
Fortinet FortiClient ZTNA
No

Kubernetes

Octelium
Secretless + verb/resource/namespace policy
Fortinet FortiClient ZTNA
No

RDP

Octelium
with clientless secretless browser access
Fortinet FortiClient ZTNA
Partial

DNS

Octelium
Native private DNS mode
Fortinet FortiClient ZTNA
FortiGuard DNS/security features

Transport & Networking

WireGuard Data Plane

Whether the product's own client/data plane is built on WireGuard, versus a proprietary or TLS-based transport.

Octelium
Kernel / userspaceWireGuard via kernel module, TUN, or unprivileged userspace (wireguard-go) implementations.
Fortinet FortiClient ZTNA
NoIPsec / SSL VPN and ZTNA agent transport, not WireGuard.

IPv6 Support

Octelium
Dual-stackDefaults to IPv6, with selectable IPv4-only or dual-stack cluster network ranges.
Fortinet FortiClient ZTNA
Enterprise IPv6

NAT Traversal

Octelium
Via GatewaysReaches resources behind NAT through Cluster Gateways; client-to-Gateway path rather than a direct P2P mesh.
Fortinet FortiClient ZTNA
Partial

Visibility, Auditing & Observability

OpenTelemetry-Native

Octelium
Yes
Fortinet FortiClient ZTNA
No

L7-Aware Access Logs

Octelium
HTTP/gRPC/K8s/DB/SSH identity-aware logs
Fortinet FortiClient ZTNA
Partial

SSH Session Recording

Octelium
Yes
Fortinet FortiClient ZTNA
No

SIEM Integration

Octelium
Via OTLP / OTel Collector
Fortinet FortiClient ZTNA
FortiAnalyzer/FortiSIEM

Access Methods

Client-Based VPN / Overlay

Octelium
WireGuard / QUIC
Fortinet FortiClient ZTNA
FortiClient / SSL VPN / ZTNA agent

Clientless Browser Access

Octelium
Yes
Fortinet FortiClient ZTNA
No

Private DNS

Octelium
Yes
Fortinet FortiClient ZTNA
No

Dynamic Configuration

GitOps / Declarative Config

Octelium
Kubernetes-like resources / YAML
Fortinet FortiClient ZTNA
No

AI / MCP / Agent Compatibility

AI / LLM Gateway

Octelium
Native LLM Service modeProtocol-aware OpenAI/Anthropic gateway: validated operations, per-request authorization on model, tools and token limits, CEL-based model selection, and token usage in access logs.
Fortinet FortiClient ZTNA
No

MCP Gateway / MCP Access

Octelium
Native MCP Service modeProtocol-aware MCP gateway: JSON-RPC method and tool-level authorization, protocol version pinning, origin validation, and managed-container MCP upstreams.
Fortinet FortiClient ZTNA
No

Deploy Containers / PaaS

Octelium
Yes
Fortinet FortiClient ZTNA
No

Scalability & Cloud-Nativeness

Kubernetes-Native

Octelium
Built on Kubernetes
Fortinet FortiClient ZTNA
No

High Availability

Octelium
K8s-native HA model
Fortinet FortiClient ZTNA
HA clustering

Openness & Self-Hosting

Fully Self-Hosted

Octelium
Yes
Fortinet FortiClient ZTNA
On-prem appliance, but proprietary ecosystem

Server Code Open Source

Octelium
Yes
Fortinet FortiClient ZTNA
No

No Mandatory Proprietary Cloud

Octelium
Yes
Fortinet FortiClient ZTNA
On-prem possible, but proprietary Fortinet stack

Data Sovereignty

Octelium
Yes
Fortinet FortiClient ZTNA
On-prem deployments
Questions

Frequently asked

Is Octelium free and open source?
Yes. Octelium is free and open source and is designed for single-tenant self-hosting. There is no proprietary cloud-based control plane, no appliance to buy and no per-agent licensing, and it is not a limited edition of a separate paid product. An enterprise package is available for organizations that need capabilities such as a web console, SCIM provisioning and secret encryption at rest, and it is free for personal, homelab and evaluation use.
What hardware does it need?
None in particular. An Octelium Cluster runs on Kubernetes, on hardware or virtual machines you already operate. The quick installer provisions a complete single-node Cluster, including Kubernetes itself, on one fresh Linux VM with 2 vCPUs, 2 GB of RAM and a domain you own. Production Clusters run on scalable managed or on-premise Kubernetes installations, and Gateways scale horizontally rather than each one imposing a fixed ceiling.
Can it enforce device posture?
Yes. Device information including the operating system type is available in the request context and can be combined with identity, group membership, session type and time in the same policy expression. Octelium also provides native FIDO2 and WebAuthn passkeys, TOTP and TPM 2.0 authenticators that can be required through policy on sensitive Services, independently of what the identity provider itself enforces.
Does it replace a firewall?
No. Octelium is a zero trust access platform: it represents each protected resource as a Service behind an identity-aware proxy and authorizes access to it per request. It does not perform network segmentation, intrusion prevention or egress filtering for a whole site, and it is normally deployed alongside whatever network security controls an organization already operates.
Can I keep my existing identity provider?
Yes. Any OpenID Connect or SAML 2.0 identity provider is supported, as well as GitHub OAuth2. Human Users authenticate through it, and workload Users authenticate with authentication tokens, the OAuth2 client credentials flow, or federated OIDC assertions issued by the platform hosting them.
How is the Cluster managed?
Declaratively, in the way a Kubernetes cluster is managed. Resources are defined in YAML, kept in a Git repository, and applied with a single octeliumctl apply that synchronizes the entire Cluster state, which makes changes reviewable and reversible. Everything is also available over the Cluster's gRPC APIs, so no configuration change requires console or SSH access to a device.
Get started

Deploy Octelium on your own infrastructure in minutes

Free and open source. Self-hosted. No vendor lock-in.