A CRA manufacturer must update the technical documentation, the risk assessment and the EU Declaration of Conformity after each new release, component change, exploited vulnerability, severe incident, threat change, support period change and economic operator change.
Key takeaways
- Article 31(2) requires the technical documentation to be continuously updated, at least during the support period.
- Every new release needs the four-factor test in Commission guidance C(2026) 5252 point 110. A positive answer makes the release a substantial modification, and the modified product needs a new conformity assessment.
- The size of a change does not decide whether the change is substantial. Point 107 of the guidance turns the test on the impact on the cybersecurity risk profile.
- Article 14 reporting has applied since 11 September 2026. An actively exploited vulnerability or a severe incident needs an early warning within 24 hours.
- A market surveillance authority can ask for the technical documentation and the Declaration of Conformity for at least ten years after placing on the market, or for the support period where that is longer.
Which changes need a record?
Eight kinds of change oblige a manufacturer to update at least one compliance document. Not every change touches all three documents. The table shows which document each change affects.
| Change | Legal basis | What to update |
|---|---|---|
| New software or firmware release | Art 3(30), Art 31(2), C(2026) 5252 point 110 | Four-factor test result, technical documentation, SBOM |
| Change of intended purpose | Art 3(30) | New conformity assessment, new Declaration of Conformity |
| Component or dependency change | Art 13(5), Annex I Part II(1) | SBOM, risk assessment, component due diligence |
| Actively exploited vulnerability or severe incident | Art 14 | Notifications to the CSIRT and ENISA, user information, risk assessment |
| Vulnerability in an integrated component | Art 13(6) | Upstream report to the component maintainer |
| New threat or risk exposure | Art 13(3), Art 13(7) | Risk assessment |
| Support period change or end of support | Art 13(8) | Support period basis, user information under Annex II |
| Manufacturer, authorised representative or notified body change | Art 28(2), Annex V | Declaration of Conformity |
A ninth item is not a change but a habit. A periodic review catches drift that no single event shows. The documentation maintenance guide explains a quarterly or semi-annual cadence.
Does every new release need a new conformity assessment?
No. Only a substantial modification needs a new conformity assessment. Every release needs the test that decides whether the release is substantial, and a written record of the result.
Article 3(30) defines a substantial modification as a change after placing on the market that affects compliance with the Annex I Part I essential requirements, or that changes the intended purpose. Commission guidance C(2026) 5252 point 110 turns the definition into four questions.
- Does the update introduce new threat vectors, such as new interfaces, communication channels, execution environments or external dependencies?
- Does the update enable new attack scenarios?
- Does the update change the likelihood of attack scenarios that the risk assessment already identified?
- Does the update change the impact of attack scenarios that the risk assessment already identified?
If all four answers are no, and the assumptions in the risk assessment still hold, the update is unlikely to be a substantial modification. If one answer is yes, the modified product is placed on the market again. The modified version then needs a conformity assessment, an updated technical file, a new Declaration of Conformity and its own support period. The conformity assessment may focus on the modified parts where the change does not harm the cybersecurity of the product as a whole.
A product assessed by a notified body has one more step. Recital 41 says that a change that might lead to a substantial modification should be notified to the notified body.
Two common mistakes
The first mistake is to judge by size. Point 107 says the test turns on the potential adverse impact on the cybersecurity risk profile, not on the size of the change. Example 44 of the guidance treats a "remember me" login feature that stores tokens on the device as a substantial modification. Example 43 treats the activation of a control feature that was designed, assessed and shipped disabled as not substantial.
The second mistake is to treat "security update" as an exemption. Recital 39 excludes a security update from substantial modification only when the update is designed to decrease the cybersecurity risk and does not change the intended purpose. Point 109 of the guidance adds that a security update that introduces new or increased risks is substantial. Example 49 moves local encryption to a remote service, and Example 50 adds a third-party key management service. The guidance treats both security updates as substantial. The worked examples page reproduces each case.
Which vulnerabilities and incidents must be reported?
An actively exploited vulnerability and a severe incident that affects the security of the product must be notified under Article 14. The obligation has applied since 11 September 2026, more than a year before the rest of the CRA applies on 11 December 2027.
| Stage | Deadline | Clock starts |
|---|---|---|
| Early warning | 24 hours | Awareness |
| Notification | 72 hours | Awareness |
| Final report, vulnerability | 14 days | A corrective or mitigating measure becomes available |
| Final report, severe incident | One month | The incident notification |
The notifications go to the CSIRT designated as coordinator and to ENISA through the Single Reporting Platform. Article 14(8) also requires the manufacturer to inform impacted users and, where appropriate, all users. A vulnerability report that is valid but shows no exploitation does not start the Article 14 clock. The report still goes through the vulnerability handling process in Annex I Part II. The reporting timelines guide gives the content of each stage.
Each reported event is also a risk assessment event. Article 13(3) requires the risk assessment to be updated as appropriate during the support period, and an exploited vulnerability shows that an assumption in the assessment was wrong.
What about third-party components?
A component change is a documentation event, and a vulnerability in a component is a reporting event. Annex I Part II(1) requires the manufacturer to identify and document the components of the product, including a software bill of materials. A new release with a new dependency therefore needs a new SBOM.
Article 13(5) requires due diligence on third-party components. Article 13(6) requires a manufacturer that finds a vulnerability in an integrated component to report the vulnerability to the person or entity that maintains the component. Where the manufacturer develops a fix, the manufacturer shares the relevant code or documentation with the maintainer. The SBOM guide covers the minimum elements.
When does the support period need a new record?
The support period needs a new record when the expected use time changes, when the end date moves, and after every substantial modification. Article 13(8) sets five years as the minimum, unless the product is expected to be in use for a shorter time. Commission guidance C(2026) 5252 point 126 requires a longer period for a product that is in use for longer.
A substantial modification does not reset or extend the existing period. Points 128 and 131 require the modified version to have its own declared support period, derived again against the Article 13(8) criteria. Article 13(19) requires the end date, at least the month and the year, to be clear at the time of purchase, so a new end date also changes the product page, the packaging or the digital notice. The support period guide explains the derivation.
Does a manufacturer report these changes to an authority?
No, not as a routine. The CRA puts no duty on the manufacturer to send each change to an authority. The duty is to keep the documents current and to make them available. Three events are the exception.
| Event | Recipient | Basis |
|---|---|---|
| Actively exploited vulnerability or severe incident | CSIRT designated as coordinator and ENISA | Art 14 |
| Change that might lead to a substantial modification, where a notified body did the assessment | Notified body | Recital 41 |
| Cessation of operations that stops compliance | Market surveillance authorities and users, before the cessation | Art 13(23) |
Article 13(13) requires the manufacturer to keep the technical documentation and the EU Declaration of Conformity at the disposal of market surveillance authorities for at least ten years after placing on the market, or for the support period where that is longer. An authority that asks for the file sees the file as it is on that day. A file that describes a product three releases old shows the gap at the first comparison.
How does CVD Portal record these changes?
CVD Portal keeps one record per product for each change type in the table above.
- The substantial modification panel runs the point 110 four-factor test for each release. The panel gives no verdict while a decisive question is unanswered, and a substantial verdict asks for a new snapshot and a new support period.
- An SBOM upload per release feeds a supply-chain scan. A critical, high-severity or actively exploited component vulnerability opens a review trigger on each affected product.
- A vulnerability report that arrives through the public portal opens a review trigger when triage confirms the report as valid. Escalation as actively exploited starts the Article 14 timeline.
- The product record holds the manufacturer, authorised representative, importer, distributor and notified body. The generated Declaration of Conformity reads the manufacturer, authorised representative and notified body from that record.
- A review clock reminds the team 30 days before each periodic review, and a support period countdown warns 90 and 30 days before the declared end date.
The CRA compliance platform page shows the full workspace. The CRA maturity assessment is a free check of where a product stands today.
Sources
Regulation (EU) 2024/2847 has the CELEX identifier 32024R2847 and the ELI http://data.europa.eu/eli/reg/2024/2847/oj.
- Regulation (EU) 2024/2847, Article 3
- Regulation (EU) 2024/2847, Article 13
- Regulation (EU) 2024/2847, Article 14
- Regulation (EU) 2024/2847, Article 28
- Regulation (EU) 2024/2847, Article 31
- Regulation (EU) 2024/2847, Annex I
- Commission guidance C(2026) 5252 on the application of Regulation (EU) 2024/2847, points 105 to 111 and 126 to 131
Frequently asked questions
Does every software update need a new CRA conformity assessment?
No. Only a substantial modification needs a new conformity assessment and a new EU Declaration of Conformity. Every release still needs the four-factor test of Commission guidance C(2026) 5252 point 110, and a record of the result.
Is a security update ever a substantial modification under the CRA?
Yes. Recital 39 excludes a security update only when the update is designed to decrease the cybersecurity risk and does not change the intended purpose. Point 109 of Commission guidance C(2026) 5252 treats a security update that adds new risks as substantial, and Examples 49 and 50 show two cases.
Must a manufacturer report product changes to an authority under the CRA?
Not as a routine. The manufacturer keeps the technical documentation current and gives it to a market surveillance authority on request. Three events go out without a request: Article 14 notifications to the CSIRT and ENISA, a possible substantial modification to the notified body under recital 41, and a cessation of operations under Article 13(23).