What Is the Purdue Model? ICS Architecture Explained for Indian Industry

The Purdue Model is the reference architecture that defines how industrial control systems should be organised, and understanding it is the prerequisite for designing OT security in any Indian industrial facility. Developed in the 1990s at Purdue University by Theodore Williams, the model organises ICS components into hierarchical levels that separate operational technology from business IT. Nearly every Indian power plant, refinery, and manufacturing facility - whether it explicitly references the model or not - operates an OT architecture that the Purdue Model describes. NCIIPC's critical infrastructure protection guidelines reference this hierarchical architecture as the basis for network segmentation requirements. (NCIIPC, 2025)

Key Takeaways

• The Purdue Model organises ICS into five levels from physical field devices (Level 0) to enterprise IT (Level 4-5).
• Each level boundary is a security control point; conduits between levels must be controlled and monitored.
• 96% of OT environments now have IT connections that the original model did not anticipate (Dragos, 2025).
• NCIIPC guidelines reference Purdue Model segmentation principles for Indian critical infrastructure operators.
• Cloud connectivity and Industry 4.0 require extending the model with a Level 5 cloud tier and adapted security controls.

OT network segmentation guide for India

What Are the Purdue Model Levels?

The Purdue Model divides industrial control systems into six levels (0 through 5), each with distinct functions and security requirements. Level 0 contains physical process elements: sensors, actuators, motors, and the physical equipment being controlled. Level 1 contains basic control elements: PLCs and RTUs that read sensor data and control actuators based on programmed logic. Level 2 contains supervisory control: SCADA systems, DCS, and HMIs that provide operator visibility and supervisory control over Level 1 devices. Level 3 is operations management: manufacturing execution systems (MES), historians, and operational databases. Levels 4 and 5 are the enterprise IT network and internet connectivity.

Each level boundary should be a controlled conduit. Traffic between Level 2 and Level 3 should be explicitly permitted and monitored; unauthorised flows should be blocked. This conduit-based architecture is the foundation of OT network segmentation as practised at Indian facilities like NTPC power stations, ONGC platforms, and PLI manufacturing sites.

[CHART: Purdue Model diagram - Levels 0-5 with examples from Indian industrial sectors - Source: Opsio]

How Is the Purdue Model Applied in Indian Industrial Settings?

Indian industrial facilities apply the Purdue Model with varying degrees of fidelity. In older installations - legacy ONGC platforms, early-generation power distribution SCADA systems, and pre-2010 manufacturing plants - the model may not have been explicitly referenced during design, but the functional hierarchy typically reflects it. In newer facilities designed under NCIIPC guidelines or to international standards, the Purdue Model is explicitly referenced in network architecture documentation.

The challenge in India is that practical operational pressures have collapsed many level boundaries over time. Engineers access Level 1 and 2 systems directly from Level 4 laptops for convenience. Historian servers straddle Level 3 and Level 4 with dual network interfaces. Business intelligence tools pull data from SCADA systems via unsecured OPC connections. These informal collapses of Purdue Model boundaries are the primary attack paths that OT security assessments identify.

The DMZ Addition for Modern Indian OT Networks

The original Purdue Model did not include a dedicated DMZ between OT and IT networks. Modern applications of the model for Indian industrial organisations add a DMZ between Level 3 and Level 4 to host shared services: the data historian servers, jump servers for remote OT access, patch repositories, and antivirus update servers that both OT and IT systems need access to. The DMZ design ensures that data can flow from OT to IT (for business analytics and monitoring) without creating paths for IT-to-OT communication that attackers could exploit.

What is IT/OT convergence in India?

What Are the Security Implications of Each Purdue Level?

Each Purdue level has distinct security characteristics and vulnerabilities. Level 0 field devices typically have no security mechanisms at all - they are purpose-built embedded systems designed for reliability, not security. Level 1 PLCs and RTUs often run proprietary RTOS or embedded Windows versions that cannot be patched through standard IT patch management. Level 2 SCADA and DCS systems are increasingly running on Windows Server platforms that can be patched but require vendor qualification before patch deployment. Level 3 systems like historians and MES are the most IT-like in the OT stack and can use standard IT security tools, though they must be isolated from direct internet access.

The conduits between levels are the most critical security control points. A firewall between Level 3 and Level 4 that permits only the specific protocols and flows needed for operational data exchange significantly limits an attacker's ability to move from a compromised IT system into OT control systems. Indian organisations should audit these conduits regularly - change management drift frequently results in overly permissive firewall rules that were opened for a specific purpose and never closed.

How Does Cloud Connectivity Change the Purdue Model for Indian Industry?

Cloud connectivity - for remote monitoring, predictive maintenance, digital twins, and operational analytics - effectively adds a Level 5 or 6 to the Purdue Model that extends beyond the factory boundary. Indian Industry 4.0 deployments under the PLI scheme, smart metering by power distribution companies, and remote SCADA monitoring by ONGC all involve sending operational data to cloud platforms outside the traditional Purdue Model boundary. This creates new conduits that require the same security controls as any other cross-level boundary: authentication, encryption, data validation, and monitoring.

NCIIPC guidance for critical infrastructure operators addresses cloud-connected OT specifically, requiring that cloud connections to OT systems be formally approved, documented, and monitored. Unmanaged cloud connectivity - vendor platforms accessing OT devices directly through firewall exceptions made for convenience - is a significant vulnerability discovered regularly in Indian industrial security assessments.

Frequently Asked Questions

Is the Purdue Model still relevant for modern Indian ICS environments?

Yes, with adaptations. The Purdue Model's core principle - hierarchical separation of operational functions with controlled conduits between levels - remains the most practical framework for OT network security. Modern adaptations extend the model to address cloud connectivity, mobile access, and Industry 4.0 architectures. NCIIPC guidelines and IEC 62443 both reference Purdue Model concepts as the basis for zone-and-conduit security architecture in Indian critical infrastructure. ([IEC 62443](https://www.iec.ch), 2025)

How does IEC 62443 relate to the Purdue Model?

IEC 62443 formalises and extends the Purdue Model concept into a comprehensive security standard. Where the Purdue Model defines the architectural hierarchy, IEC 62443 defines security levels, zone and conduit requirements, and specific technical and process controls for each level. IEC 62443 is the implementation standard that makes Purdue Model principles actionable for Indian industrial organisations seeking formal compliance certification. Most Indian OT security programmes use the Purdue Model for architecture and IEC 62443 for implementation guidance. (IEC 62443, 2025)

What is a common Purdue Model implementation mistake in Indian industry?

The most common mistake is treating the model as a paper exercise rather than enforcing it in actual network configurations. Organisations document a Purdue-compliant network architecture but then permit exceptions that create direct paths between levels without proper controls. A firewall rule opened to let an engineer access a Level 2 SCADA server from a Level 4 laptop, never reviewed and never closed, effectively collapses two levels of the model. Regular firewall rule reviews and network configuration audits are essential to maintain real-world compliance with the model. (Dragos, 2025)