They should align software retirement with access containment and replacement planning. If a system cannot be patched, isolate it, remove default access paths, and reduce trust dependencies before the product’s support ends. In OT-adjacent environments, lifecycle decisions are security decisions, not just procurement decisions.
Why support lifecycles in OT-adjacent environments should be treated as security boundaries
Support end dates change the control model. Once a product is out of support, patching, vendor-assisted recovery, and predictable remediation all become weaker or unavailable, so the organisation must rely more heavily on containment, segmentation, and trust reduction. In OT-adjacent environments, the goal is to preserve safe operation while shrinking the blast radius of an unpatchable or aging system.
That is why lifecycle planning has to be tied to architecture, not left to procurement. If a system stays in place past support, the environment should already have compensating controls in place, including constrained access paths, limited interdependencies, and a defined replacement path. For OT-facing technology, a late lifecycle decision often becomes a security and availability decision at the same time.
Support lifecycle decisions also need to account for the difference between a system that is merely old and one that is operationally embedded. A controller, historian, jump host, engineering workstation, or integration service may still be business critical long after vendor support ends. The question is not whether the asset can remain online, but whether the organisation can continue to control it safely as its vendor safety net disappears. NIST’s OT Security Guide is useful here because it frames segmentation, system hardening, and compensating safeguards as core design concerns, not afterthoughts.
What changes when a system approaches end of support
As support winds down, three things usually change first: patch confidence drops, vendor response slows, and operational exceptions multiply. That combination increases exposure because teams begin depending on known-vulnerable software, delayed maintenance windows, and informal access workarounds to keep the plant running. CISA’s Industrial Control Systems resources are relevant because they consistently emphasise operational context, segmentation, and practical mitigation for critical environments.
The most important decision is whether the asset can be safely retired, isolated, or kept in service with compensating controls. If the answer is “kept in service,” then the organisation should assume it is inheriting additional operational risk, not just postponing a refresh. That risk grows when the system has remote access, shared credentials, broad east-west connectivity, or links to business IT services that expand the trust boundary.
End-of-support also changes incident response. If the vendor can no longer supply fixes, then detection and isolation become more important than trying to recover through patching after the fact. The environment needs to know which connections are essential, which can be removed, and which can be mediated through a controlled gateway or proxy layer without breaking operations.
How to sequence containment, replacement, and decommissioning
The practical sequence is to plan replacement first, contain second, and retire third. If a full replacement is not yet possible, the system should be narrowed to the minimum necessary trust relationships before support ends. That usually means reducing inbound reachability, removing default or shared access paths, and eliminating unnecessary integrations that were tolerated only because patching was still available.
Where identity or access dependencies exist, lifecycle work should follow the same discipline as credential governance. Remove standing access that is not essential, rotate or retire access material that no longer needs to exist, and verify that administrators, vendors, and remote support paths are still justified. NHIMG’s Joiner-Mover-Leaver (JML) Guide and IAM and IGA Basics are helpful references when the lifecycle problem is really about who still has legitimate access as systems age.
When the system is already carrying long-lived or vendor-issued access material, the replacement plan should include a cutover date for removing those dependencies. That is especially important in environments where remote support, integration tokens, or service accounts have been left in place for convenience. In lifecycle terms, support sunset should trigger an access sunset, not just a procurement notice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Support expiry makes patching unavailable, so flaw remediation must be paired with compensating controls. |
| AC-4 — Information Flow Enforcement | Isolating OT-adjacent systems depends on enforcing boundaries and limiting trust paths. | |
| CM-2 — Baseline Configuration | Retirement and containment rely on knowing the approved state before support ends. | |
| Recommendation — Document exception handling and compensating safeguards for assets that can no longer be remediated on normal timelines. Enforce constrained information flows around unsupported systems and remove unnecessary connectivity. Maintain and update a hardened baseline so unsupported systems can be isolated against a known configuration. | ||
| NIST CSF 2.0 | PR.PS-01 — Identity Management, Authentication, and Access Control | Lifecycle changes must reduce standing access and constrain who can reach legacy OT-adjacent systems. |
| Recommendation — Remove unnecessary access paths and enforce least privilege as systems approach end of support. | ||
Practitioner Guidance
What to prioritise: Start with the systems that combine end-of-support exposure with high connectivity, privileged access, or safety-critical function. Those are the assets where a delay in replacement creates the largest operational and security downside.
What to verify: Confirm that every end-of-support system has a named owner, a documented containment pattern, and a target retirement or replacement milestone. If any of those are missing, treat the asset as unmanaged risk rather than a tolerated exception.
Common mistake: Teams often preserve access paths “just in case” while postponing remediation. In OT-adjacent environments, that habit extends the trust boundary and makes the unsupported system harder to isolate later.
Practitioner takeaway: Treat support expiry as the moment to reduce dependencies, not the moment to start thinking about them. If the system cannot be patched, the safety decision is to constrain its reach first and keep only the minimum operational trust required to run it.
Related resources from NHI Mgmt Group
- How should organisations govern machine identity when connecting OT environments to modern applications and AI systems?
- How should organisations defend OT environments when ransomware or credential abuse targets operational systems?
- How can organisations reduce the risk of stale API keys and machine tokens?
- How should organisations handle privileged access when workloads and AI systems are part of the model?