9. Industrial Control Systems

9.1 ICS Overview

9.1.1 What is ICS?

Industrial Control Systems (ICS) are foundational components of Operational Technology (OT) environments, designed to control and automate critical physical processes in sectors such as manufacturing, energy, water treatment, transportation, and chemical production. ICS typically include systems such as Supervisory Control and Data Acquisition (SCADA), Distributed Control Systems (DCS), and stand-alone Programmable Logic Controllers (PLCs), working in coordination with Human-Machine Interfaces (HMIs) and field instrumentation.

9.1.2 What is ICS Used For?

In OT contexts, ICS are used to execute precise, real-time control over physical processes, ensuring safety, reliability, and efficiency in complex industrial operations. In Singapore, ICS deployments are found in refineries on Jurong Island, utilities managed by PUB and SP Group, semiconductor fabrication plants, and transport networks. ICS manage pump operations, power distribution, chemical mixing, temperature control, and emergency shutdowns. They often function autonomously for high availability and low latency and are increasingly integrated with remote management platforms, predictive maintenance systems, and enterprise data pipelines to support data-driven optimisation and compliance.

9.2 ICS Threats

9.2.1 What Are the Cyber Threats Associated with ICS?

Due to their direct control over critical infrastructure and integration with both OT and IT networks, ICS are prime targets for cyber threats. These systems often run on legacy platforms with limited security controls and vendor-specific protocols not designed with cybersecurity in mind. ICS are vulnerable to logic manipulation, protocol exploitation, firmware tampering, and unauthorised lateral movement. Adversaries may seek to disrupt physical operations, cause safety incidents, or exfiltrate sensitive production data. The potential consequences of an ICS compromise include large-scale outages, physical damage, regulatory violations, or long-term disruption of national critical infrastructure.**
**

Table 27: Cyber Threats Specific to ICS

9.3 ICS Controls

9.3.1 What are the associated countermeasures for addressing cyber threats associated with ICS?

The controls for Industrial Control Systems are tailored to protect both the cyber and physical integrity of industrial operations. These measures include validating control logic, securing engineering workstations, authenticating all communication across SCADA or DCS environments, and enforcing strict segmentation between IT and OT. Controls must account for constrained real-time performance, safety-critical functions, and long equipment life cycles. They are critical in plants where downtime carries high financial and safety consequences, such as oil refineries, pharmaceutical production, or national utilities. Additionally, defence-in-depth must be implemented across field devices, control networks, and centralised monitoring stations.

9.3.2 Vulnerability, Change, and Patch Management

Securing an Industrial Automation and Control System (IACS) against evolving cyber threats requires three complementary disciplines working in concert: Vulnerability Management, Change Management, and Patch Management. These disciplines operate at different levels of the organisation and address different aspects of risk, but they share a common objective of preserving the confidentiality, integrity, availability, and safety of industrial operations.

Vulnerability Management provides the governance layer. It establishes how the organisation identifies, assesses, prioritises, treats, and tracks vulnerabilities across the IACS environment. It determines which risks are addressed, in what order, and by what means. Change Management provides the operational discipline. It governs how any modification to the IACS, whether a patch, firmware upgrade, configuration change, or hardware replacement, is planned, authorised, executed, and verified safely. Patch Management is the tactical execution of patch deployment. It operates under the governance of Vulnerability Management and within the controls of Change Management.

Together, these three disciplines ensure that cybersecurity risk is addressed deliberately, safely, and in a manner proportionate to the operational realities of IACS environments. The following sub-sections detail the controls expected under each discipline.

9.3.2.1 Vulnerability Management

Vulnerability Management is the governance programme that provides the overarching framework for identifying, assessing, prioritising, treating, and tracking vulnerabilities across the OT environment. It sets the strategic direction under which patching, compensating controls, system isolation, and formal risk acceptance decisions are made.

In IACS environments, Vulnerability Management must contend with challenges that differ significantly from IT. Many OT systems run on legacy platforms with limited or no vendor support, cannot be patched without extended planned downtime, or operate under safety certifications and warranties that constrain modification. Patching is therefore often not the primary or only treatment available. A mature Vulnerability Management programme considers the full range of treatment options, including network segmentation, access restrictions, enhanced monitoring, virtual patching, and formal risk acceptance where no other treatment is feasible.

A well-implemented programme draws on authoritative threat intelligence sources, maintains a central vulnerability register, applies risk-based prioritisation, and reports performance metrics to leadership for oversight. It also establishes expedited pathways for actively exploited vulnerabilities, ensuring that critical risks are addressed with urgency even where standard operational windows would otherwise delay response.

The controls defined in Table 28 establish the foundation of a risk-based Vulnerability Management programme tailored to the operational and threat landscape of IACS. These controls govern how vulnerabilities are managed across all IACS components, including programmable logic controllers (PLCs), human-machine interfaces (HMIs), remote terminal units (RTUs), industrial gateways, embedded control units, and supporting OT infrastructure.

Table 28: List of Vulnerability Management Controls (to be developed in subsequent versions)

9.3.2.2 Change Management

Change Management is the operational discipline that governs the structured planning, authorisation, execution, and verification of all changes made to the IACS. It applies to software updates, firmware upgrades, configuration modifications, hardware replacements, and the addition or removal of system components. In IACS environments, even seemingly minor changes can have significant consequences for process control, safety, and system availability, making disciplined change governance essential

A robust Change Management programme ensures that every change is justified, assessed for impact, properly authorised, and executed in a controlled manner. It provides traceability through comprehensive change records, enables safe rollback where issues arise, and preserves the integrity of safety and operational baselines. Unlike IT environments, where changes may be relatively routine, OT changes often require coordination with planned maintenance windows, safety recertification, and vendor involvement, further elevating the importance of a structured approach.

Change Management also underpins the safe execution of Vulnerability Management treatments and Patch Management activities. Without a formal change process, patches may be applied inconsistently, vulnerabilities may be remediated without validation, and unauthorised modifications may go undetected, each creating latent risk to the IACS environment.

The controls defined in Table 29 establish the foundation of a Change Management programme tailored to the operational, safety, and regulatory requirements of IACS. These controls apply to all changes affecting IACS components and are invoked whenever a Vulnerability Management treatment or Patch Management deployment is undertaken.

Table 29: List of Change Management Controls (to be developed in subsequent versions)

9.3.2.3 Patch Management

Patch Management is the tactical execution of patch deployment within the IACS. It involves the systematic identification, testing, deployment, and validation of software updates — commonly known as “patches” — across all updatable devices. Patches address known vulnerabilities, correct operational flaws, and introduce security enhancements that preserve the confidentiality, integrity, and availability of industrial components.

