DMZ and zone-based architectures for PI System deployments

Meta description: Practical guidance for PI System DMZ architecture and network zoning, including firewalls, trust boundaries, and trade-offs for secure OT/IT data flows.

Purpose and approach

“Put PI in the DMZ” is ambiguous. It can mean a jump host, a separate PI Data Archive, a proxy, or simply “somewhere IT can reach”. For PI System design, a zone-based approach is more useful: define trust boundaries first, then place PI components and specify the permitted flows across those boundaries. Start with “who must talk to what, and why?” — that yields simpler, more supportable architectures.

Align zoning decisions early with scalability and resilience choices because they affect buffering, naming, and high availability. See Designing a Scalable and Resilient PI System Architecture for broader context.

Typical zones

Most organisations use variations of these zones:

• OT / control zone (Level 0–2): PLCs, DCS, analysers, local historians and deterministic systems. Availability is paramount; patch windows are limited.
• OT operations / site services (often Level 3): PI Interfaces/Connectors, local PI Data Archives, buffering and site-facing operator services.
• Industrial DMZ (IDMZ): the policy “airlock” between OT and IT — a strict boundary with limited services, firewall rules and explicit routes.
• IT / enterprise zone: corporate users, analytics, identity services (AD, ADFS, PKI), monitoring and vulnerability management.

Treat each boundary crossing as a deliberate integration, not an ad‑hoc exception.

What “PI in the DMZ” typically intends

Three goals are often conflated:

1. Let enterprise users view OT data without giving them a route into OT.
2. Allow enterprise systems to pull data (BI, data lake, analytics) in a controlled way.
3. Let OT push data out so OT initiates connections.

Design descriptions should be expressed as required data paths for these goals, not just server locations. If you cannot diagram flows and justify each crossing, you are not ready to author firewall rules. For identity and authentication guidance, see Securing the AVEVA PI System in Modern Enterprise Environments.

Common architecture patterns

Pattern A — OT Data Archive; IT via a controlled presentation layer

• System of record remains in OT. IT accesses data through a secure service (middleware, brokered API) instead of connecting directly to the Archive.
• Pros: fewer inbound rules to OT; easier to enforce read‑only enterprise access; OT retains local visibility.
• Cons: requires a reliable presentation tier.

Pattern B — DMZ PI Data Archive (replica) for enterprise access

• A historian replica in the IDMZ serves enterprise consumers; OT populates it.
• Pros: insulates OT from enterprise queries.
• Cons: another service to patch, back up and govern; requires explicit SLAs for latency, backfill and tag/AF governance.

Pattern C — Site PI in OT, central PI in IT, with aggregation

• Site collection and buffering remain local; a curated set of streams is sent to a central PI System.
• Pros: aligns responsibilities (OT handles ingestion; IT handles enterprise analytics) and tolerates unreliable links.
• Cons: can become complex if sites diverge; needs governance and repeatable conventions.

Choose patterns based on organisational roles, tolerance for latency, and governance capabilities.

Designing network flows and firewalls

A workable zone model specifies:

• Directionality: Prefer OT-initiated outbound connections to the IDMZ/IT (push). Outbound rules are easier to scope and revoke.
• Principle of least privilege: Use explicit source/destination hosts and documented purpose for each rule. “Open the PI ports” is a warning sign.
• Identity and authentication: Cross‑zone Windows authentication requires clear domain/trust, SPN and Kerberos considerations, correct time synchronisation and scoped service accounts.
• DNS and time: Decide on split DNS, conditional forwarders or isolated name services and document dependencies. Time drift causes authentication and TLS failures faster than obvious time errors.

Document each flow with source, destination, protocol/port, direction and purpose.

Operational realities: buffering, latency and failure modes

Zoning affects ingestion behaviour. If OT-to-DMZ links are intermittent, define a buffering and catch‑up strategy — don’t rely on ad‑hoc queue increases without modelling backlog and recovery rates.

Define expected latency (seconds, minutes) for enterprise dashboards and state behaviour during planned and unplanned outages. Many OT/IT disputes stem from mismatched expectations about latency and completeness.

For performance and scalability implications of added hops, replication or more consumers, see Keeping PI Fast, Stable, and Predictable at Scale.

Trade-offs

Every design is a compromise:

• A strict IDMZ improves containment and auditability but can slow troubleshooting and restrict ad‑hoc diagnostics.
• A permissive rulebase reduces friction short term but makes “temporary” access permanent and increases compromise risk.
• Duplicating services for a DMZ-facing tier improves isolation and user experience but increases patching, monitoring, certificates and backups.
• Keeping everything in OT reduces components but often requires more inbound access from IT, which security teams may reject.

Make these trade-offs explicit for security reviews and operations.

Anti‑patterns to avoid

• DMZ as a dumping ground: servers with no ownership, patching or clear data contracts.
• “One firewall rule to rule them all”: broad port ranges opened between zones to speed delivery.
• Shared credentials across zones: undermines segmentation and increases risk.
• Silent dependencies: OT reliance on IT-hosted DNS, PKI or monitoring that may be unavailable during IT outages.

These shortcuts become entrenched failure modes.

Documenting the design

Documentation must be operational, not just a Visio diagram. Include:

• Flows: source, destination, protocol/port, direction, purpose
• Identity model: accounts, groups, trusts
• Support model: ownership, patching cadence, certificate responsibilities
• Explicit prohibitions: e.g. “No inbound from IT to OT PI Data Archive”

Operational documentation is required to defend zoning during audits and to preserve the design through staff turnover.

Getting specialist help

If you are rationalising an estate or negotiating firewall and identity constraints, a short engagement with experienced practitioners can save months. Browse PI System integrators and consultants at https://piadmin.com/directory and filter by the support you need.

Further reading on PIAdmin.com

• Designing a Scalable and Resilient PI System Architecture
• Securing the AVEVA PI System in Modern Enterprise Environments
• Keeping PI Fast, Stable, and Predictable at Scale