CRA preparation should be organised as a product lifecycle programme rather than a last-minute documentation project. The strongest readiness plan connects product scope, legal roles, cybersecurity risk, engineering controls, vulnerability handling, technical evidence, conformity assessment and post-market support while operating the Article 14 reporting process that already applies.
Start With a Product Inventory, Not a Policy Library
The first practical CRA task is to identify the products that may require analysis. Build an inventory of software, hardware, connected devices, embedded software, separately marketed components and relevant remote data processing solutions. Record who markets each product, the intended purpose, the EU market route, supported versions and whether the product will continue to be placed on the market after December 2027. This product-level inventory becomes the backbone of the CRA programme. Starting with generic cybersecurity policies can produce large amounts of documentation without answering the fundamental question of which product, version and economic operator the evidence relates to.
Complete Scope and Economic-Operator Assessments
For each product, determine whether it falls within the CRA definition and whether an exclusion, sector-specific interaction or transitional provision changes the analysis. Then map the legal role of each organisation in the supply chain. Identify the manufacturer, importer, distributor and authorised representative where relevant. Own-brand arrangements, significant product modifications and outsourced development can affect the manufacturer analysis. Record the reasoning instead of relying on job titles or commercial contract labels. A product that is incorrectly classified at the scope or role stage can send every later compliance workstream in the wrong direction.
Perform the Cybersecurity Risk Assessment Early
Article 13 requires manufacturers to undertake a cybersecurity risk assessment and to take its outcome into account across planning, design, development, production, delivery and maintenance. This makes the risk assessment an engineering input rather than a document that should be written after the product is finished. Define assets, trust boundaries, intended and reasonably foreseeable use, operational environment, dependencies, attack paths and potential impact. Connect each material risk to product decisions and verification evidence. When the product changes, revisit the assessment so that the technical documentation continues to represent the marketed version.
Map Annex I to Real Product Controls and Evidence
Create a requirement-by-requirement map between Annex I and the product. For each applicable essential cybersecurity requirement, identify the implementation decision, responsible team, verification method and evidence location. The evidence might include architecture records, secure-default configuration, authentication controls, data-protection mechanisms, resilience testing, attack-surface decisions, logging behaviour, update mechanisms or other product-specific measures. Annex I Part II also needs to be connected to vulnerability handling. Where a requirement is not applicable, the manufacturer should be able to support that conclusion rather than leaving an unexplained blank cell in a checklist.
Build Component and Vulnerability Handling Into Normal Engineering
The CRA requires systematic vulnerability handling across the support lifecycle. Product teams should be able to identify components and dependencies, receive vulnerability reports, assess affected versions, remediate vulnerabilities, verify corrections and distribute security updates. Annex I Part II includes a requirement to identify and document vulnerabilities and components, including a software bill of materials in a commonly used and machine-readable format covering at least top-level dependencies. The useful goal is not merely to generate an SBOM file at release. Component information needs to remain connected to vulnerability triage and supported product versions so that the organisation can determine quickly where a newly disclosed component issue creates product risk.
Operate Article 14 Reporting Now
December 2027 is not the first date on which companies need an operational CRA process. Article 14 reporting obligations have applied to manufacturers since 11 September 2026. Organisations within scope should already have procedures for identifying possible actively exploited vulnerabilities and severe incidents, recording awareness time, performing rapid legal and technical assessment and submitting required notifications through the Single Reporting Platform. The reporting workflow should use the same product inventory, version data and vulnerability records being developed for broader CRA readiness. Waiting until the main application date to build this process would ignore an obligation that is already active.
Define the Support Period and Security Update Model
Products need an operational model for post-market security support. Manufacturers should determine the support period using the CRA framework, document the reasoning and ensure that vulnerability handling and security-update capability are available for the required period. Product, commercial and engineering teams need a consistent answer about which versions remain supported, when security updates are provided, how users receive them and what happens when support ends. Support commitments should be reflected in product information and should be realistic given component lifecycles and the manufacturer's ability to investigate and remediate vulnerabilities.
Build Technical Documentation as the Product Is Built
Annex VII technical documentation should emerge from the product development process rather than be reconstructed shortly before conformity assessment. Maintain the product description, intended purpose, architecture, cybersecurity risk assessment, applicable requirements, design and development evidence, testing results, vulnerability-handling information and conformity records in a structure that can be traced to a particular product version. The documentation should also remain maintainable after market placement. Where evidence exists only in temporary project systems or individual engineers' notes, create a durable product record before the information becomes difficult to recover.
Determine Product Classification and Conformity Route Early
Do not wait until late 2027 to determine whether a product is general, important or critical under the CRA framework. The product category can influence which conformity assessment procedures are available and whether third-party involvement is required. Review Annexes III and IV together with the applicable technical descriptions and current Commission material. Once the likely route is understood, identify the evidence, standards, notified-body capacity or certification work that may be required. Products with long development or external assessment cycles need this decision earlier than products using a simpler conformity route.
Use the Remaining Transition Period for Product-Level Dry Runs
Before December 2027, select representative products and run the full CRA workflow as though the main requirements already applied. Confirm that the team can explain scope, economic-operator role, product classification, cybersecurity risks, Annex I implementation, component records, support period, user information, technical documentation, vulnerability workflow and conformity route. Test how quickly an Article 14 issue can be escalated and how an authority request for product evidence would be answered. Gaps identified during a dry run are easier to fix while product architecture and documentation processes are still being developed.
Treat 11 December 2027 as an Operational Deadline
The objective should be to enter December 2027 with a repeatable product-security and compliance system already functioning. The main CRA application date is not a useful target for beginning inventory work, rewriting development procedures or discovering that third-party conformity assessment may be necessary. The Commission has already issued practical implementation guidance in 2026, and further standards, guidance and implementation material can continue to develop during the transition. Companies should therefore combine a stable internal CRA operating model with a regulatory monitoring process that can incorporate new official material without rebuilding the entire programme.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.