When a device cannot be updated, the risk shifts from a temporary software flaw to an ongoing exposure. Any messaging or media-processing path left enabled can remain a viable entry point for exploitation. In practice, teams need to disable the risky service, restrict use, or retire the device so the weakness does not become a permanent compromise route.
Why an unpatchable device changes the meaning of the risk
Once a device can no longer receive security updates, the question is no longer whether a flaw will be fixed, but how long the exposed path remains live. Messaging features are especially sensitive because they often process untrusted content, network input, images, or attachments, so a known weakness can stay reachable for the life of the device.
The practical shift is from ordinary vulnerability management to exposure management. If the device still needs to communicate, the unsafe code path can remain part of normal operations, which means the organisation is carrying a permanent attack surface unless it changes the service, the permission set, or the hardware itself.
That is why device trust matters even when the function looks harmless. NHIMG’s Device and IoT Identity Guide is useful here because it frames device trust, onboarding, and lifecycle control as part of the security decision, not an afterthought.
What attackers gain from leaving messaging enabled
Messaging and media-processing features are attractive because they offer a repeatable entry point into a device that cannot be repaired. An attacker does not need the organisation to make a fresh mistake every day; they only need one reachable service that still accepts input through the vulnerable path.
On unmanaged or long-lived devices, that can create a reliable foothold for code execution, persistence, or repeated exploitation attempts. If the device sits on a trusted network, the issue becomes more serious because a compromised endpoint can be used to reach adjacent systems, sessions, or shared services.
For sectors where device compromise has direct operational consequences, NHIMG’s Healthcare Identity Security Guide is a strong parallel example because it treats exposed shared devices and medical endpoints as access and trust problems, not just patching problems.
What organisations should do instead of hoping the flaw stays dormant
The correct response is to reduce exposure, not to assume inactivity equals safety. If the messaging feature is not essential, disable it. If the device must remain in service, restrict what it can reach, isolate it from sensitive systems, and put a retirement plan on the calendar before the device becomes a permanent exception.
Where replacement is delayed, organisations should treat the device as a constrained asset with a known weakness: narrow the network path, limit who can use it, and monitor for any signs that the vulnerable function is still being exercised. For many teams, the real decision is whether the business value of the device justifies accepting a standing exposure at all.
External hardening baselines can help with the surrounding controls. CIS Benchmarks are relevant for tightening device and platform settings around the affected service, while NIST Cybersecurity Framework 2.0 helps structure the broader decision around identify, protect, detect, respond, and recover.
Risk and Threat Considerations
Keeping messaging enabled on an unpatchable device turns a time-limited software weakness into a standing exposure. The main risk is not just exploitation of the original bug, but the fact that the unsafe path stays reachable long enough for scanning, chaining, or repeated attempts to succeed.
Failure mechanism: The device cannot receive a fix, so the vulnerable messaging or media-processing component remains operational and accessible. If the path is still used for normal business activity, an attacker only needs one successful interaction to gain a foothold or force the organisation into emergency containment.
Impact: The organisation may face persistent compromise risk, loss of trust in the device, lateral movement opportunities, or service interruption. The longer the device stays online without a supported update path, the more the risk resembles an accepted exposure rather than a temporary vulnerability.
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 SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Unpatchable devices need hardened settings and feature reduction. |
| Recommendation — Disable unnecessary messaging features and harden the device baseline to shrink exploitable surface. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | The issue is whether the vulnerable function remains enabled on a device that cannot be updated. |
| Recommendation — Track unsupported devices and remove or isolate risky services before they become permanent exposures. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Keeping an exposed feature enabled on an unpatchable device is a configuration control problem. |
| Recommendation — Maintain approved configurations and retire devices that cannot be brought back to a supportable state. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The core issue is inability to remediate a known weakness through updates. |
| CM-7 — Least Functionality | Messaging capability should be removed when it is not required and remains risky. | |
| Recommendation — Use alternate controls or decommission the asset when flaw remediation is no longer possible. Disable nonessential messaging services on devices that cannot be patched. | ||
Practitioner Guidance
What to prioritise: Decide first whether the messaging function is business-essential. If it is not, remove it or disable it; if it is essential, treat the device as a restricted exception and document the compensating controls.
What to verify: Confirm whether the device can still receive firmware or security updates, whether the messaging path is actually disabled when unused, and whether the asset can communicate with anything sensitive if exploited.
Practitioner takeaway: An unpatchable device should not be managed as if patching will eventually solve the problem. Once the update path is gone, only service removal, strict containment, or retirement can meaningfully close the exposure.
Related resources from NHI Mgmt Group
- What happens when legacy industrial devices cannot receive security updates near the end of their lifecycle?
- Why does data security posture management fail when organisations cannot keep up with cloud and NAS sprawl?
- What happens when employees keep using unsanctioned cloud tools without security oversight?
- What happens when organisations keep using warning banners for risky emails?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