In IACS environments, Patch Management plays a vital role in reducing exposure to cyber threats, minimising disruptions caused by unpatched systems, and ensuring compliance with industry regulations and supplier-approved practices. However, patching in these contexts must be approached with heightened caution due to the potential operational risks posed by software changes to critical infrastructure.

Patch Management operates under the governance of the Vulnerability Management programme, which prioritises which vulnerabilities warrant patching, and within the controls of the Change Management process, which ensures each patch deployment is authorised, tested, rollback-ready, and recorded. This necessitates a structured, risk-based patching process that accounts for system constraints, supplier compatibility, and organisational cybersecurity policies. A well-implemented Patch Management strategy strengthens the resilience of industrial systems by enabling timely responses to emerging vulnerabilities, while also maintaining system stability and safety.

The controls defined in Table 30 establish the foundation of a robust Patch Management programme tailored to the operational and regulatory requirements of IACS. These controls apply to all updatable components, including programmable logic controllers (PLCs), human-machine interfaces (HMIs), remote terminal units (RTUs), industrial gateways, embedded control units, and supporting OT infrastructure, particularly in sectors such as energy, manufacturing, transportation and utilities where patch cadence and lifecycle transparency are critical.

Table 30: List of Patch Management Controls

PM/C1 Establish and maintain an inventory of updatable electronic devices within IACS

About This Control: An inventory of all updatable electronic devices within the Industrial Automation and Control System (IACS) environment, particularly those that can undergo changes to their functionality, configuration, operation, software, firmware, or operating code.

Purpose: To ensure visibility and accountability over all updatable devices that may introduce risk through software vulnerabilities or configuration changes. A regularly updated inventory supports secure change management, facilitates timely patching, and reduces exploitable entry points across critical infrastructure. It also enhances incident response capabilities and helps meet compliance requirements related to system integrity, availability, and cybersecurity resilience.

Implementation Guidance: To establish an inventory, begin by identifying all electronic devices within the OT environment that are capable of being updated. Each device should be assigned a unique identifier, and relevant metadata — such as device function, location, version numbers of firmware and software, current operational status, and owner or custodian information — should be recorded. All configuration and software changes must be logged with time-stamped version histories to ensure full traceability. The inventory must be reviewed and reconciled at least quarterly, or more frequently following maintenance activities, change requests or security patch deployments, to ensure ongoing accuracy and risk awareness. Automated discovery and monitoring tools should be integrated into environments where network architecture, asset visibility and resource availability permit, in order to reduce manual error and improve real-time situational awareness.

Intrinsic Limitations: While this process is essential, several limitations must be acknowledged. In rapidly evolving OT environments, inventory data can quickly become outdated if updates are not promptly recorded. Legacy or proprietary systems may not support sufficient access to internal configuration or version data, which can limit monitoring effectiveness. Additionally, environments with mixed-vendor infrastructure often face interoperability challenges that hinder standardised inventory practices. Where manual processes are heavily relied upon, human error and oversight can lead to gaps in documentation unless stringent controls are enforced.

Impact: Failure to maintain accurate records of installed versions may result in blind spots across the IACS environment, making it difficult to identify vulnerable devices during a cybersecurity incident. Inaccurate or outdated records could lead to version mismatches, deployment of incorrect updates, or delays in patch response. This lack of visibility may also undermine incident investigation efforts and hinder regulatory audits or compliance assessments.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

PM/C2 Establish and maintain a record of installed versions for updatable devices within IACS

About This Control: A maintained record of the currently installed software, firmware, or configuration version for each updatable device within the Industrial Automation and Control System (IACS) environment. This “installed version” reflects the device’s exact operational state at a given point in time.

Purpose: To ensure traceability of all updates applied to operational technology assets, support timely identification of outdated or vulnerable versions and enable consistent alignment with approved configuration baselines. It also serves as a reference point for troubleshooting, rollback, compliance audits and incident response.

Implementation Guidance: Record the installed version at the point of deployment or modification, and update the record immediately after any firmware, software, or configuration change is applied. Each entry should include the version identifier, the date of change, and the responsible personnel or system that performed the update. Automated tools should be leveraged to extract and verify version data in environments where network visibility, device capability and integration tooling allow. Reconcile version records with change logs and audit trails at least quarterly to maintain accuracy and detect any unauthorised or undocumented changes.

Intrinsic Limitations: Legacy or proprietary systems may not support automated extraction of version information, which can result in manual data entry and introduce human error. Disparities in version formatting across vendors can complicate standardisation. Additionally, decentralised update practices may lead to discrepancies between recorded and actual device states if proper controls are not enforced. Without tight integration between version tracking and change management processes, there is a risk of misalignment or incomplete visibility.

Impact: Failure to maintain accurate version records can result in undetected exposure to outdated or vulnerable software. This increases the risk of successful exploitation by threat actors, impairs incident response and root cause analysis, and may result in audit failures due to lack of documentation. Misalignment between records and actual device state may also lead to configuration drift and unintended operational disruptions.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

PM/C3 Establish a regular schedule to determine the latest available upgrades and updates for each updatable device

About This Control: A process for determining the latest available software, firmware, or configuration updates for each updatable device within the Industrial Automation and Control System (IACS). These “latest versions” are the most current releases provided by the original equipment manufacturer (OEM) or vendor.

Purpose: To maintain visibility over vendor-released patches, firmware, and software updates in order to assess whether deployed devices are current or require remediation. This enables proactive risk management, reduces exposure to known vulnerabilities, and ensures informed decision-making on when and how to apply critical updates. It also supports alignment with configuration baselines, regulatory compliance, and secure lifecycle management of OT assets.

Implementation Guidance: Establish a scheduled process to check vendor portals, security advisories, product bulletins, or support channels at least monthly for newly released updates applicable to your device inventory. Each device model and version should be matched against the latest available release. Update availability should be recorded in the centralised inventory system and linked to each corresponding asset. Automated tools or vendor APIs should be used in environments where network connectivity, system integration and vendor support allow. This information should be reviewed as part of vulnerability assessments, risk evaluations, and change control workflows to determine whether updates are necessary, urgent, or deferrable.

Intrinsic Limitations: This process depends heavily on the accessibility and transparency of vendor communications. Some vendors may delay publishing release notes, fail to notify users of updates, or retire product lines without clear update pathways. Manual tracking may become burdensome in environments with a large number of devices from diverse vendors. Additionally, determining applicability of updates may require technical evaluation to avoid unnecessary upgrades that may conflict with existing configurations or certifications. Without a clear mapping between device models and update channels, organisations risk missing critical updates or applying incompatible ones.

