Introduction
As industrial systems evolve toward remote operations and cloud integration, traditional OT architectures are being reimagined for a connected world. The challenge is maintaining the same security discipline that protected critical processes for decades — but now within virtualized, cloud-native environments.
To achieve this, most organizations still rely on a foundational reference: the Purdue Model.
To visualize the structure and dependencies of industrial control environments, security professionals often refer to the Purdue Enterprise Reference Architecture (PERA) — commonly known as the Purdue Model.
It organizes industrial systems into hierarchical levels, as you can see in the following diagram:
This model helps define security boundaries — what data can (and cannot) traverse between levels. It underpins segmentation strategies, firewall rules, and monitoring zones in modern architectures — including those deployed in the cloud.
Why Segmentation Still Reigns Supreme
One of the core security principles in OT — unchanged even as we move to the cloud — is strict network segmentation.
According to the Purdue Model, each layer must be isolated from the others, with only explicitly authorized traffic allowed between them. This design is not just good practice; it’s a fundamental requirement in most OT security standards (such as IEC 62443, NIST 800-82, and ISA-99).
In traditional environments, this segmentation was implemented through firewalls between levels. That approach still applies today — even in cloud architectures. In other words, no direct connectivity should exist between two Purdue levels without passing through a security control point.
This allows:
- Deep inspection of industrial protocols (e.g., Modbus, DNP3, OPC-UA)
- Logging and anomaly detection per zone boundary
- Granular access control between IT and OT layers
- Containment of threats within a specific zone
Extending the Purdue Model into Azure
When organizations migrate parts of their OT or SCADA infrastructure to the cloud, the Purdue segmentation model can be logically replicated using Azure networking constructs plus all the available FortiGate tools.
Architecture Overview
The topology used as an example consists of two operational remote sites, each corresponding to Level 0 and 1 of the Purdue Model.
These sites are connected through SD-WAN to Azure Virtual WAN (vWAN), which acts as the central hub for inter-site and cloud communication.
At the heart of the architecture lies a pair of FortiGates deployed in an active-active configuration within the vWAN hub. This cluster act as the enforcement points, inspecting and controlling all east-west and north-south traffic.
Attached to the vHub, several spoke VNets represent the higher Purdue layers:
- Level 2 (Supervisory Control): VMs hosting SCADA servers, HMI components, and data collectors
- Level 3 (Manufacturing Operations): Historian servers, engineering workstations, and process databases.
- Level 3.5 (DMZ): Patch management servers, mirrored historians, and jump hosts
- Level 4 (Enterprise IT): Hosted in an on-premises data center, connected through the SD-WAN
This logical mapping maintains the integrity of the Purdue model, even as workloads extend into Azure.
Traffic Flow and Enforcement
In this design, all inter-level communication — whether between two VNets or between on-prem and cloud — must traverse the FortiGates.
This ensures that:
- Layer 2 to Layer 3 traffic (e.g., SCADA polling a historian) is inspected and logged
- DMZ access (Level 3.5) is tightly controlled, serving as a buffer zone between OT and IT
- Enterprise data exchanges (Level 4) pass through policy-controlled paths, minimizing exposure
Also as any Layer access to Internet, all traffic will be inspected. The Following diagram shows a high-level diagram that represents the flows described:
Security and Cloud Governance Advantages
Deploying OT workloads in Azure under this segmented architecture provides several benefits:
- Consistent policy enforcement: Centralized through the FortiGates, Azure’s managed NVAs.
- Scalability: VNets can scale, supporting growth without compromising security zones.
- Resilience: Multi-region deployment and SD-WAN redundancy ensure continuity even under network disruption.
- Compliance alignment: The model naturally aligns with Purdue Zoning, helping meet regulatory requirements for industrial cybersecurity frameworks.
Common Challenges
- Network Segmentation and Routing Complexity
- Ensuring each Purdue level routes only through the FortiGates (no backdoors or peerings bypassing inspection, unless wanted).
- Managing asymmetric routing when using active-active Fortigates or multiple regions, locally to the vHUB through FGSP.
- Protocol and Application Compatibility
- Legacy OT protocols (Modbus, DNP3, PROFINET) are not cloud-native and may require encapsulation, tunneling, or protocol translation.
- SCADA software often expects flat networks or Layer 2 adjacency, which conflicts with cloud segmentation principles.
- Identity and Access Management
- Operators or engineers often use shared local credentials, which clash with Azure AD’s identity model and CIEM best practices
- Implementing jump hosts, bastions, or Just-in-Time access that balance security with usability is a recurring hurdle.
- Latency and Determinism
- Cloud backhauling can introduce latency that impacts control loops or real-time visualization.
- Deciding which functions stay on-prem (real-time control) and which migrate (historian, analytics, reporting) becomes critical.
- Security and Compliance Pressure
- Aligning with frameworks like IEC 62443 or local critical-infrastructure regulations.
- Demonstrating “defense in depth” when auditors expect physical firewalls but you’re using virtual ones.
- Operational Culture and Ownership
- OT and IT teams often have different priorities: uptime vs. change management.
- Cloud projects force both to collaborate — which can cause friction over responsibility boundaries
The Expanding Threat Surface in Cloud-Connected OT
Once OT workloads move into Azure — even partially — the attack surface grows in ways that traditional industrial defenses weren’t designed to address.
In addition to the operational layers defined by the Purdue Model, organizations must now manage:
- Cloud storage, databases, and VMs
- Containers or IoT edge gateways
- Service identities and managed keys
- APIs connecting to analytics or AI services
These are not just “infrastructure” — they’re software-defined assets with configurations, permissions, and dependencies that can introduce silent risks.
From Perimeter Security to Cloud-Native Visibility
While FortiGates and segmentation enforce strong network boundaries, they don’t cover cloud-specific misconfigurations — such as:
- Publicly exposed storage accounts
- Over-privileged managed identities
- Outdated container images or vulnerable libraries
That’s where CNAPP (Cloud-Native Application Protection Platform) becomes critical. CNAPP unifies several disciplines — CSPM, CWPP, CIEM, and vulnerability management — to give complete visibility into both cloud workloads and their configurations.
In the context of OT, CNAPP extends protection from the network layer into the workload and configuration layer, where many modern attacks begin.
How CNAPP Complements the OT Security Model
|
Traditional OT Control |
CNAPP Capability |
Value for OT Environments |
|
Network firewalls between Purdue levels |
Cloud Security Posture Management (CSPM) |
Detects misconfigured VNets, NSGs, or exposed endpoints that bypass intended segmentation. |
|
Patch management and antivirus |
Cloud Workload Protection Platform (CWPP) |
Scans Azure VMs and containers for known CVEs, missing patches, and runtime anomalies. |
|
Access control lists on jump servers |
Cloud Infrastructure Entitlement Management (CIEM) |
Identifies excessive permissions and enforces least-privilege across service principals and managed identities. |
|
Periodic security audits |
Continuous Compliance Monitoring |
Maps Azure resources against standards like NIST and CIS Benchmarks automatically. |
In essence, CNAPP acts as the next-generation “control layer” above Level 3.5, providing continuous posture awareness of everything hosted in or connected to Azure.
Practical Applications in an OT-to-Azure Architecture
In the two-site scenario taken as example, CNAPP can deliver visibility and protection in several critical areas:
- Vulnerability Management for OT-Linked Workloads
- Automatically scan Level 2 and Level 3 Azure VMs running SCADA or historian software for outdated libraries or insecure dependencies.
- Integrate findings with a SOC or SIEM for prioritized remediation.
- Configuration Drift Detection
- Detect when a VNet peering, NSG, or route table allows unintended east-west access between levels — a common cloud drift problem.
- Identity Risk Reduction
- Continuously evaluate service identities used by automation scripts or data collectors, ensuring they have least privilege and are rotated regularly.
- Runtime Threat Detection
- FortiCNAPP agents or integrations can observe anomalous process behavior in cloud-based historian or engineering servers — adding a behavioral layer of defense that traditional OT firewalls can’t provide.
The Bigger Picture: Converging OT Security and Cloud Governance
By incorporating CNAPP into your Azure-based OT architecture, you achieve a multi-layered defense strategy:
- FortiGate and segmentation protect how systems communicate.
- CNAPP protect what those systems are and how they’re configured.
- Together, they enforce defense in depth across both network and cloud control planes.
This convergence marks the evolution from reactive, perimeter-based OT security to a continuous, intelligence-driven security posture — essential for any organization embracing Industry 4.0 and 5.0 initiatives.
Conclusion: Securing the Convergence of OT and Cloud
The evolution of Operational Technology from isolated, air-gapped systems to cloud-connected architectures marks one of the most significant shifts in industrial cybersecurity. What began as a need for better visibility, analytics, and remote management has transformed into a complete rethinking of how we protect critical operations.
As we’ve seen, frameworks like the Purdue Model remain as relevant as ever — but now they must be translated into cloud language. In Azure, this means implementing virtualized firewalls between layers, enforcing routing through NVAs, and maintaining strict segmentation across VNets and on-premises sites. The principle hasn’t changed: every flow between levels must be inspected and controlled. What’s new is how we achieve that — through software-defined networks, centralized policies, and scalable, cloud-native controls.
Yet, segmentation alone is no longer enough. Modern threats exploit misconfigurations, exposed identities, and unpatched workloads — vectors invisible to traditional OT defenses. This is where CNAPP enters the picture, bringing continuous visibility, vulnerability management, and compliance monitoring into the same environment where SCADA servers and historians now live.
By pairing network-level protection (NVAs, SD-WAN, DMZs) with cloud-level intelligence (CSPM, CWPP, CIEM), organizations can achieve true defense in depth — one that spans both the operational and digital layers of their enterprise.
Ultimately, migrating OT workloads to the cloud isn’t just a technical journey; it’s a cultural and strategic one. It requires collaboration between IT, OT, and security teams, a shared understanding of risk, and the courage to modernize without compromising safety or reliability.
The future of industrial systems — in Azure or any cloud — belongs to those who can balance innovation with protection, ensuring that the next generation of connected factories, power grids, and smart infrastructures remain not only efficient and intelligent but also resilient and secure.
Connect with our Cloud Consulting Services team for expert guidance on advanced configurations and production deployments:
Email: consulting@fortinet.com
Learn more: Cloud Security Consulting Services
