OT Cybersecurity for Indian PLI Manufacturers: Why IT-First Zero Trust Fails

A Tier-2 auto-ancillary manufacturer in the Pune belt stamping and precision forging, three plants, supplying 4 OEM customers contacted us after receiving an IEC 62443 audit requirement from a German OEM customer. Their IT team had deployed a standard zero trust framework across the corporate network: identity-based access, microsegmentation, TLS for all inter-service communication. Their OT environment sat separately: 82 PLCs, three press lines, and a SCADA system from 2014, all connected to corporate IT via a flat network with no DMZ, no segmentation, and no monitoring. When we asked the IT team what protocols their PLCs used, the answer was “TCP/IP.” When we asked the OT team about IEC 62443, they had not heard of it.

This is the most common starting position for Indian PLI-linked manufacturers entering OT cybersecurity programs in 2026. The good news: the path is well-defined. The bad news: the IT security tools, policies, and assumptions that work in corporate networks actively break OT environments when applied without modification.

Manufacturing Is the Most Attacked Sector and India Is Not an Exception

Manufacturing has been the world’s most cyberattacked industry for four consecutive years. Ransomware incidents targeting manufacturing operations surged 61% in 2025. The attacks have evolved: where IT ransomware encrypts files, OT-targeting ransomware variants (including EKANS and LockerGoga) are designed to terminate industrial control system processes, stopping production rather than just locking data.

Indian manufacturers operating under PLI schemes face compounding pressure. They are connected to OEM supply chains that have explicit cybersecurity requirements in vendor agreements. Some of these requirements reference IEC 62443 directly. Others frame it as a general “industrial cybersecurity standard compliance” requirement. The practical outcome is the same: manufacturers without a defensible OT security posture are losing tenders and failing pre-qualification audits.

The digital transformation push under Industry 4.0 remote monitoring, cloud-connected SCADA, condition monitoring on press lines is expanding the attack surface faster than security programs are keeping up. Every sensor added to a shop floor PLC is a potential lateral movement path if the OT network is not properly segmented from corporate IT.

What IT-First Zero Trust Gets Wrong in Manufacturing

Zero trust architecture, as designed for IT environments, assumes several things: devices can authenticate with modern identity standards, network protocols support encryption, and a misconfigured policy creates an access denial, not a hardware failure.

None of these assumptions hold in OT environments.

Legacy PLCs and SCADA systems use Modbus, PROFINET, and OPC-UA protocols developed for deterministic latency in process control, not for security. Modbus has no authentication. PROFINET does not require encryption by default. OPC-UA has security extensions, but most installations in Indian factories run with security disabled for compatibility with older client software.

An IT security team that has never seen a Modbus packet should not be designing the segmentation policy for a press line running 200 strokes per minute.

The failure mode when IT policies are applied without OT protocol awareness: a microsegmentation rule that blocks Modbus TCP port 502 stops production without triggering a security alert. The PLC loses communication with the SCADA historian. The press line goes into a safe halt. Maintenance staff spend 6 to 8 hours diagnosing what looks like a hardware failure before the network change is identified.

This is not a hypothetical. It is the most common field incident we see in the first 90 days of an OT security program at a manufacturer that let the IT team lead the engagement.

The Purdue Model defined in IEC 62443-1-1 exists precisely to address this. It defines protection zones (field devices, control, supervisory, enterprise, external) with specific communication rules between zones. It was designed by people who understood that a PLC cannot be patched the same way a Windows server can be patched, and that blocking a fieldbus protocol has different consequences than blocking an HTTP port.

The OT Security Segmentation Ladder (OTSSL)

Most Indian manufacturers entering IEC 62443 compliance programs need a four-level progression framework, not a waterfall project plan:

Level 1: Asset Inventory. Every PLC, HMI, SCADA server, historian, engineering workstation, and network device is catalogued with: firmware version, operating system (where applicable), network interfaces, communication protocols in use, and connectivity to corporate IT or external networks. This is the minimum viable starting point. No IEC 62443 assessment can produce meaningful results without it.

Level 2: Network Segmentation An IT/OT DMZ is established. Purdue level mapping is completed every device assigned to a zone. Inter-zone communication rules are documented and enforced: the SCADA historian in Level 3 may read from PLCs in Level 1, but a corporate ERP system in Level 4 does not connect directly to a Level 1 device. This level changes the network architecture substantially for most manufacturers and requires OT team involvement at every step.

