A grounded CRA checklist for manufacturers and product teams preparing products with digital elements for EU market access.
Use it to turn scope, security requirements, vulnerability handling, reporting, documentation, conformity, CE marking, and support-period duties into evidence-backed release gates.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this checklist before placing a product with digital elements on the EU market and during the support period. Record the product boundary, responsible economic operator, applicable Annex I requirements, conformity route, release decision, reporting readiness, and the evidence that a market surveillance authority could request.
Start by defining the product with digital elements, the version or product family, and any remote data processing solution that is necessary for the product to perform one of its functions. Do not treat the website, cloud account, mobile app, firmware, backend API, and hardware enclosure as separate evidence sets until the CRA product boundary is clear.
Then record the economic-operator role for each market path. Manufacturers carry the core CRA design, development, production, vulnerability-handling, conformity, documentation, and CE marking duties; importers and distributors need checks that the required marking, declaration, instructions, and contact information are present before making products available.
Use Assessment Autopilot to turn CRA scope records, Annex I controls, vulnerability-handling duties, Article 14 reporting templates, technical documentation, conformity evidence, and CE marking checks into owned implementation work.
Create owned CRA work items for product scope, security controls, vulnerability handling, reporting readiness, documentation, and conformity evidence.
Review product boundaries, conformity routes, evidence gaps, and support-period operations before EU market placement.
The CRA does not ask teams to prove that a product has no vulnerabilities at all. It requires a cybersecurity risk assessment and, where applicable, release of products without known exploitable vulnerabilities, with secure-by-default configuration, security-update capability, and other objective security properties.
Use these checks as release gates. For every Annex I Part I requirement, record whether it is applicable, the implemented control, the test or review evidence, and the reason if the requirement is not applicable to the product.
Vulnerability handling is a support-period operating obligation. The evidence should show that security issues can be received, triaged, remediated, disclosed, and distributed as updates without losing traceability.
Treat component vulnerability intelligence and coordinated vulnerability disclosure as part of product maintenance, not as a separate security-team inbox.
Article 14 reporting should be prepared as an incident workflow before the reporting obligations apply. The trigger is awareness of an actively exploited vulnerability or a severe incident having an impact on the security of the product with digital elements.
The checklist should distinguish discovery, legal/reporting assessment, ENISA single reporting platform submission, user notification, component notification, and authority follow-up.
The technical documentation is not only an internal engineering archive. It must be comprehensive enough for market surveillance authorities to assess the product, the cybersecurity risk assessment, the vulnerability-handling process, the standards or specifications used, and the test evidence.
User information should let buyers and operators identify the product, understand secure deployment conditions, find the vulnerability reporting point, install security updates, and know the support-period end date.
Select the conformity route after scope and classification are documented. Default products can generally use internal control, while important or critical products may need Module B+C or Module H unless a specific self-assessment route is available.
CE marking and the EU declaration of conformity should be the end of a documented assessment, not a substitute for it.
The support period determines how long vulnerability handling and security-update expectations remain operational. The manufacturer should justify it with product use expectations, operating environment, similar products, component support, and other relevant factors.
Evidence control matters because CRA records can outlive a release cycle. Keep product, security, legal, and compliance records tied to the exact version or unit placed on the market.
"mandatory cybersecurity requirements for manufacturers"
"The CRA does not require manufacturers to ensure that a product is free from all vulnerabilities."
"essential cybersecurity requirements for products with digital elements"