Scope
This guide focuses on handling security vulnerabilities in legacy industrial control systems and building automation devices that can't be fixed with software updates. Many organizations use equipment that predates modern security standards and will continue to do so for years. You'll find practical guidance on implementing compensating controls, integrating physical security, and using risk acceptance frameworks. This isn't about theoretical solutions; it's about actionable steps when no patch is forthcoming.
Key Concepts and Definitions
Unpatchable vulnerability: A security flaw that can't be fixed with software updates due to hardware limits, end-of-life status, or design constraints.
Compensating control: An alternative security measure used when the primary control can't be applied. Under frameworks like ISO/IEC 27001, document these in your Statement of Applicability.
Physical access requirement: A vulnerability that requires direct physical connection to exploit, not remote access. The ABB KNX Update Tool vulnerability (CVE-2026-12705, CVSS 6.4) is an example, needing physical access to the KNX bus.
Defense-in-depth: Layered security controls ensure that if one fails, it doesn't lead to a complete compromise. This is crucial for legacy systems where vulnerabilities can't be eliminated.
Requirements Breakdown
Managing Unpatchable Systems
Risk assessment obligations: Under NIST SP 800-53 control RA-3, assess risk from identified vulnerabilities. For unpatchable systems, document why remediation isn't feasible and the residual risk.
Compensating control documentation: If subject to SOC 2 Type II audits, auditors expect to see how you're addressing vulnerabilities. You can't just mark them as accepted; demonstrate alternative controls.
Physical security integration: ANSI/ISA-62443 requires physical protection of control system components. When a vulnerability requires physical access, your physical security program becomes a cybersecurity control.
Change management: NIST Cybersecurity Framework 2.0 function PR.IP-3 requires configuration change control processes. For legacy systems, this means preventing unauthorized physical access that could enable exploitation.
Regulatory Considerations
CISA's recommended practices for industrial control systems address situations where patching isn't possible. Their guidance focuses on network segmentation, access control, and monitoring.
If you're in critical infrastructure sectors covered by specific regulations, document your compensating controls in your cybersecurity plan. Regulators know legacy systems exist; they want to see you've considered the risk.
Implementation Guidance
Step 1: Inventory and Classify
Document every legacy device that can't receive security updates. For each:
- Record the specific vulnerability (CVE number, CVSS score)
- Note whether physical access is required for exploitation
- Identify the system's criticality to operations
- Determine what data the system can access
Step 2: Apply Network Segmentation
Place unpatchable devices on isolated network segments. Under Zero Trust Architecture principles, create explicit trust boundaries.
Configure your network so:
- Legacy devices can't initiate connections to business networks
- Access requires authentication at the segment boundary
- Log all connection attempts to the isolated segment
Step 3: Strengthen Physical Controls
When the vulnerability requires physical access, like the ABB KNX Update Tool issue, your physical security program is your primary control.
Implement:
- Restricted access to equipment rooms housing vulnerable devices
- Badge reader logs showing who accessed the space and when
- Video surveillance of areas where physical bus access is possible
- Tamper-evident seals on equipment enclosures
Document these controls in your risk register as compensating measures. Auditors need to see the logical connection between the vulnerability and your physical security response.
Step 4: Monitor for Exploitation Indicators
You can't patch the vulnerability, but you can detect exploitation attempts.
Set up monitoring for:
- Unexpected configuration changes on legacy devices
- Physical access events outside normal maintenance windows
- Network traffic patterns inconsistent with device function
- Firmware version changes (could indicate unauthorized updates)
Step 5: Plan the Migration Path
Even if you can't replace the system today, document when you will. Include:
- Budget requirements for replacement equipment
- Timeline tied to equipment lifecycle
- Security standards the replacement must meet
- Interim controls that remain in place until migration
Common Pitfalls
Treating risk acceptance as a permanent solution: Accept risk temporarily, but your risk register should include a remediation timeline. "We'll replace this when it fails" isn't a timeline.
Ignoring physical-cyber security integration: If your physical security team doesn't know why access to a particular equipment room is a cybersecurity control, there's a gap in your defense-in-depth strategy.
Failing to test compensating controls: You can't test whether the vulnerability is exploitable, but you can test whether your monitoring would detect exploitation. Run tabletop exercises to verify your detection works.
Overlooking vendor lifecycle policies: The ABB advisory states no corrective measures are planned. When evaluating new systems, ask vendors about their security update policies for the expected equipment lifespan.
Assuming air-gapped means secure: Physical access vulnerabilities matter even in air-gapped environments. Contractors, maintenance personnel, and malicious insiders all have physical access.
Quick Reference Table
| Vulnerability Characteristic | Primary Compensating Control | Supporting Controls | Documentation Requirement |
|---|---|---|---|
| Requires physical access to bus/device | Restricted physical access with logging | Video surveillance, tamper seals, escort requirements | Physical access logs tied to risk register |
| Firmware integrity missing | Configuration baseline monitoring | Change control process, integrity verification tools | Baseline documentation, change tickets |
| Authentication weakness | Network segmentation | Firewall rules, VPN requirements | Network diagram showing isolation |
| Encryption not supported | Physical layer security | Locked cabinets, conduit protection | Physical security assessment |
| Remote code execution possible | Air-gap or strict firewall rules | Application allowlisting, monitoring | Network architecture documentation |
For risk acceptance documentation, include:
- CVE number and CVSS score
- Business justification for continued operation
- Compensating controls implemented
- Monitoring mechanisms
- Planned remediation date
- Approval from appropriate risk owner (typically needs to be senior leadership for CVSS 6.0+)
This isn't about achieving perfect security with unpatchable systems. It's about demonstrating you understand the risk, you've implemented reasonable alternatives, and you're working toward a solution. When your auditor or regulator reviews your program, they're looking for that documented thought process.