Impact: Failure to routinely identify the latest vendor-issued updates may result in devices operating with known vulnerabilities, leaving them exposed to exploitation. Lack of visibility into current patch availability can hinder risk-based decision-making, delay remediation efforts, and undermine system resilience and compliance.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

PM/C4 Establish a regular schedule to identify released versions approved by IACS suppliers and aligned with organisational standards

About This Control: A scheduled process to determine the released versions of upgrades and updates officially identified as compatible by the IACS product supplier and validated against the asset owner’s internal standards for deployment on updatable devices.

Purpose: To ensure that only trusted, supplier-validated, and organisation-approved updates are considered for deployment within the IACS environment. This reduces the risk of system instability, prevents the installation of untested or incompatible updates, and supports secure, compliant, and operationally sound industrial systems.

Implementation Guidance: Implement a process to review supplier-issued updates at least quarterly, aligned with patch management or maintenance cycles. This includes monitoring vendor websites, product bulletins, and compatibility matrices to identify released versions. Each identified version must be evaluated against internal acceptance criteria—such as technical interoperability, cybersecurity control compatibility, and operational risk. Only versions that pass both supplier and internal evaluations should be recorded in the asset inventory or version control system as authorised for deployment. These authorised versions should be referenced during change management reviews and maintained in the system of record for audit and traceability purposes.

Intrinsic Limitations: The process depends on timely and accurate communication from suppliers. Some vendors may fail to publish compatibility details, requiring internal testing to validate update applicability. In mixed-vendor environments, maintaining a complete cross-reference between supplier-approved versions and deployed configurations may require significant manual effort. Internal validation may be delayed due to limited resources or lack of a test environment. Without clear governance over internal standards, version approvals may be inconsistent across teams or sites.

Failure Scenarios and Associated Risk: Failure to track and validate vendor-approved released versions may result in the deployment of unsupported or unauthorised updates. This can lead to application errors, system instability, or failure to meet regulatory or safety requirements. In severe cases, applying incompatible updates without validation could cause operational downtime, equipment damage, or disablement of critical safety systems.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

PM/C5 Test patches in environments reflecting IACS production conditions

About This Control: Testing of IACS patches in a controlled environment that accurately reflects the production environment, to ensure that the reliability, functionality, and operability of the system are not negatively impacted before deployment. Patches that successfully pass these tests are designated as authorised for production.

Purpose: To safeguard the integrity and continuity of operational technology environments by ensuring that only validated and tested patches are applied. This prevents unintended disruptions, regressions, or failures resulting from untested updates. Testing also ensures that security patches do not interfere with the specific device interactions, industrial protocols, or configurations unique to OT systems.

Implementation Guidance: Maintain a dedicated staging or laboratory environment that mirrors the production setup as closely as possible — including hardware models, network architecture, communication protocols and system interdependencies. Each patch must be applied in this environment and tested for compatibility, operational stability, and cybersecurity behaviour. Validation steps should include functional testing, communication checks, performance monitoring and start-up/shutdown procedures. Only patches that pass all validation steps should be logged as authorised and queued for production deployment. The full test process, results, and authorisation status must be documented in a formal change management or patch management system. In environments where replicating production conditions is constrained by scale, safety, or infrastructure limitations, the highest-fidelity simulation possible should be used and additional safeguards (e.g., rollback readiness, close post-deployment monitoring) must be implemented.

Intrinsic Limitations: Even with rigorous testing, it may not be feasible to fully replicate all characteristics of live OT environments, especially for geographically distributed or high-availability systems with real-time operational demands. Vendors may release patches without adequate guidance, complicating validation efforts. Testing processes can be time- and resource-intensive, potentially delaying deployment of critical patches. Smaller organisations may lack sufficient infrastructure or personnel to maintain a test environment, resulting in inconsistent application of this control.

Impact: Deploying untested patches directly into production may introduce instability, break dependencies between systems, or cause unintended malfunctions. Without prior validation in a production-like environment, even minor updates can lead to cascading failures across critical control processes. The absence of testing also impairs root cause analysis when issues arise post-deployment, potentially resulting in prolonged downtime or safety incidents.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

PM/C6 Schedule authorised patches for timely installation within system and operational constraints

About This Control: A process to schedule the installation of authorised and validated patches at the earliest feasible opportunity, factoring in system design constraints such as redundancy, fault tolerance, and safety, alongside operational requirements like scheduled downtimes, unplanned outages, and live system conditions.

Purpose: To close the gap between patch authorisation and implementation by reducing the window of exposure to known vulnerabilities. By aligning patch deployment with operational realities and system design features, this control helps minimise security risks while avoiding disruptions to critical industrial processes.

Implementation Guidance: Integrate patch scheduling into existing change management and maintenance planning processes. Each authorised patch must be assessed to determine the most suitable deployment window based on device criticality, production cycles and system availability. Schedule patch deployment within 30 days of authorisation, unless risk assessments justify an exception. Updates should coincide with planned maintenance periods, production downtime, or staggered rollouts in redundant or hot-swappable environments to minimise disruption. All scheduled deployments must be approved by relevant operational and cybersecurity stakeholders, documented in a central patch management or configuration control system and tracked to completion.

Intrinsic Limitations: In 24/7 or high-availability environments, maintenance windows may be infrequent or heavily restricted, delaying patch application. Unplanned outages or urgent operational demands can also interfere with scheduled updates. Legacy or safety-certified systems may require additional testing or vendor validation prior to any software changes, adding to administrative delays. Without effective coordination between operations, engineering, and cybersecurity teams, patch scheduling may be inconsistent or misaligned with business risk priorities.

Impact: Failure to schedule and apply authorised patches in a timely manner increases the likelihood of continued exposure to known vulnerabilities, which may be actively exploited by threat actors. Prolonged delays in patching may compromise system integrity, lead to unauthorised access, or cause data loss and service interruptions. In the event of a security incident, unresolved patch delays can impair response and prolong system recovery, potentially violating regulatory expectations and undermining operational resilience.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

PM/C7 Maintain and update version records for all updatable devices at planned intervals

About This Control: A process for updating version records of installed, authorised, effective, and released versions for each updatable device within the Industrial Automation and Control System (IACS), ensuring accuracy and completeness of system configuration information.

Purpose: To provide a reliable and current reference for managing security posture, supporting incident response, and guiding patch planning and compliance reporting. Accurate version records allow stakeholders to assess risk exposure, validate system configurations, and make informed decisions during audits, maintenance and security events.

Implementation Guidance: Implement a formal review and reconciliation process to update version records at least quarterly, or more frequently based on operational risk. Use automated discovery tools or manual verification to collect version data from field devices, and reconcile it with information from patch authorisation workflows and vendor release notes. Record updates in a central system of record or configuration management database (CMDB), with metadata including change dates, status, and responsible personnel. Exception handling procedures must be applied for devices that cannot be updated due to technical limitations or operational constraints.

