The Brownfield Dilemma: How to Secure Legacy OT Systems You Can’t Patch or Replace
Table of Contents
You’re running machines that print money every shift—CNC mills, packaging lines, injection molders—controlled by systems that haven’t seen a security update since the Obama administration. Now your CEO wants “Industry 4.0 dashboards,” your cyber insurer is asking about network segmentation, and your IT person is quietly panicking about plugging Windows XP into your cloud network.
This guide shows you how to secure unpatchable OT equipment without halting production, voiding warranties, or ripping out systems that still work perfectly. You’ll learn the “fence it, don’t fix it” approach that manufacturing SMBs actually use—starting with visibility, not expensive tools.
Why Legacy OT Is a Security Blind Spot (And Why It Matters Now)
The Air-Gap Myth
If your production floor feels separate from your office network, you’re not alone. Most manufacturers believe their operational technology (OT)—the PLCs, HMIs, and SCADA systems running their machines—sits safely behind an “air gap,” isolated from the internet and cyber threats.
Here’s the uncomfortable truth: that air gap probably doesn’t exist anymore.
Consider how work actually happens on your plant floor. A machine goes down at 2 AM, and your vendor dials in remotely to troubleshoot. A maintenance technician plugs in a USB drive to transfer a program update from the supplier. Your production manager wants to pull efficiency reports, so IT sets up a connection to export data to Excel. Each of these everyday actions creates a bridge between your “isolated” OT environment and the outside world.
The 2021 Colonial Pipeline ransomware attack is the textbook example. Their OT network—the systems controlling fuel flow through pipelines—was supposedly air-gapped from their IT network. Yet ransomware that initially infected a corporate VPN account eventually forced them to shut down pipeline operations for six days. The air gap didn’t stop the crisis; it just made it harder to see coming.
Modern business demands are systematically demolishing whatever isolation you once had. Your CEO wants a real-time production dashboard accessible from their phone. Your largest customer requires predictive maintenance data as part of their vendor scorecard. Your CFO wants to know if investing in IoT sensors will reduce downtime. Each of these requests chips away at the air gap, often without anyone asking: “How do we secure this connection?”
The Three Forces Pushing You to Act
Three external pressures are converging right now, forcing manufacturers to confront OT security whether they’re ready or not:
1. Digital Transformation Pressure
Your leadership team is reading the same articles about Industry 4.0, smart factories, and digital twins. They want Overall Equipment Effectiveness (OEE) dashboards, predictive maintenance alerts, and cloud-based analytics. The conversation usually goes like this: “Why can’t we just connect our machines to Power BI?” or “Can we get mobile alerts when a line goes down?”
The problem? Connecting 20-year-old equipment to modern cloud platforms creates a security gap you can drive a truck through. That Windows XP machine controlling your packaging line was never designed to defend itself on a network, because it was never supposed to be on a network.
2. Cyber Insurance Requirements
If you’ve renewed your cyber insurance policy in the past 18 months, you’ve probably noticed the questionnaire got a lot more specific. Insurers are now explicitly asking about OT environments:
- “Do you maintain an inventory of operational technology assets?”
- “Is your OT network segmented from your IT network?”
- “What controls prevent unauthorized access to industrial systems?”
Answering “No” or “I don’t know” can increase your premium by 30% or more—or disqualify you entirely. Insurers have realized that a ransomware attack on a manufacturer doesn’t just encrypt file servers; it can halt production for weeks.
3. Supply Chain Audits
If you supply components to automotive OEMs, pharmaceutical companies, or defense contractors, you’ve likely received security questionnaires or on-site audits. Large enterprises are now auditing their entire supply chain for compliance with standards like NIS2 (Europe), CMMC (US defense), or ISO 27001.
A common audit question catching SMBs off-guard: “Can you show us your OT asset inventory and network segmentation documentation?” Most manufacturers can produce an equipment list from their ERP system, but that’s not the same as a security-focused asset inventory that includes IP addresses, firmware versions, and network connections.
What Makes Brownfield OT Different from IT Security
If you’re thinking, “Can’t we just apply the same security practices we use for our office computers?” the answer is: not without breaking things.
You can’t patch freely. That Windows XP machine running your CNC mill might have a “critical security update” available, but installing it could void your equipment warranty or—worse—change something that causes the machine to malfunction. Many equipment vendors explicitly prohibit software changes, even security patches, without their approval and on-site supervision.
Active scanning is dangerous. In IT security, you might run a vulnerability scanner like Nessus to identify weaknesses. Do that on an OT network and you might crash a PLC. Industrial control systems weren’t designed to handle unexpected network probes; active scanning can overwhelm their limited memory or trigger watchdog timers that force a reboot. You can’t reboot a production line mid-shift without losing tens of thousands in output.
Protocols lack basic security. Industrial protocols like Modbus and DNP3 were designed in the 1970s and 80s for point-to-point connections in closed environments. They have no authentication—any device that can reach a PLC can send it commands. Imagine if your email system had no password requirement and anyone on the network could send emails as you. That’s the reality for many OT protocols.
Uptime is everything. In IT security, the priority order is usually: confidentiality, integrity, availability (CIA). In OT, that’s flipped: availability, integrity, confidentiality (AIC). Your production manager doesn’t care if someone could theoretically read sensor data—they care that the line runs 24/6. This fundamental difference means security controls that might be acceptable in IT (like rebooting to apply patches) are non-starters in OT.
| Aspect | IT Security | OT Security |
|---|---|---|
| Priority | Confidentiality → Integrity → Availability | Availability → Integrity → Confidentiality |
| Patching | Monthly or as released | Rarely (may void warranty) |
| Reboot Tolerance | Acceptable during business hours | Only during planned downtime |
| Scanning Methods | Active vulnerability scans OK | Passive monitoring only |
| Protocol Authentication | Standard (passwords, certificates) | Often none (legacy protocols) |
| Downtime Acceptance | Minutes to hours tolerable | Every minute costs revenue |
The bottom line: brownfield OT security isn’t about making old systems as secure as new ones. It’s about building protective layers around equipment you can’t—and often shouldn’t—change.
What “Good Enough” OT Security Looks Like for SMB Manufacturers
The IEC 62443 Reality Check
If you’ve heard of IEC 62443, it probably sounded intimidating—a thick international standard written by engineers for engineers. But here’s the secret: you don’t need to implement all of it, and the entry level is surprisingly achievable.
IEC 62443 is the global framework for industrial cybersecurity. It defines four “Security Levels” (SL1 through SL4), each addressing different threat scenarios. The good news? SL1 is designed for exactly your situation.
Security Level 1 protects against “casual or coincidental violation.” In plain language: accidental mistakes, opportunistic attacks, and basic threats—not sophisticated hackers or nation-state actors. Think of it as locking your doors and windows rather than building a bank vault.
What does SL1 actually require? Four things most SMBs can accomplish without consultants:
- Asset inventory – A documented list of what OT devices you have and where they connect
- Network segmentation – Separating your production floor network from your office network
- Access control – Knowing who can access OT systems and limiting unnecessary permissions
- Basic incident response plan – A one-page document explaining who to call and what to do if something goes wrong
Notice what’s not on that list: expensive monitoring platforms, security certifications, or replacing legacy equipment. SL1 is about fundamental hygiene, not advanced threat hunting.
The “Fence It, Don’t Fix It” Philosophy
The hardest mindset shift for SMB manufacturers is accepting this reality: you cannot make a Windows XP machine or 20-year-old PLC secure in the traditional sense. You can’t patch it, you can’t install antivirus, and you can’t upgrade the OS without potentially bricking a ₹50 lakh piece of equipment.
So stop trying.
Instead, focus on compensating controls—security measures that protect vulnerable devices without touching them. The strategy is simple: limit what can reach that device and what that device can reach.
Think of a medieval castle. You can’t make the villagers inside invincible warriors, but you can:
- Build a moat (network segmentation)
- Post guards at the gate (firewall rules)
- Control who gets in and out (access management)
- Watch for threats from the walls (monitoring)
This is “fence it, don’t fix it.” The vulnerable device stays vulnerable, but you’ve made it much harder to exploit.
Here’s what this looks like in practice:
Your packaging line runs on Windows XP with no patches available. Instead of replacing it:
- Put it on a separate VLAN that can’t access the internet
- Block it from communicating with any device except the SCADA server that needs to monitor it
- Require anyone accessing it remotely to go through a hardened jump box with logging
- Monitor network traffic to detect if it suddenly starts doing something unusual
The Windows XP machine is still running vulnerable software, but you’ve made it an extremely difficult target.
Three Tiers of Brownfield OT Security (Budget-Based)
Tier 1: Free to ₹50,000 (Start Here)
This tier costs almost nothing but dramatically improves your security posture. Most manufacturers can complete this in 4-6 weeks using existing equipment and free tools.
What you’re doing: Understanding what you have and closing obvious holes.
- Network visibility: Use free passive monitoring tools (like Wireshark or NetworkMiner) to capture traffic and see what devices are communicating. “Passive” means you’re just listening—not actively scanning devices that might crash.
- Asset inventory: Create a spreadsheet listing every OT device (PLCs, HMIs, sensors, switches), its IP address, what it does, and when it was last updated. Yes, a spreadsheet is fine. Perfection is the enemy of progress.
- Basic firewall rules: Most manufacturers already have a firewall between their internet connection and internal network. Add simple rules like “block all OT devices from initiating outbound internet connections.” This stops compromised devices from calling home to attackers.
Trade-off: You’re gaining visibility but not active protection. If something goes wrong, you’ll know about it faster, but you’re not preventing attacks yet.
Tier 2: ₹1–5 Lakhs (The Security Step Change)
This is where you move from “better than nothing” to “legitimate security posture.” Most 50-200 person manufacturers should aim to reach this tier within 12 months.
What you’re doing: Building barriers between systems so a breach in one area can’t spread.
- VLAN segmentation: Configure your network switches to separate OT traffic from IT traffic. This is usually a software configuration on equipment you already own—no new hardware required. Your machines can’t get infected by ransomware from someone’s laptop anymore.
- Jump box for remote access: Instead of letting vendors VPN directly into your OT network, they connect to a hardened Windows/Linux machine that logs every action. You control what they can access, and you have a record of what they did.
- Unidirectional gateway: If you need to send production data to the cloud for analytics, a unidirectional data diode ensures data flows only one direction (OT → IT/Cloud). Attacks can’t flow backward. Hardware options start around ₹1.5 lakhs; software-based options are cheaper but less bulletproof.
Trade-off: This requires coordination with your IT team or vendor and some scheduled downtime to reconfigure networks. But the protection is substantial.
Tier 3: ₹5+ Lakhs (When Budget Allows or Compliance Demands)
This tier is for manufacturers with higher risk profiles, strict compliance requirements, or who’ve already implemented Tier 1 and 2 and want active threat detection.
What you’re doing: Continuous monitoring and automated threat detection by systems that understand industrial protocols.
- OT-specific monitoring platform: Tools like Nozomi, Claroty, or Dragos monitor your network 24/7, understand Modbus and other industrial protocols, and alert you to anomalies. Pricing starts around ₹5-8 lakhs annually for SMB-sized deployments.
- Virtual patching appliance: Devices from vendors like TXOne or Hirschmann sit in front of vulnerable systems and filter out malicious traffic patterns—giving you “patch-like” protection without actually patching. Think of it as a bodyguard for your unpatched machines.
- Managed Detection & Response (MDR) for OT: If you don’t have 24/7 security staff, OT-focused MDR providers monitor your systems and respond to threats. Expect ₹5-15 lakhs annually depending on asset count.
Trade-off: Higher cost and complexity. You need someone internally who can manage alerts and coordinate with the MDR provider. Don’t buy Tier 3 tools if you haven’t completed Tier 1 and 2—you’ll drown in false positives.
The key insight: you don’t need to reach Tier 3 to be secure enough. Most SMB manufacturers operating in non-critical infrastructure can achieve strong security with Tier 1 and 2 controls—spending ₹5 lakhs or less over 12-18 months. Tier 3 is for when you have specific compliance obligations, high-value intellectual property, or face advanced persistent threats.
Start where you are. Build the fence first, then decide if you need guards patrolling it.
Step-by-Step: Your First 90 Days of Brownfield OT Security
Phase 1 (Weeks 1–2): Turn On the Lights
Goal: Know what you have and where it connects.
You can’t protect what you can’t see. Most manufacturers are surprised to discover they have 30-40% more networked devices on their plant floor than they thought. Before you build any defenses, you need a map.
Action 1: Run a Passive Network Scan
Download Wireshark (free, open-source) or NetworkMiner (also free), or request a trial of Nozomi/Claroty if you want something more automated. The key word here is passive—these tools listen to network traffic without sending probes that could crash a PLC.
Set up a laptop with one of these tools connected to a network switch port configured for “port mirroring” (also called SPAN port). This lets you see all traffic flowing through that switch without actively scanning devices. Let it run for at least 48 hours to capture typical activity patterns—including night shifts and weekend operations.
What you’re capturing:
- IP addresses: Every device communicating on your network
- MAC addresses: The unique hardware identifier for each device (useful for identifying manufacturers)
- Protocols in use: Are you running Modbus TCP? EtherNet/IP? PROFINET? Knowing this matters for later security decisions
Why passive matters: Active vulnerability scanners like Nessus send thousands of network requests to test devices. On modern IT systems, that’s fine. On a PLC with 64KB of memory designed in 1998, those requests can overwhelm the processor and trigger a watchdog timer reset—instant unplanned downtime.
Action 2: Create Your Asset Inventory Spreadsheet
Open Excel or Google Sheets. Create columns for:
- Device name (e.g., “Packaging Line 2 – HMI”)
- IP address
- MAC address
- OS/firmware version (if known)
- Vendor/manufacturer
- Criticality: High (production stops if this fails), Medium (causes delays), Low (monitoring only)
- Last known patch/update date
- Notes (e.g., “Vendor says patching voids warranty”)
Start filling this in based on your network scan and by physically walking the plant floor. Don’t stress if you can’t fill every field—”Unknown” is a valid entry. You’re building visibility, not writing a doctoral thesis.
Action 3: Map Your Network Topology
Grab a whiteboard, paper, or use free tools like Draw.io. Sketch:
- Where your internet connection enters
- Your main firewall/router
- Switches connecting different areas
- Which devices talk to which other devices
- Where your office IT network connects to the plant floor
The diagram doesn’t need to be pretty. It needs to answer three questions:
- Which devices can currently reach the internet?
- Can an infected office laptop directly communicate with production PLCs?
- If ransomware hit your accounting PC, what path could it take to reach the plant floor?
Time commitment: Expect 8-12 hours total spread over two weeks—a few hours to set up monitoring, periodic checks, and time for the physical walkthrough.
Phase 2 (Weeks 3–6): Build the First Fence
Goal: Separate OT from IT and restrict unnecessary traffic.
Now that you know what you have, it’s time to create boundaries. Think of this as dividing your facility into security zones—each with different access rules.
Action 1: Implement VLAN Segmentation
A VLAN (Virtual Local Area Network) is a way to logically separate network traffic using your existing switches—no new hardware required if you have managed switches.
Basic VLAN structure for SMB manufacturers:
- VLAN 10: OT/Production (PLCs, HMIs, SCADA servers)
- VLAN 20: Corporate IT (office PCs, printers, file servers)
- VLAN 30: Guest WiFi (visitors, contractor laptops)
- VLAN 40: IoT/Sensors (if you have newer smart devices)
How this protects you: A device on VLAN 20 (corporate IT) cannot directly communicate with VLAN 10 (OT) unless you explicitly create a firewall rule allowing it. If ransomware infects someone’s laptop, it’s trapped in VLAN 20 and can’t spread to production systems.
Coordination needed: This requires brief network downtime or careful port-by-port migration. Schedule it during planned maintenance windows and have your operations team on standby in case something doesn’t reconnect properly.
Action 2: Configure Deny-by-Default Firewall Rules
Your firewall should operate on a “deny everything, allow only what’s needed” basis. Here are starter rules for OT:
Block OT from initiating internet connections:
- Rule: DENY any traffic from VLAN 10 (OT) to WAN (internet)
- Why: If your PLC suddenly tries to download something from the internet, that’s a red flag
- Exception: If you have cloud-connected equipment that legitimately needs internet, create a specific allow rule for just that device to just that destination
Control IT-to-OT traffic:
- Rule: ALLOW only your SCADA server (specific IP) to connect to PLCs on specific ports
- Rule: DENY all other traffic from VLAN 20 to VLAN 10
- Why: Your office PCs don’t need to talk to production equipment
Log denied traffic for two weeks before fully enforcing rules. This helps you catch legitimate traffic you forgot about. If your quality control system suddenly can’t pull data from a PLC, your logs will show the blocked connection.
Action 3: Set Up a Jump Box for Remote Vendor Access
If equipment vendors need remote access, create a controlled entry point instead of giving them direct VPN access to your OT network.
What’s a jump box? A hardened Windows or Linux machine that sits between external users and your OT systems. Vendors connect to the jump box first, then the jump box connects to the specific device they need to access.
Minimum configuration:
- Multi-factor authentication (MFA) required to log in
- Session recording enabled (you’ll have a video record of what the vendor did)
- Whitelist of allowed destination IPs (vendor can only reach equipment they’re authorized for)
- Time-limited access (credentials expire after 8 hours or when the work order closes)
Free option: Linux server running Apache Guacamole for web-based remote desktop with session recording. Hardware: any old PC with 8GB RAM will work.
Paid option: Commercial jump box solutions start around ₹40,000 (software) to ₹2 lakhs (appliances with built-in MFA).
Trade-off to expect: Vendors will complain this adds friction. Some may claim they “can’t work this way.” Stand firm—direct OT network access is one of the top ransomware entry points for manufacturers. The small inconvenience is worth it.
Phase 3 (Weeks 7–12): Monitor and Harden
Goal: Detect anomalies and lock down unnecessary access points.
You’ve built the fence. Now you need to watch it and close remaining gaps.
Action 1: Centralize Logging
Enable logging on every network device possible: switches, firewalls, and PLCs (if they support it—many older ones don’t).
Send all logs to a central syslog server. Free options:
- Graylog: Easy web interface, good for SMBs
- ELK Stack (Elasticsearch, Logstash, Kibana): More powerful but steeper learning curve
What to alert on:
- New devices joining the network (unknown MAC address)
- Failed login attempts (3+ failures in 10 minutes)
- Unusual protocols appearing (if you only use Modbus, why is Telnet suddenly showing up?)
- Traffic from OT to unexpected destinations
Realistic expectation: You’ll get false positives initially. Tune your alerts over 4-6 weeks by investigating each one and adjusting thresholds.
Action 2: Disable Unused Services
Walk through each critical OT system and disable services you don’t need.
Example – Windows XP HMI:
- Disable SMB file sharing if it’s not used
- Disable Remote Desktop (RDP) if no one accesses it remotely—or limit it to the jump box IP only
- Disable any web interfaces on the system
How to find unused services: Check your firewall logs for traffic patterns. If nothing has accessed RDP on a particular HMI in 90 days, you probably don’t need it enabled.
Action 3: Implement USB Device Control
USB drives are a common infection vector. A well-meaning technician plugs in a drive used on their home computer, and suddenly you’ve imported malware.
Options:
- BIOS-level whitelisting: Many industrial PCs let you whitelist specific USB device IDs in BIOS. Only approved devices will work.
- Group Policy (for Windows systems): Configure Windows to block USB storage devices except specific approved ones
- Physical controls: USB port locks (plastic plugs that physically block ports) cost ₹50 each
Create a policy: “No personal USB drives on OT systems. Approved drives must be scanned on the air-gapped scanning station before use.” Set up one dedicated laptop, disconnected from the network, with updated antivirus just for scanning USB drives.
Action 4: Create a Basic Incident Response Plan
You don’t need a 50-page document. A single-page checklist works for most SMBs.
Your IR plan should answer:
- Who’s the first call? (Name and mobile number—not just “IT manager”)
- How do we isolate a suspected infected device? (Physically unplug cable? Disable switch port remotely? Who has authority to do this?)
- Who decides whether to shut down production? (Operations manager? Plant manager? This must be pre-decided, not figured out during a crisis)
- What’s the evidence preservation process? (Don’t reboot the affected system—you’ll lose forensic data. Take photos of error messages.)
- Who do we notify? (Cyber insurance carrier within X hours, CERT-In if required, key customers if their data involved)
Test it: Run a tabletop exercise. Scenario: “It’s 11 PM on Friday. The packaging line HMI is showing a ransomware note. What do you do?” Walk through your checklist. You’ll find gaps immediately.
Quick Win: The 10-Minute Security Check
Before you dive into any technical work, do this physical walkthrough. It takes 10 minutes and often reveals the easiest-to-fix security gaps.
Grab:
- A laptop or smartphone with WiFi analyzer app (free: WiFi Analyzer for Android/Windows)
- A notepad
Walk the plant floor and look for:
Rogue WiFi networks: Turn on your WiFi scanner. Are there network names you don’t recognize? Common culprits:
- Contractor-installed equipment with built-in WiFi enabled by default
- Old WiFi routers someone plugged in years ago “for convenience”
- Cellular modems vendors installed for remote support without telling you
Unauthorized devices: Look for laptops or tablets permanently plugged into network switches. Are they documented in your asset inventory? Who owns them?
Physical access gaps:
- Can you open electrical cabinets without a key?
- Are HMI screens in unlocked locations where anyone can touch them?
- Can someone walk up and plug a USB drive into a control system?
What to fix immediately:
- Disable or document any unknown WiFi networks
- Lock control cabinets (₹500 padlocks are fine)
- Remove unauthorized devices or document them in your asset inventory
- Cover unused USB ports with physical port locks
Time investment: 10 minutes walking, 1-2 hours fixing what you find.
Reality check for the 90-day plan: You won’t finish everything perfectly in 90 days, especially if you’re doing this alongside your regular job. That’s okay. The goal is to have visibility (Phase 1), basic segmentation (Phase 2), and initial monitoring (Phase 3) in place. You’ll be in a dramatically better security position than 90% of SMB manufacturers.
Budget 4-8 hours per week for the first month, 2-4 hours per week after that. This is achievable without hiring anyone new.
Choosing OT Security Tools: What SMBs Actually Need
When Free Tools Are Enough (And When They’re Not)
The OT security vendor ecosystem wants you to believe you need expensive platforms from day one. You don’t. Many manufacturers can get 70-80% of the security benefit using free or low-cost tools—if they have someone with basic networking knowledge to use them.
Free/Low-Cost Tools That Actually Work:
Wireshark + NetworkMiner (both free, open-source) for passive network discovery. These tools capture and analyze traffic without sending a single packet that could disrupt production. NetworkMiner is particularly useful—it automatically extracts device information from captured traffic and presents it in a readable format. Perfect for your initial asset inventory and understanding what protocols you’re running.
pfSense or OPNsense (free, open-source) as your OT firewall. Both are enterprise-grade firewall platforms that run on commodity hardware. A ₹30,000 PC can handle 1Gbps throughput, which is more than sufficient for most SMB manufacturing environments. You get VLAN support, robust firewall rules, VPN capability, and detailed logging—everything needed for Tier 2 security.
Trade-off: These require someone comfortable with networking concepts. If your IT person has configured a router before, they can handle pfSense. If they haven’t, the learning curve is steep.
Graylog or Wazuh (free, open-source) for log aggregation and alerting. Collect logs from all your network devices in one place, search them when investigating issues, and set up basic alerts (new device detected, failed logins, unusual traffic patterns).
When to Stop Using Free Tools and Invest in Commercial OT Security:
You have multiple industrial protocols. Free tools can capture Modbus TCP traffic, but you’ll need to manually decode it using Wireshark’s protocol dissectors. If you’re running Modbus, EtherNet/IP, and PROFINET simultaneously, interpreting raw packet captures becomes overwhelming fast. Commercial OT platforms automatically decode these protocols and present readable information: “PLC changed setpoint from 150 to 200” instead of hex values.
You lack internal expertise. If nobody on your team can confidently read a Wireshark capture and distinguish normal from suspicious traffic, free tools give you data but no insight. You’ll know something happened but not what it means or whether you should care.
Cyber insurance demands it. Some insurers now require “continuous OT monitoring with anomaly detection” to maintain coverage or avoid premium increases. A Wireshark PCAP file won’t satisfy that requirement—you need a commercial platform that produces audit reports.
You’re in a regulated industry. Pharmaceutical manufacturers facing FDA audits, food and beverage plants with FSMA requirements, or suppliers with customer mandates (automotive OEMs requiring TISAX compliance) often need commercial tools to demonstrate due diligence.
Decision framework: Can you answer these questions using free tools?
- “What OT devices do we have and what firmware versions are they running?”
- “Is this traffic pattern normal for Tuesday morning, or is something wrong?”
- “Can we produce a report showing we monitor our OT network for threats?”
If you answered yes to #1 but no to #2 and #3, you need commercial tools.
Evaluating OT Security Platforms (Claroty, Nozomi, Dragos, etc.)
When you’re looking at six-figure investments, vendor demos all look impressive. Here’s how to cut through the marketing and evaluate what you actually need.
1. Deployment Model: Passive TAP vs. Inline
Preferred approach: Passive monitoring via network TAP (Test Access Point) or SPAN port. The monitoring device sees a copy of all traffic but sits completely outside your production network. If the monitoring system crashes or gets compromised, your production is unaffected.
Red flag: Vendors pushing inline deployment where their appliance sits in the data path between devices. This creates a single point of failure—if their device fails, your production stops. Only consider inline solutions if you absolutely need them for protocol filtering or virtual patching, and even then, deploy them in high-availability pairs.
Question to ask: “Can your platform operate entirely passively, or does it need to be inline to provide full functionality?”
2. Protocol Coverage: Don’t Pay for What You Don’t Use
Many platforms advertise support for 100+ industrial protocols. Impressive, but irrelevant if you only use Modbus TCP and EtherNet/IP.
Before any sales call:
- List the protocols actually running on your plant floor (you discovered this in your Phase 1 network scan)
- Identify your PLC brands and models (Allen-Bradley, Siemens, Schneider Electric, etc.)
Question to ask: “Can you demonstrate protocol decoding for Modbus TCP and EtherNet/IP specifically? Can you show me what a read coil command looks like in your interface versus a write register command?”
If they show you a generic demo with canned data, push for a proof-of-concept on your actual network.
3. Asset Discovery Accuracy: The Make-or-Break Feature
Every vendor claims their platform “automatically discovers and profiles OT assets.” The reality varies wildly.
What you’re testing for:
- Can it identify the make, model, and firmware version of your 15-year-old Allen-Bradley PLC?
- Can it distinguish between a Siemens S7-1200 PLC and an S7-1500?
- Does it show you the actual ladder logic program name running on the PLC, or just generic “Siemens PLC” data?
How to evaluate: Request a 30-day trial on your actual network, not a sales demo. Compare the asset list it generates against your manually created asset inventory. If it misses 30% of your devices or can’t provide firmware versions, the value proposition diminishes significantly.
4. Alert Fatigue: The Silent Killer
OT security platforms that alert on every minor anomaly will train your team to ignore alerts within two weeks. This is dangerous—when a real threat appears, it gets lost in the noise.
Questions to ask:
- “How does your platform baseline normal behavior before generating alerts?” (You want at least 2-4 weeks of learning before alerts start)
- “Can I customize alert thresholds?” (Example: Don’t alert me if someone accesses the HMI during first shift—that’s normal. Do alert me if someone accesses it at 2 AM.)
- “Show me your alert dashboard. How many alerts would a typical manufacturer see per week?”
Red flag: Vendors who say “Our AI detects all anomalies!” but can’t explain how to reduce false positives or customize alerts based on your operational patterns.
5. Total Cost of Ownership: The Hidden Expenses
The platform license is only part of the cost. Factor in:
Licensing models:
- Per-asset pricing: You pay for each device monitored (typically ₹5,000-15,000 per asset/year)
- Per-site pricing: Flat fee regardless of asset count (typically ₹5-12 lakhs/year for SMB deployments)
- Perpetual license: Large upfront cost, smaller annual maintenance (less common now)
Hidden costs:
- Hardware requirements: Does it need a dedicated server? (Add ₹1-2 lakhs)
- Professional services: Implementation, configuration, training (Add ₹2-5 lakhs for initial setup)
- Ongoing support: Is basic support included, or do you pay extra for phone support and updates?
ROI comparison exercise: Sometimes spending ₹3 lakhs on better network segmentation (Tier 2 controls) provides more actual security than spending ₹8 lakhs on a monitoring platform you don’t have expertise to use effectively. Don’t buy monitoring before you’ve implemented segmentation—it’s like buying a burglar alarm before you’ve locked your doors.
6. Legacy System Support: Ask Explicitly
Many OT platforms are optimized for modern industrial protocols and newer devices. Your 20-year-old equipment might be ignored.
Question to ask verbatim: “Can your platform monitor and profile devices running Windows XP, Windows 2000, Windows NT, or proprietary embedded operating systems? Can you show me an example in your demo environment?”
Specific test: If you have serial-to-Ethernet converters (common in brownfield environments), ask if the platform can see traffic passing through them. Many can’t.
The MDR for OT Question
Managed Detection and Response (MDR) is where you outsource the 24/7 monitoring and threat response to specialists. For SMB manufacturers without dedicated security staff, this often makes more sense than buying a platform and hoping someone internally has time to watch it.
When MDR Makes Sense:
You can’t confidently answer this question in under 30 minutes: “The firewall just logged 500 Modbus write requests from an unfamiliar IP address to PLC #4. Is this a cyber attack or normal operation?”
If you’re not sure, you need expertise—either hired internally (expensive) or via MDR (more cost-effective for SMBs).
OT-Specific MDR Providers:
Dragos, Nozomi, and Claroty all offer MDR services alongside their platforms. Smaller specialized providers exist but verify they have actual OT expertise (see below).
Typical pricing for SMB manufacturing: ₹5-15 lakhs annually for plants with 50-200 monitored assets. This usually includes the monitoring platform, 24/7 alert triage by OT analysts, and incident response support.
What to Verify Before Signing:
1. Do they have actual OT analysts, or IT security people who read a white paper about OT?
Ask: “Walk me through how your team would investigate an alert showing a PLC reboot. What questions would they ask our operations team?”
Good answer: “We’d first check if it aligns with a scheduled maintenance window or program update. We’d look at whether the reboot command came from the engineering workstation or an unknown source. We’d verify if the PLC came back online with the expected program or if something changed.”
Bad answer: “We’d analyze the network traffic and create a report for you to review.”
2. Can they distinguish between normal operational events and security incidents?
PLCs reboot for many legitimate reasons: power glitches, watchdog timer triggers from programming errors, intentional reboots during maintenance. An MDR team that doesn’t understand this will waste your time with false alarms.
3. What’s their escalation SLA, and who do they contact at your company?
You need clear documentation: “If we detect suspected ransomware activity, we will call [Name] at [Number] within 15 minutes and escalate to [Manager Name] if no response in 30 minutes.”
4. Do they understand your production schedule?
A Friday night alert at 11 PM might be urgent. But if you run 24/5 and shut down for the weekend, that same alert on Saturday at 11 PM can wait until Monday morning. Your MDR provider needs to know your operational rhythm.
The Make-vs.-Buy Decision:
If you have:
- Someone with networking knowledge who can dedicate 3-5 hours per week to OT security
- Relatively simple environment (one or two protocols, fewer than 50 devices)
- Budget under ₹5 lakhs
→ Start with free tools + Tier 2 controls, skip commercial platforms for now.
If you have:
- Complex multi-protocol environment
- No internal networking expertise
- Cyber insurance or compliance requirements
- Budget of ₹8+ lakhs
→ Consider commercial platform + MDR service, skip trying to do it yourself.
The honest truth: most 50-200 person manufacturers don’t need ₹20 lakh OT security platforms. They need solid segmentation, basic monitoring, and access controls—achievable for under ₹5 lakhs using a mix of free and commercial tools. Spend your money on the fundamentals first, then layer on advanced monitoring as your security posture and budget mature.
Five Mistakes That Make Brownfield OT Security Worse
Learning from others’ mistakes is cheaper than making them yourself. Here are the five most common ways manufacturers accidentally make their OT environments less secure—and how to avoid them.
Mistake #1: Patching Without Testing
The mistake: Your IT person sees that Windows XP machine controlling the injection molding press has 247 critical security updates available. They decide to patch it over the weekend to “secure” it.
Why it’s dangerous: Those patches weren’t tested against the proprietary vendor software running on that machine. One patch changes a timing behavior or deprecates a DLL file the control software depends on—suddenly your ₹1.5 crore machine won’t start on Monday morning. The vendor tells you the patch voided your warranty and charges ₹5 lakhs for an emergency on-site visit to roll it back.
Do this instead:
If you have an identical spare system or offline test environment, patch that first and run it for at least a week before touching production. Most SMBs don’t have spare production equipment, so the realistic approach is: don’t patch unless the vendor explicitly approves and supports it.
Instead, use compensating controls:
- Isolate the unpatchable system on its own network segment
- Use firewall rules to prevent it from accessing anything except the specific systems it needs
- Consider a virtual patching appliance (like TXOne or Hirschmann) that sits in front of the vulnerable device and filters malicious traffic patterns without touching the actual system
Schedule any patches during planned maintenance windows only, with your operations team and vendor on standby. Never patch production OT systems outside of scheduled downtime.
Mistake #2: Running Active Vulnerability Scans
The mistake: To satisfy a cyber insurance requirement or customer audit, you run Nessus or Qualys against your OT network, just like you would on office computers.
Why it’s dangerous: Active vulnerability scanners send thousands of network requests to probe devices for weaknesses. Modern PLCs can handle this. A 1998 PLC with 64KB of RAM and a 20MHz processor? Not so much.
Active scanning can:
- Overwhelm PLC memory and cause it to crash or reboot
- Trigger watchdog timer resets (the PLC’s safety mechanism that reboots it if it stops responding)
- Cause emergency stops on safety systems that interpret unexpected traffic as a fault condition
You’re trying to improve security but accidentally causing production downtime.
Do this instead:
Use passive monitoring exclusively. Mirror network traffic to a monitoring device that listens without sending any packets. Tools like Wireshark, NetworkMiner, or commercial platforms like Nozomi operate this way.
If active scanning is absolutely required for compliance, negotiate the terms:
- Only during scheduled maintenance windows
- With Operations team physically present at the equipment
- Start with a single non-critical device as a test
- Have a rollback plan if something crashes
Pro tip: Many auditors will accept passive monitoring evidence instead of active scan results if you explain the operational risk. Provide documentation showing you’ve identified assets and vulnerabilities through passive means.
Mistake #3: Giving Vendors Unrestricted Remote Access
The mistake: Your CNC machine vendor needs occasional remote access for support. You create a VPN account with credentials like “VendorSupport/Password123” that connects directly to your OT network and stays active indefinitely “for convenience.”
Why it’s dangerous: You’ve just inherited the security posture of your vendor’s entire operation. If they use the same VPN credentials for 50 other customers, any breach of their systems compromises yours. If one of their technicians’ laptops gets infected with ransomware, that malware now has direct access to your production network.
Worse: you have zero visibility into what the vendor accesses or changes. Did they just diagnose your CNC controller, or did they accidentally misconfigure something while troubleshooting?
Do this instead:
Implement jump box access (also called a bastion host). The vendor connects to a hardened intermediary system first, then that system connects to your equipment. This gives you:
- Session recording: You have video evidence of exactly what the vendor did
- Time-limited access: Credentials expire after 8 hours or when the work order closes
- Access control: The jump box only allows connections to specific equipment the vendor is authorized to service
- Real-time monitoring: Someone on your team can watch the vendor’s session if needed
Access policy should be: “Vendor must request access for each service call, provide a ticket number, and connect through the jump box only. No always-on VPN accounts.”
Most vendors will push back initially—”We can’t work like this, we need instant access.” Stand firm. Explain that this is your new security requirement for all vendors. The good ones will adapt within a week.
Mistake #4: Assuming “Industry 4.0” Tools Are Secure by Default
The mistake: Your leadership wants “real-time production dashboards” and “predictive maintenance.” You buy IoT sensors, edge computing gateways, and cloud-connected devices from reputable vendors and plug them directly into your OT network, assuming they’re secure because they’re new and expensive.
Why it’s dangerous: Many Industrial IoT devices are built to prove concepts quickly, not to operate securely. Common issues:
- Default passwords that never get changed (“admin/admin”)
- Outdated embedded Linux with known vulnerabilities
- Automatic cloud connections to vendor servers you can’t control
- No firmware update mechanism, or updates that break backward compatibility
- Web interfaces exposed on your network with no authentication
These devices often become the easiest entry point for attackers—bypassing all your careful OT segmentation work.
Do this instead:
Treat every new IoT device as untrusted until proven otherwise:
Before deployment:
- Change default passwords immediately
- Check if firmware is current (and if updates are available at all)
- Identify what external connections the device makes (Use Wireshark to watch its traffic for 24 hours before allowing it on the production network)
Network placement:
- Create a separate DMZ VLAN for IoT/Industry 4.0 devices (VLAN 40)
- Don’t place them directly on your OT VLAN where they can talk to PLCs
- Use firewall rules to allow only necessary communication
Data flow control:
If the device only needs to send data outbound (sensor data to cloud), consider a unidirectional gateway. Data flows OT → Cloud, but attacks can’t flow Cloud → OT. Hardware data diodes start around ₹1.5 lakhs; software-based solutions using one-way firewall rules are free but less robust.
Vendor vetting question: “What happens if your cloud service goes down or your company stops supporting this product? Will our device continue working, or will it become a brick?”
Mistake #5: Security Theater (Checkbox Compliance Without Real Protection)
The mistake: You spend ₹12 lakhs on an OT security platform because your cyber insurance audit requires “continuous monitoring.” You get it installed, configure some basic alerts, then never look at it again because nobody has time to manage it. Six months later, you have 3,000 unreviewed alerts and zero actual security improvement.
Why it’s dangerous: You’ve created a false sense of security while wasting budget. Your insurance application says “Yes, we have OT monitoring,” but the reality is you’re not actually monitoring anything. When an incident occurs, you’ll be unprepared and the expensive tool won’t help because nobody knows how to use it.
This is worse than not buying the tool at all—at least then you’d know you’re relying on other controls and would stay vigilant.
Do this instead:
Start small with controls you can actually maintain. It’s better to have three well-configured firewall rules that you review monthly than a sophisticated SIEM collecting logs nobody ever looks at.
Before buying any security tool, answer these questions:
- Who will be responsible for this tool? (Specific name, not “IT department”)
- How much time per week will they spend on it? (Be realistic—2 hours? 5 hours?)
- What specific action will we take when it generates an alert? (Document this before purchase)
- How will we measure if it’s working? (Define success metrics)
If you can’t confidently answer all four questions, don’t buy the tool yet. Invest in simpler controls first.
Tool ownership checklist:
- Assign a primary owner and backup
- Schedule weekly check-ins (literally put “Review OT security alerts” on someone’s calendar)
- Document standard operating procedures: “When you see Alert Type X, do Y”
- Include the tool in your handoff process when that person changes roles
Budget reality: Sometimes the right answer is to spend ₹3 lakhs on better network segmentation you can maintain yourself rather than ₹10 lakhs on a platform that requires expertise you don’t have. Effective security you can sustain beats perfect security that gets abandoned.
The theme connecting all five mistakes: good intentions without operational awareness. OT security requires understanding how production systems actually work and accepting their constraints. The goal isn’t perfect security—it’s effective security that doesn’t break things.
Your 3-Month Roadmap (Quick Reference)
You’ve read the strategies and understand the concepts. Now you need a simple checklist to follow. Here’s what to accomplish each month—realistic targets for someone doing this alongside their regular job.
Month 1: Visibility
Goal: Understand what you have before you try to protect it.
Checklist:
- ☐ Passive network scan to identify all OT assets – Use Wireshark or NetworkMiner, let it run 48+ hours to capture typical patterns
- ☐ Document asset inventory – Spreadsheet with device name, IP, OS/firmware, vendor, criticality level
- ☐ Map network topology – Hand-drawn diagram showing how IT and OT networks connect, which devices have internet access
- ☐ Identify current internet access – List every OT device that can currently reach the internet (prepare to be surprised)
Time commitment: 10-12 hours spread across 4 weeks. Do the network scan during week 1, spend 2-3 hours per week after that documenting findings.
What “done” looks like: You can pull up your spreadsheet and show anyone exactly what OT equipment you have, where it connects, and what’s talking to what. No more “I think we have 30-40 devices” uncertainty.
Month 2: Segmentation
Goal: Build the first fence between IT and OT.
Checklist:
- ☐ Separate OT into dedicated VLAN – Configure your existing managed switches to create VLAN 10 for OT, VLAN 20 for IT
- ☐ Configure firewall deny-by-default rules – Block OT devices from initiating internet connections, restrict IT-to-OT traffic to only necessary systems
- ☐ Set up jump box for vendor remote access – Hardened machine that vendors connect to first, with session recording and time-limited access
- ☐ Disable unused services on legacy systems – Turn off SMB file sharing, RDP, unnecessary web interfaces
Time commitment: 15-20 hours including coordination with operations for scheduled downtime windows.
What “done” looks like: Your IT and OT networks are logically separated. If ransomware infects a laptop in accounting, it can’t spread directly to the packaging line PLC. Vendors no longer have direct VPN access to production equipment.
Month 3: Monitoring & Hardening
Goal: Detect unusual activity and close physical access gaps.
Checklist:
- ☐ Enable logging on network devices – Configure switches, firewalls, and any capable PLCs to send logs to central location
- ☐ Set up basic alerts – New device detected, failed login attempts (3+ in 10 minutes), traffic to unexpected destinations
- ☐ Conduct physical security walkthrough – Lock control cabinets, scan for rogue WiFi networks, check who can physically access HMIs
- ☐ Create 1-page incident response plan – Who to call, how to isolate infected device, when to shut down production
- ☐ Review and document vendor access procedures – Who has access, how they get it, when credentials expire
Time commitment: 12-15 hours including the physical walkthrough and documentation.
What “done” looks like: You have visibility into abnormal network behavior. Your operations team knows what to do if something goes wrong. Control systems aren’t physically accessible to unauthorized people.
Success Metrics After 90 Days
Here’s how to know if you’ve actually improved your security posture:
The 2-Minute Test: Someone asks “What OT devices do we have?” You can pull up your asset inventory and answer immediately—not “Let me get back to you in three days.”
The Segmentation Test: Your IT and OT networks are on separate VLANs with firewall rules controlling what can cross between them. A compromised office computer can no longer directly access production PLCs.
The Monitoring Test: You receive weekly (or daily) reports showing network activity. You can spot when something unusual happens—a new device appears, someone tries to log into a PLC at 2 AM, or a machine starts talking to an IP address it’s never contacted before.
The Insurance Test: When your cyber insurance renewal questionnaire asks “Is your OT network segmented from IT?” and “Do you maintain an OT asset inventory?” you can answer “Yes” with documentation to prove it.
The Confidence Test: You’re no longer guessing about your OT security posture. You have specific knowledge and documented controls. You sleep better knowing you’ve addressed the most common attack vectors.
What to Do When Budget Is Zero
Free Security Wins You Can Implement This Week
No budget doesn’t mean no progress. Here are meaningful security improvements that cost nothing except time—and most take under an hour each.
1. Physical Security Audit (1-2 hours)
Walk your plant floor with a critical eye:
Lock control cabinets. Most electrical cabinets have built-in locks but nobody uses them. Find the keys (or buy ₹200 padlocks if keys are lost). Someone who can physically access a PLC can reprogram it, trigger emergency stops, or plug in infected USB drives.
Secure USB ports. For HMIs and engineering workstations where USB drives aren’t needed daily, use USB port locks (physical plugs that block the port, ₹50 each) or fill them with epoxy. Sounds extreme, but USB-borne malware is one of the most common infection vectors in air-gapped environments.
Post visible signage. Put “Authorized Personnel Only” signs on control rooms and equipment areas. This establishes expectation—visitors know they shouldn’t be there, and your team knows to question unfamiliar people near critical systems.
2. Network Hygiene (2-3 hours)
Change default passwords on every accessible device. Walk the plant floor with a laptop and access each HMI, managed switch, and any device with a web interface. Common defaults like “admin/admin” or “admin/1234” are the first thing attackers try.
Disable internet access for devices that don’t need it. Most PLCs and HMIs have no legitimate reason to access the internet. Add a simple firewall rule blocking their outbound connections. This stops compromised devices from calling home to attacker command-and-control servers.
Document “who has access to what” in an Excel spreadsheet. Create three columns: Person Name, What They Can Access, Why They Need Access. This is your access control list. Just having it written down makes you realize some people have access they don’t need anymore.
3. Process Controls (30 minutes to document)
Create a USB device policy: “No personal USB drives on OT systems. Company-approved drives only, scanned on air-gapped machine before use.” Print it and post it near engineering workstations. Most infections happen because someone doesn’t know there’s a policy.
Implement vendor “buddy system”: Require someone from your team to be physically present during any vendor access—whether in-person or remote. They don’t need to understand what the vendor is doing technically, just witness and log it. This prevents both malicious and accidental mistakes.
Start a simple logbook: Who accessed OT systems, when, and why. Can be a physical notebook or Google Sheet. Example entry: “Nov 15, 2:30 PM – TechVendor accessed CNC controller to update parameters, Bob supervised.” This creates audit trail and accountability.
4. Free Training (Ongoing)
CISA (Cybersecurity and Infrastructure Security Agency) offers free ICS security training and resources specifically for industrial environments. Start with their “ICS Security 101” self-paced course.
SANS Institute archives free ICS security webcasts. Search their website for “ICS security summits” and you’ll find hours of expert presentations covering real-world OT threats.
YouTube channels: Search for “PLC security,” “OT cybersecurity,” or “SCADA security” to find technical walkthroughs showing what attacks actually look like.
Reality check: These free measures won’t stop sophisticated attackers, but they’ll eliminate the low-hanging fruit that causes 80% of manufacturing security incidents—default passwords, unnecessary internet access, and USB-borne malware.
Building the Business Case for Year 2
When you have zero budget this year, your job is to demonstrate value so you get funding next year. Here’s how to build a compelling business case using language leadership actually cares about.
Reframe “Cybersecurity” as “Business Continuity”
Your CEO doesn’t wake up worried about “OT security.” They wake up worried about production uptime, customer delivery commitments, and revenue. Frame your request accordingly:
Don’t say: “We need ₹5 lakhs for network segmentation to improve our cybersecurity posture.”
Do say: “We need ₹5 lakhs to reduce our production downtime risk. Right now, if ransomware hits one office computer, it could spread to our production floor and halt all three lines for days. This investment prevents that.”
Calculate the Cost of Downtime
Do this math with your CFO or operations manager:
Revenue per production hour: If your plant runs two shifts generating ₹2 crore monthly revenue, that’s roughly ₹10 lakhs per day or ₹40,000 per hour.
Cost of 3-day outage: ₹30 lakhs in lost revenue, plus customer penalties, overtime to catch up, potential lost contracts.
Cost of prevention: ₹5 lakhs for network segmentation, jump box, and basic monitoring.
ROI question: “Would you pay ₹5 lakhs to prevent a potential ₹30 lakh loss?”
The answer becomes obvious when framed this way.
Use Cyber Insurance as ROI Justification
Contact your cyber insurance broker and ask: “If we implement network segmentation, asset inventory, and access controls, how much would our premium decrease?”
Many insurers offer 10-20% premium reductions for documented OT security controls. If your annual premium is ₹8 lakhs, that’s ₹80,000-1.6 lakhs in savings annually. A ₹5 lakh security investment pays for itself in 3-6 years through insurance savings alone—before counting the value of prevented downtime.
Show Progress with Free Measures
Before asking for budget, implement everything from the “Free Security Wins” section above. Then present:
“Here’s what we accomplished with zero budget:
- Documented all 47 OT assets (we didn’t know we had that many)
- Locked control cabinets and implemented USB policy
- Changed default passwords on all accessible devices
- Created incident response plan
Here’s what we can’t do without budget:
- Separate IT and OT networks (requires VLAN configuration time and potentially new firewall)
- Monitor for threats (needs logging infrastructure)
- Control vendor access properly (need jump box setup)”
This shows you’re serious and have already done the groundwork—you’re just asking for resources to complete the job properly.
Template One-Pager for Your Business Case:
Title: Protecting Production: OT Security Investment Proposal
Problem: Our production systems can currently be compromised by threats originating from office computers, vendor access, or USB devices. A 3-day outage would cost ₹[X] in lost revenue.
Proposed Solution: Implement network segmentation, access controls, and monitoring for ₹[Y].
Benefits:
- Reduce downtime risk by [Z%]
- Lower cyber insurance premium by ₹[Amount]/year
- Meet customer audit requirements for [Specific Customer]
- Protect ₹[Equipment Value] in production assets
Timeline: 3 months to full implementation.
Return on Investment: Pays for itself in [N] years through insurance savings alone, plus avoidance of potential ₹[X] downtime costs.
Adapt these numbers to your specific situation and you’ll have a compelling case that speaks the language of business, not just IT security.
Frequently Asked Questions
“Can I just air-gap everything and call it a day?”
Short answer: Not practically, unless you’re willing to give up remote monitoring, data analytics, predictive maintenance, and most of the digital transformation initiatives your leadership wants.
The reality of air-gapping: True air-gapping means absolutely zero network connectivity to the outside world—no WiFi, no internet, no connection to your office network, no remote vendor access. Ever.
This requires military-grade discipline that most SMBs simply can’t maintain:
- No USB drives can move between air-gapped and internet-connected systems. This means your engineering team can’t download a PLC program update from the vendor’s website and load it via USB—the most common way firmware updates happen.
- No contractor laptops. When your equipment vendor comes for maintenance, they can’t plug their laptop into your network. They’d need to use a dedicated, air-gapped company laptop that’s never been outside your facility.
- No data exports. That production efficiency dashboard your CEO wants? It can’t pull data from air-gapped systems. Someone would need to manually transcribe data or use one-way data diodes (₹1.5+ lakhs per device).
- No remote troubleshooting. Machine breaks at 3 AM? The vendor can’t dial in remotely. You’re waiting until morning when someone can drive to your facility.
Why this fails in practice: Even organizations with strict air-gap policies violate them constantly. Colonial Pipeline had an “air-gapped” OT network—ransomware still spread because operational needs created connectivity. USB drives for updates, contractor laptops for troubleshooting, and one forgotten network cable bridging IT and OT erode the air gap until it doesn’t exist.
Better approach: Assume the air gap will eventually be breached (intentionally or accidentally) and build security in layers:
- Network segmentation with strict firewall rules (VLAN isolation)
- Jump boxes for any necessary remote access
- Monitoring to detect when something crosses boundaries it shouldn’t
- USB device controls and policies
This “assume breach” mindset is more realistic than hoping perfect isolation can be maintained forever.
“Do I need to upgrade Windows XP systems?”
Short answer: Not necessarily. Focus on isolating them first. If they’re properly segmented and you monitor their traffic, Windows XP systems can run safely for years.
Why upgrading isn’t always the answer:
Many equipment vendors explicitly prohibit OS upgrades. Your Windows XP machine might be running proprietary control software that’s only certified for that specific OS version. Upgrading to Windows 10 could:
- Void your equipment warranty (often worth more than the cost of potential security incidents)
- Break the control software entirely (driver incompatibilities, timing changes)
- Cost ₹5-15 lakhs for vendor re-certification and testing
When isolation is enough:
If your Windows XP machine:
- Sits on a segmented OT VLAN with no direct internet access
- Can only communicate with the specific SCADA server it needs (firewall rules enforce this)
- Is monitored for unusual network activity
- Has physical access controls (locked cabinet, limited USB access)
…then it’s arguably safer than a patched Windows 10 machine sitting on a flat network with unrestricted access.
When upgrade IS necessary:
- Your vendor is willing to certify and support a newer OS at reasonable cost
- Compliance requirements explicitly forbid unsupported operating systems (some pharmaceutical and defense industry standards do this)
- The equipment is reaching end-of-life anyway and replacement makes business sense
- You can’t adequately segment the system for operational reasons
Practical decision framework:
- Can we isolate this system? (If yes, do that first)
- Does the vendor support OS upgrades? (If no, isolation is your only option)
- What’s the cost of upgrade vs. cost of compensating controls? (Segmentation is usually cheaper)
“Should I tell my cyber insurance about our legacy systems?”
Yes. Always disclose them. Hiding legacy systems from your insurance carrier is worse than not having insurance at all.
Why hiding them backfires:
If you have a security incident and your insurer discovers you failed to disclose Windows XP systems or unpatched PLCs on your network, they can:
- Deny your claim entirely (you misrepresented your environment)
- Reduce payout significantly
- Cancel your policy retroactively in some cases
You gain nothing by hiding legacy systems and risk losing everything when you need the insurance most.
What insurers actually care about:
Insurance carriers aren’t looking for perfect security—they’re assessing whether you’re managing risk responsibly. They care about:
- Asset inventory: Do you know what you have? (They want to see your spreadsheet)
- Segmentation: Are vulnerable systems isolated from IT networks and the internet?
- Access control: Who can reach these systems and how is that access managed?
- Incident response plan: If something goes wrong, do you have a documented procedure?
- Monitoring: Do you have visibility into abnormal behavior?
Notice what’s NOT on that list: “Every system must be patched and running current OS.”
How to present legacy systems in applications:
When the questionnaire asks “Do you have unsupported operating systems in your environment?” answer truthfully, then explain your compensating controls:
“Yes, we operate Windows XP systems as part of production equipment. These systems are:
- Segregated on dedicated OT VLAN with no internet access
- Protected by firewall rules restricting traffic to essential systems only
- Monitored for unusual network activity
- Subject to physical access controls and USB device policies
- Documented in our asset inventory with assigned risk ratings”
This shows you’re not ignoring the risk—you’re actively managing it within the constraints of brownfield manufacturing.
Insurance premium impact:
Expect questions and possibly slightly higher premiums if you have significant legacy infrastructure. However, demonstrating strong compensating controls often offsets this. Some manufacturers see premium reductions even with legacy systems because they’ve implemented better overall security practices than competitors running newer equipment with poor controls.
“What’s the difference between IT SOC and OT SOC?”
Key philosophical difference: availability vs. confidentiality.
IT Security Operations Center (SOC) follows the traditional “CIA Triad” priority order:
- Confidentiality (protect sensitive data from unauthorized access)
- Integrity (ensure data isn’t tampered with)
- Availability (keep systems running)
If an IT SOC sees suspicious activity on a file server at 2 AM, they can isolate it immediately, reboot it, or take it offline for investigation. A few users might be inconvenienced, but no revenue is lost.
OT Security Operations Center (SOC) inverts this priority:
- Availability (keep production running—downtime costs thousands per hour)
- Integrity (ensure control commands and sensor data are accurate)
- Confidentiality (protect intellectual property, but not at the expense of uptime)
If an OT SOC sees suspicious activity on a PLC controlling a production line at 2 AM, they can’t just reboot it. They need to:
- Understand if this is a cyber incident or normal operational behavior
- Coordinate with the operations team before taking any action
- Plan remediation during the next scheduled maintenance window if possible
Other critical differences:
Protocol understanding: OT SOC analysts understand Modbus, DNP3, EtherNet/IP, and PROFINET. They know that a “read coil” command is normal but 500 “write register” commands in 10 seconds is suspicious. IT SOC analysts looking at the same traffic might miss the threat entirely because they don’t understand the context.
Operational awareness: OT SOC knows that a PLC reboot at 6 AM Monday during shift changeover is normal (maintenance window). The same reboot at 2 PM Wednesday is suspicious. IT SOC wouldn’t know the difference.
Risk tolerance: IT SOC operates on “when in doubt, block it.” OT SOC operates on “when in doubt, monitor it and plan intervention during downtime.” Stopping production to investigate a potential false alarm is often worse than the security risk itself.
For SMBs: Do you need a dedicated OT SOC?
Probably not. A dedicated 24/7 OT SOC costs millions annually—viable for critical infrastructure and large manufacturers, not for most SMBs.
What SMBs actually need:
- OT-aware monitoring rules configured by someone who understands both IT security and production operations
- Clear escalation procedures that involve both IT and operations teams
- Defined decision-making authority for who can take actions that might affect production
- Potentially: OT-focused MDR service (Managed Detection & Response) where external experts monitor your environment using OT-specific tools and expertise—typically ₹5-15 lakhs annually for SMB scale
Practical implementation:
If you have an IT person handling security, train them on OT differences or pair them with someone from operations who understands production rhythms. Create a simple matrix:
| Alert Type | Response During Production Hours | Response During Downtime |
|---|---|---|
| New device detected | Monitor, notify operations | Investigate immediately |
| Failed login attempts | Alert after 5+ failures | Alert after 3+ failures |
| Unusual traffic pattern | Log and review daily | Investigate within 1 hour |
This gives you OT-appropriate security response without building a dedicated SOC.
The key insight: OT security is about protecting production availability first, detecting threats second. Any monitoring or response that prioritizes security over uptime will fail in a manufacturing environment.
Conclusion: Start Where You Are
You don’t need to replace your legacy systems to secure them—you need to fence them in with compensating controls. Start with visibility (asset inventory, network map), then segmentation, then monitoring. “Good enough” OT security for SMBs is achievable with Tier 1 and Tier 2 controls for ₹0–5 lakhs over 12 months.
The biggest risk isn’t sophisticated nation-state hackers—it’s unnecessary connectivity and unrestricted vendor access. Fix those first.
Your next steps this week:
- Block out 2 hours to run a passive network scan using Wireshark or NetworkMiner
- Download a simple asset inventory template (search “OT asset inventory template” or create a spreadsheet with columns: Device Name, IP Address, Vendor, OS/Firmware, Criticality)
- Schedule 30 minutes with your Operations lead to walk the plant floor and identify which systems are truly critical
Final thought: Your legacy equipment isn’t the problem—treating it like modern IT is. Protect it on its own terms.
Additional Resources
Standards and Frameworks:
- IEC 62443 Simplified Guide – CISA’s free resource explaining the standard for non-experts: https://www.cisa.gov/ics (search for “IEC 62443 Quick Start Guide”)
- NIST Cybersecurity Framework for OT – Practical guidance for manufacturers: https://www.nist.gov/cyberframework
Free Tools:
- Wireshark – Network protocol analyzer for passive monitoring: https://www.wireshark.org
- NetworkMiner – Passive network discovery tool: https://www.netresec.com/?page=NetworkMiner
- pfSense – Open-source firewall platform: https://www.pfsense.org
- Graylog – Log management and analysis: https://www.graylog.org
Training and Education:
- CISA ICS Security Training – Free courses on industrial cybersecurity: https://www.cisa.gov/industrial-control-systems-training
- SANS ICS Security Webcasts – Free archived presentations from security experts: https://www.sans.org/webcasts (filter by “ICS/SCADA”)
India-Specific Resources:
- CERT-In Guidelines – Indian Computer Emergency Response Team’s industrial security advisories: https://www.cert-in.org.in
- National Critical Information Infrastructure Protection Centre (NCIIPC) – Guidelines for critical infrastructure protection: https://nciipc.gov.in
Community and Support:
- ICS-CERT Alerts – Subscribe to receive notifications of new OT vulnerabilities: https://www.cisa.gov/uscert/ics
- r/ICS subreddit – Active community discussing industrial control system security (Reddit)
Start with the CISA resources and free tools, implement your 90-day roadmap, and revisit these resources as you progress. You don’t need to consume everything at once—bookmark this list and return to it as specific questions arise.
The goal isn’t to become an OT security expert overnight. It’s to build sustainable security practices that protect your production without disrupting it. Start small, document what you do, and improve incrementally. That’s how successful brownfield OT security gets built.