Security Overview

This document summarizes how FactoryThread is designed and operated. It is the public companion to our packet of security documents, alongside the Shared Responsibility Matrix and Compliance Readiness Statement. The Data Flow & Architecture Guide and Access / Audit / Change Control Guide are available under NDA — see Documents Under NDA.

1. Data virtualization — what we do and do not store

FactoryThread is a data virtualization platform — it is not designed to be a system of record for customer business data. Source data from manufacturing and enterprise systems (ERPs, MES, databases, APIs, files) is fetched on demand from the customer's system, transformed in memory inside an isolated worker process, and delivered to the configured target.

The application database holds only the operational metadata required to run, secure, and troubleshoot the platform. Successful flow results are not retained.

What FactoryThread persists

Category	Examples
Connection definitions and credentials	Endpoint URL, OAuth2 client credentials, Bearer tokens, Basic auth, session-cookie auth, custom headers
Flow / view / API definitions	Visual flow graph (nodes, edges, transformations), schedules, triggers
Tenancy & identity metadata	Auth0 org_id, workspace IDs, user IDs (Auth0 sub), API key SHA-256 hashes
Execution insights	Run status, duration (ms), total nodes, start/end timestamps, error messages
Billing metadata	Stripe customer / subscription / price / invoice identifiers and timestamps (no card data)

What FactoryThread does not persist

• Successful flow result rows (data virtualization model)
• Preview data (in-memory only, capped at a small sample)
• User passwords (delegated to Auth0)
• Card data (delegated to Stripe — Stripe Checkout / Customer Portal handle the PCI scope)

Two limited exceptions to the "we do not retain customer records" framing exist and are documented explicitly because they are part of the security and compliance boundary:

1. On flow execution errors, a bounded sample of the failing record(s) is captured into the execution-insights record for debugging. The sample size is bounded per node type and is only captured on the failure path; successful executions never write business data into insights.
2. The worker may use ephemeral in-memory or temporary local-disk staging during a single run (for example, to support join-style operations against IBM DB2). This staging is local to the worker process, encrypted by the host's disk encryption, and discarded at the end of the run.

For sensitive workloads, customers can request that failure-sample capture be minimized or disabled, subject to operational tradeoffs (debugging becomes substantially harder).

2. Product summary and deployment options

FactoryThread is delivered in three deployment modes. The security posture differs in expected ways across the three; the application, schema, and worker code are the same.

Mode	Hosting	Tenant model	Identity	Network egress
SaaS (multi-tenant)	Azure (default region)	Auth0 org_id per tenant; row-level isolation in Postgres	Auth0 OIDC (SAML / MFA configurable per tenant)	Outbound to customer systems from FactoryThread workers
Single-tenant managed	Azure (customer-pinned region)	Single fixed tenant	Auth0 OIDC or customer-provided IdP via Auth0 federation	Same as SaaS, isolated infra
On-prem / air-gapped	Customer's network (Docker Compose)	Single fixed tenant set at deployment time	Reverse proxy + SSO headers (x-user-id, x-user-email, x-user-name); API keys for programmatic access	All traffic stays inside the customer network

The reference architecture for each deployment mode is described in detail in our Data Flow & Architecture Security Guide, available under NDA — see Documents Under NDA.

3. Tenancy model

• The tenantId is extracted from the Auth0 org_id claim on every authenticated request.
• Every customer-data-bearing domain table — connections, connection metadata, entities, flows, flow data, published flows, execution insights, API keys, workspaces, categories, scheduled jobs, and billing — carries a tenant_id column that is NOT NULL.
• All database reads and writes go through a repository layer that filters every query by tenantId; this is enforced at the data-access layer, not at the route layer alone.
• API keys also carry both tenantId and workspaceId, so programmatic access cannot cross tenant or workspace boundaries.
• A small number of platform-global tables — for example, the shared flow-template library — are keyed by their natural identifier by design rather than by tenant_id. They contain no customer business data.
• In on-prem mode the tenant is fixed at process startup from a deployment-time environment variable; there is no Auth0 dependency.

4. Authentication

FactoryThread does not build identity from scratch. In SaaS and single-tenant managed deployments, authentication is delegated to Auth0 (an Okta company) — a dedicated identity-as-a-service provider whose entire business is identity security. The trust we ask customers to place in their identity layer is therefore inherited from a specialist provider rather than duplicated by us.

What FactoryThread does on every authenticated request

• Verifies the JWT against Auth0's JWKS endpoint and enforces both the audience and issuer claims.
• Extracts the customer's tenantId from the Auth0 org_id claim, which then drives row-level isolation in the database.
• Accepts the access token from an HTTP-only cookie (preferred) or from a Bearer-token Authorization header (for programmatic callers).
• Stores no user passwords or credential material.

What we inherit from Auth0

