--- title: "CRA Secure-by-Default FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/secure-by-default" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/secure-by-default" author: "Sorena AI" description: "CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA secure by default FAQ" - "CRA Annex I point 2b" - "CRA automatic security updates default" - "CRA tailor-made exception" - "CRA default configuration" - "CRA Article 13(4) justification" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[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 Secure-by-Default FAQ CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Secure by Default Use this CRA FAQ to understand what secure by default means under Annex I, when automatic security updates must be enabled by default, and how the narrow tailor-made exception works. Built for product, security, firmware, and compliance teams deciding default configurations and update behavior under the CRA. The CRA requires products with digital elements to be placed on the market with a secure-by-default configuration grounded in the manufacturer's cybersecurity risk assessment. This FAQ explains what that means in practice, how automatic security updates fit into the rule, when non-applicability can be justified, and why the tailor-made exception is narrow. ## What does the CRA's secure-by-default requirement mean? The CRA requires products with digital elements to be made available on the market with a secure-by-default configuration, based on the manufacturer's cybersecurity risk assessment and in light of the product's intended purpose and reasonably foreseeable use. This is not a generic slogan. It is a concrete Annex I requirement. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex I Part I, point (2)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## Does secure by default mean the same default settings for every product? No. The default configuration has to be determined through the risk assessment for the specific product. What is secure by default for one product category may not be secure by default for another. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex I Part I, point (2)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## Does secure by default mean the product always has to ship in the most restrictive technically possible state? No. The CRA ties the default configuration to the product's intended purpose, reasonably foreseeable use, and the manufacturer's cybersecurity risk assessment. So the legal test is not whether the product is maximally locked down in the abstract, but whether its default configuration is secure for the way the product is meant and reasonably expected to be used. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex I Part I, point (2)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## What kinds of settings or product states may need to be secure by default under the CRA? That depends on the product, but the CRA and Commission materials point toward defaults that reduce cybersecurity risk at first use. The Commission FAQ gives examples such as insecure or deprecated cryptographic algorithms being disabled by default, certificate validation being enabled by default, or network interfaces being disabled by default until needed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, points (2)(b), (2)(d), (2)(e), (2)(j), (2)(k) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## Does the secure-by-default requirement include a reset function? Yes. Annex I Part I, point (2)(b) expressly includes the possibility to reset the product to its original state. 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)(b) ## Does the CRA require automatic security updates to be enabled by default? Where applicable, yes. Annex I Part I, point (2)(c) says vulnerabilities must be addressable through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe and enabled as a default setting. That default setting must come with a clear and easy-to-use opt-out mechanism and the option to postpone updates temporarily. 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) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Can users turn off CRA automatic security updates? Yes. The CRA requires a clear and easy-to-use opt-out mechanism and an option to postpone updates temporarily. Annex II also requires instructions on how the default automatic-installation setting can be turned off. 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), Annex II point 8(e), recital 56 ## Are CRA automatic security updates required for every product? No. Recital 56 says the automatic-update expectations do not apply to products primarily intended to be integrated as components into other products. It also says they do not apply to products for which users would not reasonably expect automatic updates, including products intended for use in professional ICT networks and especially in critical and industrial environments where automatic updates could interfere with operations. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 56, Annex I Part I, point (2)(c) - [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 not appropriate, does the manufacturer still have update obligations? Yes. Recital 56 says that irrespective of whether a product is designed to receive automatic updates, the manufacturer should 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, Annex I Part II, points (7) and (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## If a user opts out of CRA automatic updates, is the manufacturer then compliant automatically? Not automatically, but the manufacturer is not responsible under the CRA for the user's refusal to install updates. The Commission FAQ says the manufacturer is not responsible if the user does not install security updates, including where the user opts out. But the manufacturer still must design the product and its processes so updates can be distributed, notified, and installed as required. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Annex I Part I, point (2)(c), Annex I Part II, points (7) and (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## How does CRA secure by default work for components sold for integration into other products? The component manufacturer is responsible for the configuration in which the component is placed on the market separately. The component manufacturer is not responsible for how an integrating manufacturer later reconfigures or deploys that component. The Commission FAQ gives this directly for products such as cryptographic libraries and microcontrollers sold for integration. 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)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## Can a manufacturer rely on setup instructions instead of shipping the product in a secure default state? No. The CRA requires a secure-by-default configuration at placement on the market. The March 2026 draft guidance also says that information to users cannot be used to compensate for product-design shortcomings or to justify leaving incompatible risks untreated. 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)(b), Annex II - [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 145-147 ## Can the secure-by-default requirement ever be inapplicable to a product? Yes, but only on a documented, risk-based basis. If the manufacturer concludes that a requirement is not applicable, Article 13(4) requires a clear justification in the technical documentation. The Commission FAQ says this can be the case where the requirement is incompatible with the nature of the product or where the risk assessment shows no relevant risks requiring that mitigation. But if the manufacturer still identifies cybersecurity risks in relation to that requirement, it has to address those risks by other means, for example by limiting the intended purpose to trusted environments or informing users about the risks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3)-(4), recital 55 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.3 and 4.2.4 ## Is there any exception to the secure-by-default requirement? Yes, but it is narrow. Annex I allows deviation only where the product is tailor-made, fitted to a particular purpose for a particular business user, and the manufacturer and that user have explicitly agreed to different contractual terms. That exception does not create a general enterprise-product carve-out. 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)(b), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Are ordinary enterprise products or lightly customised products automatically "tailor-made" for this exception? No. The Commission FAQ says a product is not tailor-made merely because it undergoes minor customisations before sale. It gives examples such as a CRM platform sold to multiple businesses, or platforms customised through plugins or APIs while remaining fundamentally the same product for every customer. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Does the tailor-made carve-out let the manufacturer deviate from any CRA requirement it wants? No. The Commission FAQ says the CRA allows deviation only from two essential requirements in this context: secure-by-default configuration in Annex I Part I point (2)(b), and the requirement to provide security updates free of charge in Annex I Part II point (8). It is not a general waiver from other Annex I requirements. 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)(b), Annex I Part II, point (8), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## If secure by default is not applicable because of the product's nature or interoperability needs, can the manufacturer simply omit equivalent safeguards? No. Where an essential cybersecurity requirement is not applicable but related cybersecurity risks still exist, the CRA materials say the manufacturer should address those risks by other means. The examples given are limiting the intended purpose to trusted environments or informing users about the risks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), recital 55 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.3 ## What does the manufacturer need to document about secure by default? The manufacturer needs to document how the product complies with the relevant essential cybersecurity requirements, including the secure-by-default requirement where it applies. If the manufacturer concludes that the requirement is not applicable, that justification must be documented. If the manufacturer relies on the tailor-made exception, the technical documentation should also contain relevant evidence showing that the product is genuinely tailor-made. That matters because secure by default is not just a design aspiration. It forms part of the manufacturer's conformity case under Article 13(4) and Article 31. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), Article 31, Annex I Part I, point (2)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.3 and 4.2.5 ## 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 Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [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 Secure by Default as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Secure by Default 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 Secure by Default 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/secure-by-default