OT Cybersecurity for Indian Manufacturing: The Engineer's Field GuideOT Cybersecurity for Indian Manufacturing: The Engineer's Field Guide

In October 2019, Dtrack malware — linked to the Lazarus Group — was found on the administrative network of the Kudankulam Nuclear Power Plant. It had been there for weeks. The only thing standing between a nation-state actor and the plant's control systems was network separation: the one architectural principle most Indian factories either skip or implement incorrectly.

OT security is not IT security applied to factories. The threat model, the consequences, the engineering constraints and the remediation approach are all different. Applying an IT framework unmodified is a reliable way to fail — or to stop production trying.

This is a condensed version of our OT Cybersecurity Field Guide, written for the people who keep plants running: OT, control-system and functional-safety engineers. Read sections 1–3 for the threat, 4–5 for the engineering framework, and 6–8 for what to do about it.

By the Numbers

1. OT vs IT: Why the Playbook Is Different

The most dangerous assumption in OT security is that IT practice transfers unmodified. It has caused more OT failures than any adversary.

The triad flips on the plant floor

In IT, the priority order is confidentiality, then integrity, then availability. A data breach is the failure that ends careers, and downtime during a patch window is acceptable.

In OT the order flips. Availability comes first — a stopped line is measured in tonnes and revenue, sometimes casualties. Integrity is second: control must be correct and operator visibility must be true. Confidentiality of process data is a secondary concern.

Three constraints that change everything

Patching is a shutdown, not a window. A PLC patch needs a planned outage, a staging test, vendor sign-off and a validated rollback. A failed OT patch costs orders of magnitude more than its IT equivalent.

Milliseconds are the constraint. Active scanners have crashed PLCs, and EDR agents have disrupted control-loop timing. These are documented production incidents, not theory.

Legacy is the baseline. 2003-era PLCs on Profibus and HMIs on Windows XP can't run agents or take patches. Compensating network controls are the correct engineering answer, not a workaround.

OT security is constraint-driven engineering: a control that creates a new failure mode in the system it protects is not a control.

The Purdue reference model

The Purdue model (ISA-95 / IEC 62264) layers plant systems from the physical process up to the enterprise:

Level 3.5 is the most critical element of the architecture — and the one most commonly absent. Without it, ransomware in the IT network has a direct path to SCADA and historians. That is precisely the path used in the majority of OT ransomware incidents.

Security priorities also shift by level: availability rules at L0–L1, integrity at L2–L3, and confidentiality only re-enters at L4–L5. One policy cannot govern all seven.

2. The Threat Landscape

Ransomware targeting is based on vulnerability and payment capability, not strategic importance. Assuming you are not a target is the first error.

Who is at the gate

• Nation-state actors (India risk: high). Espionage, sabotage and pre-positioning. DPRK groups target Indian defence and energy; Chinese groups target power infrastructure. Dedicated OT malware includes TRITON, Industroyer and BlackEnergy.
• Ransomware groups (India risk: very high). Purely financial — LockBit, BlackCat, Cl0p. IT ransomware pivots into OT across unsegmented IT/OT bridges, and manufacturing is the primary global target.
• Insiders and vendors (India risk: moderate). Grievance, coercion, or a compromised contractor. Direct system access makes this the highest-capability category, and vendor access is chronically under-managed.
• Hacktivists (India risk: moderate). Political and ideological. Generally IT-focused, but incidents spike during geopolitical tension — and a defaced HMI still stops a shift.

Why India, why now: PLI investment is concentrating high-value targets — electronics, semiconductors, defence, pharma — while OT security spend lags IT. Global supply-chain links also make Indian plants entry points to their multinational customers.

It has already happened here

October 2019 — Kudankulam Nuclear Power Plant. Dtrack malware sat on the admin network for weeks, harvesting keystrokes and traffic. NPCIL denied, then confirmed. The air-gapped control systems were untouched — separation was the defence that held. Lesson: reconnaissance of critical infrastructure is active.

