Insecure-by-design – Many SCADA components and protocols (e.g., MODBUS, DNP3, ICCP) were created decades ago for reliability, not security.

No built-in encryption/authentication – Control commands and telemetry data are often sent in plaintext.

Vulnerable to replay and spoofing attacks – Lack of session management or freshness checks allows old commands to be resent.

Outdated hardware/software – SCADA devices may run 10–20+ years without major upgrades.

Unpatched vulnerabilities – Applying updates can require system downtime, so security patches are delayed or skipped.

Vendor end-of-support – Legacy hardware may not receive fixes, forcing continued use of insecure systems.

Default or shared passwords – Still common in SCADA deployments.

No role-based access – Once connected, users often have unrestricted control.

Unsecured remote access – Vendor maintenance connections, VPNs, or RDP sessions may be exposed or poorly secured.

Flat networks – Little or no segmentation between SCADA, IT, and field device networks.

No demilitarized zone (DMZ) – Direct connections between enterprise and control networks increase risk of lateral movement.

Weak perimeter defenses – Firewalls and intrusion detection tuned for IT traffic may not detect OT-specific threats.

Limited logging capability – SCADA systems often lack detailed audit trails for commands and changes.

No centralized monitoring – SCADA events may not integrate with SIEM solutions, delaying detection of breaches.

Few OT-specific intrusion detection systems – Many organizations rely on IT IDS/IPS that do not understand SCADA protocols.

Increased IT/OT convergence – SCADA often shares connectivity with corporate networks for data analytics, increasing attack surface.

Third-party/vendor connections – Support access can bypass standard security controls.

Cloud-based SCADA services – If not configured securely, cloud-hosted SCADA increases exposure to the internet.

Operator focus on uptime over security – Production continuity often overrides patching or access hardening.

Lack of OT-specific cybersecurity training – Operators may be unaware of cyber risks unique to control systems.

Misconfigurations – Incorrect firewall rules, open ports, and weak password policies are common.

Unprotected field devices – Remote terminal units (RTUs), programmable logic controllers (PLCs), and sensors may be in unsecured locations.

On-site access – Physical access to SCADA hardware often means full control of processes.

No encryption – MODBUS transmits all data in plain text, making it easy for attackers to intercept and read commands or process data.

No authentication – Any device that can access the network can send valid-looking MODBUS commands, allowing unauthorized control.

Vulnerable to spoofing & replay attacks – Since there’s no built-in session or challenge–response mechanism, attackers can resend previous messages to trigger actions.

Minimal error checking – Only a CRC or LRC checksum is provided, which detects transmission errors but does not protect against malicious modification.

No recovery mechanism – If packets are lost or corrupted, MODBUS relies entirely on the application layer to retry.

Susceptible to noise in electrically noisy industrial environments, especially in serial (RS-485/RS-232) versions.

Single master–multiple slave model (in traditional MODBUS RTU/ASCII) limits concurrency—slaves can only respond when the master polls them.

Limited data throughput – Not suitable for high-speed or large-volume data applications.

Inefficient polling – Master must poll each device individually, which increases latency in large systems.

Small address space – Classic MODBUS supports only 247 slave addresses, and register addressing is fixed to 16-bit registers.

Rigid data types – No native support for complex data structures; everything must be packed into registers manually.

No device discovery – Devices must be manually configured with known addresses.

Vendor variations – While MODBUS is an open standard, different vendors may implement function codes or data mapping differently, requiring custom integration.

Legacy dependency – Designed for older, simpler devices; adapting to modern IIoT requirements often requires gateways or protocol converters.

Not ideal for large distributed systems without segmentation or hierarchy.

TCP/IP version (MODBUS TCP) improves network integration but still inherits many of the protocol’s original limitations.

An attacker gains network access (e.g., by connecting to a plant’s maintenance port or over an insecure remote VPN).

They send valid MODBUS commands (like Write Single Register or Force Coil) to change actuator positions, open valves, or stop pumps.

Since there’s no authentication, the slave device executes them without question.

Production downtime.

Equipment damage.

Safety hazards in critical infrastructure (e.g., water treatment, power distribution).

The attacker positions themselves between the master and slave (physically or via network compromise).

They intercept MODBUS packets, altering sensor values before passing them along.

Operators in the control room see fake “normal” readings while the real process runs out of safe parameters.

Operators make decisions based on false data.

Hidden process failures lead to safety incidents or sabotage.

An attacker records legitimate MODBUS messages (e.g., “Start conveyor belt” or “Shut down motor”).

Later, they replay the exact same message to repeat the action.

The system accepts it because there’s no way to distinguish between old and new commands.

Process disruption without detection.

May trigger unsafe or destructive actions during critical phases.

An attacker floods a device with continuous MODBUS requests or invalid function codes.

The device becomes unresponsive to legitimate commands from the master.

Loss of control of one or more devices.

Potential cascading failures if critical processes rely on real-time responses.

Attacker writes to configuration registers that define calibration, setpoints, or operational modes.

Process starts running under wrong parameters, potentially causing physical damage or quality defects.

Long-term process degradation.

Financial losses due to rework, product recall, or equipment wear.

Attacker passively listens to MODBUS traffic over days/weeks.

They map which registers control what, building a blueprint of the industrial process.

Enables targeted attacks later.

Provides intelligence for insiders or nation-state attackers planning coordinated sabotage.

Default or weak passwords – Many PLCs ship with factory credentials that are never changed, making them easy to compromise.

Lack of authentication/encryption – Legacy PLCs often accept commands over protocols like MODBUS, EtherNet/IP, or PROFINET without verifying the sender or encrypting traffic.

Vulnerable firmware updates – Some PLCs accept firmware without signature verification, allowing malicious updates.

