Under a Build-Own-Operate-Transfer (BOOT) arrangement, a vendor deploys and runs its own Process Control System (PCS) application on the customer’s virtualized server and storage — inside an OT mine domain shared with other PCS applications. This article covers how that works and what to control: tenant isolation, the domain-join decision, credentials, data interactions, interfaces, wired and OT-wireless connectivity, and the eventual transfer.
1. The deployment model
In a Build-Own-Operate-Transfer (BOOT) model, the vendor builds, owns, and operates its PCS application, but it runs on infrastructure the company owns — virtualized compute (hypervisor cluster) and shared storage that already host other PCS applications inside the OT mine domain. The vendor is effectively a tenant on the customer’s platform until, at the Transfer milestone, ownership passes to the company.
That shared-tenancy arrangement blends two responsibilities that are normally separate: the vendor’s application and the company’s platform. Getting the boundary right — technically and contractually — is what keeps the wider control environment safe.
2. Agree who owns what
Before anything is deployed, document a shared-responsibility (RACI) matrix. Ambiguity here is the root of most incidents.
- Company: hypervisor and storage, network and segmentation, backup, Active Directory, physical security.
- Vendor: the PCS application, its guest OS hardening and patching, and its data — within the boundary given.
- Joint and explicit: change control, patch windows, monitoring, incident response, and the Transfer plan.
3. Isolate the tenant
The vendor application must not be able to reach — or be reached by — the other PCS applications except through defined, least-privilege paths. Isolation is enforced at the virtualization and network layers.
- Place the vendor VMs in their own network zone/VLAN with micro-segmentation; default-deny to other PCS apps.
- Use dedicated resource pools (and ideally dedicated hosts/datastores) so a noisy or compromised tenant cannot starve or reach others.
- Encrypt the vendor data at rest on the shared storage and keep its backups logically separated.
- Confirm hardware/software compatibility against the hypervisor and storage HCL: guest OS version and support lifecycle, VM tools, storage protocol (iSCSI/NFS/FC), and licensing.
4. Identity, credentials and the domain-join decision
A key question is whether the vendor application joins the company OT Active Directory domain. Joining brings central authentication and GPO hardening; staying standalone keeps a cleaner trust boundary. Either way, the vendor never receives standing privileged rights to the platform.
- If domain-joined: place the vendor systems in a dedicated OU with restricted, purpose-built GPOs, and grant no rights outside that OU.
- Use dedicated, least-privilege service accounts (not shared or interactive admin) for application services; vault and rotate credentials.
- Give vendor engineers individual, time-bound accounts with MFA — no shared logins; apply LAPS to local admin passwords.
- Keep platform (hypervisor/AD/storage) administration entirely with the company; the vendor administers only inside its VMs.
5. Data interactions and interfaces
Map every data flow to and from the vendor application before go-live: process data in/out, historian feeds, and any north-bound reporting. Define data ownership (company process data vs vendor application IP), and broker cross-application exchange rather than allowing direct connections.
- Expose interfaces over controlled protocols (e.g. OPC UA with security, brokered MQTT) — not open, unauthenticated links.
- Route any Level 3 / enterprise reporting through the industrial DMZ; no direct path from the enterprise into the tenant.
- Contractually fix data ownership, retention, and the return/erasure of company data at Transfer.
6. Connectivity — wired and OT wireless
- Wired: dedicated switch ports/VLANs with port security; structured cabling documented and segregated from other PCS traffic.
- OT wireless (for field devices the app serves): secure the bearer — private LTE/5G with SIM-based auth, or Wi-Fi with WPA3-Enterprise / 802.1X certificate authentication — and terminate it in the tenant’s own segment.
- Vendor remote access (operate phase): only via a hardened jump host in the OT DMZ, with MFA, least privilege, and session recording — never a direct tunnel to the VMs.
7. Key risks
- Lateral movement from the vendor tenant to co-resident PCS applications on shared compute/storage.
- Credential sprawl or shared admin accounts blurring the ownership boundary.
- Uncontrolled vendor changes (patches, snapshots) affecting the shared platform.
- Leakage of company process data or vendor IP on shared storage.
- Gaps and orphaned access at the Transfer milestone.
8. Controls, standards and the transfer
Anchor the arrangement in IEC 62443 — particularly the requirements for service providers (62443-2-4) and system security (3-3) — and NIST SP 800-82. Plan the Transfer from day one: at handover, rotate all credentials, revoke vendor access, and hand over documentation, configurations, and as-builts so the company can own and secure the application going forward.
Cyber Data Services designs and secures these shared-tenancy PCS deployments — segmentation, virtualization isolation, identity, and the Transfer plan. Contact info@cyberdatas.com to discuss your environment.