FAQEUCyber Resilience Act

Cyber Resilience Act FAQ Reporting obligations

Article 14 requires manufacturers to report actively exploited vulnerabilities and severe security incidents through the CRA single reporting platform. This FAQ explains the triggers, timing, routing, user-notice duties, and records teams need before the clock starts.

For product security, incident response, legal, and compliance teams preparing CRA reporting playbooks.

Author
Sorena AI
Published
Mar 10, 2026
Updated
Mar 10, 2026
Questions
21

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Mar 10, 2026
Updated Mar 10, 2026
Overview

The CRA reporting regime is narrower than ordinary vulnerability management but faster than many internal incident processes. Mandatory Article 14 reporting is triggered when a manufacturer becomes aware of an actively exploited vulnerability contained in a product with digital elements, or a severe incident affecting the product's security. The first report can be due within 24 hours, so teams need a pre-agreed way to classify evidence, identify the right CSIRT coordinator, notify users, and preserve the basis for each decision.

Search this module

Find a question or answer quickly

21 of 21 questions
Question 1

What must be reported under CRA Article 14?

Manufacturers must report two categories once Article 14 applies: any actively exploited vulnerability contained in the product with digital elements, and any severe incident having an impact on the security of that product.

The duty applies from 11 September 2026. It is not limited to newly launched products: Article 69(3) extends Article 14 to in-scope products placed on the market before 11 December 2027.

Citations
Cyber Resilience Act

Supports the two mandatory Article 14 triggers, the 11 September 2026 application date, and the transitional rule for products already on the market.

Question 2

What counts as an actively exploited vulnerability?

The CRA definition requires reliable evidence that a malicious actor exploited the vulnerability in a system without the system owner's permission.

A vulnerability is therefore not reportable under Article 14 just because it exists, is serious, or has no patch yet. The Commission FAQ says zero-days discovered by ethical hackers, bug-bounty participants, or assessment laboratories are not mandatory Article 14 reports unless there is evidence of previous malicious exploitation. They may still be reported voluntarily under Article 15.

Citations
Question 3

What counts as a severe incident?

A severe incident is an incident affecting the security of the product with digital elements where either condition in Article 14(5) is met.

The first condition is a negative effect, or a capability to negatively affect, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. The second is that the incident has led, or is capable of leading, to malicious code being introduced or executed in the product or in the user's network and information systems.

Recital 68 also links severe incidents to compromises of the manufacturer's processes when those compromises affect the product's security, so investigation should not be limited to deployed product telemetry.

Citations
Cyber Resilience Act

Article 14(5) supplies the severe-incident test; Recital 68 explains product-security impact from manufacturer process incidents.

Question 4

When does the reporting clock start?

The legal clock runs from when the manufacturer becomes aware of the actively exploited vulnerability or severe incident.

The draft Commission guidance says awareness follows an initial assessment: the manufacturer is regarded as aware when it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident occurred and compromised the product's security. Teams should therefore record when the suspicious signal arrived, what initial assessment was performed, and when the assessment reached that threshold.

Citations
Cyber Resilience Act

Article 14(2) and 14(4) measure the 24-hour and 72-hour deadlines from manufacturer awareness.

Question 5

Does the CRA prescribe how manufacturers must detect reportable events?

No. The Commission FAQ says Article 14 does not prescribe how a manufacturer becomes aware of an actively exploited vulnerability or severe incident.

The FAQ gives examples: customer or partner reports, threat intelligence, security researchers, government cybersecurity agencies, ethical hackers, telemetry, honeypots, internal scanning, and dark-web monitoring. Those examples do not create a duty to monitor every channel, but they are useful for designing intake and triage routes.

Citations
European Commission CRA FAQs

Section 5.1 explains possible awareness channels and states that the examples do not require manufacturers to monitor all of them.

Question 6

What are the deadlines for an actively exploited vulnerability report?

Article 14(2) creates three stages.

- Early warning: without undue delay and in any event within 24 hours of becoming aware.

- Vulnerability notification: without undue delay and in any event within 72 hours of becoming aware, unless the information was already provided.

