- Join Our Company
- Email: sanjay@pjnetworks.com
- Phone: +91-9818361787
India’s manufacturing sector is undergoing rapid digital transformation. From automotive plants in Pune to pharmaceutical facilities in Hyderabad and petrochemical complexes on the Gujarat coast, operational technology (OT) networks are being connected to enterprise IT systems at a pace that security teams are struggling to match. That connectivity unlocks efficiency and remote visibility — but it also eliminates the air gap that once kept industrial control systems (ICS) isolated from the internet.
The consequences are becoming visible. In the past 18 months, adversary groups with documented interest in critical infrastructure have targeted industrial organisations across South and Southeast Asia. The attack patterns are consistent: initial access through IT networks (phishing, VPN credential stuffing, unpatched edge devices), lateral movement into OT segments, and ultimately the ability to disrupt or manipulate plant processes. A successful ICS attack at a manufacturing site is not a data-breach story — it is a production-stop, safety-incident, or supply-chain-disruption story.
This guide lays out a practical defence framework for Indian enterprise security and operations teams responsible for multi-site OT environments.
Most enterprise security programmes were designed for IT environments: patch aggressively, rotate credentials frequently, deploy EDR on every endpoint, segment with VLANs. Those instincts are correct in IT but can cause serious problems in OT.
Effective OT security starts by acknowledging these constraints and building controls around them — not trying to impose IT norms on an OT environment.
Three categories of threat are particularly relevant to Indian industrial organisations right now.
Ransomware groups that once focused exclusively on IT file servers have learned that OT disruption creates far more negotiating pressure. The operational pattern is to establish persistence in IT, map the OT network passively over several weeks, and then deploy the ransomware payload in both IT and OT simultaneously. Indian facilities with IT/OT convergence and no network segmentation between the two domains are highly exposed to this pivot.
Several well-documented threat actors conduct long-term, low-and-slow reconnaissance of industrial networks — particularly in energy, defence supply chain, and pharmaceutical sectors. Their objective is not immediate disruption but the placement of persistent access tools that can be activated on demand. India’s expanding defence manufacturing base (under the Make in India initiative) and its pharmaceutical export infrastructure have both attracted documented attention from nation-state actors.
Remote access to OT environments expanded sharply during the pandemic and has not fully contracted since. Equipment vendors, system integrators, and automation contractors routinely need remote access to commission, maintain, or troubleshoot plant systems. Where that access is provided through shared credentials, unmonitored VPN tunnels, or consumer-grade remote-desktop tools, it represents a substantial attack surface. Third-party supply-chain compromise — where the attacker reaches the target by first compromising a trusted vendor — is a well-established pattern in ICS incidents globally.
You cannot protect what you cannot see. The first step is a passive OT asset discovery exercise — using tools or sensors that monitor network traffic without generating active scan traffic that could destabilise PLCs. This produces a baseline inventory of every device on the OT network: its IP address, MAC address, vendor, firmware version (where detectable), and communication behaviour.
For a multi-site operation, this needs to be done at every location and consolidated into a single view. Anomalies often only become visible when you compare behaviour across sites — a PLC at Site A communicating with an IP address that no equivalent device at Sites B, C, or D has ever communicated with is worth investigating.
The Purdue Enterprise Reference Architecture divides OT into five levels — from field devices (Level 0) through control systems (Level 1–2), operations (Level 3), and IT/DMZ (Level 3.5) to enterprise IT (Level 4–5). The principle is that traffic should only flow between adjacent levels and should be inspected at every boundary.
In practice, most Indian manufacturing environments have collapsed Levels 2–4 into a flat network. A pragmatic remediation path is to start at the IT/OT boundary: deploy a next-generation firewall (FortiGate is particularly well-suited here, with ICS-aware protocol decoders for Modbus, DNP3, and OPC) at the junction between the enterprise network and the OT network, with a DMZ zone for data historians and remote-access jump servers. This single change eliminates the direct pivot path from IT to OT even before you address internal OT segmentation.
Replace shared VPN credentials and consumer remote-access tools with Zero Trust Network Access (ZTNA). Under a ZTNA model, every remote session requires strong authentication (ideally MFA), is scoped to the specific asset the user needs to reach (not the entire OT network), is time-limited, and is fully logged. When a vendor’s session ends, the access is revoked — not merely disconnected.
For multi-site environments, centralised ZTNA policy enforcement means you define access rules once and they apply consistently across all locations. A contractor approved to access the SCADA system at Site A does not automatically get access to Site B unless that is explicitly granted.
OT environments generate consistent, predictable traffic patterns under normal operating conditions. Deviations — a new communication peer, an unusual protocol command, a PLC queried at an abnormal frequency — are detectable signals. A continuous monitoring capability that ingests OT network traffic, correlates it against known-good baselines, and alerts on anomalies is the ICS equivalent of EDR.
Critically, alerts from OT monitoring must reach a 24/7 SOC with personnel who understand both the security significance of the alert and the operational context. An alert that says “PLC X received an unusual write command at 02:00” means very different things depending on whether 02:00 is a scheduled maintenance window or an unscheduled deviation.
CERT-In’s 6-hour reporting directive (applicable to critical-sector organisations) demands that you have a functioning incident response process before an incident occurs, not after. An OT-specific IR playbook needs to address questions that a generic IT IR playbook does not: Who has authority to initiate a controlled shutdown of a production line? What is the manual fallback if SCADA access is lost? Which equipment-vendor contacts are available 24/7? How do you preserve forensic evidence from a PLC without interrupting production?
The playbook should be tested through tabletop exercises at least twice a year, with plant operations management and the CISO in the room together — because the hard decisions in an OT incident are as much operational as they are security decisions.
Running 24/7 monitoring across IT, OT, and physical security for a multi-site manufacturing estate creates an operations complexity problem: alerts and events from dozens of tools and platforms arrive in different consoles, with no single view of what is actually happening across the estate. This is precisely the problem that PrahiX Ora is built to solve.
PrahiX Ora is a unified SecOps platform built by PrahiX Tech Pvt Ltd. PJ Networks is its primary field deployment and operations partner — we deploy, configure, and operate the platform for clients as a managed service.
SIEM with MITRE ATT&CK correlation: Ora ingests logs from firewalls, OT sensors, SCADA historians, Windows event logs, cloud workloads, and more — correlating events against MITRE ATT&CK techniques and reconstructing attack storylines through a graph-based engine. For Indian enterprises, the built-in tiered retention (hot/warm/cold/archive) directly supports CERT-In’s direction on 180-day in-country log retention, without requiring a separate archiving platform.
NMS for fragmented multi-vendor networks: Manufacturing estates typically run a patchwork of vendors across their WAN, switching, wireless, and firewall layers — often the result of acquisitions, plant expansions, and different procurement decisions at different sites. Ora’s network management module provides unified observability across this heterogeneity, using LLDP/CDP topology discovery to build an accurate topology map, with ML-based anomaly detection and auto-healing policies that reduce mean time to restore for network events.
Video surveillance (VMS) — physical and cyber under one view: Multi-site manufacturing and retail estates often manage ONVIF, Hikvision, and Dahua camera infrastructure separately from the network security stack. Ora’s video surveillance (VMS) module brings camera management, video analytics, and access events into the same operational view as network and security alerts — so a physical intrusion event at a plant gate is correlated with the network activity logged at the same time, giving the SOC a complete picture rather than two separate data silos.
SOAR for CERT-In’s 6-hour window: Manually assembling the evidence, drafting the CERT-In incident report, and pushing response actions (blocking a malicious IP on FortiGate, isolating a compromised segment, revoking a compromised credential) within six hours of detection is an extremely tight timeline for a team managing a multi-site estate. Ora’s SOAR module automates repeatable response actions through pre-built playbooks with FortiGate connectors — so the actions that can be automated are automated instantly, and human analysts focus on decisions that actually require judgement.
If you are evaluating how to bring IT, OT, and physical security monitoring under a single operations framework, we are happy to walk you through how we have deployed Ora in comparable environments.
Indian manufacturers handling personal data — employee records, customer information, or health data from on-site clinics — are in scope for the Digital Personal Data Protection (DPDP) Act. An OT network breach that exposes personal data is simultaneously an OT security incident and a DPDP data-breach event, triggering both CERT-In reporting obligations and DPDP notification requirements.
Practically, this means your OT security programme needs to:
A well-implemented OT security framework — with network segmentation, continuous monitoring, and documented IR procedures — supports compliance with both CERT-In and DPDP requirements and helps evidence your security posture to regulators. It does not, by itself, make an organisation “DPDP compliant,” since compliance depends on the full scope of data-processing activities. But it eliminates the most critical gaps that auditors focus on after an incident.
For organisations that are early in their OT security journey, the following sequence is recommended:
PJ Networks has deployed OT security programmes across Indian manufacturing, pharmaceutical, and energy-sector clients. Our managed security services combine FortiGate next-generation firewalls at IT/OT boundaries, ZTNA through the Fortinet Security Fabric, and 24/7 NOC/SOC coverage from our India-based operations centre.
We also deploy and operate PrahiX Ora as a managed service for clients who want unified IT, OT, and physical security observability without building a separate team to manage it.
If your organisation is assessing its OT security posture — or responding to a board or regulator asking pointed questions after a sector-wide incident — contact PJ Networks for an initial conversation. We offer a no-obligation OT security assessment that produces a prioritised risk register and a remediation roadmap scoped to your environment and operational constraints.