Intrinsic Limitations: Maintaining up-to-date version records can be challenging in environments with limited automation or poor system integration. Manual entry increases the likelihood of human error, and out-of-band changes may lead to undocumented discrepancies. Remote or legacy assets may lack sufficient visibility, making data collection inconsistent. Resource limitations in distributed environments may also delay quarterly reconciliation efforts.

Impact: Failure to update version records at planned intervals may result in inaccurate visibility of the OT security landscape. This can lead to delayed or missed patch deployments, unresolved vulnerabilities, and hindered incident response. Incomplete records may also compromise audit readiness and impede root cause analysis during investigations.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

PM/C8 Apply risk-based prioritisation for patch deployment

About This Control: A risk-based approach to prioritising patch deployment within the Industrial Automation and Control System (IACS) environment, replacing fixed-interval patching cycles with decisions driven by vulnerability exploitability, system criticality, and operational feasibility.

Purpose: To ensure that patching decisions in OT environments are informed by real-world risk rather than arbitrary schedules. Unlike IT, OT systems cannot be patched on fixed cycles due to operational constraints, safety considerations, vendor warranty implications, and the limited availability of planned maintenance windows. Risk-based prioritisation ensures that patching effort is directed at vulnerabilities most likely to cause harm, while lower-risk vulnerabilities may be deferred, mitigated through compensating controls, or formally accepted through the Vulnerability Management programme. This approach balances cybersecurity imperatives with operational continuity and safety.

Implementation Guidance: Each identified vulnerability must be assessed against a defined set of risk factors before a patching decision is made. These factors should include evidence of active exploitation in the wild (e.g. CISA Known Exploited Vulnerabilities catalogue, vendor threat advisories), severity scoring (CVSS or equivalent), criticality of the affected asset to the overall process, potential impact on process control, visibility, or safety functions, availability and maturity of compensating controls, and the operational feasibility of applying the patch within required timeframes. Each vulnerability should be assigned a priority tier (e.g. Critical, High, Medium, Low) with associated target treatment timelines. Critical and actively exploited vulnerabilities must trigger expedited treatment, including emergency change procedures invoked through the Change Management process where justified. Lower-tier vulnerabilities may follow standard change windows or be treated through compensating controls, with documented justification retained in the vulnerability register. The prioritisation framework must be reviewed at least annually or when significant threat landscape changes occur.

Intrinsic Limitations: Risk-based prioritisation depends heavily on the quality of available threat intelligence, asset criticality assessments, and operational context. Immature vulnerability intelligence feeds or incomplete asset inventories can lead to misprioritisation. Legacy systems that lack vendor support may have no patches available at all, requiring reliance on compensating controls that may themselves be imperfect. The approach also introduces subjectivity, as risk assessments involve judgment calls that may vary between assessors or over time. Finally, operational constraints such as rare maintenance windows, co-dependencies between systems, and the need for safety recertification can delay even high-priority patching decisions, requiring sustained use of compensating controls in the interim.

Impact: Failure to apply risk-based prioritisation can result in either over-patching, which disrupts stable operations and consumes limited maintenance capacity on low-value fixes, or under-patching, which leaves actively exploited vulnerabilities unaddressed in critical systems. Both outcomes degrade the overall security posture. Without a defensible prioritisation framework, patching decisions may also be difficult to justify during audits, incident reviews, or regulatory inquiries, exposing the organisation to compliance and reputational risk.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

PM/C9 Implement patches and/or compensating countermeasures to mitigate security vulnerabilities in the IACS

About This Control: A control to remediate security vulnerabilities affecting IACS components by applying vendor-issued patches or, when patching is not immediately feasible, implementing compensating controls that reduce risk to an acceptable level.

Purpose: To minimise exposure to cybersecurity threats arising from unpatched systems, insecure configurations, or known vulnerabilities within the IACS environment. This control enhances system resilience, reduces the likelihood of successful cyberattacks and demonstrates proactive risk mitigation in support of secure industrial operations.

Implementation Guidance: Monitor vulnerability advisories, threat intelligence feeds, and internal assessments to identify security issues affecting IACS assets. Upon identifying a vulnerability, evaluate the availability and relevance of vendor-issued patches. If suitable patches are available and have passed testing, deploy them through established change control and maintenance workflows. If patching is not feasible due to operational constraints, implement compensating controls such as network segmentation, access restrictions, monitoring enhancements or protocol filtering. All remediation actions must be documented in the organisation’s risk register or vulnerability management system and reviewed at least quarterly to ensure continued effectiveness and alignment with evolving threats.

Intrinsic Limitations: Patches may not always be immediately available or safe to apply due to compatibility or production stability concerns. Compensating controls may not fully eliminate risk and often require manual upkeep, periodic reassessment and operator awareness. Overreliance on temporary mitigations without progressing to full remediation can create long-term security gaps. Lack of coordination between IT and OT teams may also delay or impede implementation, particularly in complex or safety-critical environments.

Impact: Failure to apply patches or implement compensating controls in a timely manner increases the risk of exploitation via known vulnerabilities. This can result in unauthorised access, service disruptions, system manipulation or compromise of sensitive data. Vulnerabilities left unmitigated may be exploited by malware, ransomware or advanced persistent threats (APT) targeting critical infrastructure, potentially causing safety incidents, production downtime or regulatory breaches.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

PM/C10 Validate patch outcomes post-deployment

About This Control: Post-deployment validation of patches within the Industrial Automation and Control System (IACS) environment, covering functional verification, performance monitoring, and confirmation that the targeted vulnerability has been successfully remediated.

Purpose: To ensure that applied patches have achieved their intended security outcome without introducing operational issues, performance degradation, or unintended side effects. In OT environments, a patch that fixes a vulnerability but destabilises a process control function can be more harmful than the vulnerability itself. Post-deployment validation closes the loop on the patching process, confirming both security effectiveness and operational safety. It also provides evidence for the Change Management record, supports continuous improvement of the patching process, and enables early detection of latent issues before they escalate into incidents.

Implementation Guidance: Following each patch deployment, a structured validation procedure should be performed before the system is returned to normal operations. The procedure should include functional verification that the affected system continues to perform its intended control, monitoring, or safety functions correctly; performance monitoring against established baselines for parameters such as cycle time, response latency, data throughput, and resource utilisation; security verification confirming that the targeted vulnerability has been remediated, typically through vulnerability rescan, configuration check, or patch acknowledgement log; and operator confirmation that the system behaves as expected during initial post-change operations. All validation outcomes must be documented in the Change Management record and the vulnerability register. Any anomalies, degradations, or unexpected behaviours must be escalated through the Change Management process and may trigger rollback. Where feasible, validation should extend over a defined observation period (e.g. 24 to 72 hours) to detect delayed effects.

