This article provides a concrete reference architecture — not a framework overview, but a design that manufacturing IT teams can actually build. It maps Zero Trust controls to manufacturing-specific threats, defines an OCI Virtual Cloud Network topology that enforces those controls, and shows how Thinfinity Workspace, VergeIO, Okta, Claroty, and OCI’s built-in security services come together into a single, auditable Zero Trust design.
Why Zero Trust Works Differently in Manufacturing
The Zero Trust model described in NIST SP 800-207 and in the CISA Zero Trust Maturity Model was built mainly for IT environments. Manufacturing has unique characteristics that change how Zero Trust controls are applied — not which principles matter, but how you put them into practice.
You Can’t Put Security Agents on OT Devices
Typical Zero Trust setups rely on software agents on every device — EDR tools, certificate-based enrollment, managed device policies — to check device health before granting access. In manufacturing OT environments, this doesn’t work. PLCs, RTUs, DCS controllers, and legacy HMI workstations can’t run modern endpoint agents. Many operate on embedded systems; others run outdated OSes like Windows XP or 7 where installing agents could void support agreements.
Zero Trust in manufacturing must achieve device-level security through network controls — VLAN segmentation, firewall rules, network-level authentication — instead of endpoint agents. If a device is on the OT network, it’s treated as an OT device with OT-level access; it can’t reach IT systems except through defined pathways.
Legacy Applications Don’t Speak Modern Security Languages
Zero Trust access control assumes applications can evaluate identity tokens (OAuth 2.0, SAML, client certificates) and make authorization decisions. Legacy manufacturing applications from the VB6 and Win32 era can’t do this — they authenticate through Windows session identity at best, or have no authentication at all.
So Zero Trust identity controls for legacy apps must be applied at the Thinfinity Gateway, not at the application level. The Zero Trust controls (MFA, conditional access, RBAC, session recording) are all enforced before the application is reached. This isn’t a workaround — it’s the right pattern for environments where apps can’t integrate with modern identity systems.
Production Can’t Stop for Security Checks
Standard IT Zero Trust blocks access when policy conditions aren’t met. In manufacturing, blocking access to the MES or SCADA system because a conditional access policy triggered can halt the entire production line. An operator who can’t reach the scheduling app because their device posture check failed isn’t a security win — it’s a production incident.
Zero Trust in manufacturing must include production continuity: break-glass procedures (emergency access paths that bypass normal checks), offline access modes (access that works when the identity provider goes down), and conditional access policies that stay open for production-critical applications on plant floor devices. These aren’t compromises — they’re the right adaptations for the operational reality.
Attackers aren’t reinventing playbooks, they’re speeding them up with AI. The core issue is the same: businesses are overwhelmed by software vulnerabilities. The difference now is speed.
The Five Zero Trust Pillars Mapped to Manufacturing Controls
The CISA Zero Trust Maturity Model defines five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Here’s how each pillar maps to its manufacturing-specific implementation.
- Every human user authenticated through a central IdP (Okta or Microsoft Entra ID) with MFA enforced — no application access without MFA
- Machine-to-machine identity: service accounts for OT data flows (historian replication, OPC-UA sessions) use certificate-based authentication, not shared passwords
- Vendor and contractor identities managed as external identities in Okta/Entra ID — time-limited, scoped to specific applications, auto-expiring
- Legacy application users: individual identity enforced at Thinfinity Gateway even when the application itself uses a shared Windows session account
- OT adaptation: PLCs and RTUs cannot authenticate to an IdP — their identity is asserted by network position (OT zone membership) and by the conduit-level authentication of the relay that communicates with them
- Privileged access: PAM (CyberArk or HashiCorp Vault) for administrative credentials on session hosts, OCI instances, and VergeIO infrastructure
- IT endpoints: MDM enrollment (Microsoft Intune or Jamf) required for full access; device compliance checked by Entra ID Conditional Access or Okta Device Trust before Thinfinity session is assigned
- BYOD and unmanaged devices: routed to Thinfinity RBI (Kubernetes ephemeral containers) for regulated and OT-adjacent applications — no application content reaches the unmanaged endpoint
- Plant floor shared terminals: fixed hardware registered in Entra ID or Okta as shared devices; per-user authentication enforced at Thinfinity Gateway regardless of device account
- OT devices (PLCs, RTUs, HMIs): device posture enforced through network segmentation (Purdue Model zones) and Claroty passive monitoring, not endpoint agents
- Session host VMs on OCI and VergeIO: enrolled in Intune or managed through Thinfinity Cloud Manager image policies; OS patches applied through golden image updates, not in-session patching
- OCI Compute instances: managed through OCI Cloud Guard and OS Management Service; CIS benchmark hardening applied at image build time
- OCI VCN: micro-segmented into functional subnets (Gateway, Session Host, RBI/OKE, Management, Storage) with NSG rules enforcing least-privilege inter-subnet traffic
- IT/OT boundary: IDMZ proxy pattern (Article 9) — no direct IT-to-OT routable connection; all data exchange through IDMZ intermediaries (PI Relay, OPC-UA aggregator, MQTT broker)
- Thinfinity Gateway: terminates all user-to-application connections; no application server directly reachable from user networks; reverse connection architecture eliminates inbound ports
- OCI FastConnect or VPN Connect: encrypted, dedicated connectivity from OCI to plant sites — not public internet for production traffic
- Network traffic monitoring: Claroty passive OT monitoring; OCI VCN Flow Logs ingested into Datadog; NSG rule violations alerted in OCI Cloud Guard
- DNS security: OCI Private DNS for internal service resolution; no OT device resolves public DNS directly
- All application access through Thinfinity portal — VDI sessions (RDC), VirtualUI legacy apps, WAG-proxied internal web apps, RBI-isolated sensitive apps, VNC Linux sessions
- Per-application RBAC: every application in the Thinfinity portal has an explicit access policy; no application accessible without an assigned role
- Session recording: mandatory for regulated applications (QMS, SCADA web clients, financial ERP modules, OT asset access); stored in OCI Object Storage with immutable retention
- Legacy applications: security enforced at Thinfinity delivery layer (MFA, RBAC, recording) — application code unchanged
- Web SCADA and historian interfaces: delivered through Thinfinity RBI on OKE — ephemeral containers, no application content persists to endpoint
- Application health monitoring: Datadog monitors session host availability, application crash events, login time trends, and pool capacity by application
- Session recordings (OCI Object Storage, immutable buckets): process data, regulated records, and audit trails stored with write-once-read-many policy
- OT process data: flows OT → IDMZ → IT through PI Relay / OPC-UA aggregator — IT systems read from IDMZ copy, never from OT source directly
- Clipboard and download controls: enforced at Thinfinity session layer per application and per user group — regulated content cannot be copied to unmanaged endpoints
- Data classification: OCI tags applied to Object Storage buckets and file systems by data sensitivity (OT process data, regulated records, engineering IP, general operational)
- Encryption at rest: OCI Block Volume and Object Storage encrypted with OCI Vault-managed keys; customer-managed keys for highest sensitivity data
- Encryption in transit: TLS 1.2 minimum, TLS 1.3 preferred, for all application sessions through Thinfinity; OPC-UA Sign+Encrypt for all cross-zone data exchange
OCI Virtual Cloud Network Topology for Manufacturing Zero Trust
The OCI VCN design is the network foundation of the Zero Trust architecture. Here’s the subnet structure and security configuration.
VCN Subnet Design
Each subnet hosts a specific workload type with NSG rules that only allow the traffic that workload needs. Inter-subnet traffic not explicitly permitted is blocked. There are no “allow all” security lists.
| Subnet | CIDR | Workload | Inbound Permitted | Outbound Permitted |
|---|---|---|---|---|
| Gateway | 10.0.1.0/24 | Thinfinity Gateway, OCI LB, WAF | 443/TCP from 0.0.0.0/0; 8080/TCP from Session Host (health) | 8443/TCP to Session Host; 443/TCP to RBI/OKE; 443/TCP to OCI services; DENY else |
| Session Host | 10.0.2.0/24 | Thinfinity RDC/VNC session hosts | 8443/TCP from Gateway; 443/TCP from Management | 443/TCP to Object Storage; 443/TCP to File Storage; 1433/TCP to DB; DENY else |
| RBI/OKE | 10.0.3.0/24 | OKE node pool for RBI containers | 443/TCP from Gateway; OKE mgmt from control plane | 443/TCP to WAG targets; 443/TCP to OCI services; DENY OT access |
| WAG Backend | 10.0.4.0/24 | Internal web apps, WAG relay | 443/TCP from Gateway; 443/TCP from RBI/OKE | Specific app ports to on-prem via FastConnect; DENY else |
| Management | 10.0.5.0/24 | Cloud Manager, OCI Bastion, break-glass | 443/TCP from authorized admin IPs; OCI Bastion | 443/TCP to all subnets; 443/TCP to OCI API; DENY from user subnets |
| Storage | 10.0.6.0/24 | OCI File Storage, Object Storage PE | 2049/TCP (NFS) from Session Host; 443/TCP from Session Host | No outbound internet; OCI internal only |
| Database | 10.0.7.0/24 | OCI DBaaS, Oracle Autonomous DB | 1433, 5432, 1521/TCP from Session Host only; DENY else | 443/TCP to OCI services for backups; DENY else |
OCI Security Controls Built Into the Platform
- OCI Cloud Guard: Monitors for security issues — public buckets, permissive security lists, unused SSH keys. Enable at root compartment. Findings forwarded to Datadog.
- OCI Vault (Key Management): Manages encryption keys. Use customer-managed keys (CMKs) for regulated environments. Keep session recording CMKs separate.
- OCI Bastion: Time-limited, IAM-authenticated SSH/RDP access without public IPs. Fully logged. Use for all admin access.
- OCI VCN Flow Logs: Captures accepted/rejected traffic at subnet level. Forward to Datadog for detecting unauthorized traffic.
- OCI WAF: OWASP Top 10 rules, rate limiting, geo-restriction in front of Thinfinity Gateway’s Load Balancer.
FastConnect and VPN Connect: Connecting OCI to the Plant
The architecture requires reliable, encrypted connectivity between OCI and plant sites for Thinfinity session traffic, PI Relay replication, and FSLogix containers. OCI FastConnect (dedicated private circuit, 1 or 10 Gbps) is preferred for latency-sensitive environments. Where FastConnect isn’t available, OCI VPN Connect (IPsec IKEv2) provides encrypted connectivity over the internet. For multi-plant organizations, use OCI’s Hub-and-Spoke topology with peered VCNs.
Zero Trust Control Matrix
Complete control inventory for a manufacturing Zero Trust deployment on OCI. Controls marked Required (baseline), Recommended (mature), or Enhanced (regulated/high-security).
| Control | Pillar | Tool | OCI Implementation | Level |
|---|---|---|---|---|
| MFA for all user access | Identity | Okta / Entra ID | Enforced at Thinfinity Gateway via SAML; no session without MFA | Required |
| Vendor/contractor lifecycle | Identity | Okta / Entra ID External | Time-limited guest accounts; auto-expire; scoped to specific apps | Required |
| Privileged access mgmt | Identity | CyberArk / Vault | Admin credentials vaulted; session recording; JIT access for OCI root | Recommended |
| Machine identity | Identity | OCI IAM / X.509 | Instance Principal for API calls; X.509 for OPC-UA; no shared passwords | Required |
| SSO across all apps | Identity | Okta / Entra ID | Thinfinity portal integrated with IdP; single auth for all sessions | Recommended |
| Managed device enrollment | Devices | Intune / Jamf | Device compliance checked before Thinfinity session assignment | Recommended |
| BYOD isolation | Devices | Thinfinity RBI on OKE | Unmanaged devices to ephemeral K8s containers; no app content reaches device | Required |
| Session host hardening | Devices | OCI OS Mgmt / CIS | CIS-hardened golden image; patched monthly via rotation | Required |
| OT device posture | Devices | Claroty / OT segmentation | Bounded by Purdue zone membership; Claroty monitors cross-zone traffic | Required |
| OCI compute hardening | Devices | Cloud Guard / CIS | Cloud Guard at root compartment; findings to Datadog | Required |
| Micro-segmented VCN | Networks | OCI NSGs | Functional subnets; NSG rules deny all except permitted flows | Required |
| IT/OT boundary (IDMZ) | Networks | Thinfinity/PI Relay/OPC-UA | No direct IT-to-OT connection; all through IDMZ intermediaries | Required |
| Zero inbound ports | Networks | Thinfinity reverse conn | App servers have no public ports; relay outbound to Gateway only | Required |
| Encrypted OCI-to-plant link | Networks | FastConnect / VPN | Dedicated or IPsec circuit; no unencrypted session traffic | Required |
| Network anomaly detection | Networks | Claroty / Flow Logs / DD | Flow Logs to Datadog; Claroty passive OT; Cloud Guard alerts | Recommended |
| DNS security | Networks | OCI Private DNS | Internal resolution via Private DNS; no OT public DNS | Recommended |
| Single portal for all apps | Apps | Thinfinity Workspace | VDI, VirtualUI, WAG, RBI in one portal; one auth, one audit trail | Required |
| Per-application RBAC | Apps | Thinfinity + IdP groups | Explicit access policy per app; no access without role | Required |
| Session recording | Apps | Thinfinity + OCI Object | Immutable recordings; bucket with WORM retention | Required |
| Legacy app security | Apps | Thinfinity VirtualUI/RDC | MFA + RBAC at Thinfinity layer; recording fills audit gap | Required |
| OT web app isolation | Apps | Thinfinity RBI on OKE | SCADA clients in ephemeral K8s containers; no content to device | Required |
| App availability monitoring | Apps | Datadog + Thinfinity | Pool availability, login time, crash events to Datadog | Recommended |
| WAF for gateway | Apps | OCI WAF | OWASP Top 10 + rate limiting on Gateway LB | Recommended |
| Recording immutability | Data | OCI Object Storage WORM | Immutable bucket; 12-month minimum retention | Required |
| Clipboard/download restrict | Data | Thinfinity session policy | Per-app clipboard and file transfer policy | Required |
| OT data isolation | Data | PI Relay / OPC-UA / MQTT | OT-to-IDMZ only; IT reads from IDMZ; no IT write-back | Required |
| Encryption at rest | Data | OCI Vault CMK | Block Volume, Object Storage, File Storage with CMKs | Recommended |
| Data classification tagging | Data | OCI Resource Tags | Buckets tagged by sensitivity; Cloud Guard tag policies | Enhanced |
| DLP for sessions | Data | Thinfinity clipboard + recording | Clipboard restriction + retrospective recording audit | Enhanced |
Thinfinity Workspace as the Zero Trust Control Plane
In this architecture, Thinfinity Workspace acts as the Zero Trust control plane for all application access — the component that makes and enforces access decisions.
What “Control Plane” Means Here
Thinfinity Gateway is the Policy Enforcement Point for all application access — VDI sessions, VirtualUI legacy apps, WAG-proxied web apps, and RBI sessions. The identity provider (Okta or Entra ID) is the Policy Decision Point. OCI Object Storage with immutable retention is the audit data store. A single enforcement point covers the entire application portfolio — legacy Win32 tools, modern web apps, cloud ERP portals, and OT-adjacent SCADA interfaces — without modifying any application.
How Authentication Flows Through the Architecture
The user opens the Thinfinity portal and logs in. Thinfinity redirects to the IdP (Okta or Entra ID) which evaluates conditional access policies — device compliance, user risk, location, time-of-day — and challenges with MFA as needed. On success, the IdP issues a SAML/OIDC token. Thinfinity checks role-based access, assigns a session from the right pool (GPU host for CAD, standard host for legacy apps, OKE pod for RBI, WAG relay for web apps), and records the session. On session end, RBI sessions destroy the Kubernetes pod.
This flow is the same for modern web apps, legacy VB6 tools, SCADA web clients, or full remote desktops. Consistent user experience, consistent security, consistent audit trail.
VergeIO: Extending Zero Trust to the Plant Floor
For plants that can’t route all sessions through OCI — due to latency, connectivity, or local network dependencies — VergeIO provides on-premises session host infrastructure that extends Zero Trust to the plant floor.
Thinfinity Cloud Manager manages session host pools on both OCI and VergeIO from one console. Access policies and session recording settings are identical across both — a user’s authorization doesn’t depend on where the session host lives. A VergeIO cluster in the plant’s server room sits physically next to the historian, SCADA server, and MES, keeping session traffic local for latency-sensitive OT applications while authentication stays centralized on OCI. The IT/OT boundary stays intact — VergeIO hosts access OT systems only through defined IDMZ conduits.
Detection and Response: Claroty and Datadog
Zero Trust isn’t just about prevention — it requires detection and response capabilities to identify when prevention controls have failed or been bypassed.
CISA has been acutely focused on guiding agencies, who are at various points in their journey, as they implement zero trust architecture.
Claroty: OT-Specific Zero Trust Enforcement and Anomaly Detection
Claroty operates as a passive monitoring system in the OT network — it receives all OT traffic via switch port mirroring, builds a behavioral baseline of all devices, and alerts when traffic deviates. In the Zero Trust context, Claroty detects when network-level enforcement controls (Purdue zone segmentation, IDMZ conduits, firewall rules) have been bypassed or misconfigured.
Key capabilities: zone and conduit management (any direct IT-to-OT connection triggers an immediate alert), device baseline enforcement (a PLC communicating with a new destination IP is flagged as potential lateral movement), and passive vulnerability assessment without disrupting OT communication. For more on zone-and-conduit segmentation, see this guide on ISA/IEC 62443 from Dragos. Claroty alerts forward to Datadog, where they’re correlated with VCN Flow Logs and Thinfinity session logs for unified investigation.
Datadog: The Single Observability Layer
Datadog receives telemetry from every layer: OCI VCN Flow Logs, Thinfinity session metrics, NVIDIA DCGM metrics, Windows Event Logs, Claroty alerts, and OCI Cloud Guard findings.
The key security dashboards track: after-hours access to regulated apps (a SCADA client accessed at 2 AM from a new location is a real-time alert), OT zone boundary violations from Claroty (any direct IT-to-OT connection is a P1 alert), failed authentication spikes, and session host pool availability (zero hosts at shift start is a production incident). Manufacturing IT security keeps a Datadog dashboard open during production shifts — one pane of glass for the entire architecture’s operational state. For more on how IEC 62443 enhances industrial cybersecurity, Fortinet’s overview provides additional context.
Zero Trust Maturity Roadmap: From Current State to Full Architecture
Most manufacturing organizations aren’t starting from scratch. This phased roadmap provides a realistic path from a typical starting point (VPN-dependent access, minimal OT segmentation, no unified portal) to the full Zero Trust architecture.
| Phase | Timeline | Actions | Outcome |
|---|---|---|---|
| Phase 1: Foundation | 0–3 months | Deploy Thinfinity Gateway. Integrate Okta/Entra ID with MFA. Migrate highest-risk VPN apps to WAG. Enable session recording. Deploy OCI VCN. | MFA enforced. VPN eliminated for web apps. Session recording live. |
| Phase 2: App Coverage | 3–6 months | Wrap legacy Win32 apps in Thinfinity VirtualUI/RDC. Deploy RBI on OKE for SCADA/BYOD. Deploy FSLogix. Implement per-app RBAC. Deploy Datadog. | All apps in unified portal. BYOD isolated. Legacy audit gaps closed. |
| Phase 3: OT Boundary | 6–9 months | Implement IDMZ (PI Relay, OPC-UA, MQTT). Remove direct IT-to-OT rules. Deploy Claroty. Migrate OT vendor access to Thinfinity. Integrate Claroty into Datadog. | IT/OT boundary defensible. Vendor access audited. OT anomaly detection live. |
| Phase 4: Cloud Hardening | 9–12 months | Enable Cloud Guard. Migrate to CMKs in OCI Vault. Deploy OCI WAF. Implement OCI Bastion. Configure break-glass procedures. | Cloud posture monitored. Encryption key control. Admin access audited. |
| Phase 5: Maturity | 12–18 months | Implement PAM. Formalize IEC 62443 SL2 documentation. Tabletop exercises. Data classification tagging. Annual architecture review. | Audit-ready. IEC 62443 SL2 evidence complete. Incident response tested. |
Frequently Asked Questions
How does this architecture satisfy IEC 62443 requirements?
It maps to IEC 62443-3-3 Security Level 2: MFA via Okta/Entra ID covers SR 1.1, PAM covers SR 1.3, session recording and OCI audit logs cover SR 2.8, and IDMZ + VCN micro-segmentation covers SR 5.1/5.2. For SL3, add hardware unidirectional gateways at the IT/OT boundary.
What’s the break-glass procedure when Thinfinity Gateway or OCI is unreachable?
Gateway down: on-prem apps use a local VergeIO-hosted Thinfinity Gateway with local AD auth. IdP down: Thinfinity falls back to local AD after 60 seconds for production-critical apps. Both should be documented, tested quarterly, and events logged locally.
How do we demonstrate this to an auditor or cyber insurer?
Provide: MFA logs (Okta/Entra ID + Thinfinity), network segmentation evidence (OCI NSG exports + Claroty config), privileged access logs (OCI Audit + session recordings + PAM exports), and detection proof (Datadog dashboards + Claroty alert history).
Can this work for a multi-site manufacturing organization?
Yes — OCI hub-and-spoke topology. Gateway and management in the hub VCN; each plant connects via FastConnect or VPN. Session hosts can be in the hub, spoke VCNs, or on VergeIO on-prem. Same portal URL for all sites; Cloud Manager routes sessions by site and role.
How long does implementation realistically take?
12–18 months for full maturity. Phase 1 (Thinfinity + MFA + WAG) takes 6–8 weeks and delivers immediate value: VPN elimination, MFA enforcement, and session recording. The hardest phase is the OT boundary work (Phase 3), which requires careful change management to avoid production disruption.
