Safeguarding a Vendor-Owned PCS Application on Company-Owned Virtualized Infrastructure

Executive summary

Operators increasingly ask specialist vendors to deploy and run PCS applications under a Build-Own-Operate-Transfer (BOOT) model — but on the operator’s own infrastructure, rather than the vendor’s. In practice this means the vendor’s application runs as a tenant on the company’s virtualized compute and shared storage, inside an OT domain that already hosts other PCS applications, until ownership transfers to the company.

This model is attractive commercially but creates a shared-tenancy security problem in one of the most sensitive parts of an industrial estate. The controlling ideas are: define responsibility precisely, isolate the tenant at the virtualization and network layers, control identity and privileged access without blurring ownership, protect and delineate data, secure every interface and connectivity path, and plan the Transfer from the outset. This paper develops each of these into an implementable reference.

1. Introduction and scope

The scenario: a vendor will build, own, and operate a PCS application, deploying it into customer-owned server and storage infrastructure that is virtualized and shared with other PCS applications within an OT mine domain. At the Transfer milestone the application and its operation pass to the company. This paper addresses the technical and governance controls required across the Build, Operate, and Transfer phases.

2. Deployment model and topology

The vendor application is delivered as one or more virtual machines on the company’s hypervisor cluster, drawing storage from the company’s shared arrays, and connected within the OT network. It coexists with other PCS applications on the same platform. The design objective is strong logical (and, where justified, physical) separation of this tenant from its neighbours, while enabling only the specific, controlled interactions the process requires.

3. Shared-responsibility model

A written RACI matrix must precede deployment. Unclear ownership of patching, backup, monitoring, and access is the most common source of shared-tenancy failure.

• Company (platform): hypervisor, storage, physical hosts, network and segmentation, Active Directory, backup/DR, physical security, and overall OT security governance.
• Vendor (application): the PCS application, its guest OS hardening and patch currency, application configuration, and application data — strictly within its allocated boundary.
• Shared and explicit: change and patch windows, vulnerability management, security monitoring and log sharing, incident response roles, and the Transfer plan.

4. Compute and storage virtualization

• Compatibility: validate guest OS, application, hypervisor tools, and storage against the vendor and hypervisor Hardware Compatibility Lists; confirm support lifecycles (no EOL OS) and licensing (OS, database, application, and per-socket/‑core hypervisor).
• Isolation: allocate dedicated resource pools; prefer dedicated hosts and datastores for the tenant so resource contention or a compromise cannot affect co-resident PCS apps.
• Data protection: encrypt the tenant’s data at rest on shared storage; separate its datastores and backup jobs logically from other applications.
• Lifecycle: control who may take snapshots, clone, or migrate (vMotion/Live Migration) the vendor VMs; uncontrolled snapshots and clones are a common data-leak and drift vector.
• Backup/restore: define ownership and test restores; ensure vendor VM backups do not expose company data or vice versa.

5. Network segmentation and micro-segmentation

Segmentation follows the Purdue model and IEC 62443. The vendor tenant is its own zone; every interaction with other PCS applications, historians, or higher levels is a defined conduit.

• Dedicated VLAN/zone for the tenant with host-based and network micro-segmentation; default-deny to co-resident PCS apps.
• Broker any Level 3 / enterprise reporting through the industrial DMZ; no direct enterprise-to-tenant path.
• Permit only named protocols and endpoints on each conduit; inspect and log cross-zone traffic.

6. Identity, credentials and the domain-join decision

Whether the vendor application joins the company OT Active Directory domain is a deliberate design decision with trade-offs. Domain-join brings centralised authentication, certificate services, and GPO-based hardening; a standalone (workgroup) deployment preserves a cleaner trust boundary and simpler Transfer. In either case the vendor holds no standing rights to the platform.

