The organisation should ensure that products are scanned for known vulnerabilities before they are released to the market. This process includes checking the product and its third party components against public vulnerability databases. Any identified exploitable vulnerabilities must be addressed before the product is made available.

The organisation should define and implement a process for integrating all third party software components, including open source software. This should include a vetting process to verify components do not introduce security risks and should include steps like checking for known vulnerabilities and assessing the security posture of the supplier. Post-integration processes should be established for reporting vulnerabilities to relevant parties and defining the necessary steps for remediation.

The organisation should establish a process to continuously identify vulnerabilities within all integrated third party components, including open source software. This process should include using tools for software composition analysis, subscribing to security advisories, and regularly checking vulnerability databases to ensure timely detection.

The organisation should establish policies and procedures to identify and document product vulnerabilities effectively throughout the product lifecycle. These procedures should address at least:

• The effective handling of vulnerabilities in products with digital elements
• Processing vulnerability reports from internal and external sources
• Remediating identified vulnerabilities in a timely manner.
• Implementing a coordinated vulnerability disclosure policy

The organisation should establish and document a policy for coordinated vulnerability disclosure between manufacturers of products with digital elements and third parties. The policy should include a documented process to effectively handle and remediate identified vulnerabilities throughout the product's support period. This process should include:

• A method for assessing the severity and risk of each vulnerability.
• A system for prioritising remediation efforts based on risk.
• Procedures for developing, testing, and distributing security patches to users without delay.

The policy define should define the procedures for processing and remediating potential vulnerabilities reported from internal and external sources. It should specify the secure channels for receiving reports, provide timelines for response, and outline the process for coordinating the public disclosure of a vulnerability.

The organisation should maintain a record of all notifications sent to authorities regarding actively exploited vulnerabilities. This record serves as proof of compliance and should include the details and timing for each mandatory reporting stage: the 24 hour early warning, the 72 hour vulnerability notification, and the final report.

The organisation should maintain an inventory of critical software components highlighted in the SBoM. Components should be included in the inventory in at least the following cases:

• They have a security-critical function
• They have network or input exposure
• They are a maintenance risk
• A critical supplier relationship

The organisation should ensure products remain secure throughout their support period. This depends on every employee treating vulnerability information with discipline and urgency.

In practice this means:

• Any discovered or suspected vulnerability should be routed into the agreed vulnerability handling process immediately, whether found internally or reported from outside
• Vulnerability details stay confidential until a fix exists and disclosure is coordinated; no independent investigation or exploitation in production systems
• Security updates are developed, tested and distributed without delay, kept separate from functionality updates where possible
• Actively exploited vulnerabilities carry strict regulatory reporting deadlines and are escalated immediately

The organisation should define and implement a security update process for its products with digital elements based on the cybersecurity risk assessment. The update mechanism should provide users with the following functionalities:

• Automatic security updates enabled as a default setting.
• A clear and easy-to-use option to opt out of automatic updates.
• Notifications about available updates.
• The ability to temporarily postpone updates.

The organisation should establish a process to continuously monitor the third party components, identified in the Software Bill of Materials (SBoM), for new security vulnerabilities. This ensures the product remains secure after its release and throughout its support period.

The organisation should define an internal process for addressing and remediating vulnerabilities in accordance with the vulnerability handling requirements set out in Part II of Annex I of the CRA.

When a vulnerability is found in an integrated component, it should be reported to the component maintainer. If the organisation creates a fix for the vulnerability, the relevant code or documentation should be shared back with the maintainer.

The organisation should establish and maintain a process for documenting relevant cybersecurity information concerning its products. This documentation should include identified vulnerabilities and information received from third parties. The collected information must be used to regularly review and update the product's cybersecurity risk assessment on a proportionate basis.

The organisation should determine and document the support period for each product with digital elements based on nature of the product, relevant EU law, competitor support periods and operating environment. This is the period during which vulnerabilities will be handled. The support period must be at least five years, unless a shorter expected use time is justified.