Intrinsic Limitations: Post-deployment validation is only as effective as the baselines against which it is measured. Where baselines are poorly defined or outdated, subtle degradations may go unnoticed until they manifest as operational issues. Some latent patch effects, such as memory leaks, intermittent failures, or interactions with specific process conditions, may only surface after extended operation or under rare operating states, making short-window validation insufficient. In environments with limited observability or legacy equipment that lacks diagnostic interfaces, meaningful validation may be difficult to achieve. Finally, validation itself consumes operational attention and time, which can create pressure to shorten or skip validation steps, particularly during busy maintenance windows.

Impact: Without post-deployment validation, patches may fail silently, leaving vulnerabilities technically unremediated while giving a false sense of security. Alternatively, patches may introduce operational issues that remain undetected until they cause process disruption, equipment damage, or safety incidents. Lack of validation records also undermines audit defensibility and complicates root cause analysis during subsequent incidents, as it becomes unclear whether a patch was successfully applied and verified.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

9.3.2.4 Unsupported Systems (Legacy Systems and End-of-Life Assets)

Unsupported assets are a defining characteristic of many Industrial Control System (ICS) environments, where equipment and software often remain in service for decades. Unlike modern IT assets, these systems may depend on outdated operating systems, proprietary applications, or hardware platforms that suppliers no longer maintain. Despite their limitations, unsupported assets continue to underpin critical infrastructure operations, making their secure management essential for overall ICS resilience.

Managing unsupported assets involves identifying systems that are unpatchable or no longer fully supported, applying compensating security measures, and ensuring they remain functionally reliable while limiting cyber exposure. Because suppliers may not issue updates or patches, organisations must adopt alternative approaches such as network segmentation, strict access control, application allow-listing, and enhanced monitoring to reduce risk.

In ICS environments, unsupported asset management plays a vital role in maintaining operational continuity, reducing the risk of exploitation of unpatched vulnerabilities, and ensuring compliance with organisational policies and regulatory requirements. It requires balancing the operational necessity of keeping critical systems online with the cybersecurity imperative to defend against modern attack techniques. A structured, risk-based approach is therefore essential: maintaining an accurate inventory, assessing vulnerabilities and criticality, and prioritising protective measures according to risk appetite and system dependencies.

Unsupported assets in ICS generally fall into two categories:

Legacy Assets: These are components that remain operational and often business-critical but rely on outdated hardware, software, or operating systems with limited update options. Some vendor support may still exist, but patching is constrained or highly disruptive. Legacy assets present heightened cybersecurity risk due to inherent vulnerabilities, older protocols, and complex integration dependencies, yet they often cannot be replaced quickly due to cost, certification, or operational requirements.

End-of-Life (EoL) Assets: These are systems or devices for which the vendor has fully discontinued support—no security patches, updates, or technical assistance are available. EoL assets cannot be addressed through standard patch management and must instead rely on strict compensating controls, enforced isolation, and time-bound decommissioning or replacement strategies.

By explicitly distinguishing legacy from EoL assets, organisations can adopt tailored safeguards. Legacy assets may require risk-based protection to sustain operations, whereas EoL assets demand stricter measures, enforced segregation, and proactive retirement to prevent them from becoming persistent entry points for cyber threats.

The controls defined in Table 2 establish the foundation of a robust unsupported asset management programme tailored to the unique operational and regulatory requirements of ICS. These controls apply to all unsupported or partially supported components—including programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) servers, operator workstations, embedded devices, and other critical OT infrastructure—particularly in sectors such as energy, water, transportation, and manufacturing where ageing systems remain a long-term operational reality.

Table 1: List of Unsupported Systems Controls

US/C1 Establish and maintain an inventory of unsupported assets within ICS

About This Control: An inventory of all unsupported assets within the Industrial Control System (ICS) environment, including hardware, operating systems, and applications that are either no longer supported by the vendor, unpatchable, or operating with constrained update options. This inventory should also capture associated dependencies such as communication protocols, middleware, and integrations with other systems that may amplify cyber risk.

Purpose of the Control: To ensure visibility and accountability over all unsupported assets that may present heightened cyber risk due to the absence of vendor updates or security patches. A dedicated inventory enables risk assessments, prioritisation of compensating controls, and strategic planning for system replacement, isolation, or retirement. It also provides traceability to support incident investigations and compliance with internal and external regulatory requirements. This addresses the threats of T5. Network Bridging and T8. External Network Access Compromise.

Implementation Guidance:

• Identify Unsupported Assets. Identify all ICS assets that are no longer fully supported by the vendor or cannot receive patches due to technical or operational constraints, and tag them as “unsupported” in the master asset database.

• Record Asset Details. For each asset, record the manufacturer, model, operating system, firmware and software version, date of last update, vendor support status, and operational owner.

• Document Dependencies. Record dependencies on legacy protocols (for example Modbus, DNP3, Profibus), middleware (for example OPC Classic), custom applications, and every network or external connection.

• Distinguish Legacy from End-of-Life. Classify each asset as Legacy (limited vendor support remains) or End-of-Life (support fully discontinued). For Legacy assets, record the remaining support, such as restricted patch availability or extended maintenance contracts, and potential upgrade paths. For End-of-Life assets, record the final supported version, decommission status, planned retirement or replacement date, and whether spares or substitutes are available.

• Reconcile Records. Reconcile inventory entries against procurement records, maintenance logs, and passive network observation to confirm completeness.

• Review at Planned Intervals. Review and update the inventory at planned intervals, and after maintenance activities or vendor site visits.

Intrinsic Limitations: Unsupported devices may lack telemetry or reporting features, requiring manual processes that are prone to human error. Where this is the case, use passive network monitoring to detect them, complement it with physical walkdowns of control rooms and field cabinets, and record the findings in the register. Documentation may be incomplete or inconsistent, especially for assets deployed many years ago. Where records are missing, reconstruct them from procurement files, vendor contacts, and the knowledge of maintenance staff, and mark entries as unverified until confirmed. Network discovery tools may be ineffective in isolated or serial-based environments. Where this is the case, rely on manual audits at planned intervals, and prioritise areas that support safety-critical or high-impact processes.

Impact: Failure to maintain accurate records of unsupported assets can result in blind spots, leaving vulnerable devices unmonitored and unprotected. This increases the likelihood of exploitation, complicates the deployment of compensating controls, and hampers incident response. Inaccurate or outdated inventories may also undermine replacement planning, risk assessments, and regulatory compliance efforts.