- Final report: no later than 14 days after a corrective or mitigating measure is available.

The 24-hour and 72-hour deadlines do not wait for a patch. The final-report clock is tied to availability of a corrective or mitigating measure.

Citations
Cyber Resilience Act

Article 14(2) sets the staged reporting deadlines for actively exploited vulnerabilities.

Question 7

What are the deadlines for a severe incident report?

Article 14(4) also creates three stages.

- Early warning: without undue delay and in any event within 24 hours of becoming aware.

- Incident notification: without undue delay and in any event within 72 hours of becoming aware, unless the information was already provided.

- Final report: within one month after submission of the incident notification.

The severe-incident final report is therefore keyed to the 72-hour incident notification, not to patch availability.

Citations
Question 8

What information must be ready for the early warning and 72-hour notification?

For an actively exploited vulnerability, the early warning indicates, where applicable, the Member States where the manufacturer knows the product has been made available. The 72-hour vulnerability notification adds available information about the product, the general nature of the exploit and vulnerability, corrective or mitigating measures already taken, measures users can take, and the sensitivity of the notified information where applicable.

For a severe incident, the early warning must at least say whether the incident is suspected of being caused by unlawful or malicious acts, and where applicable identify Member States where the product has been made available. The 72-hour incident notification adds available information about the incident's nature, an initial assessment, corrective or mitigating measures already taken, user measures, and sensitivity.

Citations
Cyber Resilience Act

Article 14(2)(a)-(b) and 14(4)(a)-(b) specify the minimum content of early warnings and 72-hour notifications.

Question 9

What must be in the final report?

For an actively exploited vulnerability, the final report must include a description of the vulnerability, its severity and impact, information about the malicious actor where available, and details of the security update or other corrective measures made available.

For a severe incident, the final report must include a detailed incident description, severity and impact, the likely threat type or root cause, and applied and ongoing mitigation measures.

Citations
Cyber Resilience Act

Article 14(2)(c) and 14(4)(c) list the final-report content for vulnerability and incident reports.

Question 10

Where is the notification filed?

The manufacturer files via the single reporting platform established by ENISA, using the electronic notification endpoint of the relevant CSIRT designated as coordinator. ENISA receives simultaneous access through that mechanism.

A direct ENISA-only notification is not the Article 14 route for mandatory reports. The route is CSIRT coordinator endpoint plus simultaneous ENISA access through the single reporting platform.

Citations
Cyber Resilience Act

Article 14(7) and Article 16(1) establish the single reporting platform, CSIRT coordinator endpoint, and simultaneous ENISA access.

Question 11

Which CSIRT coordinator receives the report?

If the manufacturer has a main establishment in the Union, the relevant CSIRT is in the Member State where decisions related to product cybersecurity are predominantly taken. If that cannot be determined, it is the Member State where the manufacturer has the establishment with the highest number of employees in the Union.

If the manufacturer has no main establishment in the Union, Article 14(7) uses a fallback order based on the authorised representative, importer, distributor, and finally the Member State with the highest number of users. If the user-location fallback is used, later related reports may be sent to the same CSIRT coordinator.

Citations
Cyber Resilience Act

Article 14(7) defines the main-establishment rule and fallback order for manufacturers without a Union main establishment.

Question 12

How does the CSIRT and ENISA flow work after filing?

The CSIRT coordinator that initially receives the notification disseminates it through the single reporting platform to the CSIRTs for Member States where the manufacturer indicated the product has been made available. CSIRTs designated as coordinators also provide national market surveillance authorities with notified information needed for CRA tasks.

The initially receiving CSIRT may request intermediate status updates. ENISA manages and maintains the platform, can receive relevant information for EU-level crisis coordination, prepares trend reports from notifications, and adds publicly known notified vulnerabilities to the European vulnerability database after a security update or other corrective or mitigating measure is available and in agreement with the manufacturer.

Citations
Cyber Resilience Act

Articles 14(6), 16(1)-(3), and 17 describe CSIRT dissemination, market-surveillance sharing, ENISA operation of the platform, trend reporting, and vulnerability database entries.

Question 13

