Security architecture
Tethyr carries remote access and alarm traffic for industrial control systems. That makes isolation and fail-closed behavior the product, not a feature. This paper describes how the platform is built to keep one customer's control system unreachable to everyone else, written for the engineers who have to sign off on it.
Last reviewed July 2026
Two rules the system is built around
Everything below serves two non-negotiables. They are enforced structurally, in code and infrastructure, not left to operator discipline.
Tenant isolation
One customer's traffic never reaches another customer's control system. This is the first constraint the architecture is designed around, and it is enforced at more than one layer so a single missed check cannot open a gap.
Fail closed
When the system cannot verify something, it denies rather than guesses. For alarm forwarding specifically, no customer goes live without an independent fallback path, so a platform problem never silently swallows a callout.
Defense in depth
Critical controls are checked at write time, at reconcile time, and at the moment traffic is served. An error at any one layer is caught by the next.
Two planes, one writer
Tethyr separates a stateless control plane (dashboard, onboarding, billing) from the live data plane that carries alarms and access sessions. If the control plane is unavailable, existing alarm forwarding and access keep flowing. Isolation-critical network state has exactly one writer, so there is no split-brain over the tenant boundary.
Control and data planes are separate
A control-plane outage stops new signups and dashboard changes, not the alarm and access traffic your operations depend on.
A single reconciler owns the network state
One process is the only component permitted to change tunnel routing and network policy. Nothing else in the system can write it, which removes the races that let isolation gaps open.
Enforced by build checks, not just intent
The separation is verified in continuous integration: a build fails if a component reaches for privileges it should not have.
Outbound only, encrypted end to end
Your firewall opens nothing inbound. The connector on your network dials out over an ordinary outbound HTTPS connection and builds a WireGuard-encrypted tunnel. Traffic is encrypted across the tunnel and again with TLS at our edge.
- 01
The connector dials out
It initiates a standard outbound connection. No inbound port is opened on the VTScada box or your firewall.
- 02
A WireGuard tunnel forms
The link is a modern, encrypted tunnel. Only the connector and Tethyr's data plane are on it.
- 03
Access is brokered per session
A browser session is cryptographically bound to one server and dialed only to that address. No request input can retarget it.
Why one customer cannot reach another
Isolation is enforced by the code that builds the network, not by configuration an operator might get wrong. These are the controls that hold the boundary.
Identity is resolved on the server
Which tenant a request belongs to is derived from a verified organization identity, never from anything the client sends. An unknown or torn-down tenant is denied.
Sessions are cryptographically bound
A brokered session carries its target inside a signed token. One customer's session can never resolve to another customer's server, because the binding is cryptographic, not a lookup that could be confused.
Dial addresses must belong to your connector
An internal review identified a self-service address-validation gap before it reached production. We closed it with defense in depth: a server's address is now verified, at three independent points, to be one your own connector actually carries, so a session cannot be routed onto another network.
Cross-tenant rules are structurally absent
Network policy is generated by a single function that can only ever connect Tethyr's data plane to one customer's network at a time. A rule joining two customers is not a setting to misconfigure; it does not exist in the code that builds the policy.
The server is the gate
Authentication is delegated to a dedicated identity provider. Authorization is a separate, customer-owned model, and it is re-checked on the server every time, regardless of what the interface shows.
Roles you control
Operator, Admin, and Owner roles, with groups and per-resource assignments, are managed by your own administrators. Tethyr staff do not grant or manage your end-user access.
Re-authorized on every launch
Every access launch is independently re-checked server-side against your entitlements. A hidden button is not security; the server-side check is the actual gate, and it fails closed.
Staff tooling denies by default
Our internal staff console refuses every request until explicitly provisioned. There is no accidental-admin state, and every staff view of customer data is logged.
Short-lived, never in a URL
The token that carries an authenticated identity between hosts is engineered so that seeing it does not help an attacker.
Under a minute
The handoff token expires in seconds, not a session, so a captured copy is useless almost immediately.
Delivered in the request body
It is posted in the request body, never a URL, so it never lands in an access log, a proxy log, or browser history.
Single use
Each token can be redeemed exactly once. A replay is refused, enforced by an atomic single-use claim.
Purpose-bound
Tokens are cryptographically domain-separated and bound to the exact environment and host, so one can never be replayed for another purpose.
Secret hygiene by construction
Secrets never live in the repository or on a developer's machine.
Managed secret storage
Service and customer secrets are held in a managed secrets platform and injected only at deploy time. Nothing sensitive is committed to source control.
Customer credentials stay out of the database
A customer credential such as a messaging-provider token is never written to the application database. Secrets are scoped per service and, for customer credentials, designed for per-tenant isolation.
Encrypted in transit
Traffic is encrypted with WireGuard across the tunnel and with TLS at the edge, in both directions.
An append-only record
Security-relevant actions are recorded so you can answer who did what.
Append only by design
Authentication events, entitlement changes, provisioning, and launch decisions (allowed and denied) are written to an audit log. No code path in the system updates or deletes an audit record.
Secrets redacted automatically
Values are redacted before an entry is written, so a secret can never appear in a log line, even by accident.
Staff access is logged too
Every time Tethyr staff view a customer's data through our internal console, that view is recorded against the tenant.
Shared, or reserved for you
Most customers run on our shared fleet, isolated by the cryptographic and structural controls described above. For the highest-assurance environments, a dedicated deployment reserves compute for a single customer.
Shared
Your traffic runs on a common fleet, separated from every other tenant by cryptographically enforced, tag-based segmentation and the isolation controls in this paper. Efficient, and the default.
Dedicated
The access broker and callouts proxy that carry your live traffic run on compute reserved exclusively for you, serving no other tenant. The strongest separation we offer for the traffic path.
What is true today
We will not claim a certification we do not hold. Here is the honest status, and how to reach us with a concern.
Engineered to SOC 2 objectives
Audit logging, least-privilege access, tenant isolation, and secret hygiene are built into the architecture from day one, aligned to SOC 2 control objectives.
No certification yet
We have not completed a third-party audit. SOC 2 Type I and Type II are on our roadmap, and no formal compliance certification has been issued to date. If your assessment needs evidence, we will share what we have and our plan.
Responsible disclosure
If you find a security issue, we want to hear from you. Email us and we will respond and work the fix.
Questions from your security team are welcome. We would rather answer them before a pilot than after.
Bring us your hardest security questions
We would rather earn a technical buyer's trust with a straight answer than a slogan. Talk to us about your requirements or a dedicated deployment.