References:

IEC 62443-2-1 (Establishing an IACS Security Program)
NIST SP 800-82 Rev 2 (Guide to Industrial Control Systems Security)
NIST SP 800-53 CM-8 (System Component Inventory)
ENISA Good Practices for Security of Legacy Systems

US/C2 Record supplier support status and known limitations for each unsupported asset

About This Control: A record, for each unsupported asset, of the supplier’s current support position (supported, limited, or discontinued), the known security limitations of the product, and any available mitigations or end-of-support dates.

Purpose of the Control: To ensure that decisions about each asset rest on facts about what the supplier will and will not provide, so that treatment matches the real exposure. It prevents assets from being assumed safe because they were once supported. This addresses the threats of T3. Rogue Firmware Upload and T4. Protocol Exploits.

Implementation Guidance:

• Record Support Status. For each asset, record the supplier’s support position (full, limited, extended contract, or discontinued), the end-of-support date, and the date the status was last confirmed.

• Confirm With the Supplier. Obtain written confirmation of support status from the supplier or an authorised distributor at least annually, and after any supplier acquisition, product line retirement, or change in support terms.

• Record Known Limitations. Record known unpatched vulnerabilities, unsupported protocols or cryptographic functions, missing security features (for example no authentication, no logging, no firmware signing), and operating system end-of-support dates.

• Record Available Options. Note extended support contracts, third-party support providers, supplier-recommended mitigations, and migration paths, with indicative cost and lead time.

• Track Vulnerability Disclosures. Monitor supplier, national CERT, and industry advisories for each unsupported product, and link each relevant advisory to the asset record.

• Update on Change. Update the record when support terms change, when a new vulnerability is disclosed, or when the asset is modified.

Intrinsic Limitations: Suppliers may be unresponsive, may no longer exist, or may decline to state a support position in writing. Where this is the case, record the best available evidence (product lifecycle notices and last known support dates), and treat the asset as End-of-Life until confirmed otherwise. Public vulnerability data may be incomplete for obscure or proprietary products. Where this is the case, assume that undisclosed weaknesses exist, and rely on the compensating controls in this section instead of waiting for advisories. Support records can go stale. Where this is a risk, assign an owner and a review date to each record.

Impact: Without support records, organisations may assume an asset is covered when it is not, miss end-of-support dates, or invest in controls that do not address the real limitations. Known weaknesses are then left without a treatment plan.

References:

IEC 62443-2-3 (Patch Management in the IACS Environment)
NIST SP 800-82 Rev 2 (Guide to Industrial Control Systems Security)
NIST SP 800-53 SA-22 (Unsupported System Components)
CISA Known Exploited Vulnerabilities Catalog

US/C3 Assess risk and record treatment decisions for each unsupported asset

About This Control: A control requiring a risk assessment of each unsupported asset and a recorded decision on how it will be treated: retain with compensating controls, isolate further, replace, or retire.

Purpose of the Control: To make sure limited resources go first to the assets that pose the greatest risk to safety and operations, and that every retained asset has an accountable decision. This addresses the threats of T3. Rogue Firmware Upload, T4. Protocol Exploits and T6. Engineering Station Compromise. The vulnerability management programme in Section 9.3.2.1 provides the wider governance for these decisions.

Implementation Guidance:

• Rate Criticality. Rate each asset by its effect on safety, environmental protection, production, and dependent systems if it fails or is compromised.

• Rate Exposure. Rate each asset by network reachability, connectivity to IT or external networks, remote access paths, and physical accessibility.

• Rate Exploitability. Rate the likelihood of exploitation using known unpatched vulnerabilities, the absence of authentication or logging, and the availability of public exploits.

• Assign a Risk Tier. Combine the ratings into a risk tier (for example Critical, High, Medium, Low) using a documented method.

• Record a Treatment Decision. For each asset, record one of: retain with compensating controls, isolate further, replace by a target date, or retire. State the reasons and the controls required.

• Approve Residual Risk. Require formal approval by the asset owner and a senior accountable officer for any retained Critical or High asset, with an expiry date for the acceptance.

• Review Regularly. Review tiers and decisions at least annually, and whenever support status, threats, or the operating environment change.

Intrinsic Limitations: Risk assessment depends on reliable inventory and support data, and on judgement that may differ between assessors. Where data is incomplete, use conservative ratings and record the assumptions, and refine them as better data arrives. Scoring schemes designed for IT may not reflect safety and process consequences. Where this is the case, use a rating method that explicitly includes safety and process impact, with input from operations and safety staff. Long-lived accepted risks can become permanent. Where this is a risk, require every acceptance to carry an expiry date and a replacement or retirement plan.

Impact: Without risk-based decisions, unsupported assets are managed ad hoc, the most dangerous ones may stay exposed, and retained risk has no owner. Audits and investigations cannot show a rational basis for what was and was not done.

References:

IEC 62443-3-2 (Security Risk Assessment for System Design)
IEC 62443-2-1 (Establishing an IACS Security Program)
NIST SP 800-30 Rev 1 (Guide for Conducting Risk Assessments)
NIST SP 800-82 Rev 2 (Guide to Industrial Control Systems Security)

US/C4 Isolate unsupported assets in dedicated network zones with enforced boundary controls

About This Control: A control that places unsupported assets in dedicated network zones, behind firewalls or protocol-aware gateways, allowing only explicitly approved flows, so that an attack cannot easily reach them from other networks and a compromise cannot spread from them.

Purpose of the Control: Because unsupported assets cannot be patched, restricting who and what can reach them is the primary protection. This control limits exposure of known weaknesses to attackers on other networks. This addresses the threats of T4. Protocol Exploits, T5. Network Bridging and T8. External Network Access Compromise.

Implementation Guidance:

• Define Dedicated Zones. Place unsupported assets in dedicated zones and conduits, separate from supported assets, IT networks, and external connections.

• Apply Default-Deny Boundaries. At each zone boundary, use firewalls or protocol-aware gateways, allow only documented and approved flows, and deny everything else.

• Restrict Protocols and Functions. Where the gateway supports it, restrict industrial protocol traffic to the function codes and addresses the process needs, for example allowing reads but blocking writes from monitoring systems.

• Block Direct External and Internet Access. Prohibit direct connection of unsupported assets to the internet, corporate IT, and external networks such as leased lines, cellular modems, radio, and satellite links, unless mediated by a controlled gateway.

• Use One-Way Flows Where Possible. Use data diodes or one-way gateways to move data out of the zone to historians and monitoring systems.

• Apply Stricter Isolation to End-of-Life Assets. Hold End-of-Life assets in the most restricted zones, with no routine connectivity beyond the dependencies recorded in the inventory.