October 2020 — Maharashtra electricity grid. Mumbai lost power, including hospitals, the BSE and railways. Recorded Future found ShadowPad malware and RedEcho tooling across 10 power organisations and 2 seaports in the preceding months. Causation was never publicly established; presence was. Lesson: pre-positioning precedes disruption.

April 2022 — Oil India Limited, Duliajan. Ransomware disrupted IT systems, with a demand of roughly USD 7.5M (₹57 crore). OT systems survived because IT/OT separation limited the blast radius. Lesson: segmentation is the blast wall.

3. Attack Vectors

Six vectors account for the overwhelming majority of documented OT intrusions, and they are rarely used alone.

A typical pathway runs: phishing (entry), then the IT network (lateral movement), then credential theft, then the DMZ gap (the pivot), then SCADA/HMI, then the PLC, and finally the safety system — where the risk becomes physical.

V1 — Flat IT–OT networks. ERP and MES adoption connects once-isolated networks with no DMZ and no inspection. It is the most prevalent path. Test: run a traceroute from IT to OT. No firewall hop means the network is flat.

V2 — Remote access abuse. Post-2020 VPN, RDP and TeamViewer sprawl, often without MFA and with shared credentials. At Oldsmar in 2021, an attacker on SCADA raised sodium hydroxide levels via TeamViewer. Test: is RDP 3389 visible from the internet on any OT IP?

V3 — USB and removable media. Stuxnet crossed Natanz's air gap on a USB stick. In India, firmware and licences routinely travel by USB, and each transfer is an infection event. It remains a persistent top-3 vector (ICS-CERT, Dragos).

V4 — Vendor access debt. Accounts granted at commissioning and never revoked. Plants often hold dozens of dormant vendor logins, some administrative and many shared. A vendor's breach is your breach.

V5 — Internet-exposed OT. Shodan indexes Indian HMIs, Modbus on port 502 and S7 on port 102 — forgotten NAT rules and default-on web servers, visible to anyone. Test: search Shodan for country:IN port:502.

V6 — OT spear phishing. Lures themed as vendor advisories and software updates, aimed at engineers with OT access. HAVEX, Industroyer and TRITON were all delivered this way. The target is the engineering workstation.

The typical intrusion chains three of these: phishing for entry, a flat network for movement, and a dormant vendor account for persistence. The answer is layered controls, not point solutions.

4. IEC 62443: An Engineering Methodology

IEC 62443 is not a compliance checkbox. It is the technical framework behind the EU Cyber Resilience Act, NIS2 and the NCIIPC guidelines alike.

One standard, three obligations

• Asset Owner (the plant) defines requirements, runs the risk assessment (-3-2) and operates the security management system (-2-1) across the lifecycle.
• System Integrator (the builder) designs zones and conduits, delivers the specified Security Levels (-3-3) and meets supplier requirements (-2-4).
• Product Manufacturer (the maker) handles secure development (-4-1) and component security (-4-2). This is the role the EU Cyber Resilience Act primarily regulates.

Zones and conduits

Think of zones and conduits as fire-zone architecture for networks: contain the failure, and control what crosses the boundary.

A zone is a group of assets sharing one target Security Level and trust policy. Communication inside is free; nothing crosses out except through a conduit. A conduit is a defined pathway with an explicit policy — which assets, which protocols, what authentication, what monitoring. No policy means no conduit, just a gap.

The layout runs from the enterprise zone (L4–5) and a remote zone (vendor VPN, engineers), through a default-deny firewall into the Industrial DMZ (L3.5) where every crossing is brokered, then through a protocol-aware firewall into the control zone (L2–3), the cell zones (L0–1), and a separate SIS zone with its own conduit.

The one rule: data flows up, OT to IT, for monitoring. Commands never flow down without explicit, audited authorisation.

How much security is enough

