Yes, when a device is no longer supported, workarounds should be treated as temporary containment, not a durable control. Firewalls, isolation, and password changes can reduce exposure, but they do not restore patchability. Organisations should prioritise removal or upgrade when feasible, because unsupported assets create a persistent gap that attackers can revisit whenever new tooling emerges.
Why replacement is usually the safer long-term decision
Unsupported hardware creates a structural problem: the device can still function, but the security control plane around it stops improving. That means workarounds may reduce noise, yet they do not close the underlying exposure, especially when the asset handles secrets, tokens, remote access, or other trust-bearing functions. In practice, this is less about convenience and more about whether the organisation still has a defensible path to maintenance, patching, and accountability.
Workarounds can be justified as short-term containment, but they should be judged against the actual blast radius of the device. If the asset is internet-reachable, adjacent to sensitive systems, or embedded in a privileged workflow, the residual risk usually stays high until the hardware is removed or upgraded. That is why replacement tends to be the durable control, while isolation is only a temporary risk reducer.
Unsupported assets also age badly from a governance perspective. As new vulnerabilities, exploit techniques, and compliance expectations emerge, the organisation is forced to rely on compensating controls that were never designed to be permanent. If you want a useful operating model for this problem, NHIMG’s Ultimate Guide to NHIs is a strong reference for lifecycle, offboarding, and visibility thinking, and the broader pattern is reinforced by real compromise cases such as the 52 NHI breaches Report, where retained access and unmanaged trust paths repeatedly turn into lasting exposure.
When workarounds are acceptable, and when they are not
A workaround is acceptable only when it is clearly time-bound, monitored, and paired with a funded replacement path. That means the organisation can state why the device still exists, what exposure remains, who owns the exception, and when the exception ends. If any of those answers are vague, the workaround has already started behaving like a permanent control.
Replacement should move to the front of the queue when the device can authenticate to other systems, mediate privileged access, or hold secrets that cannot be rapidly rotated. In those cases, the workaround may lower the probability of direct exploitation, but it does not eliminate the persistence risk created by a vulnerable or unpatchable component. For readers who want the operational detail behind that view, the Lifecycle Processes for Managing NHIs and the Key Challenges and Risks sections are useful because they show how unmanaged lifecycle gaps turn into long-lived exposure.
One useful heuristic is to ask whether the workaround changes the threat or only the path. Firewalls, segmentation, and password changes may change the path, but they do not repair the unsupported state itself. If the device can still be reached through any trusted dependency, the organisation should treat it as a controlled liability, not a solved problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 4 — Secure Configuration of Enterprise Assets and Software | Unsupported hardware needs controlled configuration and removal of weak assets. |
| CIS Control 7 — Continuous Vulnerability Management | Unsupported hardware cannot receive normal patch-based risk reduction. | |
| CIS Control 6 — Access Control Management | Workarounds often rely on limiting access to reduce exposure on unpatched hardware. | |
| Recommendation — Remove or tightly isolate unsupported devices and enforce approved configuration baselines. Prioritise replacement when patching is no longer possible. Restrict access paths to unsupported assets and review exceptions frequently. | ||
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Replacement versus workaround is a risk acceptance and remediation decision. |
| PR.IP — Information Protection Processes and Procedures | Lifecycle and retirement procedures determine whether unsupported assets linger. | |
| DE.CM — Continuous Monitoring | Compensating controls need monitoring to ensure the workaround still contains exposure. | |
| Recommendation — Treat unsupported hardware as a managed risk requiring a defined remediation path. Define retirement and exception procedures for hardware that can no longer be supported. Monitor unsupported assets and the controls compensating for them. | ||
| ISO/IEC 42001:2023 | A.6.3 — AI system lifecycle | Lifecycle discipline matters when deciding whether obsolete hardware can remain in service. |
| Recommendation — Apply lifecycle controls so obsolete components are retired before they become unmanaged risk. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Microsegmentation and Resource Access Policies | Isolation is a common workaround for unsupported assets and must be enforced rigorously. |
| AC-4 — Policy Enforcement Point | Access policy must limit what unsupported hardware can still reach. | |
| Recommendation — Use segmentation to contain unsupported hardware while replacement is scheduled. Enforce explicit access policies around legacy devices that cannot be patched. | ||
Practitioner Guidance
What to prioritise: Prioritise replacement first for any unsupported device that has network reach, privileged integration, or secret-bearing functions. Those are the cases where delay creates the most durable exposure and where a workaround is least likely to stay effective.
What to verify: Verify whether the workaround actually reduces access to the device, or merely obscures it. Confirm who can reach it, what credentials it accepts, what systems depend on it, and whether the exception is tracked with an expiry date and owner.
Decision rule: If the asset cannot be patched and still supports sensitive operations, treat replacement as the remediation target and the workaround as temporary containment only. If the asset is truly isolated, low impact, and scheduled for retirement, a workaround may buy time, but it should not reset the risk rating.
Practitioner takeaway: Unsupported hardware is a lifecycle failure, not just a technical nuisance, so the right question is not whether a workaround exists, but whether the organisation can tolerate the remaining exposure until replacement is complete.
Related resources from NHI Mgmt Group
- When should organisations prioritise PAM replacement over more tuning?
- When should organisations prioritise browser-layer controls over browser replacement?
- When should organisations prioritise hardware lifecycle controls over simple inventory counts?
- When should organisations prioritise digital credential support over broader IAM redesign?