• Review Boundary Rules. Review rules at least quarterly, remove unused rules, and re-test the boundary after any network change.

Intrinsic Limitations: Some unsupported assets depend on flat networks or broadcast-based protocols that do not tolerate filtering. Where this is the case, place a firewall or gateway in front of the group of assets instead of between each device, and use tested, narrowly scoped allow rules. Retrofitting segmentation can require outages that operations cannot accept. Where this is the case, stage the work over planned shutdowns, start with the highest-risk assets, and use VLANs with access control lists as an interim step. Isolation may break integrations with newer systems. Where this occurs, provide the needed flow through a single mediated interface, and record it as an approved exception.

Impact: Unsupported assets that remain reachable from IT or external networks give attackers a way to exploit unpatched weaknesses remotely and to move onward into the process network. The 2015 Ukrainian grid attack in Table 27 illustrates how a route from IT into SCADA leads to operational disruption.

References:

IEC 62443 Part 2-3

NIST SP 800-82 Rev 2

US/C5 Restrict and control access to unsupported assets

About This Control: A control governing who and what can log in to or change unsupported assets, including operators, engineers, vendors, and remote users, using strong authentication where the asset supports it and compensating measures where it does not.

Purpose of the Control: Many unsupported assets have weak or no authentication and cannot be updated to add it, so access must be controlled around them. This prevents misuse of maintenance and engineering paths, and limits what insiders and attackers can do. This addresses the threats of T2. HMI Interface Abuse, T6. Engineering Station Compromise, T8. External Network Access Compromise and T10. Insider Threat.

Implementation Guidance:

• Mediate All Access. Route operator, engineering, and vendor access through a jump host or privileged access management solution that enforces multi-factor authentication, instead of connecting directly to the asset.

• Control Engineering Workstations. Restrict engineering and programming workstations that connect to unsupported assets to a named list of hardened, managed devices, and prohibit personal or unmanaged laptops.

• Apply Least Privilege and Time Limits. Give each person only the access their role needs, for a defined period, and remove it when the task is complete.

• Disable Unused Interfaces. Disable or physically block unused services, ports, remote access features, and default accounts, and change default passwords where the asset allows.

• Control Vendor Remote Access. Keep vendor remote access disabled by default and enable it only for approved work with a named individual, a time window, and a recorded session.

• Protect Local and Physical Access. Keep unsupported assets in locked cabinets or rooms with logged access and control removable media at the asset.

• Review Access Rights. Review who has access at least quarterly and remove dormant accounts and unneeded rights.

Intrinsic Limitations: Some unsupported assets have no user accounts, a single shared account, or hard-coded passwords that cannot be changed. Where this is the case, enforce individual accountability at the jump host or gateway in front of the asset, restrict reachability to that single point, and record every session. Older HMIs and workstations may not support multi-factor authentication. Where this is the case, apply multi-factor authentication at the access gateway instead of on the device. Strict access control can slow emergency response. Where this is a concern, define an emergency access procedure with a sealed break-glass account that is monitored and reviewed after each use.

Impact: Weak access control on unsupported assets lets attackers or insiders alter logic, hide process failures on operator screens, or load malicious files with little chance of detection. The scenarios in Table 27, such as a vendor laptop used to upload malicious ladder logic, show how a trusted maintenance path becomes the route of compromise.

References:

IEC 62443-3-3 SR 1.1 (Human User Identification and Authentication)
IEC 62443-3-3 SR 1.13 (Access via Untrusted Networks)
IEC 62443-3-3 SR 2.1 (Authorization Enforcement)
NIST SP 800-82 Rev 2 (Guide to Industrial Control Systems Security)

US/C6 Protect unsupported hosts with compensating technical controls

About This Control: A control that applies host-level and network-level protections in place of patching on unsupported operating systems, applications, and devices, including application allowlisting, hardening, removable media control, and virtual patching.

Purpose of the Control: To reduce the chance that known, unpatched weaknesses can be exploited on assets that can no longer be updated. This addresses the threats of T3. Rogue Firmware Upload, T4. Protocol Exploits and T6. Engineering Station Compromise.

Implementation Guidance:

• Harden the Host. Disable unused services, accounts, and features, remove unneeded software, and apply the supplier’s security configuration guidance where it exists.

• Apply Application Allowlisting. On Windows-based or similar hosts, allow only approved executables, scripts, and drivers to run, and block everything else.

• Control Removable Media and Ports. Disable USB and optical media by default, and where media is needed, use a scanning station and approved media only.

• Use Virtual Patching. Place an intrusion prevention system or protocol-aware filter in front of the asset to block known exploit patterns, malformed packets, and unauthorised commands.

• Block Weak Services at the Boundary. Block or proxy legacy protocols and services with known weaknesses, such as unauthenticated file sharing, remote procedure calls, and legacy remote desktop, at the zone boundary.

• Restrict Outbound Connections. Prevent unsupported hosts from initiating connections to networks beyond their documented dependencies.

• Record Exceptions. Record every control that cannot be applied, with the reason and the alternative used.

Intrinsic Limitations: Endpoint agents and security software may not run on unsupported operating systems, and suppliers may not certify them with their control software. Where this is the case, enforce allowlisting and filtering at network and gateway level, run network-based detection beside the asset, and use supplier-approved configurations where they exist. Virtual patching depends on current detection signatures for old products, which may be unavailable. Where this is the case, use protocol allow-lists that permit only known-good function codes instead of relying on signatures. Hardening can break functions that operations depend on. Where this is a risk, test changes on a spare or lab asset first, and apply them during planned maintenance.

Impact: Without compensating controls, an unsupported host is as exposed as the day its support ended, and a known exploit may work unchanged. Malware or an attacker on an engineering station can reach controllers, and unsupported hosts become a persistent foothold.

References:

IEC 62443-3-3 SR 3.2 (Malicious Code Protection)
NIST SP 800-82 Rev 2 (Guide to Industrial Control Systems Security)
NIST SP 800-167 (Guide to Application Whitelisting)

US/C7 Monitor unsupported assets for abnormal behaviour and unauthorised change

About This Control: A control that monitors unsupported assets from outside, to detect abnormal network activity, unauthorised commands, configuration or logic changes, and loss of expected communication, using passive methods that do not disrupt the process.

Purpose of the Control: Unsupported assets often cannot generate reliable logs or alerts, so detection must come from the network around them and from comparison against a known-good baseline. This addresses the threats of T1. PLC Logic Injection, T3. Rogue Firmware Upload, T4. Protocol Exploits and T5. Network Bridging.

Implementation Guidance:

