Skip to main content
Last reviewed: March 5, 2026 Owner: Security + Engineering Review cadence: Quarterly Status: Implemented Security reviews move faster when ownership is explicit. This page defines who owns what in each deployment model.

What this page answers

  • Which controls are Tero-owned vs customer-owned
  • How baseline integration traffic flows between customer systems and Tero
  • Where enterprise teams typically add stricter controls

Current state (as of March 5, 2026)

Tero supports two deployment models:
  • Tero-hosted control plane
  • Self-hosted control plane in customer-managed infrastructure
Control ownership changes by model, primarily at infrastructure and network layers.

Scope and integration boundary

  • Baseline integration model is customer-initiated outbound API traffic over HTTPS.
  • Baseline operation does not require vendor-initiated inbound connectivity into customer environments.
  • Identity policy inside the customer IdP remains customer-owned in both models.

Ownership model diagram

Responsibility matrix

Control areaTero-hostedSelf-hosted
Infrastructure security and patchingTeroCustomer
Network perimeter and private connectivityTero-managed baselineCustomer
Identity provider policy (IdP side)CustomerCustomer
Application authn and authz implementationTeroTero software with customer runtime controls
Secrets and key administrationTero-managed servicesCustomer-managed services
Data retention and deletion operationsTeroCustomer-operated runtime with product-defined behavior
Incident response for platform operationsTeroCustomer for environment ops, Tero for product support
Subprocessor managementTeroCustomer (for customer-chosen stack)

Where enterprise teams usually tighten controls

  • Self-hosted deployment for full environment ownership
  • Customer IdP policy enforcement for authentication lifecycle controls
  • Destination allowlisting and private routing in customer networks
  • Customer-selected AI provider path where required
  1. Confirm identity and role mapping model.
  2. Confirm network allowlisting and routing requirements.
  3. Confirm data handling and retention expectations.
  4. Confirm incident communication paths and named contacts.

Evidence you can request

TopicPrimary evidence
Ownership split by deployment modelThis page
Architecture and trust boundarySecurity Architecture
Data handling scope and storage modelOverview, Data Handling
Encryption and key managementEncryption and Key Management, Encryption Standard

Exceptions and governance

If a control allocation does not match customer policy requirements, we document the gap, agree on compensating controls, and define a time-bound resolution plan before production use. Evidence requests: