Shared Responsibility Matrix
This document divides operational and security responsibilities between FactoryThread and the Customer across our three deployment modes:
| Mode | Hosting | Tenancy |
|---|---|---|
| SaaS | FactoryThread, on Microsoft Azure (multi-tenant) | Multi-tenant; isolated by tenantId (Auth0 org_id) at the row level in PostgreSQL |
| Single-tenant managed | FactoryThread, on Microsoft Azure (single-tenant infra) | Single tenant; customer-pinned region |
| On-prem | Customer's network (Docker Compose) | Single tenant set at deployment time |
Throughout this document, "FactoryThread" refers to the platform vendor and "Customer" refers to the organization deploying or subscribing to FactoryThread.
A foundational point: FactoryThread is a data virtualization platform — not a system of record for customer business data. The application database holds only operational metadata (connection definitions, flow definitions, tenancy / identity metadata, execution insights). Two limited exceptions are documented in the Security Overview: a bounded sample of failing records may be captured on execution errors for debugging, and workers may use ephemeral in-memory or temporary local-disk staging during a single run. This shapes the responsibility split below — many "data at rest" responsibilities that would normally fall on a SaaS vendor do not apply.
Matrix
Legend: FT = FactoryThread is responsible · C = Customer is responsible · Shared = both parties contribute · n/a = not applicable in this deployment mode
| Topic | SaaS | Single-tenant managed | On-prem |
|---|---|---|---|
| Identity provider — operation and availability | FT (Auth0) | FT (Auth0) | C (customer SSO behind reverse proxy) |
| Identity provider — configuration (allowed domains, MFA policy, password policy) | FT (Auth0 organization settings) | FT | FT |
| MFA enforcement | C (configured in Auth0) | C | C (customer SSO) |
| SAML federation / SCIM provisioning | Shared (FT enables Auth0; C configures IdP) | Shared | C |
| User lifecycle (provision / deprovision) | C (via Auth0 / IdP) | C | C |
| Workspace assignment and RBAC | C (workspace owners assign access) | C | C |
| API key issuance and rotation | C (FT provides the UI; SHA-256-hashed at storage) | C | C |
| API key secrets — handling on the customer side | C (treat as production credentials) | C | C |
| Connection credential lifecycle (OAuth2 client credentials / Bearer token / Basic / session cookies) | C (rotate per Customer's policy) | C | C |
| Connection credential storage | FT (PostgreSQL, JSONB; AES-256-GCM application-layer encryption shipping Q2 2026) | FT (same) | C operates the database; FT provides the schema and application code |
| TLS termination on platform endpoints | FT (Azure Front Door / App Gateway, TLS 1.2+) | FT | C (customer reverse proxy) |
| Strict TLS verification on outbound REST calls | FT — outbound HTTPS calls do not strictly verify TLS certificates today, in order to support customer endpoints with self-signed or private-CA certificates; strict-by-default with per-connection opt-in shipping Q2 2026 | FT (same) | FT (same) |
| Customer endpoint TLS configuration (e.g., TLS cert, ciphers on the customer-side endpoint) | C | C | C |
| Network egress allow-listing for FactoryThread workers | Shared (FT publishes outbound CIDRs; C allow-lists) | Shared | n/a — workers run inside customer network |
| Network segmentation between FactoryThread and customer systems | C (firewall / VNet on Customer side) | C | C |
| Production host hardening (OS, container runtime, kernel) | FT (Azure-managed) | FT | C |
| Backup of the FactoryThread application database (Postgres) | FT (Azure-managed Postgres backups) | FT | C |
| Backup of customer source-of-truth systems (ERPs, MES, databases, files) | C | C | C |
| Disaster recovery — FactoryThread compute | FT (container redeploy from immutable image) | FT | C (customer's DR plan) |
| Disaster recovery — RPO / RTO targets for the application database | FT (Azure-managed Postgres point-in-time recovery) | FT | C |
| Patching of base container images | FT (rebuilt and redeployed on every merge to main) | FT | C — FT publishes image versions; customer pulls and redeploys per their cadence |
| Patching of Postgres / RabbitMQ | FT (managed services) | FT | C |
Application-layer vulnerability management (Dependabot, pnpm audit, advisories) | FT | FT | FT publishes patches; C deploys |
| Infrastructure as code (Bicep, GitHub Actions) | FT | FT | FT provides reference; C operates customer-side IaC |
| Logging — application and worker logs | FT (Pino → Grafana Alloy → Loki/Prometheus) | FT | C operates the log stack; FT provides Pino output |
| Logging — flow execution insights surfaced in-product | FT (built-in flow_execution_insights table; retention configurable via insightsRetentionDays) | FT | FT (operates inside C's environment) |
| Audit trail — comprehensive who-did-what-when | Roadmap Q3 2026; today FT records publish events, API key lifecycle, and execution insights | Roadmap Q3 2026 | Roadmap Q3 2026 |
| Incident detection and response — platform | FT (paging on alerts from Loki / Prometheus) | FT | C |
| Incident detection and response — customer systems | C | C | C |
| Customer notification of platform-side security incidents | FT (per support agreement) | FT | n/a |
| Data residency | FT (default region) | FT (customer-pinned region) | C (data stays inside customer network) |
| Data subject rights handling (GDPR, CCPA) | Shared (C is Controller; FT is Processor) | Shared | C is both Controller and operator |
| Stripe billing data (PCI scope) | FT (Stripe-hosted; only Stripe IDs and timestamps persisted on FT side; no card data) | FT | n/a (license-managed) |
| License compliance (on-prem) | n/a | n/a | C |
| Customer training on secure configuration of flows and connections | C (FT provides documentation; C ensures internal users follow it) | C | C |
Things that are always the customer's responsibility
A short consolidated list, regardless of deployment mode:
- Configure MFA and SSO policies in your IdP. FactoryThread enforces what your IdP returns; the strength of authentication is set by your IdP.
- Rotate connection credentials per your own policy. FactoryThread does not auto-rotate ERP, MES, or database credentials; rotation happens on the customer side and the new value is updated in the FactoryThread connection metadata.
- Allow-list FactoryThread egress IPs at your perimeter (SaaS / single-tenant managed). FactoryThread publishes the outbound CIDR list on request; the customer firewalls / VNet / load-balancer rules are your job.
- Treat API keys as production credentials. FactoryThread shows the plaintext key once at creation and only stores the SHA-256 hash thereafter. If a key is exposed, revoke and reissue.
- Choose the right deployment mode for your regulatory posture. GxP and 21 CFR Part 11 workloads belong on the on-prem release.
Things that are always FactoryThread's responsibility
- Operating the platform. Container builds, deploys, autoscaling, observability, on-call.
- Securing how connection credentials are stored within the application database — including the application-layer encryption shipping in Q2 2026.
- Keeping the application code current. Dependency hygiene, base-image patching, type-checking and linting on every PR.
- Honest disclosure of known security gaps with target quarters. The four open gaps (connection-metadata encryption, strict TLS, comprehensive activity log, flow version history) are listed in the Security Overview with Q2 / Q3 2026 targets.
- Customer notification of platform-side security incidents affecting your tenant, per the support agreement.
Contact
For this matrix tailored to your specific deployment, or to confirm any item above, contact support@factorythread.com.