# How Teicho keeps the wall up, in plain words.

Teicho sits between your people and your most sensitive systems, so you should know exactly how it works. Here is the short version.

## Every access belongs to someone

People sign in with Google or Microsoft, with multi-factor authentication enforced by the provider under the policies you already run, or with a one-time code sent by email. Nobody creates a Teicho password.

Servers, CI runners and AI agents get their own machine identity and per-device config, owned by the team rather than a person. Every connection is tied to a person or a machine, never to a shared account.

CI jobs that start on a fresh machine every run, such as GitHub Actions, get a short-lived device per run: the job proves who it is with its CI provider’s own signed token, so no shared VPN key lives in your CI secrets, and the audit log shows the repository, workflow and run.

People and groups sync from Google Workspace, Entra ID or GitHub organizations, so removing someone there removes their access in Teicho, on every device, within minutes. Connecting a company directory needs that provider’s admin to approve it.

## Keys and signed configs

Device keys are generated on the device and never leave it; Teicho stores only public keys. Revoking one device, say a lost laptop, doesn’t affect anyone else.

IKEv2 profiles, for devices that can’t run WireGuard, are the exception: Teicho makes the device’s key and certificate from your team’s own IKEv2 certificate authority, shows the profile once and keeps no copy of the private key. Removing the device disconnects it.

Every config is signed with your team’s own key, which is held in a key management service. Tower delivers configs but can’t forge one, and devices reject any config that isn’t signed by your organization.

The client is not where the decision is made. Your Gate drops any packet to a destination your rules don’t allow for that device, so modifying the app or editing a config gains nothing.

## Fail-open by design

Tunneling is split by domain. Only traffic to your team’s destinations goes through the Gate; everything else goes straight to the internet, exactly as it would without Teicho.

In split tunnel, the default, your people’s internet never depends on Teicho. If something on our side is unavailable, calls, email and the web keep working. Team destinations fail closed instead: if no Gate can be reached, they stay shut.

## How the tunnel travels

Every device connects with WireGuard by default. Where a network blocks UDP, the Teicho app carries the same WireGuard tunnel inside TLS 1.3 on port 443, so the traffic looks like ordinary HTTPS. WireGuard’s own encryption stays inside, and the Gate accepts a tunnel only after the device proves it holds its WireGuard key; anyone else gets the Gate’s normal web answer. The fallback is on by default per Gate pool.

IKEv2 is off by default. When you turn it on for a pool, its Gates accept IKEv2 connections with per-device certificates; when you turn it off, they stop listening for it.

## Gates are yours alone

A Gate is a small server that carries your team’s traffic out from fixed egress IPs. It is dedicated to one team and never shared, so allowlisting its IPs lets in your team and nobody else.

You run your Gates on your own Linux server, in your cloud account or your office, joined with one command. A Gate behind NAT works through Tower’s relay.

## What Tower can and can’t see

Towers are shared by default. They hand out signed configs, connect your Gates to our control plane, and relay encrypted traffic for Gates your devices can’t reach directly.

Tower never sees your traffic in the clear, never sees your DNS lookups and never holds device private keys. Your team names are answered by the Teicho app from its signed config, or by your own Gate inside the tunnel.

## An audit trail you can hand over

Teicho records who connected, from which device, to what, and when, along with sign-ins, device changes and every change to access rules. The log is append-only: the database refuses any change to an entry or its deletion.

The audit log and the access review export as CSV. External checks confirm that your assets stay closed to everyone except your Gates.

## A note on compliance

Teicho helps you produce evidence for SOC 2 and ISO 27001 controls around access: who could reach what, how access was granted and removed, and that assets are closed to everyone else.

Teicho is not certified, and using it does not by itself make your company compliant. That is between you and your auditor; we try to make the evidence part easy.

## Put a wall around what matters.

Teicho is in early access. Tell us what you want to protect and we’ll be in touch. [Request early access](https://teicho.io/early-access)