The gap analysis compares three values: SL-T is what the risk assessment requires, SL-A is what the system achieves today, and SL-C is what the installed components can support. The distance from SL-A to SL-T is your work plan.

Security Levels are defined across seven Foundational Requirements:

1. FR1 — Identification and authentication. Every user, device and process identified. SL2 and above: MFA for remote access.
2. FR2 — Use control. Least privilege by role.
3. FR3 — System integrity. No unauthorised modification. SL2 and above: firmware integrity checks.
4. FR4 — Data confidentiality. SL2 and above: encrypted remote-access communications.
5. FR5 — Restricted data flow. Segmentation — zones and conduits are the implementation of this requirement.
6. FR6 — Timely response. Detect, report, respond. SL2 and above: OT-specific monitoring and audit logs.
7. FR7 — Resource availability. The system stays available under attack. SL2 and above: DoS resistance.

5. The Safety–Security Intersection

Independence is not immunity. A safety instrumented system (SIS) separated from the control system can still be reached through the workstation that programs it.

Two disciplines, one attack surface

Functional safety and OT cybersecurity share a plant but not a worldview.

Functional safety assumes failures are random and probabilistic. The concern is random hardware failure and systematic design error. Methods are FMEA, FTA, HAZOP and LOPA. The model is a closed system with defined inputs and outputs, measured in PFDavg, PFH, SIL and PL, under IEC 61508, IEC 61511 and ISO 13849.

OT cybersecurity assumes failures are targeted, coordinated and timed. The concern is intentional adversarial action. Methods are threat modelling and IEC 62443-3-2 risk assessment. The model treats inputs, outputs and logic as open to manipulation, measured as a Security Level, under the IEC 62443 series and NIST SP 800-82.

Where the two meet, safety analysis meets adversaries:

• Sensor spoofing — the SIS trips on readings that no longer reflect the process.
• Logic modification — a SIL 3 rating assumes the logic hasn't been rewritten.
• Timed fail-safe — a shutdown forced at the worst process moment becomes the initiating event.

IEC TR 63069 recommends running both analyses in parallel, then discounting LOPA credit for attackable layers.

Case file: TRITON, the attack on safety itself

In August 2017, TEMP.Veles — a Russian government-linked group — deployed purpose-built malware against Schneider Electric Triconex safety controllers at a Saudi petrochemical plant (Petro Rabigh). The objective was not data. It was to disable the last line of defence before fire, explosion or toxic release.

1. Recon. Months inside the corporate network, mapping quietly.
2. OT pivot. Lateral movement to the SIS engineering workstation.
3. SIS payload. TRITON reprograms Triconex logic to let a dangerous condition persist.
4. The bug. An invalid command trips the controllers to fail-safe. The plant shuts down.
5. Discovery. Forensics on the "malfunction" reveals custom SIS malware.
6. Lessons. Safety systems formally enter the global threat model.

Three lessons stand out. Safety systems are in the threat model: "too specialised, too obscure, too isolated" was invalidated. Independence is not immunity: the SIS was physically separate from the BPCS, per IEC 61511, and the attackers came through the engineering workstation that configures it. And the failure was accidental: no security control stopped TRITON — a bug in the malware did. Without it, the SIS would have looked normal while its protection was gone.

6. Practical Controls

The gap between theory and implementation is a sequencing problem. These six controls are ordered by dependency, not impact: discover, segment, monitor, respond, recover.

1. Asset discovery and inventory. You cannot segment, monitor or patch what you haven't mapped, and every plant has assets nobody remembers commissioning. Use passive monitoring only: a SPAN port and deep packet inspection of OT protocols (Modbus, Profinet, OPC-UA) maps every device without sending it a single packet. No agents, no active scans. The output is an asset register with type, firmware, zone, protocols and last seen.