Can sensitive vulnerability information be held back from wider dissemination?

Yes, but the CRA frames this as an exceptional dissemination control after notification, not as extra time for the manufacturer to file.

Article 16 allows the initially receiving CSIRT to delay dissemination on justified cybersecurity-related grounds for only the period strictly necessary, including coordinated vulnerability disclosure cases. Article 16 also has a narrower exceptional process for actively exploited vulnerabilities where immediate wider dissemination would conflict with specified essential interests or create imminent high cybersecurity risk.

If no corrective or mitigating measure is available, ENISA and the CSIRTs network must provide procedures so information is shared under strict security protocols and on a need-to-know basis.

Citations
Cyber Resilience Act

Article 16(2), 16(5), and 16(6) support delayed dissemination, exceptional vulnerability handling, and need-to-know controls where no fix is available.

Question 14

Does the manufacturer also have to inform users?

Yes. After becoming aware of an actively exploited vulnerability or severe incident, the manufacturer must inform impacted users and, where appropriate, all users. The notice must include any risk-mitigation and corrective measures users can deploy where necessary, and where appropriate must be structured, machine-readable, and easily automatically processable.

The Commission FAQ confirms this Article 14(8) user-notice duty also matters for older in-scope products placed on the market before 11 December 2027.

Citations
Cyber Resilience Act

Article 14(8) requires notification to impacted users and, where appropriate, all users, including mitigation and corrective measures.

European Commission CRA FAQs

Section 5.3 confirms Article 14(8) user communication for pre-11 December 2027 products that still fall under Article 14 reporting.

Question 15

Does user notice always require public disclosure?

No. The draft Commission guidance says Article 14(8) should be applied in a risk-based and proportionate way. It does not require public or indiscriminate disclosure in every case.

Detailed information may be limited to affected users or customers where appropriate, especially for products used in sensitive or essential environments where public technical detail could increase cybersecurity risk or facilitate further exploitation. If the manufacturer does not inform users in time, the notified CSIRTs may inform users when proportionate and necessary to prevent or mitigate impact. For severe incidents, Article 17(2) also allows public information or a requirement that the manufacturer inform the public where public awareness is necessary or in the public interest.

Citations
Cyber Resilience Act

Article 14(8) covers CSIRT user communication if the manufacturer does not act in time; Article 17(2) covers public awareness for severe incidents.

Question 16

How are third-party component vulnerabilities handled?

If an actively exploited vulnerability in an integrated component is contained in the finished product, the finished-product manufacturer must notify it under Article 14 when aware of it. If the component manufacturer placed that component on the market separately, it may have its own Article 14 duty as well.

If the manufacturer knows the integrated component has a vulnerability but that vulnerability cannot be exploited in the finished product, the Commission FAQ says it is not an actively exploited vulnerability in that finished product for mandatory Article 14 reporting. Voluntary Article 15 reporting may still be used, and Article 13(6) can require upstream reporting to the person or entity manufacturing or maintaining the component.

Citations
European Commission CRA FAQs

Section 5.4 explains Article 14 reporting for actively exploited vulnerabilities originating in integrated components and the non-exploitable-component limit.

Cyber Resilience Act

Article 14(1), Article 15, and Article 13(6) support mandatory reporting, voluntary reporting, and upstream component reporting.

Question 17

Do importers and distributors file Article 14 reports?

Article 14 places the mandatory reporting duty on the manufacturer. Importers and distributors have related escalation duties rather than becoming the ordinary Article 14 reporter.

If an importer or distributor becomes aware of a vulnerability in the product, it must inform the manufacturer without undue delay. If it considers or has reason to believe the product presents a significant cybersecurity risk, it must also immediately inform the market surveillance authorities of the Member States where the product has been made available.

Citations
Cyber Resilience Act

Article 14 assigns reporting to manufacturers; Articles 19(5) and 20(4) describe importer and distributor escalation duties.

Question 18

Can teams use voluntary reporting when Article 14 is not triggered?

Yes. Article 15 allows manufacturers and other natural or legal persons to notify vulnerabilities, cyber threats that could affect a product's risk profile, incidents, and near misses on a voluntary basis to a CSIRT coordinator or ENISA.

