Defense-in-depth by design
Create real zero-trust security by separating the Control Plane from the Data Plane.
Xiid's Terniion platform represents a fundamental shift in how organizations think about secure access architecture. At its core, the platform deliberately separates the control plane from the data plane so that configuration and policy live in one tightly protected layer, while traffic handling and enforcement live in another, highly segmented layer[1]. This separation is enforced both logically in software behavior and trust boundaries, and physically through where components are deployed and how they communicate.
Photo by Marah Bashir on Unsplash
Core Terniion Architecture
At a high level, Terniion uses SealedTunnel technology that creates outbound-only, triple-encrypted, process-to-process tunnels that never require exposed inbound ports or public IPs. Within this architecture, the control plane is centered on the Commander component, while the data plane is formed by STLinks and Connectors that actually move traffic between protected resources.
The distinction is clear:
The control plane defines which entities may talk, under what conditions, and via which Zones and Connectors.
The data plane enforces those decisions in real time at the tunnel endpoints, without ever needing direct access to sensitive configuration data or stored credentials
This separation means that the control plane and data plane can be managed, secured, and monitored independently. Compromising one does not automatically compromise the other, fundamentally raising the barrier for attackers who may penetrate enterprise systems.
The Control Plane: Commander Behind Closed Firewalls
The Commander is the nerve center for Terniion’s configuration and orchestration and is designed to sit inside the customer's environment, behind closed firewalls and without any inbound exposure[2][3].
Physical Separation
The Commander's deployment is a textbook example of physical security at the infrastructure level:
The Commander can be hosted entirely on-premises or in a private cloud, with all inbound ports closed, and accessed only via outbound SealedTunnel paths.
Sensitive policy, topology understanding, and any locally stored metadata remain inside the customer's trust boundary rather than in Xiid's cloud.
No one from the internet can ever directly connect to a Commander; only STLinks that have already been authenticated and authorized can reach it through sealed tunnels.
Because Commander never accepts inbound connections, it becomes a natural fortress. Network segmentation is enforced not by firewall rules alone but by the fundamental architecture—the Commander simply cannot be reached by external parties.
Logical Separation
While physical separation ensures that Commander is unreachable, logical separation ensures that even if an attacker observes the control-plane traffic itself, they cannot gain the ability to modify policies or trick the data plane:
The Commander defines policies, application mappings, and which STLinks and applications are allowed to participate in specific tunnels, but it does not handle user data traffic itself.
Control messages (policy updates, tunnel instructions, health checks) are distinct from encrypted application payloads that traverse the STLinks and Connectors.
When the Commander issues a policy decision to an STLink or Connector, that decision is signed and verified; the data plane cannot unilaterally act outside the scope of the Commander's authorization
This design means that even if an attacker could observe data plane traffic, they would not gain access to the configuration and policy logic that the Commander stores inside the customer's environment. The data plane is "dumb" by design—it only enforces what the Commander tells it to enforce, nothing more.
The Data Plane: STLinks and Connectors Enforcing Policy
The data plane consists of STLinks and Connectors that terminate and forward SealedTunnel traffic between clients, services, and environments, while remaining strictly outbound-only. These components are the gatekeepers of actual traffic, but they operate under tight constraints set by the Commander.
STLinks: Policy Enforcement at the Resource Edge
STLinks run close to protected resources (e.g., subnets with GitLab runners, production servers, IoT/OT devices) and originate outbound SealedTunnels with no open inbound ports on any subnet.
Logical enforcement by STLinks:
STLinks enforce the Commander's policies locally by only establishing tunnels that match allowed identities, destinations, and applications, without needing any stored long-term credentials for those resources.
STLinks enforce process-to-process segmentation, allowing only the specific services and ports that the Commander has authorized, which prevents lateral movement to other local resources.
Even if an attacker compromised a machine next to an STLink, they would still need valid control-plane authorization for that STLink to build a usable tunnel.
STLinks receive Mapping Configurations from the Commander that specify exactly which loopback addresses and ports are allowed to communicate, and no traffic outside those specifications will be forwarded.
Physical security of STLinks:
STLinks are deployed directly on the machines or gateways that need to communicate, and operate strictly as outbound-only processes
Because they do not accept inbound connections, they inherit the same fundamental protection as the Commander: attackers cannot directly target them from the internet
Connectors: Gatekeeping Without Inspection
Connectors provide a hardened bridge for outbound SealedTunnel connections in SaaS, cloud, or other networks while never decrypting application payloads.
Logical enforcement by Connectors:
Connectors accept only mutually authenticated, outbound SealedTunnels created under the Commander's policies and cryptographic trust relationships.
They enforce which applications, protocols, and flows are permitted based on control-plane instructions, but cannot inspect or modify cleartext user data because of multilayer, end-to-end encryption.
Connectors cannot spontaneously create new access paths or expand reach; every tunnel and application exposure must correspond to a policy that originates in the Commander.
The trust boundary:
No decryption occurs on Connectors. Even though Connectors are often deployed in Xiid-managed cloud infrastructure, the encryption remains end-to-end, meaning Xiid has no ability to see or modify the data flowing through them, nor do outside threat actors.
Together, STLinks and Connectors form the data plane: they move packets, apply tunnel-level access control, and implement segmentation that the control plane specifies, but their view of the world is strictly limited to what the Commander authorizes. Because neither STLinks nor Connectors store centralized policies or user identities, a compromise of a single data-plane node does not expose the broader control fabric.
Zones and Geoclusters: Layering Logical and Physical Separation
The Zone abstraction adds another layer of both logical and physical separation by grouping STLinks and Connectors into scoped communication domains, typically aligned with geography, sensitivity level, or business function.
Logical Separation via Zones
A Zone defines which STLinks and Connectors can communicate and which applications or services they can expose to each other, based on specific policies. Zones are the policy tool for saying "traffic from this group of resources can only reach that group of resources, and nothing else." Zones can be used to ensure that a given SealedTunnel can reach only a specific subset of Connectors in a defined Geocluster (for example, EU-only or particular mission enclave), enforcing clean blast radius boundaries.
Physical Separation via Zones and Geoclusters
Terniion infrastructure and Connectors can be deployed in multiple clusters, and the control plane maps STLinks into one or more Zones that correspond to those clusters, ensuring traffic stays within chosen regions or security domains. Because all communication is outbound and tied to Zone-specific trust relationships, an STLink in one Zone cannot create tunnels into Connectors in another Zone. This prevents data exfiltration to unexpected geographies and helps organizations meet sovereignty and compliance requirements.
In practice, this means an organization can carve the data plane into multiple sealed "slices" that are both logically distinct and physically separated, while managing all of them centrally through the Connector Portal control plane.
Why This Architecture Matters
The separation of control and data planes is not a new concept in networking, but Terniion's implementation is distinctive because it combines physical isolation (closed firewalls, outbound-only communication) with logical isolation (cryptographic enforcement, policy signing, process-level granularity) to create a defense-in-depth model.
For organizations:
Simplified compliance: Sensitive configuration stays on-premises while secure tunnels manage access globally.
Reduced blast radius: Compromise of a data-plane node does not expose policies, identities, or control logic.
Granular segmentation: Zones and Connectors allow fine-tuned control over which resources can reach which services, region by region.
Quantum-resistant encryption: The tunnels themselves are triple-encrypted and quantum-secure, protecting data in transit against future decryption attacks.
For security teams:
Clear lines of responsibility: Control plane and data plane can be monitored and audited separately.
Insider threat mitigation: Process-level enforcement by STLinks prevents lateral movement even from compromised machines on the same subnet.
No decryption required: Unlike traditional break-and-inspect solutions, Connectors never see cleartext traffic, reducing the risk surface of the access infrastructure itself.
Conclusion
Xiid's Terniion demonstrates how thoughtful architectural separation can turn security from a feature bolted onto an access platform into a fundamental property of the system. By cleaving the control plane into a hardened, inbound-less fortress (Commander) and distributing the data plane across outbound-only, policy-enforcing endpoints (STLinks and Connectors), Terniion creates a system where the attacker's job is not simply harder—it is structurally impossible in most cases.
The addition of Zones extends this principle into multiple dimensions: logical separation at the policy level, physical separation at the infrastructure level, and geographic separation across cloud providers and regions. For organizations serious about Zero Trust Network Access, this multi-layered approach to control and data plane separation is a cornerstone of impenetrable access control.