2. Build the Industrial DMZ. The single highest-impact control. A Level 3.5 DMZ stops ransomware's IT-to-OT pivot at the boundary. Two default-deny firewalls bracket a DMZ hosting the jump server, replicated historian, file transfer and AV updates. Filtering must be protocol-aware — a firewall that passes port 502 blindly can't tell a read from a write.

3. Harden remote access. No always-on tunnels into OT. Access is requested, approved, time-boxed and terminated. Everything terminates at the DMZ jump server, with MFA mandatory and sessions recorded. Vendors get named accounts opened for the maintenance window and closed after it. Direct RDP, SSH or VNC from the internet to OT must not exist. Test: can any vendor reach a PLC right now? Who would know?

4. Risk-based patching. OT can't ride the IT patch cycle — vendor contracts, warranty terms and shutdown windows forbid it. Priority order: actively exploited OT vulnerabilities (CISA KEV, ICS-CERT) first, then public exploits for your firmware, then internet-exposed or DMZ-adjacent systems. Deeply segmented L0–1 devices wait. Where patching is impossible, isolate harder, watch closer and restrict who can reach it. Never test a patch on a production PLC.

5. OT-native monitoring. A standard SIEM can't read a Modbus write to an unexpected register. OT monitoring baselines who talks to whom, then alerts on deviation. Suggested alert priorities:

• P1: PLC download outside a maintenance window; a new device on the OT network.
• P2: Remote access from a new IP; failed OT logins.
• P3: Protocol anomalies; unusual polling frequency.

This depends on the baseline from control 1.

6. OT incident response. IT isolates infected systems. In OT, isolating a PLC can stop a line or create an uncontrolled process condition, so decide the decision tree before the incident. Prepare offline backups of every PLC, DCS and SIS configuration, documented isolation consequences per zone, manual-operation procedures for critical processes, and tested recovery with real recovery time objectives. Run an annual tabletop exercise: historian ransomware, HMI compromise, SIS anomaly.

7. The Regulatory Landscape

OT security is no longer voluntary. CERT-In binds you at home; the CRA, NIS2 and the Machinery Regulation bind you at the EU border. IEC 62443 is the common thread: one correct implementation demonstrates compliance on both sides.

Operating in India

CERT-In Directions (binding, April 2022). Report incidents within 6 hours. Keep ICT logs for 180 days, in India — historian, SCADA event and firewall logs included. Use NTP-synchronised clocks and name a contact who understands OT. Penalties run at ₹1 lakh per day, up to ₹1 crore.

NCIIPC (CII sectors). The nodal agency for critical infrastructure — defence, aerospace, pharma at scale, energy manufacturing. It recommends IEC 62443 as the technical framework, and audits carry regulatory consequences.

BIS IS 17428 (emerging). IoT cybersecurity assurance, applicable to connected OT devices. Voluntary today, but increasingly cited in government procurement.

Exporting to the EU

Cyber Resilience Act (applies December 2027). Every product with digital elements must meet cybersecurity requirements before EU market placement. It maps to IEC 62443-4-1 and -4-2, and is the machine builder's regulation.

NIS2 Directive (in force October 2024). EU customers in essential sectors must secure their supply chains, and Indian suppliers inherit the obligation contractually. It maps to IEC 62443-2-4.

Machinery Regulation (applies January 2027). Machinery must withstand cyberattacks that affect safety, so cybersecurity by design becomes an essential CE requirement. It maps to IEC 62443-3-3 and -4-2.

8. The Road Map

OT security cannot be a single project. A running plant demands a sequenced programme that reduces risk at every stage without stopping production.

Phase 1 — Visibility (months 1–3): know what you have.

• Passive asset discovery
• Network map and zones
• Remote-access audit
• Shodan exposure check
• Vendor account inventory

Phase 2 — Risk reduction (months 3–9): close the highest-risk gaps.

• IT–OT segmentation and DMZ
• Jump server with MFA
• Default credentials removed
• Vendor accounts reviewed and deactivated
• CISA KEV patches and a USB policy