The CSIRT may prioritise mandatory notifications over voluntary ones. If someone other than the manufacturer reports an actively exploited vulnerability or severe incident, the CSIRT coordinator must inform the manufacturer without undue delay. CSIRTs and ENISA must protect voluntary-notifier information, and voluntary reporting does not by itself impose extra obligations on the notifier.

Citations
Cyber Resilience Act

Article 15 covers voluntary reporting scope, prioritisation, manufacturer notice, confidentiality, and no additional obligations from voluntary reporting.

Question 19

What evidence should a CRA reporting file preserve?

Keep the evidence needed to support the classification and every report stage: original intake signal, source and timestamp, affected product and version, whether the issue is a product vulnerability or an incident, evidence of malicious exploitation or severe product-security impact, initial assessment notes, awareness-time decision, affected Member States where known, user-impact assessment, sensitivity marking, and any corrective or mitigating measures already taken or available to users.

For the final record, preserve severity and impact analysis, root-cause or threat-type assessment where available, malicious-actor information where available for exploited vulnerabilities, security update or mitigation details, user communications, CSIRT submissions, intermediate reports requested by a CSIRT, and the rationale for any delayed public or wider disclosure.

For older products, preserve practical investigation limits such as unavailable build environments, unsupported dependencies, missing tooling, or departed product knowledge. The Commission FAQ says those limits do not remove the Article 14 reporting duty, but they explain what could and could not be verified.

Citations
Cyber Resilience Act

Articles 14(2), 14(4), 14(6), 14(8), and 16 identify the facts, updates, user measures, sensitivity, and intermediate status information that reporting files should support.

European Commission CRA FAQs

Section 5.3 lists practical investigation limits for older products while confirming the Article 14 reporting duty remains.

Prepare the reporting file

Turn CRA Article 14 duties into an incident-ready evidence pack

Map intake signals, awareness decisions, CSIRT coordinator routing, user-notice templates, and final-report evidence before a 24-hour CRA clock starts.

Question 20

Does notifying under CRA Article 14 increase liability?

No. Article 17(4) says the mere act of notification under the mandatory or voluntary reporting provisions does not subject the notifier to increased liability.

That protection does not remove the underlying CRA obligations, but it is important for escalation playbooks because teams should not delay a required report simply because the act of notifying is visible to authorities.

Citations
Question 21

Is there any reporting relief for microenterprises and small enterprises?

There is narrow penalty relief, not a removal of the reporting duty. Article 64 exempts microenterprises and small enterprises from administrative fines for failure to meet the 24-hour early-warning deadline in Article 14(2)(a) or Article 14(4)(a).

The CRA also requires CSIRTs designated as coordinators to provide helpdesk support for Article 14 reporting, in particular for microenterprises and small or medium-sized enterprises.

Citations
Cyber Resilience Act

Article 64(10)(a) covers the narrow fine exemption; Article 17(6) covers CSIRT helpdesk support.

Primary sources

References and citations

data.europa.eu
Referenced sections
  • Article 64(10)(a) covers the narrow fine exemption; Article 17(6) covers CSIRT helpdesk support.
"with regard to any failure to meet the deadline"
ec.europa.eu
Referenced sections
  • Section 5.3 lists practical investigation limits for older products while confirming the Article 14 reporting duty remains.
"tooling to scan or run old software versions"
Related guides

Explore more topics

CRA Applicability Test for Products With Digital Elements
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
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
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
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
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
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
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
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
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
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
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
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
A grounded 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
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
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
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
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
Grounded 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 Requirements | Annex I, Manufacturer Duties and CE Evidence
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
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
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
Cyber Resilience Act FAQ on classifying security updates, functionality updates, support-period duties, automatic updates, user notices, and substantial-modification review.
CRA Substantial Modification FAQ | Updates, Repairs, Manufacturer Duties
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.
CRA Support Period FAQ | Expected Product Lifetime, Security Updates, User Information
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
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
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
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
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
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
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
Compare grounded 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
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
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
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
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
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
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
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
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
Build an audit-ready CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, and retention.