--- title: "CRA Substantial Modification FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/substantial-modification" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/substantial-modification" author: "Sorena AI" description: "Cyber Resilience Act FAQ on when software updates, repairs, spare parts, and post-market changes become substantial modifications and trigger CRA manufacturer, evidence, and conformity duties." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA substantial modification" - "Cyber Resilience Act software update" - "CRA repairs spare parts" - "CRA new manufacturer" - "CRA conformity assessment" - "Cyber Resilience Act" - "CRA FAQ" - "EU product cybersecurity" - "Substantial modification" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Substantial Modification FAQ Cyber Resilience Act FAQ on when software updates, repairs, spare parts, and post-market changes become substantial modifications and trigger CRA manufacturer, evidence, and conformity duties. *FAQ* *EU* *Cyber Resilience Act* ## Cyber Resilience Act FAQ Substantial Modification This FAQ helps decide when a post-market change to a product with digital elements may become a CRA substantial modification. For product, engineering, repair, legal, and compliance teams assessing software updates, replacement parts, conformity evidence, and manufacturer obligations. Under the Cyber Resilience Act, a post-market change is not automatically a new product event. It becomes a substantial modification when it affects compliance with Annex I Part I essential cybersecurity requirements or changes the intended purpose for which the product was assessed. This page explains the practical consequences for software updates, repairs, spare parts, conformity files, legacy products, and parties that become the CRA manufacturer after a modification. ## What is a substantial modification under the Cyber Resilience Act? A CRA substantial modification is a change made after a product with digital elements has been placed on the market that affects the product's compliance with Annex I Part I essential cybersecurity requirements or changes the intended purpose for which the product was assessed. The test is about the change's cybersecurity and intended-purpose effect. A release note label such as patch, upgrade, repair, maintenance, hotfix, or feature update does not decide the answer by itself. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Defines substantial modification in Article 3(30) by reference to Annex I Part I compliance and assessed intended purpose. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Explains in points 85-87 why substantial modification matters across manufacturer status, legacy products, and conformity reassessment. ## Does every post-market software update become a CRA substantial modification? No. Software development is iterative, and the CRA guidance expects a case-by-case assessment. A later software iteration is not substantial merely because the code changed. The key question is whether the update introduces new or increased cybersecurity risks that were not already covered in the original risk assessment, affects compliance with the essential requirements, or changes the product's assessed intended purpose. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 39 distinguishes security updates and minor functionality updates from feature updates that change intended functions, type, performance, or risk. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Points 95-106 give the software-update assessment factors for substantial modification. ## Are CRA security updates usually substantial modifications? Usually no. A security update whose purpose is to reduce cybersecurity risk, and that does not change the product's intended purpose or introduce new cybersecurity risks, should generally not be treated as a substantial modification. That remains true even if the update changes internal implementation or constrains an existing feature solely to mitigate a vulnerability. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 39 says security updates designed to decrease cybersecurity risk are not considered substantial modifications when intended purpose is not modified. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Point 101 gives examples of security updates that do not alter intended purpose or introduce new exposure. ## Can a security update still become a CRA substantial modification? Yes. A security-driven change can still be substantial if it moves the product beyond the intended purpose originally assessed or introduces new risks that were not foreseen in the original cybersecurity risk assessment. Examples from the draft guidance include security updates that move local processing to a remote service, change the trust model, add new external dependencies, or materially change data flows. Sources for this answer: - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Point 102 explains when a security objective does not prevent an update from becoming a substantial modification. ## What practical risk factors should a CRA software-change review check? Start with the original intended purpose, architecture, threat model, risk assessment, technical documentation, and release scope. Then check whether the update changes the cybersecurity risk profile in a way the original assessment did not cover. - New threat vectors: interfaces, communication channels, execution environments, remote processing, third-party services, or external dependencies. - New attack scenarios: new ways to gain unauthorised access, manipulate the product, interfere with functions, or misuse processed data. - Changed likelihood: lower exploitation effort, increased exposure to untrusted actors, weakened safeguards, or wider reachable attack surface. - Changed impact: broader data exposure, more severe operational or safety consequences, harder detection, or reduced containment and recovery. Sources for this answer: - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Point 103 lists non-exhaustive software-update factors for substantial-modification analysis. ## If a manufacturer adds new functionality, when is it likely to be substantial? New functionality is more likely to be substantial when it changes the product's intended purpose as a whole or introduces cybersecurity risks that were not considered and mitigated in the original risk assessment. A large feature is not required. A small-looking addition can be substantial if it changes the attack surface or risk profile in a way that affects compliance with the essential requirements. Sources for this answer: - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Points 98 and 100 explain substantial modification for new functionality and limited changes with significant cybersecurity effects. ## Can planned feature activations avoid substantial-modification treatment? Yes, if the later functionality and its risks were already included in the original intended purpose, cybersecurity risk assessment, mitigations, and technical documentation. The practical evidence should show that the update implements a foreseen design path rather than expanding the product into a new intended use or unassessed risk profile. Sources for this answer: - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Point 99 explains that later functionality already covered by the original assessment should not be regarded as a substantial modification. ## Do repairs, maintenance, or refurbishment automatically create a CRA substantial modification? No. Repairs, maintenance, and refurbishment do not necessarily lead to a substantial modification when the product's intended purpose, functionality, and cybersecurity risk level remain unaffected. The repair becomes more sensitive when it changes how core functions operate, changes intended purpose, or affects compliance with Annex I Part I requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 42 addresses refurbishment, maintenance, repair, and upgrades under the substantial-modification concept. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Points 88-90 apply the substantial-modification test to physical repairs. - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - Section 2.1 explains when important changes or overhaul can make a modified product a new product under Union harmonisation legislation. ## Does replacing a defective part with a better-performing part automatically count as substantial? No. Replacing a defective or worn item with a better-performing part does not itself trigger substantial modification. It becomes substantial only if the performance change or changed operation affects compliance with essential cybersecurity requirements or changes the intended purpose that was covered by the original risk assessment. Sources for this answer: - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Point 90 and Examples 29-30 distinguish better-performing replacement parts from changes that alter core behaviour. ## How should CRA teams treat spare parts that are not identical to the original component? A non-identical spare part may itself be a CRA product because it does not fall within the identical-spare-parts exemption. That does not automatically mean the host product has been substantially modified. For the host product, assess whether the replacement changes intended purpose, functions, interoperability assumptions, cybersecurity risk profile, or compliance with Annex I Part I. For the spare part itself, assess CRA compliance in light of its own intended purpose and any compatibility or interoperability constraints. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(6) excludes identical replacement spare parts manufactured to the same specifications from CRA scope. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Points 91-94 and Examples 31-34 explain identical and non-identical spare parts and their effect on host-product modification analysis. ## When does a substantial modification create new CRA manufacturer obligations? When a product is substantially modified and the modified product is made available on the market, the modified product is treated as a new CRA product event. The person carrying out the substantial modification, or having it carried out, is treated as the manufacturer for the modified product. If the original manufacturer makes the substantial modification, it remains the manufacturer. If another party makes the substantial modification and makes the modified product available on the market, that party can become responsible for the relevant CRA manufacturer obligations. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Articles 21 and 22 set manufacturer consequences for importers, distributors, and other persons that carry out substantial modifications. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Points 107-108 explain that a substantially modified product is treated as a new product and a new placing-on-the-market event. ## Do importers, distributors, and other third parties become manufacturers under the same CRA rule? No. The CRA separates the provisions. Article 21 covers importers and distributors that carry out a substantial modification of a product already placed on the market. Article 22 covers other natural or legal persons where they carry out a substantial modification and make the modified product available on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Articles 21 and 22 distinguish importer/distributor manufacturer status from other persons making substantially modified products available. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Point 86 summarises the different substantial-modification triggers for economic operators and other persons. ## If only one part is affected, do CRA obligations apply only to that part? Article 22 narrows the obligation to the part affected by the substantial modification, unless the modification affects the cybersecurity of the product as a whole. In practice, the evidence should explain the affected boundary. If the changed part alters shared authentication, update mechanisms, communications, data flows, remote processing, or other whole-product security assumptions, teams should expect the whole-product assessment to be relevant. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 22(2) limits obligations to the affected part or extends them to the whole product when whole-product cybersecurity is affected. ## Does a CRA substantial modification trigger a new conformity assessment? Where a substantial modification may affect CRA compliance or changes intended purpose, compliance should be verified again and, where applicable, the product should undergo a new conformity assessment. If a third-party conformity assessment was used, a change that might lead to a substantial modification should be notified to the third party where applicable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 41 addresses re-verification, new conformity assessment where applicable, and notifying third parties about possible substantial modifications. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Points 107-110 explain conformity consequences and reuse of unaffected evidence. ## Must every CRA test and technical-documentation item be redone after a substantial modification? No. Existing tests and documentation can be reused for parts of the product that are not affected by the substantial modification. The person placing the modified product on the market must still update the technical documentation for impacted requirements, demonstrate why unchanged parts do not need new evidence, take responsibility for the modified product's conformity, and draw the required declaration of conformity. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - Section 2.1 explains that technical documentation updates should track modification impact and that unchanged aspects need not be retested. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Points 109-110 apply the Blue Guide approach to CRA substantial modifications and affected product parts. ## What evidence should a CRA substantial-modification file contain? Keep enough evidence to show the change was assessed against the CRA test rather than only approved as an engineering release. A useful file links the release scope to the original intended purpose, risk assessment, threat model, affected architecture, Annex I Part I controls, vulnerability-handling impact, user instructions, test results, conformity route, declaration status, and any third-party assessment notification. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Articles 13(7), 31(2), and Annex VII require the risk assessment and technical documentation to remain accurate and updated. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Point 106 confirms that update classification does not remove the duty to keep risk assessment and technical documentation current. ## What should user-facing guidance say after a CRA post-market change? Users should receive practical information tied to the actual change: what changed, whether action is needed, any configuration or security-update steps, changed support information, and any known constraints introduced by replacement parts or interoperability measures. For security updates, the CRA separately requires security updates to be disseminated without delay and accompanied by advisory messages with relevant information, including potential user action. Where technically feasible, new security updates should be provided separately from functionality updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II points 2, 7, and 8 address vulnerability remediation, secure update distribution, and user advisory messages. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - The Commission FAQ explains security-update transparency, automatic-update expectations, and separate security updates where technically feasible. ## How does CRA substantial modification affect products placed on the market before 11 December 2027? Products with digital elements placed on the market before 11 December 2027 are subject to CRA requirements only if, from that date, they are subject to a substantial modification. The Commission FAQ gives a practical contrast: a non-substantial bug-fix update for a smart TV placed on the market in 2027 does not require bringing that TV into full CRA conformity, but a later update that adds smart-home-control functionality and qualifies as substantial does. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2) sets the transition rule for products placed on the market before 11 December 2027. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 1.4 explains the legacy-product rule and gives smart-TV examples for non-substantial and substantial updates. - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Points 111-113 explain the Article 69(2) substantial-modification consequence for pre-application products. ## For a legacy product, should the manufacturer be able to prove an update is not substantial? Yes. For products placed on the market before 11 December 2027 where the CRA was not applied at initial placement, the draft guidance says manufacturers must be able to demonstrate to a market surveillance authority that later updates do not constitute substantial modifications. A cybersecurity risk assessment covering Article 13(2) elements, plus documented compliance reasoning, should make that position easier to support. Sources for this answer: - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Point 112 describes evidence expectations for later updates to products placed on the market before 11 December 2027. - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2) is the legal basis for substantial-modification treatment of pre-application products. ## If a legacy product is substantially modified after 11 December 2027, what must happen before market placement? The manufacturer must comply with the CRA in its entirety before placing the substantially modified product on the market, and then for the duration of that product's support period. Teams should treat this as a release gate: confirm product scope, update the risk assessment and technical documentation, choose or confirm the conformity assessment route, prepare conformity evidence, update user information, and confirm vulnerability-handling processes before the modified product is made available. Sources for this answer: - [Draft Commission guidance on the Cyber Resilience Act](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Point 113 states that full CRA compliance is required before placing a substantially modified legacy product on the market. - [European Commission CRA FAQs](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Section 1.4 illustrates that a smart-TV update adding smart-home-control functionality can require CRA compliance. ## Primary sources - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Official Cyber Resilience Act legal text supporting this FAQ and its article-level compliance conclusions. ## Topic Guides - [CRA Applicability Test for Products With Digital Elements](/artifacts/eu/cyber-resilience-act/applicability-test.md): Check whether the EU Cyber Resilience Act applies to a hardware, software, firmware, open-source, or connected product before conformity planning. - [CRA Article 14 Reporting Obligations for Vulnerabilities and Incidents](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Article 14 guide to CRA reports for actively exploited vulnerabilities and severe product-security incidents, including deadlines, CSIRT routing, users, and evidence. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ explaining Blue Guide market-access concepts for products with digital elements: placing on the market, making available, imports, CE marking, operator roles, online sales, stock, and testing exceptions. - [CRA CE Marking FAQ | Conformity Assessment, EU Declaration, Evidence](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): Practical CRA CE marking answers for products with digital elements: conformity assessment, EU declaration, technical documentation, standards, software placement, and launch evidence. - [CRA Component Due Diligence FAQ | Third-Party Software, FOSS, SBOMs](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): Cyber Resilience Act FAQ on manufacturer due diligence for integrated components, third-party software, FOSS dependencies, SBOMs, vulnerability handling, and evidence records. - [CRA Conformity Assessment and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): How to choose a Cyber Resilience Act conformity route, prepare technical documentation, issue the EU declaration of conformity, and affix CE marking. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Important and Critical Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): Cyber Resilience Act FAQ on when manufacturers can use module A, when module B+C or module H is required, and how important and critical products affect the route. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Annex I, Updates](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on Article 13 cybersecurity risk assessments, Annex I applicability, intended purpose, foreseeable use, technical documentation, and update evidence. - [CRA deadlines and compliance calendar | EU Cyber Resilience Act](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the Cyber Resilience Act entry into force, staged application dates, Article 14 reporting deadlines, transitional rules, and review dates. - [CRA Declaration of Conformity FAQ | Annex V, Simplified Declaration, CE Marking](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): FAQ on the Cyber Resilience Act EU Declaration of Conformity: Annex V contents, simplified Annex VI wording, CE marking link, technical documentation, retention, updates, and operator duties. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic-operator roles: manufacturers, importers, distributors, authorised representatives, substantial modification, traceability, and evidence controls. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on Annex I product cybersecurity requirements, vulnerability handling, secure-by-default design, risk assessment, documentation, lifecycle duties, and user information. - [CRA Essential Cybersecurity Requirements in Annex I](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): An official source guide to the Cyber Resilience Act Annex I requirements for product security, vulnerability handling, secure-by-design controls, documentation, and evidence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Components, RDPS](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): FAQ on Cyber Resilience Act hardware and software boundaries: combined products, standalone software, source code, components, remote data processing, SaaS and market-placement changes. - [CRA Harmonised Standards FAQ | Presumption of Conformity, Common Specifications](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): Cyber Resilience Act FAQ on how harmonised standards, common specifications, certification schemes, and OJ publication affect CRA conformity evidence. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Conformity Assessment](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): FAQ on CRA important and critical products, Annex III and Annex IV classification, core functionality, and conformity assessment consequences. - [CRA Integrated Components and Dependencies FAQ | Third-Party Software and SBOM Evidence](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): Cyber Resilience Act FAQ on integrated components, third-party software, remote data processing, SBOM-style evidence, upstream fixes, FOSS dependencies, and manufacturer responsibility. - [CRA Interplay With EU Product Laws FAQ | RED, Machinery, Data Act](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): Official source CRA FAQ on overlap with the Radio Equipment Directive, Machinery Regulation, GPSR, Data Act, exclusions, declarations, documentation, and existing certificates. - [CRA Known Exploitable Vulnerabilities at Launch FAQ](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): FAQ for Cyber Resilience Act launch decisions: known exploitable vulnerabilities, CVEs, component flaws, secure-by-default settings, release gates, Article 14 reporting, and evidence. - [CRA Legacy Products FAQ | Pre-11 December 2027 Products](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): Cyber Resilience Act FAQ on products placed on the market before 11 December 2027, Article 14 reporting, substantial modification, distributor stock, spare parts, and records. - [CRA Manufacturer Obligations FAQ | Article 13, Annex I, CE Marking](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): FAQ for Cyber Resilience Act manufacturers covering Article 13 duties, risk assessment, Annex I, vulnerability handling, support periods, documentation, conformity assessment, reporting, CE marking, and evidence controls. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Corrective Action, Safeguards](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): Cyber Resilience Act FAQ on market-surveillance authorities, investigations, corrective action, withdrawal, recall, safeguards, sweeps, documentation access, and penalties. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA Module B+C FAQ explaining EU-type examination, conformity to type, notified-body evidence, production control, CE marking, declarations, and certificate changes. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA Module H FAQ explaining the full-quality-assurance route, notified-body assessment, quality-system scope, technical documentation, CE marking, declarations, and records. - [CRA Notified Bodies FAQ | Scope, Modules B+C and H, Certificates](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): Practical CRA FAQ on when notified bodies are needed, how CRA bodies are designated, what their notified scope means, and how Module B+C and Module H assessments work. - [CRA Open-Source Software FAQ | FOSS Scope, Stewards, Manufacturers](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): Cyber Resilience Act FAQ for free and open-source software: commercial activity, steward duties, manufacturer due diligence, vulnerability handling, public documentation, and user obligations. - [CRA Over-the-Air Updates FAQ](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): Cyber Resilience Act FAQ on OTA updates, automatic security updates, secure update distribution, support-period evidence, and offline update paths. - [CRA penalties and fines FAQ | Article 64 fine caps](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): FAQ on EU Cyber Resilience Act Article 64 penalties: maximum fine tiers, turnover caps, national enforcement, economic operators, reporting duties, and open-source steward carve-outs. - [CRA Penalties and Fines: Article 64 Caps and Enforcement Context](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Article 64 of the EU Cyber Resilience Act sets administrative fine ceilings for Annex I, manufacturer, reporting, economic-operator, notified-body, and information-request breaches. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families, variant grouping, shared technical documentation, conformity evidence, and when cybersecurity-relevant differences need separate assessment. - [CRA Products with Digital Elements Scope | EU Cyber Resilience Act](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Apply the EU Cyber Resilience Act scope test for software, hardware, remote data processing, components, open-source software, exclusions, and economic-operator roles. - [CRA Products With Digital Elements Scope FAQ](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): EU Cyber Resilience Act FAQ on products with digital elements, software, firmware, remote data processing, components, exclusions, market placement, and CRA operator boundaries. - [CRA Remote Data Processing Solutions FAQ | Product Scope, Cloud and Backend Boundaries](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): FAQ on how the EU Cyber Resilience Act treats remote data processing solutions, manufacturer-controlled backends, third-party cloud services, SaaS, risk assessment, documentation, and user information. - [CRA Reporting Obligations FAQ | Article 14, CSIRTs, ENISA, User Notices](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): Cyber Resilience Act FAQ on Article 14 reporting for actively exploited vulnerabilities and severe incidents, including timing, CSIRT routing, ENISA access, user notices, and evidence. - [CRA Requirements | Annex I, Manufacturer Duties and CE Evidence](/artifacts/eu/cyber-resilience-act/requirements.md): Map Cyber Resilience Act requirements from Annex I to manufacturer duties, vulnerability handling, user information, technical documentation, declaration of conformity, and CE marking evidence. - [CRA SBOM and Vulnerability Management Template](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields. - [CRA Secure-by-Default FAQ | Default Configuration and Annex I Controls](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): Cyber Resilience Act FAQ on secure-by-default configuration, automatic security updates, attack surface reduction, authentication, data minimisation, user information, and tailor-made products. - [CRA Security Updates vs Functionality Updates FAQ](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): Cyber Resilience Act FAQ on classifying security updates, functionality updates, support-period duties, automatic updates, user notices, and substantial-modification review. - [CRA Support Period FAQ | Expected Product Lifetime, Security Updates, User Information](/artifacts/eu/cyber-resilience-act/faq/support-period.md): Practical CRA FAQ on how manufacturers determine support periods, disclose support end dates, keep security updates available, and document support-period evidence. - [CRA Tailor-Made Products FAQ | Bespoke Products, Market Placement, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): FAQ on when a bespoke product may be treated as tailor-made under the EU Cyber Resilience Act, what the carve-out changes, and what manufacturers still need to document. - [CRA Technical Documentation FAQ | Annex VII Evidence and Technical File](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access. - [CRA Transition Period FAQ | Entry Into Force, Application Dates, Reporting, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, 2026 reporting, 2027 application, legacy products, stock, customs timing, and software versions. - [CRA Update Availability and Software Archives FAQ](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): FAQ on CRA security-update availability, support-period notices, optional public software archives, historical versions, and Article 13(10) software-version limits. - [CRA User Information and Transparency FAQ | Annex II Instructions](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): Practical CRA FAQ on Annex II user instructions, support-period disclosure, vulnerability contacts, update notices, importer and distributor information. - [CRA vs RED Cybersecurity Delegated Act](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the EU Cyber Resilience Act with the RED cybersecurity delegated act for connected and radio equipment, including scope, timing, evidence, and transition treatment. - [CRA vs UK PSTI Act | Cyber Resilience Act Comparison](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare cited EU Cyber Resilience Act duties with UK PSTI planning points, with UK legal details clearly marked for separate source review. - [CRA Vulnerability Handling and Disclosure | Article 14 Reporting and Security Updates](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): How EU Cyber Resilience Act manufacturers should run vulnerability intake, remediation, coordinated disclosure, Article 14 reporting, secure updates, and evidence records. - [CRA Vulnerability Handling FAQ | Support Periods, Components, Reporting](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): Practical CRA FAQ on vulnerability handling: SBOMs, remediation, coordinated disclosure, component issues, security updates, support periods, Article 14 reporting, and user notices. - [Cyber Resilience Act Module A FAQ | Internal Production Control](/artifacts/eu/cyber-resilience-act/faq/module-a.md): FAQ on when CRA Module A internal production control is available, when it is blocked, and what documentation, testing, standards, and evidence it still requires. - [EU CRA Compliance Program for Manufacturers and Economic Operators](/artifacts/eu/cyber-resilience-act/compliance.md): Build a Cyber Resilience Act compliance program around product scope, Annex I security requirements, conformity assessment, technical documentation, vulnerability reporting, and market surveillance. - [EU Cyber Resilience Act Checklist for Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): A CRA checklist for products with digital elements: scope, Annex I security controls, vulnerability handling, Article 14 reporting, technical documentation, conformity assessment, CE marking, and support-period evidence. - [EU Cyber Resilience Act Core Functionality FAQ | CRA Product Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality, product boundaries, remote data processing, integrated components, ancillary functions, and software changes that affect product classification. - [EU Cyber Resilience Act FAQ](/artifacts/eu/cyber-resilience-act/faq.md): Direct CRA FAQ answers on scope, economic-operator roles, essential requirements, vulnerability reporting, conformity assessment, CE marking, support periods, and market surveillance. - [EU Cyber Resilience Act Repairs and Spare Parts FAQ](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes. - [EU Cyber Resilience Act Technical Documentation and Audit File](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build an audit-ready CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, and retention. *Recommended next step* *Placement: after key answers* ## Review CRA change evidence before release Use Research Copilot to compare a planned product change against the CRA substantial-modification test, link the answer to cited sources, and identify missing conformity evidence before market release. - [Open Research Copilot](/solutions/research-copilot.md): Build a cited CRA change assessment for software updates, repairs, replacement parts, or legacy-product releases. - [Talk through implementation](/contact.md): Review affected product boundaries, conformity evidence gaps, and release-gate ownership. --- [Privacy Policy](https://www.sorena.io/privacy.md) | [Terms of Use](https://www.sorena.io/terms-of-use.md) | [DMCA](https://www.sorena.io/dmca.md) | [About Us](https://www.sorena.io/about-us.md) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md