Phase 3 — Defence in depth (months 9–18): detect, respond, recover.

• OT monitoring deployed and tuned
• OT-specific incident response playbooks
• Configuration backup programme
• Manual-operation procedures
• Tabletop exercises and engineer training

Phase 4 — Compliance (month 18 onward): demonstrate and certify.

• IEC 62443-3-2 risk assessment
• Zone and conduit documentation
• SL-T vs SL-A gap closure
• CERT-In documentation
• CRA conformity preparation (for exporters)

A programme that reaches Phase 4 does not stop. It enters a cycle of continuous monitoring, assessment and improvement. The threat landscape will not wait for your next budget cycle.

What you can do this week

These cost almost nothing and close the most common doors first.

1. Run a Shodan search on your public IP ranges to find your exposed OT assets before an attacker does. (Impact: high)
2. Audit every remote-access account on OT systems and kill the dormant and the shared. (Impact: high)
3. Change every default credential on OT systems to remove trivial initial access. (Impact: high)
4. Back up every PLC, DCS and SIS configuration to offline storage, so recovery doesn't depend on a ransom. (Impact: high)
5. Document every connection between IT and OT — the baseline for segmentation. (Impact: medium)
6. Disable unused ports and services on HMI and SCADA workstations. (Impact: medium)
7. Designate and brief your CERT-In contact, and verify you can report within 6 hours. (Compliance)

The one question: "Can an attacker who has compromised any machine on our IT network reach our OT systems?" If the answer is yes — or unknown — that is the first problem to solve.

Glossary

• OT — Operational Technology: the hardware and software that monitors and controls physical processes.
• PLC — Programmable Logic Controller: the workhorse of basic control at Purdue Level 1.
• SCADA — Supervisory Control and Data Acquisition: the operator's window on the process.
• HMI — Human-Machine Interface: the screen an operator uses to view and command the process.
• DCS — Distributed Control System: continuous process control across many controllers.
• SIS — Safety Instrumented System: the independent last line of defence that trips a process to a safe state.
• BPCS — Basic Process Control System: the day-to-day control layer the SIS must stay independent of.
• Purdue model — The reference architecture (ISA-95 / IEC 62264) layering plant systems from L0 to L5.
• DMZ (L3.5) — The brokered buffer between OT and IT: jump servers, replicated historians, file transfer.
• Zone / conduit — IEC 62443's containment model: assets grouped by trust, with defined, policy-bound crossings between them.
• SL-T / SL-A / SL-C — Security Level: target required, achieved today, and capability of installed components.
• FR1–FR7 — The seven Foundational Requirements that define each Security Level in IEC 62443.
• SIL / PL — Safety Integrity Level / Performance Level: functional-safety risk-reduction ratings.
• LOPA / HAZOP — Layer of Protection Analysis / Hazard and Operability study: core safety analysis methods.
• Historian — The time-series database recording process data, replicated into the DMZ for IT analytics.
• Passive monitoring — Asset discovery by listening to network traffic, never by probing OT devices.
• RAT — Remote Access Trojan: malware granting an attacker persistent covert control.
• CISA KEV — Known Exploited Vulnerabilities catalogue: the priority list for OT patching.
• CERT-In / NCIIPC — India's incident-response agency and its critical-infrastructure protection centre.
• CRA / NIS2 — The EU Cyber Resilience Act (products) and NIS2 Directive (operators and supply chains).
• TRITON / TRISIS — The 2017 malware built to disable Triconex safety controllers, the first attack on safety itself.

Sources: IBM X-Force Threat Intelligence Index, Dragos OT Year in Review, Recorded Future, CERT-In, and public reporting. This guide is provided for informational purposes and is not legal, regulatory or professional engineering advice.

Start with a conversation, not a contract. A one-hour review of your IT/OT boundary answers the one question that matters most — get in touch to book one.