Reference Architecture: Cloud VDI on OCI for Multi-Plant Manufacturing (2026)

From Plant-Centric IT to Cloud Workspaces
Picture of Micaela Asaad
Micaela Asaad

Solution Engineer

Table of contents

A deep technical reference architecture for cloud VDI on OCI in multi-plant manufacturing environments, focused on ZTNA, OT/IT integration, and resilience.

Manufacturing VDI Architecture Is an OT/IT Problem First

In 2026, designing VDI for manufacturing is no longer a desktop virtualization exercise. It is an OT/IT integration problem, a security boundary problem, and a resilience engineering problem.

Manufacturing environments combine fundamentally different worlds:

  • OT systems that are latency-sensitive, fragile, and often not designed for direct exposure
  • IT systems that are identity-driven, cloud-connected, and continuously changing
  • Users who span operators, engineers, planners, OEMs, and third-party vendors
  • Plants with uneven connectivity, limited maintenance windows, and low tolerance for disruption

Traditional VDI reference architectures—designed for corporate offices—fail in this context because they assume stable networks, uniform endpoints, and trusted internal connectivity.

This article defines a modern reference architecture for deploying cloud VDI on Oracle Cloud Infrastructure (OCI) in multi-plant manufacturing environments, with a strong focus on:

  • Zero Trust Network Access (ZTNA) principles
  • Reverse connectivity to protect OT networks
  • Secure IT/OT integration without flat networks
  • Operational resilience under failure conditions

This reference architecture builds on the broader discussion of why manufacturing CIOs are re-architecting workspaces in 2026, driven by IT/OT convergence, operational risk, and changing access patterns across plants.

Architectural Goals for Manufacturing VDI in 2026

Before defining components, it is critical to define what the architecture must guarantee.

Operational continuity over architectural purity

Manufacturing VDI must prioritize continued access to critical systems over idealized cloud-native designs. This means accepting hybrid states, temporary asymmetry between plants, and controlled technical debt—while maintaining security and governance.

OT protection as a first-class requirement

The architecture must assume that OT networks cannot be trusted, patched, or redesigned quickly. Any solution that requires inbound connectivity to plants, persistent VPN tunnels, or direct exposure of MES/SCADA systems increases risk unacceptably.

Identity-driven access instead of network trust

All access decisions must be driven by identity, role, and context, not by IP ranges or network location. This is foundational to Zero Trust and essential for contractor-heavy manufacturing environments.

High-Level Architecture Overview

At a system level, a multi-plant manufacturing VDI architecture on OCI consists of six tightly integrated layers:

  1. Identity and Trust Layer
  2. ZTNA and Access Control Layer
  3. Workspace Orchestration Layer
  4. Compute and Session Execution Layer
  5. OT/IT Connectivity Layer
  6. Observability, Security, and Governance Layer

The key architectural shift—compared to legacy designs—is that connectivity flows outward from OT and inward from users, never the reverse.

Identity and Trust Layer

Flowchart of unified identity roles (Engineer, Vendor, Planner) accessing OT systems through a ZTNA security gateway.

Centralized identity as the single source of truth

Manufacturing organizations typically already operate one or more enterprise identity providers. The reference architecture assumes:

  • Federation with existing IdPs (cloud or on-prem)
  • No duplication of identities inside plants
  • Explicit differentiation between employees, contractors, and vendors

Identity becomes the only trust anchor. Network location, device location, and plant location are treated as untrusted context.

Role and scope modeling aligned to OT reality

Roles must map to systems, not networks. For example:

  • An OEM engineer may access a specific MES interface for a specific line
  • A maintenance vendor may access PLC management tools for a defined time window
  • A planner may access reporting systems without touching OT networks

This role-to-application mapping is enforced at the access layer, not through network segmentation alone.

ZTNA and Access Control Layer (Core of the Architecture)

ZTNA and Access Control Layer (Core of the Architecture)

Why ZTNA replaces VPN in manufacturing

VPNs assume that once a user is connected, the internal network is trustworthy. This assumption is incompatible with modern manufacturing environments where:

  • OT networks must remain isolated
  • Contractors rotate frequently
  • Credential compromise is a leading attack vector
  • Lateral movement must be prevented

ZTNA in this architecture enforces application-level access, not network-level access.

Thinfinity as the ZTNA enforcement point

Thinfinity plays a central role here as a ZTNA gateway and workspace broker, not just a VDI front-end.

Key architectural characteristics:

  • No inbound connections to plants
    Thinfinity components inside OT or plant-adjacent networks establish outbound-only, reverse connections to the control plane.
  • Application-level exposure
    Users never see the network. They are granted access to specific desktops or applications, delivered through the workspace.
  • Session containment
    Each session is isolated. Even if credentials are compromised, lateral movement into OT networks is prevented.

This reverse connectivity model is critical in manufacturing, because it allows secure access without opening firewalls or exposing OT segments.

Workspace Orchestration Layer

Decoupling access logic from execution location