• Independent attestations. Auth0 maintains its own SOC 2 Type II, ISO 27001, ISO 27018, and additional independent attestations. The identity layer of every FactoryThread login is covered by those programs without any work on our part. Customers can review the current attestation list on Auth0's own trust page.
• MFA. TOTP, push notifications (Auth0 Guardian), WebAuthn / passkeys, and SMS — selectable per-tenant by the customer's Auth0 admin.
• SSO and federation. SAML 2.0 and OIDC against the customer's identity provider, plus social-login providers if the customer chooses to enable them.
• Identity protection. Breached-password detection against published credential-leak datasets, credential-stuffing protection, brute-force lockout, and anomaly detection (impossible-travel, suspicious-IP, unusual device).
• Password policy enforcement. Complexity rules, password history, and rejection of known-leaked passwords — enforced by Auth0, not implemented by FactoryThread.
• User lifecycle. SAML / OIDC just-in-time provisioning, SCIM provisioning on Auth0 Enterprise plans, and immediate deprovisioning when the customer's IdP revokes the user.
• Token hygiene. Short-lived JWTs with periodic JWKS key rotation; rotating refresh tokens.
• Audit logs. Every sign-in, MFA challenge, password reset, and administrative action is logged on the Auth0 side and is queryable by the customer's Auth0 admins.
• Operational reliability. Geo-distributed identity service with a published uptime SLA.

The practical effect: a customer's identity-layer controls are owned by a provider who specializes in identity. FactoryThread engineers do not build, operate, or store the password and credential surface — and the strength of the customer's authentication is set by the customer's Auth0 configuration, not by us.

On-prem:

• Authentication is delegated to a customer-supplied reverse proxy (nginx, Traefik) that performs SSO and forwards user identity headers (x-user-id, x-user-email, x-user-name).
• Programmatic access uses API keys.
• The reverse-proxy boundary is the only authentication checkpoint in air-gapped deployments — customers should ensure the proxy is the only path to the backend container.

5. Authorization

• Workspaces are the second level of isolation under a tenant. Connections, flows, API keys, and insights are workspace-scoped; users see and act on only the workspaces they are assigned to.
• API keys:
  • Generated as 32 random bytes (256 bits of entropy) base64url-encoded with an ft_ prefix.
  • Only the SHA-256 hash is persisted; the plaintext is shown to the user once at creation and never again.
  • Each key is scoped to a single workspace and tenant; lookups are by hash.
  • The issuing user, creation time, and last-used timestamp are recorded on the key for review and revocation.
  • Accepted as an X-API-Key header, HTTP Basic auth (with x-api-key as the username), URL path parameter (for OData routes), or api_key query parameter.

6. Encryption

In transit

• All *.factorythread.com endpoints are HTTPS-only with TLS 1.2 or higher, terminated by Azure Front Door / App Gateway.
• The frontend talks to the backend over HTTPS; the backend publishes flow execution requests to RabbitMQ over an authenticated channel; the worker calls customer systems over HTTPS where the destination supports it.
• Roadmap (Q2 2026): today, the REST connector's shared HTTPS agent does not strictly verify TLS certificates on outbound calls, in order to support customer endpoints that present self-signed or private-CA certificates. We are moving to strict TLS verification by default, with a per-connection self-signed-certificate opt-in for customers who genuinely need it.

At rest

• The application database is Azure-managed PostgreSQL with cloud-provider disk encryption.
• Auth0 owns user passwords; Stripe owns card data.
• Roadmap (Q2 2026): application-layer encryption for connection metadata using AES-256-GCM with envelope keys held in Azure Key Vault. Today connection metadata sits as plaintext inside the encrypted database; the upcoming change adds a second layer so that even a database-level read does not expose connection secrets.

What we inherit from Microsoft Azure

The same delegation principle that applies to identity (see §4) applies to compute and storage. FactoryThread runs on Microsoft Azure, and a number of important controls are operated by Azure rather than by us:

• Independent attestations. Microsoft Azure maintains its own SOC 1 / 2 / 3, ISO 27001, ISO 27017, ISO 27018, FedRAMP High, HIPAA / HITRUST, PCI-DSS, CSA STAR, and a long tail of regional and industry attestations. The current list is on Microsoft's own trust portal.
• Physical data center security. Multi-layer physical access control, biometric verification, 24×7 monitoring, redundant power and cooling, and certified disposal of failed media — all run by Microsoft.
• At-rest encryption. Storage and database disks are transparently encrypted at the storage layer using Azure-managed keys, before any FactoryThread process reads or writes them.
• Managed PostgreSQL. Automated backups with point-in-time recovery, transparent data encryption, encrypted replication, and minor-version patching are operated by Azure rather than by FactoryThread engineers.
• Network protection. Azure Front Door / App Gateway terminates TLS for the platform's public hostnames. Microsoft operates platform-level DDoS protection in front of every Azure-hosted service.
• Key management. The envelope keys for the Q2 2026 connection-metadata encryption rollout will live in Azure Key Vault, an HSM-backed key-management service.

