Making Decommissioning Part of the Cybersecurity Lifecycle

How can a lifecycle approach support retiring products, instances, and components securely?

Every connected or networked product, from a simple IoT sensor to a complex automated vehicle, eventually reaches the end of its useful life. Product engineers typically view this through a standard product lifecycle: a concept is refined through design and development, validated and verified, and released to the market. Units are purchased, deployed, and maintained until they reach end-of-support, end-of-life, or another removal-from-service condition, at which point, they are decommissioned, whether that means discarded, recycled, resold, or, in the case of complex, safety-critical, or regulated products, formally retired.

Because security decisions made at every stage directly impact a product's overall cybersecurity strength, security plays a vital role across the entire timeline. Skipping early phases often leads to expensive, less effective, or harder-to-sustain security controls, as well as uncontrolled risks down the line. The same holds true for the final phase: decommissioning. International standards and regulations increasingly treat retirement as an essential security phase. Without this phase, sensitive cybersecurity or private data such as cryptographic keys or a former device owner's name and home address may unintentionally be at risk after it is taken out of use.

However, standard lifecycle planning often harbors a critical blind spot: organizations, regulators, and standards bodies tend to frame retirement primarily around an entire product line. In reality, individual units and sub-components are frequently decommissioned long before an overall product line is sunset. For example, a vehicle component such as an electronic control unit (ECU) may fail due to an isolated issue just a few years after the model enters the market. As part of the replacement process, the ECU may need to be formally decommissioned to prevent potential security or privacy risks. To manage risk effectively, organizations can take care to recognize decommissioning wherever it occurs, including at the product, instance, or component level, and fulfill the security obligations that are unique to each.

Beyond the product line: instance and component decommissioning

Viewing decommissioning strictly through the lens of a product line makes it easy to overlook routine operational events, such as handling sensitive residual data or credentials when a component in a complex system is swapped during maintenance.

Organizations can distinguish between three distinct lifecycle levels.

1. Product-Line Level: The global sunset of an entire product family or software version.
2. Instance Level: Individual units retired before full product-line end of life (e.g., automated vehicles, robots, or deployed systems damaged in an accident, affected by a natural disaster, modified for specialized testing, or otherwise rendered unsuitable for operation).
3. Component Level: Sub-systems or elements (e.g., cameras, radars, lidars, other sensors, compute modules, storage devices, or communication units) removed because they are damaged, degraded, obsolete, or no longer functioning as intended.

Ultimately, effective security depends on recognizing decommissioning wherever it happens: not just at the final sunset of a product line, but at the level of every instance of a product and component reaching the end of its useful life.

In practice, instance-level and component-level decommissioning events are often far more common than full product-line retirement. Recognizing these granular, more common scenarios means decommissioning planning must go further.

• Credential & Access Revocation: Deleting cryptographic keys from local physical hardware is rarely enough; those keys and credentials may also need to be revoked in backend systems, and access may need to be removed for specific product instances rather than the entire fleet.
• Asset & Baseline Hygiene: Components removed from service may need to be systematically removed from vulnerability management, patch management pipelines, active asset inventories, and configuration baselines.
• Targeted Evidence & Data Retention: Records may need to be preserved for accident investigation, safety analysis, warranty claims, regulatory compliance, cybersecurity monitoring, or future maintenance, even though those records might not be retained in the same way during a full product-line retirement.

Securing the complete decommissioning stage

Comprehensive decommissioning amounts to far more than wiping memory before discarding hardware. It requires organizations to deliberately address the affected product's data, credentials, identities, network access, cloud relationships, update channels, support obligations, asset records, and retained evidence across every scenario where decommissioning occurs.

Ultimately, effective security depends on recognizing decommissioning wherever it happens: not just at the final sunset of a product line, but at the level of every instance of a product and component reaching the end of its useful life. Organizations that build this recognition into their lifecycle planning set themselves up to exercise control across every stage of a product's journey.