Level 3: Vulnerability Management. OT-specific CVE monitoring is active (ICS-CERT advisories, vendor security bulletins). A patch cadence is defined but with an OT-critical caveat: most OT vendors require testing and approval before patches are applied, and some void equipment warranties on unauthorized patching. The patch approval process involves the OT team and the equipment vendor, not just IT. Access control review happens quarterly.

Level 4: Active Defense. OT anomaly detection is deployed using passive monitoring not inline blocking. Tools like Claroty, Dragos, or Nozomi operate by mirroring OT network traffic, not by injecting into the data path. An incident response playbook covers OT-specific scenarios: what to do when a SCADA server is encrypted, when a PLC starts behaving anomalously, when an external connection is detected on a Level 1 device. A tabletop exercise runs annually.

What IEC 62443 Actually Requires from Indian PLI Manufacturers

IEC 62443 is a family of standards across four series, covering policies, systems, components, and the IACS lifecycle. What OEM customers typically require from their suppliers is not full certification across all series; it is compliance with IEC 62443-2-1 (security management system) and IEC 62443-3-3 (system security requirements by security level).

Security Level 1 (SL1) requires protection against casual or coincidental violation. Security Level 2 requires protection against intentional violation using simple means. Most manufacturing OEM supplier requirements specify SL1 or SL2 achievable at OTSSL Levels 2 to 3 for most plant configurations.

The IEC 62443 compliance timeline that fails is the one that starts with the audit rather than the asset inventory.

A realistic timeline for a 3-plant manufacturer starting at OTSSL Level 0 (no inventory, no segmentation):

OTSSL Level 1 completion: 6 to 10 weeks. This is almost entirely a data collection and documentation effort. No network changes are required at this stage.

OTSSL Level 2 completion: Add 10 to 16 weeks. Network architecture redesign, DMZ implementation, and Purdue model enforcement were coordinated with production windows to avoid line stoppages.

OTSSL Level 3 completion: Add 12 to 16 weeks. Patch assessment against vendor approvals, access control implementation, vulnerability management process establishment.

IEC 62443-2-1 readiness for external audit: 2 to 3 months after Level 3. The documentation system, risk assessment, and management review process need to be operational for at least one cycle before the audit.

Total: 10 to 14 months from starting point to audit readiness for a manufacturer with no prior OT security program. Compressing this timeline requires parallel workstreams and is rarely advisable; the segmentation work in Level 2 can disrupt production if rushed.

Why Passive Discovery Is Non-Negotiable

Passive network discovery is not optional in OT environments. An active scan can crash the PLC it is auditing. That is a production outage, not a minor inconvenience.

Standard IT vulnerability scanners Nessus, Qualys, and OpenVAS send probe packets to discover hosts and enumerate services. In IT environments, these probes are harmless. Older PLCs and HMIs respond to unexpected probe packets by entering fault states. Some firmware versions of widely deployed Siemens S7-300 PLCs will halt on an unexpected TCP SYN to certain ports.

The correct approach for OT asset discovery is passive: mirror a port on the OT network switch to a capture device running an OT-aware protocol dissector. The capture device reads traffic without injecting any. Asset discovery, protocol identification, and communication mapping all happen from read-only observation.

This requires network access physical presence on the OT network which must be coordinated with the OT team. It cannot be done remotely, and it should not be delegated to an IT team without OT protocol expertise.

What This Means for Manufacturing Leaders

Three questions to answer this week, before any vendor engagement:

First, do you know which OEM customers have cybersecurity requirements in your vendor agreements? If the answer is no, pull the agreements and check. The IEC 62443 requirement is often buried in a supplier quality manual or technology addendum, not in the main contract.

Second, is your OT network segmented from your corporate IT network or connected via a flat network? If you do not know, ask your IT team to show you the network diagram for the production floor. If there is no diagram, that is the answer.

Third, Does your OT team have an asset list for the shop floor every PLC, HMI, and SCADA component with firmware versions and network connectivity? If this list does not exist, OTSSL Level 1 is your starting point regardless of what the OEM contract requires.

The manufacturers who begin this program in the second half of 2026 have a realistic path to IEC 62443 readiness before OEM pre-qualification cycles in 2027 and 2028. The ones who wait until an audit failure are looking at a 6-month remediation window under commercial pressure. That is a significantly worse position to engineer from.

About the author: The Codelynks Cybersecurity practice has delivered OT security assessments and IEC 62443 readiness programs for manufacturers across automotive, pharma, and industrial components sectors in India.