The customer's compute and storage layer is therefore hosted on a provider with its own audited security program. FactoryThread is responsible for the application-level controls on top of that — not for re-implementing data-center security or operating managed services.

7. Secrets management

• Application secrets (Auth0 audience/domain, RabbitMQ URL, database URL, Stripe webhook signing secret) are passed as environment variables and managed by the deployment platform (GitHub Actions secrets → Azure App Service / Container Apps).
• On-prem deployments can wire their own secrets manager (HashiCorp Vault, Azure Key Vault, AWS KMS) into the docker-compose .env step or directly into the container runtime.
• API keys, access tokens, and outbound-call credentials are never written to logs. Authorization headers and request bodies are stripped before any error is logged.

8. Logging and monitoring

• The backend and worker emit structured JSON logs that include tenantId, userId, and request/run identifiers as context on every log line.
• Logs are forwarded into a Grafana Alloy → Loki / Prometheus stack. Dashboards cover request rates, error rates, latency, and worker queue depth.
• Flow execution insights are stored in the application database and are visible to customers in their workspace. Retention is configurable per organization.

9. Vulnerability management

• Dependencies are tracked by Dependabot; security advisories are reviewed and patched on a rolling basis.
• pnpm audit runs as part of CI on every push to a PR or main.
• Production images are rebuilt and redeployed on every merge to the main branch, picking up base-image security patches as part of the regular release cadence.
• Static type-checking, ESLint, and Prettier run on every PR.

10. Corporate controls

The bulk of this document is product security — how the platform itself is built and run. A short note on company-level controls and the vendor stack underneath the platform:

• Production access is limited to approved engineering personnel using SSO with MFA, least-privilege role assignments, and logged sensitive actions. Access lists are reviewed periodically.

• New hires complete background checks where local law permits. Internal device access uses corporate SSO; sensitive admin actions use MFA.

• Vendor stack. The external services that may touch customer data each maintain their own independent security attestations. FactoryThread maintains a vendor risk register tracking purpose, data processed, and certification references for each:

  • Auth0 (identity, see §4) — SOC 2 Type II, ISO 27001, ISO 27018, and additional independent attestations. FactoryThread does not store passwords or credential material.
  • Microsoft Azure (hosting, managed PostgreSQL, RabbitMQ, Key Vault, see §6) — SOC 1 / 2 / 3, ISO 27001, ISO 27017, ISO 27018, FedRAMP High, HIPAA / HITRUST, PCI-DSS, CSA STAR, and a long tail of regional attestations.
  • Stripe (billing) — PCI-DSS Level 1, SOC 1, SOC 2 Type II, and ISO 27001. FactoryThread is out of PCI scope for cardholder data: card collection happens entirely in Stripe-hosted UI (Stripe Checkout / Customer Portal). FactoryThread persists only Stripe object identifiers (customer / subscription / price / invoice IDs) and timestamps; we never see PAN, CVC, or any other cardholder data.
  • OpenAI / LangChain (AI-driven flow nodes, opt-in only) — SOC 2 Type II. Engaged only when a customer explicitly enables an AI node or AI flow; the data sent to the model is the prompt the customer's flow constructs.

  Customers can review each vendor's current attestation list on the vendor's own trust portal. A data-processing agreement (DPA) and the current subprocessor list are available on request.

11. Roadmap (security gaps we are actively closing)

We disclose these here because a thorough third-party reviewer would find them anyway. Each item is tagged with the target quarter; engineering work is in progress.

Area	Today	Target	Quarter
Connection metadata encryption	Connection credentials are stored as plaintext inside the encrypted database, protected by Azure-managed disk encryption only	AES-256-GCM application-layer encryption with envelope keys held in Azure Key Vault	Q2 2026
Strict TLS on outbound REST	Outbound HTTPS calls do not strictly verify TLS certificates, in order to support customer endpoints that present self-signed or private-CA certificates	Strict TLS verification by default, with a per-connection self-signed-certificate opt-in	Q2 2026
Tenant-scoped activity audit log	We record publish events, API-key issuance and last-used timestamps, execution insights, and infrastructure logs — but not a single comprehensive who-did-what-when surface	A unified activity log queryable per tenant in the product UI	Q3 2026
Flow change history	Only the latest version of a flow definition is retained for editing; published versions are captured separately at publish time	Full change history with side-by-side diff viewer in the designer	Q3 2026

12. Compliance posture

FactoryThread does not currently hold SOC 2, ISO 27001, 21 CFR Part 11, or GxP certifications. Our Compliance Readiness Statement describes our control alignment with each framework, the gap to certify, and target audit timelines. We will complete CAIQ-Lite, SIG-Lite, or a customer-specific questionnaire on request.

Contact

To request the NDA-gated documents, a security questionnaire, or a 30-minute walkthrough with our team, email support@factorythread.com.