The organisation should appoint personnel to monitor for potential role reclassifications under the CRA. This ensures classification changes can be made and compliance with manufacturer obligations can begin without delay.

The organisation should define and implement a secure development process for its products with digital elements. This process ensures that cybersecurity is considered at every stage of the product lifecycle, from initial design and development to production and release. Key activities should include threat modelling, secure coding practices, and security testing before the product is placed on the market.

The organisation should document how essential cybersecurity requirements for products are met. Documentation should indicate how the essential requirements defined in Annex I of the CRA are applied throughout the product lifecycle, based on their intended purpose, reasonably foreseeable use, and expected lifetime. Product security measures should be determined by a risk assessment.

The documentation should also consider the specific conditions of use, such as their operational environment, the assets to be protected and their potential impact on the health and safety of users.

The organisation should develop a top-level plan for enhancing cybersecurity and vulnerability management in its products with digital elements and the production environment. The plan should apply to the full spectrum of the product manufacturing process.

The organisation should ensure an up-to-date register exists which tracks the resilience measures applied to products with digital elements. Product batches should be linked with unique names or other identifiers. These can be applied to a product category, batch or individual product. The product itself should bear the name or identifier. This register is crucial for traceability and managing products throughout their lifecycle and across the value chain.

Importers and distributors of products with digital elements should define a process to identify situations where they act as a manufacturer. This occurs if the organisation places a product with digital elements on the market under its own name or trademark, or performs a substantial modification to a product. In these cases, the organisation must comply with all manufacturer obligations outlined in the Cyber Resilience Act. This includes steps for conducting a risk assessment, creating technical documentation and the declaration of conformity, and setting up a vulnerability management process.

Substantial modifications include:

• New net functionality that changes the product's intended purpose
• The introduction of minor features that introduce risks not considered in the risk assessment
• Security updates that change the intended purpose of the product
• Security updates that materially alters the logic of the underlying software design
• Physical repairs or replacements parts where a performance change affects compliance with the essential cybersecurity requirements
• Modifications which alter security-relevant attributes of algorithms, protocols, cryptographic mechanisms or access control features

Substantial modifications do not include:

• Security updates whose purpose is reducing risk, without changing intended purpose or introducing new risks
• New functionalities already anticipated and assessed in the original risk assessment, with mitigations in place
• Refurbishment, maintenance and repair where purpose, functionality and risk level are unchanged
• Replacing defective/worn parts with better-performing ones where the new performance stays within the assessed intended use
• Identical spare parts made to the same specifications

The organisation should establish a process for any modifications made to products with digital elements it did not originally manufacture. This process should determine if a modification is 'substantial', meaning it could alter the product's compliance with cybersecurity requirements.

If a modification is deemed substantial, the organisation assumes the role of the manufacturer for the modified parts. Manufacturer obligations will apply to the entire product if the modification impacts its overall cybersecurity. This includes at least:

• ongoing vulnerability monitoring
• reporting actively exploited vulnerabilities to ENISA
• ensuring conformity of series production

The organisation should ensure a new conformity assessment is conducted and the necessary technical documentation created for the affected components.

The organisation should establish a process to ensure that findings from the product cybersecurity risk assessment are used to inform decisions throughout the product's lifecycle. This includes the planning, design, development, production, delivery, and maintenance phases to minimise risks and their potential impact.

The organisation should ensure its products with digital elements are made available with a secure-by-default configuration which includes the possibility to reset to its original state. This configuration should be based on a risk assessment and aim to minimise the attack surface from the start. Default configurations for products tailor-made for business-users can be negotiated.

The organisation should ensure that products with digital elements are protected from unauthorised access. This should be achieved by implementing appropriate control mechanisms, such as authentication or identity and access management systems. The product should also be capable of reporting on possible unauthorised access events.

The organisation should ensure that data processed by its products is protected using encryption or other technical means. Examples of other technical protections include:

• Hardware-anchored protection
• Integrity and authenticity mechanisms
• Architectural controls
• Data limiting by design
• Lifecycle controls

This applies to both data stored on the product (data at rest) and data sent or received by the product (data in transit). The encryption methods used should be up to date and follow industry best practices.

The organisation should implement mechanisms to ensure the integrity of data, programs, commands and configurations of its products with digital elements. These mechanisms should be effective protections in stored, transmitted or otherwise processed data states. Measures to detect of unauthorised modifications to products can include:

• Digital signatures
• Hashing
• Checksums

A process should be established for regular integrity checks, and any detected corruptions must be reported and investigated.

The organisation should implement a process to ensure data minimisation is applied during the design and development of its products. This involves identifying all data processed by a product and ensuring there is a clear, documented justification linking it to the product's intended purpose. Any data processing that is not essential for the core functionality should be removed or made optional and disabled by default.

