Equipment telemetry is among the most commercially sensitive data a fab produces. Recipe parameters, chamber conditions, throughput and yield-adjacent signals together describe how you make what you make. Reasonable people take very different views on where it should be allowed to sit.
This is a decision framework rather than a recommendation, because the right answer genuinely depends on the plant.
Option 1 — Fully air-gapped, on premise
Everything runs inside the fab network. No connection to the outside, in either direction.
What crosses the boundary. Nothing.
Good for. Plants with a strict OT security posture, foundry work under customer confidentiality obligations, and anywhere the security review would stall on any external egress at all.
The costs, honestly.
- Updates become a manual, scheduled operation. Someone carries them in
- You cannot be remotely supported. Diagnosis happens over a phone call or on site
- Multi-site aggregation is your problem to solve, not the platform's
- Backup and disaster recovery are entirely yours
Air-gapped is the most secure option and the most operationally expensive one. Plants sometimes choose it by default when they would be adequately served by the next option, and pay for that default for years.
Option 2 — In-country cloud, single tenant boundary
The platform runs in a data centre inside the country, under domestic jurisdiction. The fab connects out to it.
What crosses the boundary. Equipment telemetry, as configured. This is the question to interrogate: *which* variables, at what rate, and can you enumerate them? A platform that cannot tell you precisely what it sends is not one you can take through a security review.
Good for. Plants that want dashboards, cross-tool comparison and remote support, and whose concern is jurisdiction rather than egress per se. This is a real and common position, particularly where public funding or state incentives come with expectations about where data resides.
The questions your security team will ask, and should:
- Where physically is the data, and under which country's legal process can it be compelled?
- Is the connection outbound-only from the fab, or does the platform need to reach in?
- Is tenant isolation enforced in the database itself, or only in application code?
- What is retained, for how long, and how is deletion proven?
- Who at the vendor can see the data, and is that access logged?
The tenant isolation question is worth pressing on. Isolation implemented only in application logic fails the moment any query is written without the right filter. Isolation enforced at the database layer — row-level security that the database applies regardless of what the query says — fails closed instead. Ask which one you are getting.
Option 3 — Global cloud
The platform runs wherever the vendor runs it, typically a major hyperscaler region chosen for cost or latency.
What crosses the boundary. As above, but now also a jurisdictional boundary.
Good for. Multinational operators who already have this conversation settled at group level and whose existing tooling lives there anyway.
The friction. For a plant built with domestic public support, or one whose customers impose location requirements, this is often the option that cannot get through procurement regardless of its technical merits.
A hybrid worth considering
The options are not mutually exclusive, and the split that tends to work is by data type rather than by system.
Keep the high-volume, high-sensitivity material — raw trace data, recipe bodies, per-wafer detail — inside the fab. Send outward only what a dashboard or a multi-site view actually needs: state transitions, alarm summaries, aggregate performance.
This gets you remote visibility without exporting the process. It requires the connectivity layer to be capable of running split, and to let you configure precisely what leaves, which is a fair thing to ask a vendor to demonstrate rather than assert.
How we handle this
FabConnect supports the air-gapped on-premise deployment and an India-resident cloud deployment. Production hosting is in India, which was a deliberate decision: fab telemetry is commercially sensitive, and plants built with domestic support generally prefer domestic infrastructure.
Tenant isolation is enforced in the database with row-level security applied to every table that holds customer data, not in application code alone. A statement issued without a tenant context matches no rows — reads return nothing and writes are rejected. We would encourage you to ask any vendor, including us, to show you that rather than describe it.
What we do not offer is a hosted multi-tenant deployment outside India, and we would rather say so than pretend the choice is wider than it is.