CRA FAQ clarifies open-source steward reporting starts in December 2027

The 60-second summary

The 4 September 2026 FAQ update distinguishes stewards’ 11 December 2027 reporting start from manufacturers’ 11 September 2026 duties. This clarifies existing law; it does not extend manufacturers’ deadlines.

Timeline that matters

10 December 2024
CRA enters into force
Regulation (EU) 2024/2847 entered into force and the transition period began.
11 September 2026
Manufacturer reporting begins
Article 14 reporting applies to in-scope manufacturers; this is not the Article 24(3) start date for stewards.
11 December 2027
Main obligations apply
The main obligations of the Regulation, including the essential cybersecurity requirements, technical documentation and conformity assessment, begin to apply.
4 September 2026
FAQ version 1.4
Question 5.5 added.
11 December 2027
Steward reporting begins
Article 24(3) applies to open-source software stewards in its specified circumstances.

What changed

Revision to the existing CRA briefing: FAQ version 1.4, dated 4 September 2026, adds question 5.5. It expressly places Article 24(3) reporting for open-source software stewards on the 11 December 2027 timetable. The published briefing groups several roles around the September 2026 reporting milestone without making this exception explicit. This draft adds that distinction; the underlying Regulation and its dates are unchanged.

Who should pay attention?

Manufacturers of products with digital elements

Organisations that place hardware or software with digital elements on the EU market under their own name or trademark, including software supplied separately from a device.

Component, library and embedded-software suppliers

Suppliers whose components are integrated into products placed on the EU market may need to assess how the Regulation reaches their part of the chain.

Importers and distributors

Economic operators that place products on, or make products available to, the EU market carry verification duties that differ from those of the manufacturer.

Open-source software stewards

Assess the tailored Article 24 regime and its December 2027 reporting start separately from manufacturer activities.

Product, security, legal and privacy teams outside the EU

Market placement rather than establishment is the relevant trigger, so non-EU organisations supplying the EU market may need to assess their position.

What the guidance clarifies

Different roles, different reporting dates: An organisation should assess each activity separately. Being associated with open-source software does not automatically establish steward status or remove manufacturer duties.
When a product is placed on the market: The guidance addresses the point at which obligations attach, including for software made available for download, and how later versions and updates are treated.
Software as a product with digital elements: It discusses how standalone software, software supplied with hardware, and software components are treated, which affects who holds the manufacturer role.
Remote data processing solutions: Remote functionality that a product depends on to perform its function may fall inside the product boundary, while functionality outside that dependency is generally treated differently.
Open-source software and stewardship: The guidance sets out how commercial activity and stewardship are approached, and what may be expected of each role.
Conformity assessment and product categories: It explains how product categorisation influences the conformity-assessment route, including where harmonised standards or third-party involvement may be relevant.

Global relevance — scope depends on your products and role

Why this matters for global organisations.

A single reporting calendar can assign the wrong deadline to different supply-chain roles. Maintain activity-level role assessments, accountable reporting owners and tested supplier escalation routes.

Organisations placing connected products into regulated markets under their own name or trademark may have manufacturer responsibilities.
Software, library and component suppliers may be asked for security evidence even when they are not the final product manufacturer.
Service and maintenance providers may receive contractual requirements for vulnerability handling, incident coordination and security updates.
Assess applicability separately for each product and economic-operator role, with qualified legal advice where the position is unclear.
Product-security evidence can also support customer assurance reviews, supplier assessments and related privacy obligations.

12 actions to start now

Build an inventory of products with digital elements sold or supplied into the EU.
Map whether remote data processing and software components may be in scope.
Identify the organisation's economic-operator role for each product.
Gap-assess lifecycle cybersecurity requirements.
Document product-level cybersecurity risk assessments.
Strengthen secure-development and vulnerability-handling processes.
Define and evidence support periods and security-update commitments.
Prepare manufacturer reporting for 11 September 2026; separately plan applicable steward reporting for 11 December 2027.
Map technical documentation, conformity-assessment and CE-marking evidence needs.
Assign owners, milestones and supplier dependencies ahead of December 2027.
Record the legal basis for each manufacturer/steward role assessment.
Update reporting calendars, supplier escalation routes and owner training to distinguish the two regimes.

Evidence worth retaining

Product inventory recording, for each entry, the assessed economic-operator role and scope position.
Product-level cybersecurity risk assessments, dated and version controlled.
Software bill of materials per product release, including third-party and open-source dependencies.
Documented vulnerability-handling and coordinated disclosure process, with a monitored contact route.
Stated support period and security-update commitment as communicated to customers.
Reporting runbook for actively exploited vulnerabilities and severe incidents, with a dry-run record.
Technical documentation pack mapped to conformity-assessment and CE-marking evidence needs.
Approved role assessment with dated source copies and separate reporting calendars.
Versioned record of this clarification and reviewer approval before replacing the published briefing.

Questions to take to counsel or your conformity team

These are discussion prompts, not legal advice or conclusions.

For each product we supply into the EU, what economic-operator role do we hold, and on what basis was that assessed?
Does any remote data processing we operate form part of a product with digital elements?
Which products, if any, fall into categories that affect the conformity-assessment route?
What support period can we credibly commit to and resource for each product?
Who is authorised to declare a severe incident and to report within the applicable deadlines, including out of hours?
How would CRA reporting interact with our existing personal data breach and sectoral notification processes?
Which supplier contracts need to change so that vulnerability information and security updates reach us in time?
Are we a steward, manufacturer, or performing different roles across our activities?
Which Article 24(3) conditions apply to our development activity and infrastructure?

Official sources

PrivacyBuilt / PrivacyBuilt is an independent educational publisher. It is not affiliated with, or endorsed by, any regulator or the European Union.

PrivacyBuilt publishes educational and technical guidance. Nothing on this site constitutes legal advice, and it should not be relied on as a legal determination for your organisation.

LinkedIn Share on X WhatsApp