OT Vulnerability Management in India: Risk-Based Prioritisation for Industrial Environments
Country Manager, Sweden
AI, DevOps, Security, and Cloud Solutioning. 12+ years leading enterprise cloud transformation across Scandinavia
OT vulnerability management in India requires a fundamentally different approach from IT vulnerability management - and most Indian industrial organisations are applying IT methods to OT environments with predictably poor results. The average Indian OT environment carries 6.6 unmitigated vulnerabilities per device, according to Claroty's 2024 State of CPS Security report. With millions of OT devices across India's industrial base, this translates to an enormous vulnerability backlog that cannot be addressed through traditional patching approaches. Risk-based prioritisation - focusing on vulnerabilities that are exploitable in the specific environment and would have significant impact - is the only practical path forward. (Claroty, 2024)
The gap between IT and OT vulnerability management is stark. IT vulnerability management operates on 30-90 day patch cycles, uses automated scanning to discover vulnerabilities, and can typically deploy critical patches within weeks. OT vulnerability management must account for device lifecycles of 15-25 years, patching that requires vendor qualification and maintenance window scheduling, and scanning approaches that cannot use active tools without risking operational disruption. The result is OT environments where known critical vulnerabilities remain unpatched for 12-18 months or more - not because organisations are negligent, but because the operational constraints genuinely prevent faster remediation.
OT security assessment for Indian enterprisesKey Takeaways
- Average Indian OT environments carry 6.6 unmitigated vulnerabilities per device (Claroty, 2024).
- Risk-based prioritisation - exploitability in your specific environment, not CVSS score alone - is the only practical OT vulnerability management approach.
- Compensating controls must bridge the gap between vulnerability discovery and patch deployment in constrained OT environments.
- CERT-In advisories on ICS vulnerabilities provide India-specific guidance that complements global CVE databases.
- OT vulnerability management requires OT-specific scanning tools and methods that do not disrupt industrial protocol communications.
Why Does Traditional Vulnerability Management Fail in OT Environments?
Traditional IT vulnerability management assumes three capabilities that do not exist in most Indian OT environments. First, active scanning: Nessus, Qualys, and similar IT vulnerability scanners send probing packets to discover vulnerabilities. In OT environments, these packets can disrupt legacy industrial protocols and cause device resets or communication failures that trigger safety alarms. Active scanning has caused unplanned shutdowns at Indian industrial facilities where IT assessment teams applied standard tools without understanding OT network constraints. Second, rapid patching: IT vulnerability management assumes that critical patches can be deployed within days or weeks. OT patching requires vendor qualification (adding weeks to months), maintenance window scheduling (adding months to the cycle), and operational risk acceptance that IT patching does not require. Third, endpoint agents: IT vulnerability management commonly uses agents on managed endpoints to collect vulnerability data. OT devices often cannot support software agents - they run proprietary embedded operating systems, have limited compute resources, and cannot accommodate third-party software that might affect their deterministic control function. (ICS-CERT, 2024)
OT-Specific Vulnerability Discovery Methods
OT vulnerability discovery uses passive methods that are safe for industrial environments. Passive network monitoring tools (Dragos, Claroty, Nozomi) analyse industrial protocol traffic and identify device types, firmware versions, and operating systems from the communication patterns and protocol headers they observe. This passive inventory is then matched against CVE databases and vendor security advisories to identify known vulnerabilities. The approach requires no active probing and poses no risk to operational continuity. Physical device inspection supplements passive monitoring: engineers directly accessing PLC consoles, SCADA HMI systems, and historian servers can read firmware version information and configuration details that passive monitoring cannot always determine from network traffic alone.
[CHART: OT vulnerability management process: passive discovery, CVE matching, risk scoring, prioritisation - Source: Opsio]How Should Indian Organisations Prioritise OT Vulnerabilities?
CVSS scores alone are insufficient for OT vulnerability prioritisation. A CVSS 9.8 critical vulnerability in a device that is network-isolated with no communication path to a threat actor is lower priority than a CVSS 7.0 medium vulnerability in an internet-exposed engineering workstation. OT vulnerability prioritisation must consider: network exposure (can a threat actor reach the vulnerable device?), authentication requirements (does the vulnerability require authenticated access that is controlled?), impact of exploitation (what physical process is affected if this device is compromised?), exploitability in the wild (are threat actors actively exploiting this vulnerability?), and availability of compensating controls (can the risk be reduced while waiting for a patch?).
Dragos's ARMOR vulnerability prioritisation methodology adapts this multi-factor approach specifically for OT environments. Claroty's risk scoring incorporates network exposure and criticality of the affected OT system. For Indian organisations using NIST 800-82 as their framework, the document provides OT-specific vulnerability prioritisation guidance that goes beyond CVSS. The key insight is that the same CVE has different risk implications in different OT environments - context-specific prioritisation is not optional, it is the only way to make OT vulnerability management practical.
CERT-In ICS Vulnerability Advisories for India
CERT-In publishes advisories specifically about ICS and OT vulnerabilities that are relevant to Indian infrastructure. These advisories incorporate threat intelligence about active exploitation - a vulnerability that CERT-In is advising about is one that threat actors are actively targeting, which moves it to the top of the Indian OT priority list regardless of its generic CVSS score. Indian OT security teams should subscribe to CERT-In advisories and implement a process to assess each advisory against their specific asset inventory within 24-48 hours of receipt. For vulnerabilities covered by CERT-In advisories where immediate patching is not possible, CERT-In typically also provides compensating control guidance. (CERT-In, 2025)
OT security best practices for IndiaNeed expert help with ot vulnerability management in india?
Our cloud architects can help you with ot vulnerability management in india — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
What Compensating Controls Apply When Patching Is Not Immediately Possible?
Compensating controls are the practical reality of OT vulnerability management for Indian industrial organisations. When a vulnerability cannot be patched within the risk-acceptable timeframe, compensating controls must reduce the effective risk until patching is possible. The right compensating controls depend on the vulnerability's attack vector and the specific environment. Network isolation limits exposure: if the vulnerable device is network-isolated so that no threat actor can reach it from the corporate network or internet, the vulnerability's exploitability in your environment is significantly reduced even though the device remains unpatched. Application whitelisting prevents exploitation of vulnerabilities that require malicious code execution on OT workstations. Firewall rules can block specific protocol versions or function codes that a vulnerability exploits, even if the underlying vulnerability in the device firmware cannot be addressed. Increased monitoring around the vulnerable device provides detection capability that can alert to exploitation attempts. (NIST, 2023)
[PERSONAL EXPERIENCE] A consistent challenge in Indian OT vulnerability management programmes is the documentation of compensating controls. Security teams implement compensating controls in response to identified vulnerabilities but do not document which controls are compensating for which vulnerabilities, or what conditions would trigger the need to escalate (for example, if the compensating control is removed by a network change). A vulnerability management system that tracks each open vulnerability alongside its associated compensating controls and the conditions for risk escalation is essential for managing large OT vulnerability backlogs responsibly.
How Does OT Patch Management Work in Indian Industrial Settings?
OT patch management for Indian industrial organisations requires a formal programme with four components. Patch awareness: tracking vendor security bulletins and CERT-In advisories to know when patches are available. Patch assessment: evaluating each patch for applicability to your specific environment, potential operational impact, and installation requirements. Patch testing: testing patches in a replica or testing environment before production deployment, particularly for SCADA and DCS patches where vendor qualification takes time. Patch deployment: scheduling deployment during appropriate maintenance windows, with rollback procedures prepared and operational backup in place. The entire process from patch release to production deployment typically runs 3-12 months for Indian OT environments, significantly longer than IT patching cycles but much shorter than the indefinite deferral that is the current practice in many organisations.
The patch testing requirement is often a bottleneck. Many Indian industrial organisations do not have replica OT environments where patches can be safely tested before production deployment. Investment in test environments - even simplified versions with the same PLC and SCADA software versions as production, without the full physical process - significantly accelerates the patch cycle and reduces the production risk of OT software updates. This investment is particularly justified for large, complex OT environments where a patch-induced malfunction in production could cause significant operational and financial impact.
What Tools Support OT Vulnerability Management in India?
OT vulnerability management tools available to Indian industrial organisations fall into two categories. Passive OT monitoring platforms with built-in vulnerability management: Dragos Platform, Claroty Continuous Threat Detection, and Nozomi Networks Guardian all include vulnerability identification capabilities that cross-reference their passive asset inventories against CVE databases and vendor security advisories, generating prioritised vulnerability reports without active scanning. Vulnerability intelligence platforms: Dragos Vulnerability Intelligence, Claroty Research, and Tenable.OT provide OT-specific vulnerability data with contextual analysis of exploitability and impact in OT environments. These platforms are complementary - the passive monitoring platform discovers what devices are present and what versions they run; the vulnerability intelligence platform provides the security content needed to assess and prioritise the identified vulnerabilities. (Dragos, 2025)
Frequently Asked Questions
Can we use Nessus or Qualys for OT vulnerability scanning in Indian plants?
Nessus and Qualys can be used for OT vulnerability scanning in limited configurations, but must not be used in unauthenticated aggressive scan mode on OT networks. Both tools offer safer scanning profiles designed for fragile systems. Tenable.OT (formerly Tenable.sc with ICS module) provides active scanning profiles designed specifically for industrial environments that are safer than generic IT scanning. However, even these safer profiles carry some risk in legacy OT environments. Passive monitoring remains the safest approach for production OT networks; active scanning should be reserved for pre-production validation or isolated testing environments. (Tenable, 2025)
How do we track OT vulnerabilities across thousands of devices?
Tracking OT vulnerabilities at scale requires a dedicated OT asset management system or an OT monitoring platform with built-in vulnerability tracking. Passive monitoring platforms like Claroty and Dragos maintain asset inventories and continuously update vulnerability status as new CVEs are published and as devices are patched. For organisations without dedicated OT monitoring platforms, a structured spreadsheet-based tracking system - device inventory with current firmware versions, matched against periodic CVE database review - is a starting point that can be migrated to platform-based tracking as the programme matures. CERT-In advisories should be tracked in a separate register and reviewed against the asset inventory within 48 hours of publication. (CERT-In, 2025)
What is the CVSS score threshold for emergency OT patching?
CVSS score alone should not determine OT patching urgency. A context-adjusted risk score that factors in network exposure, exploitability in the wild (particularly if CERT-In has issued an advisory), and impact to the specific controlled process is more appropriate. As a practical guide, CVSS 9.0+ vulnerabilities in internet-facing or IT-connected OT systems warrant emergency response; CVSS 7.0+ vulnerabilities actively referenced in CERT-In advisories warrant accelerated response. All other vulnerabilities should be managed through the standard prioritised patching cycle. Organisations should develop their own scoring criteria based on their specific risk tolerance and operational constraints. (NIST, 2023)
Does the DPDPA affect OT vulnerability management in India?
DPDPA 2023 is primarily a data protection law and does not directly specify OT vulnerability management requirements. However, where OT systems process personal data - industrial MES systems tracking individual worker productivity, smart meters collecting household energy data, healthcare OT processing patient data - DPDPA requires appropriate technical security measures, which include vulnerability management for systems processing personal data. A successful exploitation of a known, unmitigated vulnerability in a personal-data-processing OT system may constitute negligence under DPDPA's security requirement provisions. ([DPDPA](https://meity.gov.in/dpdpa), 2023)
How long does OT vulnerability remediation typically take for Indian organisations?
OT vulnerability remediation timelines for Indian industrial organisations vary significantly by vulnerability severity and system type. High-severity vulnerabilities in internet-facing systems: target within 30 days, using compensating controls immediately. High-severity vulnerabilities in internal OT systems: target within 90 days with compensating controls in place. Medium-severity vulnerabilities in critical OT systems: target within next planned maintenance window (3-12 months). Lower-severity vulnerabilities and end-of-life device replacement: planned for lifecycle-based capital expenditure cycles. These timelines assume active programme management; without a formal programme, many Indian organisations carry vulnerabilities indefinitely with no remediation plan. ([IEC 62443](https://www.iec.ch), 2025)
Making OT Vulnerability Management Work at Indian Industrial Scale
OT vulnerability management in India is a programme discipline, not a one-time project. The vulnerability landscape changes continuously as new CVEs are published, new threat intelligence emerges, and the OT asset inventory evolves. A sustainable programme requires ongoing passive monitoring to maintain an accurate asset inventory, regular CVE database reviews matched against that inventory, integration of CERT-In advisories into the prioritisation process, and a managed queue of vulnerabilities with compensating controls and remediation schedules documented for each.
The goal is not a zero-vulnerability OT environment - that is neither achievable nor necessary. The goal is a managed vulnerability posture where the highest-risk vulnerabilities are mitigated, compensating controls are in place and documented for the rest, and the programme has the visibility and process discipline to respond appropriately when new high-priority vulnerabilities emerge. This is the OT vulnerability management posture that NCIIPC audits expect and that operational security demands.
For OT vulnerability management programme support, visit our OT security services for India.
For hands-on delivery in India, see vulnerability management service.
About the Author
Country Manager, Sweden at Opsio
AI, DevOps, Security, and Cloud Solutioning. 12+ years leading enterprise cloud transformation across Scandinavia
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.