ChecklistEU

EU Cyber Resilience Act Product Security Checklist

A source-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.

Back to main artifact Review sources

Author

Sorena AI

Published

Mar 4, 2026

Updated

Jul 31, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Mar 4, 2026

Updated Jul 31, 2026

Overview

Review this checklist before placing a on the EU market and during the . 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.

Section 1

Scope, product boundary, and role checks

Start by defining the , 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.

Create one inventory record per product, product family, version line, hardware variant, firmware branch, software release train, and necessary remote data processing solution.
Confirm whether the product is made available on the EU market in the course of a commercial activity and whether a sector exclusion or overlapping Union product law changes the compliance route.
Classify each in-scope product as default, important class I, important class II, or critical, and keep the Annex III or Annex IV rationale if the product has a listed core functionality.
Name the manufacturer, authorised representative if used, importer, distributor, fulfilment service provider if relevant, and the EU contact point responsible for authority cooperation.
Keep evidence for scope exclusions, open-source component treatment, third-party component due diligence, tailor-made product terms, and any decision that a remote service is outside the CRA product boundary.

Recommended next step

Convert the CRA checklist into release gates

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.

Assessment workflow

Open Assessment Autopilot

Create owned CRA work items for product scope, security controls, vulnerability handling, reporting readiness, documentation, and conformity evidence.

Explore next step

Talk to Sorena

Talk through implementation

Review product boundaries, conformity routes, evidence gaps, and support-period operations before EU market placement.

Explore next step

Section 2

Application-date and transition checks

Schedule the checklist against the CRA's staged application. Article 14 reporting applies from 11 September 2026. Most other duties apply from 11 December 2027, while Chapter IV on notified bodies has applied since 11 June 2026.

For a product placed on the market before 11 December 2027, the remaining CRA requirements generally apply only if the product undergoes a substantial modification from that date. Article 14 reporting still applies to all earlier in-scope products, so a legacy-product inventory cannot be omitted from reporting readiness.

Record the placement-on-market date and support status for each product version or unit covered by the checklist.
Include earlier in-scope products in Article 14 intake, triage, escalation, and user-notification procedures before 11 September 2026.
Create a change review for post-11 December 2027 modifications to earlier products and record whether the change is substantial.
Apply the full pre-market checklist to products first placed on the market from 11 December 2027.

Section 3

Annex I Part I product security checks

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.

Risk assessment: document intended purpose, reasonably foreseeable use and misuse, operating environment, threat assumptions, security objectives, residual risks, and the product lifetime considered.
Known exploitable vulnerabilities: block release when reliable evidence shows a vulnerability can be effectively exploited under practical operational conditions.
Secure by default: verify default credentials, access control, exposed services, cryptographic defaults, logging defaults, network interfaces, reset behavior, and any business-user tailor-made exception.
Security updates: verify that vulnerabilities can be addressed through security updates, with automatic security updates enabled by default where applicable, user notification, and an opt-out or postponement mechanism where required.
Core security properties: test controls for unauthorised access, confidentiality, integrity, data minimisation, availability, denial-of-service resilience, attack-surface limitation, exploitation mitigation, security monitoring, and secure removal or transfer of user data and settings.

Section 4

Annex I Part II vulnerability-handling checks

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.

Maintain a commonly used, machine-readable covering at least top-level dependencies, and connect each SBOM record to the product version it supports.
Document the vulnerability intake path, public reporting contact, coordinated vulnerability disclosure policy, component-maintainer notification process, severity assessment, exploitability assessment, remediation owner, and closure evidence.
Run regular product security tests and reviews, including regression checks for update mechanisms, default configuration, authentication, exposed interfaces, logging, and data-removal behavior.
Address and remediate vulnerabilities without delay in relation to product risk, using patches, mitigations, workarounds, configuration guidance, user advisories, or documentation updates as appropriate.
Distribute security updates securely, free of charge unless a tailor-made business-user exception applies, and separate security updates from functionality updates where technically feasible.

Section 5

Article 14 reporting and user-notification checks

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 .

The checklist should distinguish discovery, legal/reporting assessment, ENISA single reporting platform submission, user notification, component notification, and authority follow-up.

Define awareness sources: customer reports, partner evidence, threat intelligence, government agency notice, ethical hacker reports, telemetry, honeypots, internal monitoring, and component-maintainer notifications.
Prepare early-warning templates for the 24-hour notification clock covering product identity, affected Member States where known, suspected malicious activity, sensitivity marking, and known immediate mitigation.
Prepare 72-hour notification templates for general product information, exploit or incident nature, initial assessment, corrective or mitigating measures taken, and user actions that can reduce impact.
Prepare final-report templates: for actively exploited vulnerabilities, due no later than 14 days after a corrective or mitigating measure is available; for severe incidents, due within one month after the incident notification.
Keep user-notification records showing which impacted users, and where appropriate all users, were informed of the vulnerability or incident and what action they were asked to take.

