--- title: "CRA Security Updates vs Functionality Updates FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates" author: "Sorena AI" description: "CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA security updates FAQ" - "CRA functionality updates FAQ" - "CRA Annex I Part II point 2" - "CRA Article 13(10)" - "CRA free security updates" - "CRA substantial modification update" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" - "CRA security updates vs functionality updates FAQ" --- **[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 Security Updates vs Functionality Updates FAQ CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates Use this CRA FAQ to understand when security updates must be separated from functionality changes, when combined releases are allowed, and how update choices interact with Article 13(10) and substantial-modification analysis. Built for product, release, engineering, and compliance teams managing secure update strategies under the CRA. The CRA distinguishes between vulnerability remediation and broader functionality changes, but it does not ban every combined release. This FAQ explains when security updates must be provided separately, when combined releases are allowed, what Article 13(10) means for version support, and how update-related changes interact with substantial-modification analysis. ## Does the CRA require manufacturers to patch every vulnerability they discover during the support period? No. The CRA requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed. The Commission FAQ explains that this does not mean every vulnerability must receive a dedicated patch. The response depends on the risk assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.1 ## If not every vulnerability needs a dedicated patch, what other remedies can satisfy the CRA? The Commission FAQ says remedies can take different forms depending on the risk. These can include immediate patches, advisories on workarounds, configuration guidance, updates to user manuals, later software updates, or other mitigation measures. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 4.3.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2), Article 13(21) ## Must security updates be provided separately from functionality updates? Yes, where technically feasible. That is the rule in Annex I Part II point (2). Recital 57 explains that the purpose is to avoid forcing users to install functionality changes just to receive the latest security fix. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2), recital 57 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 ## Why does the CRA push for separation between security and functionality updates? To improve transparency and to ensure users are not required to install new functionality updates for the sole purpose of receiving the latest security updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 57 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 ## Can a manufacturer still combine a security update with a functionality change? Yes, if separation is not technically feasible. The Commission FAQ gives the example of a vulnerability fix that requires replacing a parser with a safer one that changes some functionality. In that situation, the CRA does not require strict separation. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2) ## Can a functionality change itself be the security fix? Yes. The Commission FAQ explains that disabling or changing a vulnerable function can itself be the security update. The key point is whether the change is needed to address the vulnerability. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 ## Must CRA security updates be disseminated without delay? Yes. Annex I Part II point (8) requires manufacturers to ensure that available security updates are disseminated without delay. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Must CRA security updates be free of charge? Yes, unless otherwise agreed between the manufacturer and a business user for a tailor-made product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.5 and 4.3.3 ## Must CRA security updates come with user-facing guidance? Yes. When security updates are available to address identified security issues, they must be accompanied by advisory messages with the relevant information, including potential action users should take. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8) ## Does the CRA require secure update-distribution mechanisms? Yes. Manufacturers must provide mechanisms to securely distribute updates so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (7) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Are CRA automatic security updates always required for every product? No. The CRA requires products, where applicable, to support automatic security updates with default enablement, an opt-out mechanism, notifications, and the option to postpone. Recital 56 and the Commission FAQ explain that automatic updates are not always applicable, especially for components and for products where users would not reasonably expect automatic updates, including some professional and industrial environments. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## If CRA automatic updates are used, must users still be able to opt out or postpone installation? Yes. Annex I Part I point (2)(c) requires a clear and easy-to-use opt-out mechanism and the option to temporarily postpone updates. Recital 56 adds that users should retain the ability to deactivate automatic updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Is the manufacturer responsible under the CRA if a user refuses or fails to install a security update? No. The Commission FAQ states this directly. The manufacturer must make the update available through the required mechanisms and keep users informed, but is not responsible under the CRA if the user does not install the update. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II points (7)-(8) ## If a vulnerability cannot be fixed adequately, can withdrawal or recall become necessary? Yes, in exceptional cases. Article 13(21) requires corrective measures to bring the product or the manufacturer's processes into conformity, or withdrawal or recall as appropriate. The Commission FAQ explains that this may become necessary where a serious vulnerability cannot be adequately remediated. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ## Even when CRA automatic updates are not applicable, must the manufacturer still inform users about vulnerabilities and make security updates available? Yes. Recital 56 states this expressly. Even where a product is not designed to receive automatic updates, the manufacturer should still inform users about vulnerabilities and make security updates available without delay. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Must a manufacturer keep delivering security fixes for every historical version of a software product? Not always. Article 13(10) allows the manufacturer, under specific conditions, to ensure compliance with the remediation obligation only for the latest substantially modified version it has placed on the market. That is allowed only if users of the earlier versions can access that latest version free of charge and without additional costs to adjust their hardware or software environment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 ## If earlier versions can move to the latest substantially modified version, does that end all obligations for the older versions? No. Recital 40 says the manufacturer may limit remediation to the latest substantially modified version only under the Article 13(10) conditions, but other vulnerability-handling obligations still continue for all subsequent substantially modified versions placed on the market. The same recital also says minor security or functionality updates that do not amount to a substantial modification may be provided only for the latest version or sub-version that has not been substantially modified. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), Annex I Part II points (5) to (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 ## What if a hardware product cannot run the latest software version? The CRA does not let the manufacturer stop there. Recital 40 says that where a hardware product is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should continue to provide security updates at least for the latest compatible version for the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 ## If a release is labelled a security update, does that automatically mean it is not a substantial modification? No. Recital 39 and the March 2026 draft guidance say security updates are generally not substantial modifications when they only reduce cybersecurity risk, do not change the product's intended purpose, and do not introduce new cybersecurity risks. But a security-driven change can still be substantial if it changes the intended purpose beyond what was originally foreseen or introduces new interfaces, dependencies, data flows, or other risks that were not covered in the original risk assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39 - [Draft Commission guidance on the CRA (March 2026 draft)](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 101-102 ## Are later functionality updates automatically substantial modifications? No. The March 2026 draft guidance says later functionality updates are not substantial modifications just because they add or activate features. If the original risk assessment already foresaw those later functions, already assessed their risks, and already accounted for the needed mitigation measures, the later rollout should not be treated as a substantial modification. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](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 ## Can a small-looking feature update still become a substantial modification? Yes. Recital 39 and the March 2026 draft guidance both make clear that the scale of the feature is not the legal test. Even a limited update can be substantial if it modifies the original intended functions or type or performance of the product in a way that increases cybersecurity risk, or if it introduces new or increased risks that were not covered in the original risk assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39 - [Draft Commission guidance on the CRA (March 2026 draft)](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 100 ## Does it matter for substantial-modification analysis whether the feature change was shipped separately or bundled with a security update? No. Recital 39 says that when assessing whether a feature update is a substantial modification, it is not relevant whether the feature update is provided separately or in combination with a security update. What matters is the effect on intended purpose and cybersecurity risk, not the packaging of the release. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39 ## When Article 13(10) says users must not incur additional costs to move to the latest version, what does that cover? The March 2026 draft guidance says this should be interpreted practically and proportionately. Reasonable operational effort does not itself count as additional costs. The guidance gives examples such as personnel time, routine testing, configuration adjustments, and upgrades of underlying software dependencies that are necessary to address end-of-life components or known vulnerabilities. By contrast, additional costs mean burdens going beyond normal software maintenance, such as mandatory purchases of new hardware, infrastructure replacement, or fundamental changes to the operating environment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10) - [Draft Commission guidance on the CRA (March 2026 draft)](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 118-120 ## If an update is not a substantial modification, can the manufacturer leave the CRA documentation unchanged? No. The March 2026 draft guidance says that regardless of whether a software update qualifies as a substantial modification, manufacturers remain responsible for the security of the update and of the product during the support period. It also says the cybersecurity risk assessment and technical documentation must remain accurate, complete, and continuously up to date. That aligns with Articles 13(7) and 31(2). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Article 31(2) - [Draft Commission guidance on the CRA (March 2026 draft)](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 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [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 on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [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 the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [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 covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates