TSEC / For security leaders
TSEC for security leaders
Written for the person who has to sign off, and for the architect they will hand it to. It covers what TSEC does, what you own versus what we own, and what it cannot do yet. The last part is included because you will find it anyway, and we would rather you found it here in ten minutes than in week three of a pilot.
On this page
What TSEC actually is
TSEC is a self-hosted identity orchestration platform. Authentication, registration and step-up flows are authored visually as node graphs — called expeditions — then executed by a runtime in your own cluster. Device intelligence, risk rules and multi-factor steps are nodes inside those flows rather than separate products.
It is deliberately not a replacement for your identity provider or your user directory. It sits in front of what you already run and calls it: credential checks, MFA, your IdP, your system of record. Your users stay where they are.
An optional OIDC authorization server, built on Spring Authorization Server, lets TSEC act as an identity provider to downstream applications — with the login step delegated to one of your expeditions. That is the part most teams find interesting: a standards-based OIDC login whose logic is a flow you drew, not a configuration screen you filled in.
The three problems it addresses
1. Your fraud and device vendor is a data export
Cloud device-intelligence services work by ingesting your users' device, network and behavioural data into their cloud. Under GDPR that makes them a processor in your chain, with the transfer analysis, DPA and residency questions that follow. TSEC collects signals in the browser and evaluates them on your servers. There is no third party in the data path, and no consortium pooling your users with anyone else's.
2. You cannot explain a vendor's score to a regulator
When someone asks why a customer was challenged or blocked, "the model said so" is not an answer. TSEC's risk decisions are rules you wrote, stored in your database, with a per-decision record of which signals matched, what they weighed and which rule fired.
3. Changing a login flow takes a quarter
Authentication logic is usually spread across an IdP's configuration, some application code and a vendor's console. Changing it means a release. In TSEC a flow is a versioned artifact: published versions are immutable and content-hashed, and rollback appends a new version carrying the old bytes rather than rewinding history, so sessions already running on the previous version are unaffected. Rollback is also re-validated against today's modules and secrets, because restoring a flow that no longer works is the last thing you need mid-incident.
What you own, what we own
TSEC is delivered as container images and a Helm chart. There is no hosted component, no tenancy on our side and nothing to phone home to.
| Concern | Who holds it |
|---|---|
| End-user data, device records, session history | You. In your Postgres, in your cluster. We have no access path to it. |
| Encryption keys and signing keys | You. Generated and held by you; supplied by environment or Kubernetes secret. |
| User directory / system of record | You. TSEC calls it over HTTP; it never becomes the master copy. |
| Risk rules and flow logic | You. Authored, versioned and readable in your deployment. |
| Egress policy | You. Outbound calls are allowlisted, and the runtime blocks loopback, link-local, cloud-metadata and private ranges by default. |
| Upgrade timing | You. Images are pinned by version and digest; nothing updates itself. |
| Source code, images, Helm chart | Us. Published to a container registry for you to pull and pin. |
| Licence verification key | Us — but verification is offline. See below. |
| Telemetry about your deployment | Nobody. There isn't any. |
What happens if we go away
This is a fair question to ask a pre-1.0 vendor you are about to put in your login path, so here is the honest mechanical answer.
The runtime never checks a licence. Published expeditions keep serving logins regardless of licence state, connectivity, or anything happening at our end. Taking your authentication offline would be an outage of your business caused by us, so the runtime was built without the ability to do it.
The builder — the authoring console — does check a licence, and it does so offline: the licence is an RS256 JWT verified against a public key baked into the image. No licensing service, no network call, no availability dependency on us. It works in an air-gapped install.
If a licence lapses, the builder becomes read-only. Everything stays readable, every published flow keeps running, and sign-in plus licence management keep working so a lapsed install can always be recovered without database surgery. You lose the ability to author new flows. You do not lose your logins, your data, or access to your own configuration.
Proof versus guess
Most risk products blend strong and weak signals into a single number, which is why nobody can explain the number. TSEC labels the difference, in the product, at the point where you build the rule.
The clearest example is automated-client detection. TSEC implements Web Bot Auth (HTTP Message Signatures, RFC 9421): a cooperating agent signs its request, and TSEC verifies an Ed25519 signature over the request authority with replay protection. A verified signature is proof of which client is calling. Public keys are fetched from each operator's well-known directory on a schedule — never on the request path — so a directory outage cannot become your login outage.
The same node can also classify a client from its user-agent string and header shape. That is not proof; any client can set those. TSEC calls that outcome a hint and says so in the builder, rather than leaving you to discover the distinction in production. You decide which outcomes are allowed to carry weight.
This matters beyond bot detection. It is the difference between a risk engine you can defend in an audit and one you cannot.
What it cannot do yet
TSEC is pre-1.0. The following are accurate as of release 26.10.0. If one of them is a hard control requirement for you, say so early and we will tell you honestly whether the timeline works, rather than discovering it during a security review.
| Capability | Status |
|---|---|
| Audit event export to a SIEM | Admin plane Administrative actions — sign-in, expedition publish, rollback and restore, secret change, licence change — are emitted as JSON on stdout, so any log collector already picks them up, plus an optional webhook for a SIEM. Runtime and authorization-server events are not yet emitted: end-user login outcomes, device binding and step-up results are recorded and queryable in your database but do not reach the export. If your control requirement covers end-user authentication events, that part is still outstanding. |
| Tamper-evident audit trail | Admin plane The audit table is hash-chained — each row carries an HMAC over the previous hash and its own canonical form — and ships with a verifier that re-walks the chain straight from the database, independently of the running application, exiting non-zero on the first break. It needs only read access and the chain key, so you can verify the trail when you no longer trust the app or the operator. Rows carry a key version, so rotation does not invalidate history. Runtime events are not in the chain yet. |
| MFA on the admin consoles | In progress Admin sign-in is password-based with lockout throttling. The builder is an administrative surface that can change authentication logic, so it must be network-isolated — private ingress, VPN or mesh, not the public internet. We state this as a deployment requirement, not a suggestion. |
| Multi-factor for end users | TOTP Authenticator-app TOTP ships as a module, with issuer and screen configuration, attempt and lockout policy, recovery codes, and admin unlock and reset. No WebAuthn or passkeys, SMS, email OTP or push yet. |
| SAML | No OIDC and OAuth 2.0 only. |
| SCIM / directory sync | No No lifecycle provisioning. TSEC reads your directory through an API call; it does not synchronise it. |
| OAuth grant coverage | v1 Authorization code with PKCE, plus refresh-token rotation. No client credentials, device code or token exchange yet. |
| Formal attestations | None No SOC 2, ISO 27001 or FedRAMP. Worth noting for scoping: because TSEC runs entirely in your environment, most of the control boundary is already yours — the attestation that matters for the data is the one covering your own cluster. |
| Tenancy model | Per deployment Isolation is per instance or namespace, not a native tenant model inside one install. |
| Prebuilt connectors | No catalogue Integrations are authored as reusable API modules against any REST endpoint. Flexible, but there is no marketplace of ready-made connectors. |
What a first deployment looks like
We would not suggest starting by moving your primary customer login. Three starting points that fit what TSEC does today:
Device trust in front of your existing IdP
TSEC handles device recognition, binding and step-up decisions; your current IdP still performs the factors, called from the flow. The measurable result is fewer MFA prompts for recognised devices without lowering assurance for unrecognised ones. Low blast radius, and the metric is easy to agree on in advance.
Internal platform access
TSEC's OIDC server in front of the Kubernetes API server and Grafana, with group claims driving RBAC in both. One login governs application access and cluster access. The data is internal, the blast radius is contained, and your platform team is both the operator and the user — which makes the evaluation honest.
A policy for automated and AI clients
If you are being asked what your position is on agent traffic, the Web Bot Auth path above is a standards-based answer you can actually implement and explain, rather than a blocklist.