Manufacturing environments rarely migrate all plants simultaneously. The orchestration layer abstracts:

  • Whether a workload runs on-prem or in OCI
  • Whether access is session-based or desktop-based
  • Whether the user is internal or external

Thinfinity’s orchestration capabilities allow:

  • Central policy definition
  • Per-role application catalogs
  • Consistent user experience across heterogeneous environments

This avoids parallel access stacks (VPN + VDI + web portals), which are a major source of operational complexity.

Compute and Session Execution Layer (OCI)

Compute and Session Execution Layer (OCI)

Separation of workload classes

A critical architectural decision is to never collapse all users into a single desktop pool.

Instead, workloads are separated by behavior and risk profile:

  • Task and operator desktops (pooled, stateless)
  • Knowledge worker desktops (pooled with profiles)
  • Engineering desktops (dedicated or GPU-backed)

OCI compute shapes allow precise sizing of each pool, avoiding the “average desktop” anti-pattern that inflates cost and complexity.

Separating workload classes and avoiding per-plant overprovisioning has a direct impact on the total cost of ownership of VDI in manufacturing, particularly when downtime and recovery effort are included in the model.

Engineering and OT-adjacent workloads

Engineering and OT-adjacent workloads often require:

  • High and predictable CPU/GPU performance
  • Low jitter rather than lowest possible latency
  • Stable session behavior over long periods

These workloads are explicitly isolated from office user pools to prevent noisy-neighbor effects and simplify incident containment.

OT/IT Connectivity Layer

Reverse connectivity as a safety boundary

The defining feature of this architecture is directionality.

  • OT and plant-adjacent systems initiate outbound connections
  • No inbound sessions are allowed into OT networks
  • Firewalls remain closed by default

This model dramatically reduces the attack surface and aligns with zero-trust principles.

Controlled integration points

Integration between IT and OT occurs through controlled mediation points:

  • Virtual desktops that host OT-facing applications
  • Jump-host–like execution environments without exposing networks
  • Session recording and audit trails

Users interact with OT systems through the workspace, not with the network.

Observability, Security, and Governance Layer

Session-level visibility instead of packet inspection

Traditional network monitoring is of limited value in encrypted, identity-driven environments. This architecture emphasizes:

  • Session telemetry
  • Authentication and authorization events
  • Application usage patterns

Thinfinity contributes session-level visibility that is meaningful for both security teams and operations.

Audit and compliance alignment

Because all access is mediated, logged, and identity-bound, the architecture supports:

  • Access traceability
  • Separation of duties
  • Time-bound permissions
  • Forensic readiness

This is particularly relevant for ISO 27001, NIST-based frameworks, and internal manufacturing governance requirements.

Scaling the Architecture Across Plants

The reference architecture is designed to scale through replication, not customization.

New plants are onboarded by:

  • Deploying a local connector/broker
  • Establishing outbound trust
  • Applying existing access policies

No redesign of network topology or security model is required.

Conclusion: Manufacturing VDI Architecture Is a Control System

In 2026, manufacturing VDI architecture must be treated as a control system, not an IT convenience layer.

By combining OCI’s infrastructure primitives with a ZTNA-first workspace platform like Thinfinity, organizations can:

  • Enable secure IT/OT integration without exposing OT networks
  • Replace VPN-based access with application-level trust
  • Support hybrid, phased modernization without parallel stacks
  • Improve resilience, auditability, and operational confidence

The result is not just cloud VDI, but a governed access fabric that reflects how modern manufacturing actually operates.

This architecture is the technical execution layer behind a broader manufacturing workspace strategy in 2026—one where resilience, governance, and access control are treated as first-class design requirements, not afterthoughts.

FAQ: Cloud VDI, ZTNA, and OT Integration in Manufacturing

Why is reverse connectivity so important for OT environments?

Because it eliminates inbound attack paths. OT systems never accept external connections, drastically reducing exposure.

For most user access scenarios, yes. VPNs may still exist for specific machine-to-machine use cases, but user access shifts to ZTNA.

Third parties never touch the network. They access only the applications or desktops explicitly assigned to them, for limited time windows.

Yes. Legacy systems are accessed indirectly through controlled execution environments, avoiding direct exposure or modification.

Reverse connectivity behavior, session isolation, access control granularity, recovery workflows, and real plant network conditions.

Thinfinity_logo
Validate the Architecture with a Free POC
Run a no-cost proof of concept to test ZTNA access, OT isolation, performance, and recovery behavior in your manufacturing environment.

Add Comment

Thinfinity-blue-logo
See the Architecture in Action
Walk through a real multi-plant manufacturing VDI architecture using ZTNA and reverse connectivity to securely integrate IT and OT environments.

Blogs you might be interested in

<span>Cloud Architecture</span>, <span>Cloud VDI</span>, <span>Cost Optimization</span>, <span>Manufacturing</span>, <span>Oracle Cloud Infrastructure (OCI)</span>, <span>Thinfinity Workspace</span>, <span>Virtual Desktop Infrastructure (VDI)</span>