Section 6

Technical documentation and user-information checks

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.

Product description: include intended purpose, affected software versions, hardware photos or illustrations where relevant, architecture diagrams, interfaces, remote data processing dependencies, and user instructions.
Design and process evidence: include architecture, development controls, production and monitoring process validation, vulnerability-handling specifications, SBOM, disclosure policy, reporting contact, and secure-update distribution design.
Risk and requirements evidence: include the cybersecurity risk assessment, Annex I applicability mapping, support-period rationale, residual-risk decisions, standards or common specifications used, and alternative technical solutions where standards were not fully applied.
Verification evidence: include test reports for product requirements and vulnerability-handling processes, conformity-assessment records, the EU declaration of conformity, and authority-request handling for SBOM access where applicable.
User-facing information: include manufacturer contact details, vulnerability contact, unique product identification, intended purpose, secure deployment assumptions, significant cybersecurity risks, support type, support-period end date, update installation instructions, and declaration-of-conformity access.

Section 7

Conformity assessment, declaration, and CE marking checks

Select the conformity route after scope and classification are documented. Default products can generally use internal control. Important class I products can use internal control only under the Article 32 conditions, while important class II and critical products require Module B+C, Module H, or an applicable certification route. Article 32(5) separately allows qualifying important class I or II free and open-source software to use internal control when its technical documentation is made public.

CE marking and the EU declaration of conformity should be the end of a documented assessment, not a substitute for it.

Record the chosen conformity route: Module A internal control, Module B+C EU-type examination plus conformity to type, Module H full quality assurance, or another route permitted by the CRA for the product category.
For Module A, keep evidence that the manufacturer verified applicable CRA essential requirements, drew up technical documentation, controlled production and vulnerability handling, signed the declaration, and affixed CE marking.
For Module B+C or Module H, keep notified-body selection, certificate, audit, quality-system, reassessment, and surveillance evidence, including changes that may affect the approved type or vulnerability-handling process.
Prepare the EU declaration of conformity for the product, keep it with the technical documentation for 10 years after placing on the market or for the , whichever is longer, and make it available to authorities on request.
Verify CE marking placement: visible, legible, indelible for physical products where possible; for software, on the EU declaration of conformity or an easily and directly accessible accompanying website section.

Section 8

Support-period and evidence-control checks

The 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.

Set a of at least five years unless the product is expected to be in use for less than five years; use a longer period where the product is reasonably expected to remain in use longer.
Document the support-period rationale in the technical documentation, including expected use time, component support, operating environment, and why any shorter-than-five-year period is justified by product nature.
Track end-of-support communications, update availability, archival access, component end-of-support dependencies, and user guidance for secure retirement or replacement.
Retain the declaration of conformity, technical documentation, certificates, test reports, SBOM records, vulnerability decisions, user notices, and authority correspondence under version-controlled evidence ownership.
Create release and change-control gates for substantial modifications, security-relevant updates, support-period changes, new market paths, new importers or distributors, and authority requests.

Primary sources

References and citations

European Commission CRA reporting obligations

digital-strategy.ec.europa.eu

Referenced sections

Current Commission implementation page for the 11 September 2026 reporting start, staged notification deadlines, and Single Reporting Platform.

European Commission Cyber Resilience Act policy page

digital-strategy.ec.europa.eu

Referenced sections

Supports the page framing that the CRA covers software and hardware products with digital elements, lifecycle vulnerability handling, CE marking, market surveillance, and staged application of reporting and main obligations.

"mandatory cybersecurity requirements for manufacturers"

European Commission FAQs on the Cyber Resilience Act, version 1.3, July 2026

ec.europa.eu

Referenced sections

Supports implementation distinctions used in the checklist, including known exploitable vulnerabilities, secure-by-default expectations, support-period criteria, reporting triggers, conformity modules, CE marking, and declaration-of-conformity handling.

"The CRA does not require manufacturers to ensure that a product is free from all vulnerabilities."

Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal

eur-lex.europa.eu

Referenced sections

Supports the checklist items for CRA scope, Annex I essential cybersecurity requirements, Article 14 reporting clocks, technical documentation contents, conformity assessment, declaration retention, CE marking, and support-period obligations.

Related guides