• Domain-joined: a dedicated Organisational Unit with purpose-built, restrictive GPOs; no rights beyond that OU; the OT domain remains segregated from enterprise AD (see separate forests guidance).
• Standalone: locally managed accounts with strong policy, LAPS for local administrators, and its own certificate/time sources.
• Service accounts: dedicated, least-privilege, non-interactive, credential-vaulted and rotated — never shared across applications.
• Vendor personnel: individual, time-bound accounts with MFA; no shared logins; access provisioned and de-provisioned through the company’s process.
• Privileged access: platform administration (hypervisor, AD, storage) stays with the company under a tiered model; the vendor administers only inside its guests.

7. Data interactions, ownership and protection

Enumerate every inbound and outbound data flow — process values, setpoints, historian feeds, alarms, and reporting — and classify ownership: company process data versus vendor application intellectual property. Both must be protected, and their separation must survive the Transfer.

• Encrypt data in transit and at rest; scope the tenant’s access to only the process data it requires.
• Contractually define data ownership, retention, residency, and the return/erasure of company data at Transfer, and protection of vendor IP.
• Log data access at the tenant boundary for audit.

8. Integration and interfaces

• Use secured industrial protocols (OPC UA with security profiles, authenticated/brokered MQTT) and authenticated APIs — no open, anonymous interfaces.
• Integrate to the site historian and other PCS apps only through defined conduits with least-privilege accounts.
• Version and document every interface so the company can support it after Transfer.

9. Connectivity: wired and OT wireless

• Wired: dedicated, documented switch ports and VLANs with port security and 802.1X where feasible; structured cabling segregated and labelled.
• OT wireless serving field assets: secure the bearer — private LTE/5G with SIM/eSIM authentication and network slicing, or Wi-Fi with WPA3-Enterprise and 802.1X certificate authentication — and terminate wireless in the tenant’s own segment, never a flat OT SSID.
• Radio/mesh links (where used across the mine): authenticated and encrypted, with monitoring for rogue devices.
• Remote connectivity for the vendor: brokered through an OT-DMZ jump host with MFA, least privilege, time-boxing, and full session recording.

10. Risk analysis

• Cross-tenant lateral movement to co-resident PCS applications via shared compute, storage, or network.
• Hypervisor or management-plane compromise affecting all tenants.
• Credential sprawl, shared admin, or vendor rights that exceed the intended boundary.
• Uncontrolled vendor changes, snapshots, or clones introducing drift or data leakage.
• Exposure of company process data or vendor IP on shared storage/backups.
• Insecure OT wireless or remote-access paths bypassing segmentation.
• Orphaned access, un-rotated credentials, and missing documentation at Transfer.

11. Security controls and standards

Anchor the arrangement in recognised standards and make them contractual: IEC 62443-2-4 (security requirements for service providers), IEC 62443-3-3 (system security requirements and security levels), and NIST SP 800-82 for the OT programme. Translate these into concrete controls — segmentation, virtualization isolation, RBAC and privileged-access management, encryption, logging and monitoring with shared visibility, and disciplined change control — and verify them before go-live and periodically thereafter.

12. The Transfer phase

Transfer is a security event, not just a commercial one. Plan it from day one so the company inherits a secure, well-documented, fully owned application.

• Rotate every credential and certificate; revoke all vendor accounts and remote access.
• Hand over complete documentation: architecture, configurations, interfaces, GPOs/accounts, and as-builts.
• Re-baseline and re-assess the application against IEC 62443 under company ownership.
• Confirm data return/erasure obligations are met and IP boundaries are clean.
• Move to the company’s own support, patching, backup, and monitoring processes.

Conclusion

Running a vendor-owned PCS application on company-owned, shared virtualized infrastructure is workable and can be secure — but only with deliberate design. Precise responsibility, strong tenant isolation, controlled identity and access, protected and delineated data, secured interfaces and connectivity, and a Transfer planned from the outset together let operators gain the BOOT model’s benefits without importing shared-tenancy risk into the OT domain.

Cyber Data Services assesses, designs, and secures these deployments end to end and prepares operators for a clean Transfer. Contact info@cyberdatas.com to discuss your PCS hosting arrangement.