• Monitor Network Traffic Passively. Use network taps or mirror ports and passive monitoring to learn the normal communications of unsupported assets, and alert on new devices, new connections, scans, and unexpected protocols.

• Detect Unauthorised Commands. Alert on write, program-download, firmware-load, and stop commands from sources that are not on the approved list.

• Check Logic and Configuration Against Baselines. At planned intervals, compare controller logic and configuration against the approved baseline, and alert on differences.

• Collect Logs Externally. Where assets cannot send logs, collect events from the gateways, jump hosts, and firewalls in front of them, and forward them to central monitoring.

• Alert on Loss of Communication. Alert when an asset stops communicating or shows unexpected restarts.

• Define Response Steps. Document who responds to each type of alert and the first actions, including isolating the zone.

• Retain Records. Retain monitoring data and logs for at least 90 days, or longer where required.

Intrinsic Limitations: Passive monitoring cannot see traffic that never crosses a monitored link, such as serial connections. Where this is the case, place monitoring on the gateways that convert serial to network traffic, and use periodic manual checks for isolated devices. Industrial protocol monitoring tools may not recognise proprietary protocols. Where this is the case, use flow-level analysis (who talks to whom, how often, how much) as a baseline, and add protocol support as it becomes available. Alert volume can overwhelm small teams. Where this occurs, tune alerts to a short list of high-value events, and review the rest in scheduled reviews.

Impact: Without monitoring, changes to logic or firmware and exploitation of legacy protocols can go unnoticed on assets that cannot report on themselves. Investigators cannot tell when or how an asset changed, which delays containment and recovery.

References:

IEC 62443-3-3 SR 2.8 (Auditable Events)
IEC 62443-3-3 SR 6.2 (Continuous Monitoring)
NIST SP 800-82 Rev 2 (Guide to Industrial Control Systems Security)
ISO/IEC 27001 A.8.15 (Logging)

US/C8 Maintain backup, spare and recovery capability for unsupported assets

About This Control: A control that maintains current offline backups of configurations, logic, and data, spare hardware or tested substitutes, and tested procedures to restore unsupported assets quickly after failure or compromise.

Purpose of the Control: Unsupported assets can fail or be corrupted, and they cannot be rebuilt from supplier media or support. Recovery capability limits downtime and allows a safe return to operation. This addresses the threats of T1. PLC Logic Injection, T3. Rogue Firmware Upload and T4. Protocol Exploits.

Implementation Guidance:

• Back Up Configuration and Logic. Take and verify backups of controller logic, configurations, and application data after each approved change, and store copies offline and off site.

• Preserve Installation Media and Licences. Keep verified copies of operating system and application installation media, licence keys, drivers, and supplier tools, with checksums, before they become unobtainable.

• Hold Spares. Hold spare hardware for critical unsupported assets, or identify and test compatible substitutes, and keep them in controlled storage.

• Keep Known-Good Images. Keep verified, protected system images of unsupported hosts that can be restored to isolated hardware.

• Test Restoration. Test restoring from backups and images at least annually, on spare or lab hardware where possible, and record the time taken.

• Define Manual and Degraded Operation. Document how the process runs safely if the asset is unavailable, including manual control and the limits of degraded operation.

• Protect Backups. Control access to backups and verify their integrity, so that a compromise cannot corrupt the recovery copies.

Intrinsic Limitations: Spare parts for discontinued products can be scarce or expensive. Where this is the case, identify certified refurbishment suppliers, hold a pooled spares stock across sites, and consider virtualising unsupported hosts so they run on current hardware. Backups of some embedded devices cannot be taken without stopping the process. Where this is the case, take them during planned shutdowns and record the device settings manually between backups. Restoration tests can disrupt operations. Where this is a risk, test on lab or spare hardware, and perform live tests only in planned windows.

Impact: Without tested recovery, a failure or compromise of an unsupported asset can lead to extended downtime, because replacement parts, software, and configurations cannot be obtained quickly. Recovery then depends on improvisation, which risks unsafe operation.

References:

IEC 62443-3-3 SR 7.3 (Control System Backup)
IEC 62443-3-3 SR 7.4 (Control System Recovery and Reconstitution)
NIST SP 800-34 Rev 1 (Contingency Planning Guide for Federal Information Systems)
NIST SP 800-82 Rev 2 (Guide to Industrial Control Systems Security)

US/C9 Plan and execute time-bound replacement or retirement of unsupported assets

About This Control: A lifecycle control that sets target dates, funding, and responsibilities for replacing or retiring unsupported assets, with secure decommissioning.

Purpose of the Control: Compensating controls reduce risk but do not remove it, and End-of-Life assets cannot be made safe permanently. Replacement or retirement removes the underlying exposure, so that protective controls are not relied on forever. This addresses the threats of T3. Rogue Firmware Upload and T4. Protocol Exploits.

Implementation Guidance:

• Set Replacement Targets. For each asset, set a target replacement or retirement date based on its risk tier (US/C3), scheduling End-of-Life assets in the Critical and High tiers first.

• Plan Funding and Resources. Include replacement in capital and maintenance planning, with owners, budgets, and outage windows.

• Engage Suppliers Early. Ask suppliers for migration paths, compatibility information, and interim support options, and begin procurement before support ends.

• Specify Support in New Purchases. Require new equipment to have a stated support period, security update commitments, and secure update mechanisms, and record these in the inventory.

• Plan a Safe Transition. Plan cutover, testing, and fallback so that replacement does not create new safety or availability risks and re-validate controls on the new asset.

• Decommission Securely. Remove retired assets from the network, erase or destroy storage and credentials, revoke accounts and certificates, and update the inventory.

• Track Progress. Report progress against targets to senior management at least twice a year and escalate overdue items with their residual risk.

Intrinsic Limitations: Replacement can take years because of cost, certification, and the need for long outages. Where this is the case, define interim milestones, such as isolating, virtualising, or replacing only the most exposed components, and keep compensating controls in force until replacement is complete. Replacement equipment may need process requalification or regulatory approval. Where this is the case, begin approval early, and run new and old systems in parallel where it is safe to do so. Suppliers may no longer offer a direct replacement. Where this is the case, assess functional equivalents from other suppliers or a platform migration, and treat the project as a design change.

Impact: Without replacement and retirement plans, compensating controls become permanent, the asset base becomes more fragile each year, and a failure or compromise of an unsupported asset becomes more likely and harder to fix.

References:

IEC 62443-2-1 (Establishing an IACS Security Program)
NIST SP 800-53 SA-22 (Unsupported System Components)
NIST SP 800-88 Rev 1 (Guidelines for Media Sanitization)
NIST SP 800-82 Rev 2 (Guide to Industrial Control Systems Security)

End of Playbook