Why does the CRA make supported updates a security issue?

Why supported updates are a security issue under the CRA

The Cyber Resilience Act treats supported updates as a security requirement because patchability is part of whether a product can stay trustworthy after it ships. If a device cannot receive security fixes, it can drift into an unmaintainable state where known weaknesses persist, evidence of compromise is harder to interpret, and the product no longer meets the security expectation that was valid at release.

That matters most for products with digital elements that remain deployed for years. A supported update path is not just a convenience feature, it is the mechanism that keeps vulnerability remediation, secure configuration correction, and lifecycle security possible once the product is in the field.

What “supported updates” really protect in the lifecycle

Supported updates preserve the operator’s ability to respond when new flaws, unsafe defaults, or dependency issues appear after procurement. Security is not frozen at shipment, because the threat environment changes and defects are discovered continuously. A product that can be updated under vendor support can still be brought back into a defensible state without replacement or risky workarounds.

This is why support status becomes a security question rather than a purely commercial one. If the vendor stops providing fixes, the organisation may still be able to run the device, but it cannot reliably reduce exposure when new vulnerabilities emerge. The asset may remain operational while becoming increasingly unsafe.

Supported updates also matter for assurance. When patching is available, teams can validate remediation, track version state, and keep a realistic inventory of exposure. When it is absent, compensating controls become the only option, and those controls often depend on isolation, monitoring, or reduced exposure rather than actual repair.

Why unsupported devices create a compliance and trust gap

Once support ends, compliance and security begin to diverge. The organisation may still have a business need to keep the product alive, but it has lost a core control needed to meet a modern product-security baseline. That is why the CRA pushes security upstream into the product’s life cycle, instead of treating patching as an afterthought left entirely to the operator.

The practical problem is that an unsupported device can remain in production while known issues accumulate. If there is no dependable way to patch, attest, or remediate it, the operator has to choose between operational continuity and security confidence. That is a poor trade-off for critical or long-lived deployments.

For the same reason, supported updates are tied to broader product accountability. The regulation is designed to prevent “ship once, forget forever” security, where a device is sold with a finite support window but is still expected to survive in environments that require ongoing assurance.

Risk and Threat Considerations

Unsupported products create exposure because vulnerabilities, configuration flaws, and supply-chain issues can no longer be corrected in a timely way. That leaves a stable target in production, especially where devices are hard to replace or are embedded in operational environments with long lifecycles.

Failure mechanism: The vendor stops maintaining the update path, so the operator loses the primary mechanism for closing newly discovered weaknesses. Over time, the device accumulates unpatched exposure, and any compromise or instability becomes harder to contain.

Impact: Attackers can target known weaknesses with greater confidence, while defenders are forced to rely on isolation or compensating controls. The result is higher residual risk, weaker auditability, and a growing chance that the product must be retired before the business is ready to replace it.

Practitioner Guidance

What to verify: Treat supported update capability as a procurement and operating requirement, not a post-deployment hope. Verify that the vendor commits to security fixes for the full expected deployment life, that updates can be delivered reliably, and that the organisation can actually apply them without unacceptable downtime.

Decision rule: If the device cannot be patched or remediated within a defensible support window, classify it as a lifecycle risk and plan for replacement, isolation, or formal exception handling before the support period expires.

Practitioner takeaway: The key security question is not whether the device worked when installed, but whether it can still be brought back into a trustworthy state after the next vulnerability is discovered.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• When does NHI compliance become an operational security issue?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?