The organisation should establish a process for collecting vulnerability information related to its products. This process should define how to gather information from various sources, such as:

• Public vulnerability databases for third party components.
• Vulnerability reports from external parties like security researchers.
• Internal security testing and code review activities.

This information should be used for the product's cybersecurity documentation and risk assessment process.

The organisation should define its policy for managing software versions, particularly regarding security updates and end-of-life products. The policy should ensure that if a product is substantially modified, users of previous versions are offered a free upgrade to the latest supported version without requiring changes to their hardware or software environment. If the organisation maintains public archives of unsupported software, it must clearly inform users of the associated security risks.

The organisation should establish a process for addressing and remediating vulnerabilities in its products without delay. This includes providing security updates that, where technically feasible, are separate from functionality updates.

The organisation should establish a process for regularly testing the security of its products with digital elements. This process should define:

• The types of security tests to be conducted, such as penetration testing, vulnerability scanning, and code reviews.
• The frequency for performing these tests.
• How test results are documented and how identified vulnerabilities are remediated.

The organisation should define a process for publicly announcing information about vulnerabilities that have been fixed. This communication should occur after a security update is available to users. The disclosure must include:

• A description of the vulnerability and its severity.
• Information to identify the affected product.
• The potential impact of the vulnerability.
• Clear instructions to help users apply the security update.

The organisation should also define the criteria for when to delay a public disclosure if the risks of publishing outweigh the benefits.

The organisation should establish a process for managing vulnerabilities within the components of its products. This includes maintaining a Software Bill of Materials (SBOM) to identify all components, including third party software, and ensuring that any identified vulnerabilities are addressed in a timely manner.

The organisation should create and publish a vulnerability disclosure policy. This provides a clear pathway for security researchers and users to report potential vulnerabilities. The policy should specify a dedicated contact address for reporting and state that it covers vulnerabilities in the product and its third party components.

The organisation should define a process for distributing software updates to its products with digital elements. This process must ensure the integrity and authenticity of updates, for example by using digital signatures. The process should also facilitate the timely delivery of vulnerability fixes and, where appropriate, enable automatic installation of critical security updates.

The organisation should establish a clear process for distributing security updates to users. This process must ensure updates are released promptly and free of charge. It should also define how to create and send advisory messages that inform users about the update and any necessary actions.

The organisation should designate a single point of contact to allow users to communicate directly and quickly. This channel is particularly important for reporting product vulnerabilities. The contact information must be easy for users to find and should be included in the product's user instructions. The organisation should provide several communication options, such as an email address and a phone number, and not rely solely on automated tools.

The organisation should create and maintain the specific communications and documentation related to its software support lifecycle. This involves documenting the upgrade path for users of older versions after a substantial modification and creating the explicit warning messages for any public archives that contain unsupported software.

The organisation should create and maintain the specific communications and documentation related to its software support lifecycle. This involves documenting the upgrade path for users of older versions after a substantial modification and creating the explicit warning messages for any public archives that contain unsupported software.

The organisation should ensure the cybersecurity risk assessment documentation explains how the vulnerability handling requirements are applied. This includes outlining the processes for identifying, managing, and remediating vulnerabilities discovered after the product has been placed on the market.

A substantially modified product with digital elements made available on the market should be treated as a new product. Making substantially modified products available on the market constitutes a new placing on the market. The support period in such cases should be determined by the products expected use time. The manufacturer should recalculate the support period to reflect new expected use times where substantial modifications affect the factors that originally determined the expected use time of the product.

Factors to consider in determining the support period of a substantially modified product support period can include:

• Reasonable user expectations
• The nature and intended purpose of the product
• The relevant EU law determining the lifetime of products with digital elements
• The support periods of products offering a similar functionality placed on the market by other manufacturers
• The availability of the operating environment
• The support periods of integrated components which provide core functions and are sourced from third parties