Product Security Across the Entire Lifecycle

Enterprise IT security protects a company's own infrastructure and is typically governed by an ISMS based on ISO/IEC 27001. Product security, by contrast, protects the product in the field – in the customer's environment, often with attackers having physical access, and over lifetimes that far exceed typical IT support cycles. A vulnerability then affects not a single system but the entire installed base, and can lead to safety consequences, recalls or the loss of type approval. Organizationally, responsibility thus shifts from IT operations to product development – with its own management systems (CSMS), development processes (secure development lifecycle) and response structures (PSIRT).

ISO/SAE 21434:2021 defines cybersecurity engineering for road vehicles across the entire lifecycle – from the concept phase through to decommissioning. Its centerpiece is the Threat Analysis and Risk Assessment (TARA) under Clause 15: from asset identification through threat scenarios and damage and attack path analysis to the risk treatment decision. The UNECE regulations make the topic binding: UN R155 requires a certified cybersecurity management system (CSMS) as a prerequisite for type approval, UN R156 a software update management system (SUMS). In the EU, both apply via the General Safety Regulation (EU) 2019/2144 – since July 2022 for new vehicle types and since July 2024 for all new vehicles; ISO/SAE 21434 is regarded as the recognized state of the art for implementing the CSMS requirements.

For components of industrial automation systems, the IEC 62443 series separates process and product requirements. IEC 62443-4-1:2018 describes a secure product development lifecycle in eight practices – from security management and requirements specification through secure design and implementation to verification, defect and patch management, and security guidelines for users – which explicitly extends to product end-of-life and is assessed across four maturity levels. IEC 62443-4-2:2019 specifies the technical requirements for the components themselves: component requirements for four component types (embedded devices, host devices, network components, software applications), derived from seven foundational requirements and tiered into security levels SL 1 to SL 4. For manufacturers, both parts are increasingly becoming procurement criteria, because operators are specifically asking for evidence and security levels.

Delegated Regulation (EU) 2022/30 activates the cybersecurity requirements of Art. 3(3)(d)–(f) of the Radio Equipment Directive (RED); since 1 August 2025 they have been a binding prerequisite for placing internet-connected radio equipment on the market. EN 18031-1, -2 and -3 (2024 edition) serve as harmonized standards for network protection, protection of personal data and fraud protection; the European Commission listed them in the Official Journal in January 2025 – albeit with restrictions. If, for example, a product allows a password to be dispensed with (clauses 6.2.5.1/6.2.5.2), or if assured parental controls are missing under EN 18031-2 (clauses 6.1.3–6.1.6), the presumption of conformity does not apply and a notified body must be involved. Manufacturers should therefore review these restrictions early in the conformity assessment procedure.

A Product Security Incident Response Team (PSIRT) handles vulnerabilities in a company's own products – unlike a CSIRT, which deals with incidents in the company's own infrastructure. The PSIRT Services Framework v1.1 from FIRST (2020) structures the tasks into six service areas – Stakeholder Ecosystem Management, Vulnerability Discovery, Triage, Remediation, Disclosure, and Training and Education – and describes distributed, centralized and hybrid organizational models. At the latest with the Cyber Resilience Act (Regulation (EU) 2024/2847), this capability becomes mandatory: from 11 September 2026, manufacturers must report actively exploited vulnerabilities under Art. 14 in stages within 24 hours, 72 hours and 14 days to the CSIRT designated as coordinator and to ENISA; for severe incidents the same staging applies, with one month for the final report. Without well-rehearsed PSIRT processes, these deadlines are barely achievable.

Product security does not end at market launch: vulnerability management, security updates and monitoring must be planned and funded across the entire period of use. The Cyber Resilience Act requires a support period that reflects the expected product lifetime and is, as a rule, at least five years (Art. 13(8)); security updates must be provided free of charge, and the support period must be made transparent before purchase. Industry standards also factor in end-of-life: IEC 62443-4-1 explicitly includes it in the development lifecycle, and UN R156 requires managed software updates over the vehicle's lifetime. An orderly end-of-life comprises early announcement of the end of support, final security advisories, and migration paths for existing customers.