You should determine whether your products fall within the CRA’s scope and how hardware, software, tools, or components are incorporated into your products. You need to be able to recognize these events quickly, determine whether reporting is required, and preserve the information supporting that decision. 

The CRA is intended to make connected hardware and software more secure throughout their lifecycles. Most CRA product-security and conformity requirements apply beginning December 11, 2027, but mandatory reporting begins earlier, on September 11, 2026.

An actively exploited vulnerability generally means there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. A severe incident is an incident that negatively affects, or is capable of negatively affecting, a product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. An incident is also considered severe if it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in a user's network and information systems. . 

Once you become aware of a reportable event, the clock begins. An early warning must be submitted without undue delay and no later than 24 hours after awareness. A more complete notification is generally due within 72 hours. For an actively exploited vulnerability, a final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month after the 72-hour notification. 

Your response plan should also address customer communications. The CRA requires manufacturers to inform impacted users—and, where appropriate, all users—about actively exploited vulnerabilities or severe incidents and any corrective or risk-mitigation measures users may need to take. Reports are submitted through ENISA’s Single Reporting Platform. The reporting clock may begin before you have completed your investigation, so your process needs to work even outside normal business hours and when an issue may involve a third-party component.

Start Preparing in 15 Minutes: Five Steps You Can Take Now 

1. Name the reporting team — 3 minutes. Write down one primary and one backup person for receiving alerts, assessing the event, approving the report, and submitting it. Include phone numbers or another method that works after normal business hours.

2. Create one reporting channel — 2 minutes. Choose a monitored email address or ticket queue, such as security@[company].com, where employees, customers, suppliers, and researchers can report product vulnerabilities or incidents involving your products.

3. Create a one-page event record — 3 minutes. Include the product name, affected versions, relevant third-party products or components involved, date and time of awareness, who reported the problem, evidence of exploitation, possible customer impact, available mitigations, and the assigned owner.

4. Set three calendar triggers — 2 minutes. From the recorded awareness time, mark the 24-hour early-warning deadline, the 72-hour notification deadline, and the applicable final-report deadline. Do not wait for a complete investigation before starting these timers.

5. Understand the reporting process and run a quick test — 5 minutes. Identify who would submit a report through ENISA's Single Reporting Platform and review ENISA's current instructions for accessing and using the platform. Then test your internal escalation process with a simple scenario: “A supplier tells us that attackers are actively exploiting a vulnerability in a component used in our product. Who needs to be contacted right now?” 

Take these five steps today. They will not complete your entire CRA compliance program, and an actual report will normally require more than 15 minutes, but they will give your company a working starting point before an emergency occurs. After completing the setup, schedule a full reporting exercise, confirm which products and versions are affected, train backup personnel, and review ENISA’s current platform instructions.

September 11 is coming. If the CRA applies to your products, now is the time to prepare: identify your CRA responsibilities, establish your reporting process, and make sure your team can respond before the next security alert starts the clock.

Official CRA Resources

For current requirements and reporting instructions, consult the European Commission and ENISA directly:

• European Commission — Cyber Resilience Act Reporting Obligations

• ENISA — CRA Single Reporting Platform FAQ

• European Commission — Cyber Resilience Act Overview

Note: EU-CyCLONe has no relation to PEmicro's Cyclone products.

Important Disclaimer: This article is provided by PEmicro for general educational and informational purposes only. It is not legal, regulatory, cybersecurity, compliance, engineering, or professional consulting advice and should not be relied upon as a substitute for advice from qualified legal counsel, compliance professionals, cybersecurity specialists, or conformity-assessment experts. Publication of this article does not create an attorney-client, consultant-client, advisory, fiduciary, or other professional relationship between PEmicro and any reader.

The information in this article is based on PEmicro’s understanding of the EU Cyber Resilience Act and related guidance as of the publication date. Laws, regulatory interpretations, technical standards, reporting systems, deadlines, and official guidance may change. PEmicro does not represent or warrant that this information is complete, accurate, current, applicable to a particular product, or sufficient to establish or demonstrate CRA compliance.

Each manufacturer, developer, importer, distributor, integrator, and other economic operator is independently responsible for determining the laws and requirements applicable to its products and activities. Customers are solely responsible for determining their role and obligations under the CRA; conducting any required risk assessments and conformity assessments; maintaining technical documentation; monitoring and addressing vulnerabilities; and making complete and timely regulatory reports. 

References or links to ENISA, the European Commission, national authorities, standards organizations, or other third parties are provided only for convenience. PEmicro does not control and is not responsible for third-party content, systems, availability, interpretations, instructions, or changes. Customers should verify all requirements using current official sources and obtain advice appropriate to their products, roles, markets, and circumstances.

To the fullest extent permitted by applicable law, PEmicro disclaims all express, implied, and statutory warranties relating to this article and any associated templates, checklists, examples, or guidance, including warranties of accuracy, completeness, merchantability, fitness for a particular purpose, and non-infringement. PEmicro shall not be liable for any direct, indirect, incidental, special, consequential, exemplary, or punitive damages; lost profits, revenue, business, data, or opportunities; regulatory penalties; reporting failures; compliance costs; product delays; security incidents; or third-party claims arising from or related to reliance on or use of this material.