Security-buyer FAQ

The questions a SOC or IR lead asks in the first 30 minutes of evaluating Threxen — answered here, in one page, with anchors you can quote in your security review ticket. If your question isn't covered, drop it into the form at the bottom and we'll come back within one business day.

Where does our telemetry live (data residency per tenant)?

Every Threxen tenant is pinned to a single region at signup. There is no silent failover across regions and no cross-region replication without an explicitly agreed policy pack written into your order form.

• Default region. New tenants land in us-east-1. The choice is recorded in the tenant create-audit row and is immutable in the audit trail — later deletions of a tenant carry the original region forward in the compliance log.
• EU addendum. Tenants operating under GDPR, DORA, or NIS2 choose eu-west-1 at signup. The addendum binds the data plane to that region for the lifetime of the tenant and is enforced at the row level — a misrouted event from a US operator would be rejected, not silently rerouted.
• Per-tenant scoping. Region is enforced in the data plane, not just in the routing layer; the bearer-key authentication applied at POST /api/telemetry/ingest resolves to a single region identifier before any row is written.
• Visible from the pane. The active region is shown on /app/settings/jurisdictions and is part of every AuditEvent row's metadata, so a downstream SIEM bridge can key rollups off it without a separate handshake.

The full jurisdictional posture — including where the SOC2 / ISO27001 evidence packs were captured — lives on the [/trust](/trust) surface.

What leaves your perimeter?

Only the telemetry you choose to forward. There is no implicit exfiltration channel, no background sampling, and no payload that lands on Threxen's data plane without an explicit policy pack.

• Forwarder-mediated only. Telemetry leaves your SIEM endpoint only when the forwarder pushes a typed event to POST /api/telemetry/ingest. The endpoint accepts what the forwarder sends; it never pulls, never polls, and never opens an inbound socket.
• Allow-list policy packs. Each tenant ships with an explicit policy pack describing which event types and severity bands are forwarded. The default pack is "forward everything the forwarder emits" — but you can scope it down with a per-tenant pack, and an empty pack is a valid (and tested) configuration.
• Tenant-scoped aggregates. Rolled-up metrics — the daily counts, severity histograms, and the per-asset heatmap — are computed against your tenant's rows only. There is no global rollup, no cross-tenant cohort, and no panic-button view that exposes other tenants' data.
• Transport posture. The ingest endpoint serves TLS 1.3 only; HTTP/1 cleartext is refused at the edge. The forwarder talks to Threxen over a normal outbound 443 — no inbound firewall rules, no agent port, no DMZ hole.

How are API keys rotated, and by whom?

API keys are minted per tenant at /app/settings/api. There is no global key, no service account that bypasses the tenant check, and no out-of-band channel for ingesting telemetry.

• Per-tenant mint. Every key lists the tenant slug, the minting user, and lastUsedAt — the latter updated on every successful ingest so on-call can map a row back to the forwarder that emitted it.
• Rotation cadence. We recommend a 90-day rotation cycle for production tenants and a 30-day cycle for tenants under active incident response. The pane surfaces "days since last mint" so rotation is reviewable in a SOC control check.
• Revocation behaviour. Revoke at /app/settings/api. A revoked key is rejected with the same 401 as a wrong key — there is no "almost expired" grace window, no telemetry buffer for late events, and no public probe endpoint that would let an attacker enumerate live keys.
• Two halves, one credential. The token shape is thx_<prefix>.<secret> — the prefix half is safe to log and ships in the keys list; the secret half is shown exactly once on creation and is scrypt-hashed before persistence.

The full call shape, including the curl example your forwarder engineer can paste into a SIEM bridge, is on [/docs/api](/docs/api).

What are the retention windows?

Retention is set per data class. The numbers below are the platform defaults; tenant admins on a regulated deployment negotiate an extension against a written order-form addendum.

• Raw AuditEvent rows. Hot storage for 90 days, then compressed into cold storage for the remainder of the retention window. Analysts query the live pane against hot rows; cold rows are accessible on explicit request and ship with the same per-tenant RLS posture.
• Aggregated rollups. Daily and hourly rollups (counts, severity histograms, per-asset heatmaps) are kept for 12 months. Rollups remain tenant-scoped — a rollup row never crosses tenant lines.
• Access / administrator audit log. Kept for 7 years to align with SOC2 CC7.2 and ISO27001 A.9.4 evidence windows. This log captures who minted a key, who revoked one, and who modified the policy pack.
• Compliance extension window. Tenants under HIPAA, PCI-DSS, FedRAMP Moderate, DORA, or NIS2 can extend both the cold-storage window and the audit-log window via a per-tenant addendum; the pane shows the negotiated window next to the running clock so an auditor can verify retention posture without a separate spreadsheet.

What's the integration footprint on our side?

A single outbound HTTPS POST. There is no on-prem agent, no kernel-level component, and no firewall change required to start ingesting telemetry.

• One endpoint, one method. POST https://<region>.threxen.app/api/telemetry/ingest, Authorization: Bearer <key>, JSON body. The full payload schema is documented on [/docs/api](/docs/api).
• Agentless. No forwarder-process to install on the source host. The integration lives entirely on the SIEM side — CrowdStrike, Wazuh, Splunk, Elastic, and Sentinel all emit the same shape of event with the same field set.
• Optional private link. High-volume tenants operating under FedRAMP or DORA can terminate ingest over a private VPC link or via an S3 connector for batch replay; both are activated against a per-tenant policy pack, not by default.
• No inbound rules. The integration is one outbound 443 from the SIEM bridge to Threxen's edge. Your firewall posture is unchanged — the only required rule is the one your SIEM operator already needs to forward to any third party.

Talk to us — drop a security question below

We respond within one business day, and we can share the SOC2 + ISO27001 evidence pack under NDA on request. The form below posts to threxen@polsia.app and goes straight to the engineering team that builds ingest.