The organisation should implement technical resilience and mitigation measures to ensure the availability of its product's essential and basic functions. This includes ensuring the product can withstand and recover from incidents without a complete loss of its core purpose.

Cybersecurity risk assessments performed by the organisation should identify potential threats to the availability of the essential and basic functions of their products. These assessment forms the basis for defining and implementing resilience and mitigation measures, including protection against denial of service attacks. Such protections can include, for example:

• Rate limiting and connection throttling
• Defining degraded operating modes
• Recovery mechanisms like watchdog timers and automatic restarts of failed services
• Protocol level robustness to handle malformed packets without crashing
• Device health-status reporting

The organisation should design its products with digital elements to prevent them from negatively impacting the availability of other services or networks on the basis of risks identified during the risk assessment process. This includes implementing measures to prevent the product from being used in denial of service attacks and limiting its network resource consumption to reasonable levels.

The organisation should implement a secure design, development and production process to limit the attack surface of its products based on risks identified during the risk assessment. This process should ensure all non essential ports, protocols, services and external interfaces are disabled or removed by default.

The organisation should implement technical measures in the product's software to make it more resilient to exploitation. These techniques aim to disrupt common attack methods and limit the potential damage if a security vulnerability is successfully exploited.

The selection of techniques should be based on the product's risk assessment and may include:

• Address Space Layout Randomization (ASLR)
• Data Execution Prevention (DEP)
• Stack protection mechanisms

The organisation should design its products to record and monitor relevant internal security activities. This logging should cover events such as access to or modification of data, services, or functions. The product must also include a clear and accessible mechanism for the user to opt out of this monitoring.

The organisation should design and implement a feature that allows users to securely and easily remove all personal data and settings on a permanent basis. If the product supports transferring data to other systems, this process must also be secure, for example by using encryption during the transfer.

The organisation should ensure that for any free and open source software products falling under the categories of Annex III of the Cyber Resilience Act, the technical documentation is made publicly available. This action is necessary to demonstrate conformity with the essential cybersecurity requirements at the time the product is placed on the market.

The organisation should ensure it has registered and has active access to the single reporting platform designated for notifying authorities like the CSIRT coordinator and ENISA. Key personnel should be familiar with the platform's functionality to ensure that the mandatory 24 hour early warning can be submitted without technical delays.

A clear procedure for managing and reporting actively exploited vulnerabilities to the relevant authorities (CSIRT coordinator and ENISA) should be in place. This procedure must ensure compliance with the strict reporting timelines.

The procedure should define responsibilities and steps for:

• Submitting an early warning within 24 hours of awareness.
• Providing a more detailed vulnerability notification within 72 hours.
• Issuing a final report no later than 14 days after a security update or fix is available.

The 24-hour warning should indicate which Member States are affected by the vulnerability. The 72-hour notification should include specific user-side mitigation measures. Mitigation measures, impact, and corrective actions taken should be documented in each step of the procedure.

The final report should include details on the malicious actor responsible. The 24-hour, 72-hour, and final reports should all be submitted to the CSIRT coordinator and ENISA.

The organisation ensures security is built into products with digital elements from the start. It is part of design, development and production, never an afterthought.

In practice this means:

• Design and implementation choices are driven by the product's cybersecurity risk assessment.
• Products follow secure development principles — secure defaults, minimal attack surface, least privilege — and are delivered without known exploitable vulnerabilities.
• The data a product handles is protected (e.g. through encryption), and products contain no undocumented functionality, hidden access paths or hardcoded credentials.
• Products support accountability: security events can be logged and users can securely remove their data.
• Any deviation from these principles is escalated before it reaches production.

The organisation ensures general rules for secure product development has been drawn up and approved by product development managers. The implementation of these rules is monitored. Rules are reviewed at least yearly.

Secure product development policy may include, for example:

• Security requirements for the development environment
• Instructions for secure coding of the programming languages used
• Security requirements at the product design stage
• Secure software repositories
• Version control security requirements
• The skills required from developers to avoid, discover and fix product vulnerabilities
• Compliance with secure coding standards

Compliance with the rules of product secure development is required of key partners.

Technical documentation provides the evidence our products meet the essential cybersecurity requirements. The organisation should ensure it is accurate, current and traceable at all times.

In practice this means:

• Documentation reflects how design, development and vulnerability handling actually operate, and is updated whenever the product, its components or its risk assessment change.
• Risk assessments, their outcomes and an up-to-date software bill of materials are maintained as part of the technical file for each product and version.
• Documentation lives in approved systems, retained for the required period, with integrity preserved — nothing backdated, retroactively altered or omitted.
• Gaps are flagged to the compliance owner as soon as they are noticed.