Security
How your fab data is handled
This page describes what is implemented, in enough detail to be checked. It ends with what we have not done, because that is the part your security reviewer is going to ask about, and hearing it from us first is worth more than being caught out by it.
Where your data actually goes
FabConnect runs on your infrastructure. The gateway and the protocol engine are deployed inside your network, next to the tools they talk to, and equipment telemetry does not leave the fab unless you deploy a component that sends it somewhere.
There is no FabConnect cloud account, no central service your tools report to, and no tenant of ours holding your process data. If you deploy air-gapped, the software works air-gapped — that is the on-premise option, not a configuration flag on a hosted service.
This is also why there is no "sign in" on this website. There is nothing here to sign in to. Your console is at your own gateway address, behind your own firewall.
Tenant isolation is enforced by the database
Where one deployment serves more than one site or organisation, isolation does not rely on the application remembering to filter. Every tenant-scoped table has Postgres row-level security enabled and FORCED, so the policy applies to the table owner as well — the usual way RLS is silently bypassed.
Each request runs inside a transaction that binds the tenant with a transaction-local setting before any query executes. Transaction-local matters: the value cannot leak onto the next borrower of a pooled connection.
Both layers are present at once — an explicit predicate in every query and the database policy underneath it — and the test suite fails if either is removed.
Authentication
Passwords are hashed with bcrypt at a configurable cost. Sessions are JWTs, with a refresh token issued alongside the access token.
Time-based one-time passwords (TOTP) are supported for multi-factor authentication, using any standard authenticator app.
OIDC single sign-on works and is the supported path for identity federation. SAML is not: the provider exists in the codebase, and the response parsing and token validation return "not implemented". If your organisation requires SAML, it is not available today, and we would rather tell you now than during onboarding.
Secrets and failing closed
Database passwords and signing secrets can be supplied as file paths rather than environment variables, which is how Docker and Kubernetes secret mounts are meant to be consumed — the value does not appear in the process environment or in a container inspect.
In release mode the gateway refuses to start if the database password or the JWT signing secret is missing. It does not fall back to a default. A mis-wired secret mount is meant to be a failed deployment, not a service running in production with a known password.
What is audited
Changes that matter are recorded with the acting user, the target, and the outcome. Specifically: equipment created, updated and deleted; alarms acknowledged; API keys created and deleted; and user deletion, role changes and status changes.
That is the current list, and it is deliberately a list rather than the word "comprehensive". Reads are not audited, and the EDA and command surfaces are not yet covered. If your reviewer needs a specific action in the audit trail, ask — it is a small change, and a precise answer is more useful to you than a broad claim.
Audit records are themselves tenant-scoped under row-level security.
Transport
Connections the gateway originates negotiate TLS with a floor of TLS 1.2. Certificate verification is on by default; it can be disabled explicitly for a self-signed development peer, and that path is named, documented and still uses TLS rather than dropping to plaintext.
We say 1.2 rather than 1.3 because 1.2 is what the code enforces. Fab networks still contain equipment and middleboxes that a 1.3 floor would lock out, and claiming a floor we do not set would be the kind of detail a reviewer checks in a minute.
What we have not done
Every item here is a question a fab security review will ask. The answers are short and they are not flattering, which is the reason to publish them.
- No third-party penetration test
- No external security assessment has been performed. If your procurement process requires one, that is a real gap and we would want to talk about who does it and when.
- No SOC 2, ISO 27001 or equivalent
- We hold no security certification. We are a young company and have not been through an audit programme. Anyone claiming otherwise at our stage would be worth checking.
- Never run against physical equipment
- The platform is verified against our own equipment simulator. Nothing described here has been exercised in a production fab, on a real tool, on a real fab network. That is true of the whole product and is stated everywhere else on this site.
- SAML is not implemented
- OIDC works. SAML returns "not implemented" in the code path that would parse the response.
- No published vulnerability disclosure process
- There is no security@ mailbox or CVE process yet. Until there is, security reports should go to the contact address below and they will reach the person who wrote the code.
Questions, and reports
If you are reviewing FabConnect for deployment and need a specific answer — a control we have not listed, an audit action you require, a deployment topology — ask. If you have found a security problem in the software, the same address reaches the person who wrote it.
Contact us