Remote access risks – Exposed PLCs on public networks (often via insecure remote maintenance) can be scanned and attacked using tools like Shodan.

Vendor-specific exploits – PLCs often have proprietary protocols with undocumented flaws that attackers can reverse-engineer.

Susceptibility to power surges and EMI – Electrical noise or spikes can cause logic faults or damage components.

Limited temperature/humidity tolerance – Extreme industrial conditions can accelerate hardware degradation.

Lack of tamper resistance – Physical access often allows direct connection to programming ports, bypassing network security.

Single point of failure – In many systems, one PLC controls critical processes; if it fails, the process stops.

Limited redundancy – Unless designed into the system, PLCs may lack failover controllers.

Proprietary lock-in – Vendor-specific hardware and software make replacement or upgrades costly and complex.

Firmware/software bugs – PLCs run specialized firmware, but like any software, they can contain exploitable or disruptive bugs.

Insecure industrial protocols – Protocols like MODBUS, DNP3, and others used by PLCs often have no built-in security.

No logging/auditing – Many PLCs lack detailed event logs, making it hard to detect intrusions or diagnose failures.

Broadcast and multicast abuse – Some industrial networks allow attackers to cause load spikes with unnecessary traffic.

Long operational lifespans – PLCs are often in service for decades without security updates, creating “insecure by design” environments.

Patch management gaps – Applying firmware updates may require shutting down production, so security patches are often delayed or skipped.

Legacy OS dependencies – Engineering software may require outdated Windows versions, adding vulnerabilities.

Inadequate security training for engineers – PLC programmers often focus on process logic and safety, not cybersecurity.

Over-reliance on “air-gapping” – Assumes isolation from the internet provides safety, even though USB drives, laptops, and remote connections bridge that gap.

Misconfigurations – Incorrect access control lists, open debug ports, and unprotected ladder logic downloads are common.

Legacy origins – Many OT protocols (MODBUS, DNP3, PROFINET, EtherNet/IP) were designed decades ago for reliability, not security.

No built-in encryption or authentication – Communications often rely on trust within an “air-gapped” environment.

Flat networks – Lack of segmentation means that a compromise in one part of the OT network can spread quickly.

Outdated hardware – OT devices often run 10–30 years without major upgrades, making them incompatible with modern security measures.

Unpatchable systems – Applying firmware or OS updates can require costly downtime, so many vulnerabilities remain unpatched for years.

Vendor end-of-support – Legacy systems may no longer receive updates or parts, forcing continued use of insecure components.

Default credentials – Many devices still operate with factory-set usernames/passwords.

No user-level permissions – Access control is often “all or nothing,” allowing full control once connected.

Physical port exposure – Serial ports, USB ports, or Ethernet jacks can allow local attackers to inject commands.

Plaintext data transmission – Exposes sensitive process data and credentials to interception.

No message integrity checks – Allows modification of commands/data in transit without detection.

Susceptibility to replay and spoofing – No session verification mechanisms in most OT protocols.

Minimal event logging – OT devices often have limited storage and processing, so security events go unrecorded.

No centralized SIEM integration – OT logs aren’t usually correlated with IT systems, leading to missed early warning signs.

Limited intrusion detection – Many plants still lack specialized OT-aware IDS/IPS systems.

Operator focus on uptime, not security – Production continuity is prioritized over patching or hardening.

Limited cybersecurity training – OT engineers may be unfamiliar with IT security practices.

Over-reliance on “air-gapping” – Assumes isolation, even though USB drives, laptops, and remote support often bridge the gap.

Converged IT/OT networks – Increases the attack surface by exposing OT to internet-connected IT systems.

Remote access exposure – Unsecured VPNs, RDP, or vendor maintenance links can be exploited.

Shadow IT/OT – Untracked wireless devices or sensors may connect to the OT network without proper vetting.

Unprotected installations – Field devices may be in accessible locations, vulnerable to tampering.

Environmental hazards – Power surges, temperature extremes, and EMI can cause disruptions or failures.

Weak default credentials – Many IoT devices ship with easy-to-guess or universal passwords.

Lack of authentication and encryption – Some devices transmit control commands and data in plaintext.

Hardcoded credentials – Embedded usernames/passwords in firmware that cannot be changed.

Vulnerable firmware – No secure boot or signature verification, allowing malicious firmware uploads.

No update mechanism – Many low-cost IoT devices cannot receive firmware updates at all.

Delayed patches – Vendor patches arrive late, if at all, leaving devices exposed to known exploits.

Manual update requirements – Updates require physical access, impractical for large-scale deployments.

Unsecured data collection – Personal or operational data sent over unencrypted channels.

Cloud dependency – Sensitive data stored in third-party cloud services with unclear security practices.

Over-collection of data – Devices gather more data than necessary, increasing breach impact.

No role-based access control – All users or apps have full control once connected.

Unauthenticated APIs – Open web or mobile APIs can be abused if not secured.

Exposed management interfaces – Web dashboards or admin panels accessible over the public internet.

Plaintext protocols – Use of MQTT, CoAP, or HTTP without TLS.

No integrity checks – Data can be altered in transit without detection.

Replay/spoofing risks – Lack of session tokens or timestamps allows old commands to be resent.

Large attack surface – More devices means more potential entry points.

Device heterogeneity – Mixed-vendor environments complicate patching and monitoring.

Abandoned products – Vendors may stop supporting devices long before their operational life ends.

Tamper vulnerability – Devices in public or unprotected areas can be physically accessed or stolen.

Hardware reverse engineering – Attackers can extract firmware and secrets from flash memory or debug ports.

Poor security awareness – Users rarely change defaults or enable advanced security features.

Shadow IoT – Unauthorized devices added to a network without IT/security oversight.

Misconfiguration – Incorrect firewall rules, open ports, or disabled security settings.