图片名称

LCS Network Security | CRA 9.11 Vulnerability Reporting FAQ QA

Author.

LCS

Source:

Post time:

2026-08-27

CRA 9.11 Vulnerability Reporting: The 12 Most Concerned Issues for Enterprises, Explained at Once


 

CRA 9.11 Vulnerability Reporting Obligation Countdown


 

As September 11, 2026 approaches, the vulnerability reporting obligation for overseas enterprises is about to officially come into effect.


 

On September 11, 2026, the vulnerability and incident reporting obligations of the European Union's Cyber Resilience Act (CRA) will officially come into effect. This is the earliest and most urgent obligation of the CRA to be implemented - it does not require you to complete CE certification or conformity assessment first, but directly requires that as long as your product is sold in the EU market, any vulnerabilities or serious security incidents that are actively exploited must be reported in a very short period of time.


 

Many companies still have a lot of questions about this obligation: what exactly should be reported? When is 24 hours counted? Who is responsible for the vulnerabilities of third-party components? What if I don't report? This article compiles 12 high-frequency questions and provides answers based on the original regulations and the latest guidelines from the European Commission.


 

01

Q: What exactly is CRA 9.11? Is it Article 9, Paragraph 11?

Not the term number, but the effective date.


 

Article 14 of the CRA stipulates the manufacturer's obligation to report vulnerabilities and incidents, and the applicable date of this provision is September 11, 2026. The industry commonly uses "CRA 9.11" to refer to this time point, just as "GDPR 5.25" refers to the effective date of the EU General Data Protection Regulation.


 

This is the earliest substantive obligation to come into effect in the entire CRA regulation. The applicable dates for other obligations (such as CE certification, conformity assessment, technical documentation, etc.) are later and will be implemented in stages in 2027 and 2028.


 

02

Q: Which companies must comply with it? Are Chinese manufacturers also included?

As long as your product belongs to the category of "Products with Digital Elements" (PDE) and is launched in the EU market, it needs to comply.


 

The term 'manufacturer' here is not limited to companies within the European Union. The CRA adopts a "market access" logic - any manufacturer that places a product on the EU market, whether registered in the EU or a third country (including China), is subject to the reporting obligation under Article 14.


 

If you are a brand owner, ODM/OEM manufacturer, or a hardware/software enterprise with your own brand going global, this obligation directly applies to you.


 

03

Q: Under what circumstances must it be reported? Do I have to report a vulnerability once it is discovered?

Not all vulnerabilities need to be reported. CRA Article 14 only requires reporting two types of situations:


 

Category 1: Actively Exploited Vulnerability


 

There is reliable evidence to suggest that malicious actors have actually exploited the vulnerability without the permission of the system owner. The definition in the original text of the regulation (Article 3, Paragraph 42) is very clear - there must be "reliable evidence" to prove that "actual utilization" has occurred.


 

Category 2: Severe Incident


 

Security incidents that have a negative impact (or may have a negative impact) on the availability, authenticity, integrity, or confidentiality of product protection data or functionality. The criteria for determining severity are specified in CRA Annex I.


 

Key distinction: If you discover a vulnerability during internal testing that has not yet been exploited, you can follow the normal vulnerability management process and do not need to go through the CRA reporting channel. Mandatory reporting is only triggered when vulnerabilities are actively exploited.


 

04

Q: How to determine 'actively utilized'? Is one victim enough?

The regulations do not set a threshold for the scale of utilization. According to the definition in Article 3 (42) of the CRA and industry interpretation, as long as there is reliable evidence that the malicious actor actually exploited the vulnerability, it is sufficient to trigger the reporting obligation.


 

What constitutes' reliable evidence '? Common situations include:


 

Your clients or users have reported experiencing attacks that exploit this vulnerability;


 

Your security monitoring system has detected genuine exploitation behavior targeting this vulnerability;


 

Authoritative institutions (such as CISA's known exploited vulnerability directory KEV, ENISA's EU vulnerability database EUVD) mark the vulnerability as being exploited;


 

Security researchers have provided verifiable evidence of utilization.


 

Note: Just 'exploitable' does not necessarily mean 'actively exploited'. If a high-risk vulnerability has not been actually attacked yet, there is no need to go through the CRA mandatory reporting channel.


 

05

Q: What do I need to report for 24 hours, 72 hours, and 14 days?

Article 14 of the CRA stipulates a three-stage reporting mechanism, with different content requirements for each step:


 

Phase 1: Within 24 hours - Early Warning


 

Submit an early warning through the SRP platform within 24 hours from the time you become aware of a vulnerability or serious incident that has been actively exploited. This stage does not require a complete technical analysis, the core is to quickly inform the regulatory authorities that something has happened. The content usually includes: a brief description of the affected products, vulnerabilities/events, and known preliminary impacts.


 

Phase 2: Within 72 hours - Full Notification


 

Submit a more detailed technical report within 72 hours, including an assessment of the severity of the vulnerability, affected product versions, known attack indicators (IOC), scope of impact, and mitigation measures taken or planned.


 

Phase 3: Final Report


 

For actively exploited vulnerabilities: submit within 14 days after repair or mitigation measures are available;


 

For serious incidents: submit within one month after 72 hours of notification.


 

The final report should include: root cause analysis, complete remediation plan, coordinated disclosure strategy, and a comprehensive impact assessment of the event.


 

06

Q: When does 24 hours start counting?

This is one of the easiest problems to get stuck in.


 

The 24-hour clock starts from the moment the manufacturer becomes aware, rather than from the completion of internal troubleshooting, release of CVE, or readiness of repair solutions.


 

The European Commission's guideline (C (2026) 5252 final) released on July 27, 2026, further clarifies that the time point of "knowledge" is when the manufacturer confirms two things simultaneously - (1) their own product is affected; (2) This vulnerability is being actively exploited.


 

This means that if you receive a vulnerability report but are still verifying whether it really affects your product and whether it has been exploited - this verification time theoretically does not count towards 24 hours. But once you confirm these two points, the clock starts immediately.


 

Practical advice: Do not understand "knowing" as "the technical team completing all the analysis". Establishing an internal rapid judgment mechanism (security → legal → management upgrade path) and immediately initiating the reporting process after confirming the triggering conditions is the prudent approach.


 

07

Q: Where to report? How to use the SRP platform?

All reports must be submitted through the Single Reporting Platform (SRP), which is the only legal channel as stipulated in Article 16 of the CRA. Email, phone, and private contact with CSIRT do not meet legal requirements.


 

SRP is built and operated by ENISA (European Network Security Agency) and will be officially launched on September 11, 2026. You only need to submit once on SRP, and the platform will simultaneously deliver the information to two recipients:


 

The CSIRT (Computer Security Incident Response Team) of the country where your company's main institution is located;


 

ENISA (EU level).


 

Receiving CSIRT will subsequently share information with CSIRT of other affected member states as necessary.


 

First use requires registration: access the SRP platform, select your role (manufacturer), choose the corresponding country CSIRT from the drop-down menu, authenticate your identity through EU Login, read and accept legal agreements, and fill in the manufacturer's name, address, and other information. It is recommended to complete the registration before September 11th to avoid being flustered when the incident occurs.


 

08

Q: Do I need to report vulnerabilities in third-party components or open-source libraries?

This depends on whether the vulnerability has been exploited in your product.


 

The European Commission's July 2026 guidelines clarify the principles of judgment:


 

If the vulnerability originates from third-party components (such as open source libraries, chip firmware, SDKs) and is actively exploited in your product - as a product manufacturer, you have a reporting obligation;


 

If the vulnerability cannot be exploited in your product, or has not been exploited in your product - even if the same vulnerability is being exploited in other vendors' products, your reporting obligation will not be triggered.


 

This means that you cannot simply say 'this is an upstream issue, it has nothing to do with me'. You need to evaluate whether the vulnerability of this third-party component can really be exploited in my product configuration and usage scenario? If the answer is affirmative and there is evidence that it has been exploited, it must be reported.


 

Practical suggestion: Establish SBOM (Software Bill of Materials) management capability to quickly locate the usage and availability of third-party components in the product, which is the foundation for addressing such issues.


 

09

Q: What are the consequences of not reporting or reporting late?

Violation of the reporting obligation under Article 14 is subject to the highest penalty level of CRA.


 

According to Article 64 of the CRA, non compliant enterprises may face:


 

Administrative fines of up to 15 million euros; or


 

2.5% of the global annual revenue in the previous fiscal year;


 

The higher of the two shall prevail.


 

This penalty level is the same as the punishment for violating CRA core safety requirements (Attachment I) and is the most severe in the entire regulation. The CRA adopts a "whichever is higher" mechanism similar to GDPR, which means even companies with low revenue may face a maximum fine of 15 million euros.


 

In addition, the competent authorities of member states may take other corrective measures, such as requiring products to be removed from shelves, recalls, etc.


 

10

Q: Do I need to disclose it to the public after reporting?

Yes, but there is a time difference.


 

Article 14, Paragraph 8 of the CRA stipulates that after reporting to ENISA and CSIRT, manufacturers should also inform users of actively exploited vulnerabilities and serious incidents, as well as the protective measures that users can take.


 

But regulations also allow for 'coordinated disclosure' - manufacturers can coordinate with CSIRT to temporarily delay public disclosure until a fix is in place to prevent attackers from exploiting the unrepaired vulnerabilities. The usual practice is to first report to the regulatory authorities, and then disclose to the public through safety notices, CVE records, and other means after the release of repair or mitigation measures.


 

Key principle: There is a hard deadline of 24/72 hours for reporting to regulatory authorities; Disclosure to the public can be coordinated with the pace of restoration, but cannot be concealed indefinitely.


 

11

Q: September 11th is not far away, what should companies do now?

If you are not ready yet, the following are the top priority things:


 

1. Complete SRP platform registration - register an account in advance, complete EU Login authentication, and select the corresponding CSIRT to avoid discovering login issues only when an incident occurs.


 

2. Establish an internal reporting decision-making process - clarify who will judge whether to trigger the submission, who will approve the submission, and who will execute the submission. The 24-hour window does not allow hierarchical approval.


 

3. Sort out the product asset list - know which products are sold in the EU market and which software and hardware components they contain, in order to quickly determine the scope of impact when vulnerabilities arise.


 

4. Establish a vulnerability receiving channel - set up a security @ email or vulnerability disclosure page to ensure that external researchers and clients can deliver vulnerability information to you.


 

5. Prepare reporting templates - Prepare templates for 24-hour early warning and 72 hour detailed notification in advance, pre fill in fixed fields such as product information and contact person, and only add event specific content when an incident occurs.


 

6. Training related teams - security, legal, public relations, and customer service teams - all need to be aware of the existence and basic process of CRA reporting obligations to avoid delays in internal information transmission.


 

12

Q: How to solve the low efficiency of manual monitoring and reporting of enterprise vulnerabilities?

Lixun has launched the Automated Vulnerability Management Cloud Platform (Article 14 Solution), which greatly improves the efficiency of vulnerability management. Platform capabilities:


 

1) Generate standardized SBOM


 

2) Vulnerability analysis


 

3) Continuous vulnerability monitoring


 

4) Vulnerabilities in receiving external reports


 

5) Quick one click automated SRP reporting


 

6) Efficiency improvement+auditability

 


 

Our advantage!!!


 

The Network Security Laboratory of Lixun Network Security Department holds dual authoritative laboratory qualifications of CNAS and A2LA, and has been deeply involved in EN18031, ETSI EN 303 645, IEC62443, ISO27001 and SDLC landing projects. It has rich experience in network security technology and information security system construction, and is equipped with a team of senior compliance and security experts, relying on mature project accumulation to comprehensively support the implementation of enterprise CRA compliance.

Media Center

Latest News

Contact Us

图片名称
图片名称

National 24-hour service hotline

400-116-2629

Group Headquarters

Cell phone:18126505465

E-mail: webmaster@lcs-cert.com

Address: Shenzhen City, Baoan District, Shajing Street, Nga side of the school of Wei Juji Industrial Park, Building A 1 ~ 2 floor, Building C 3 floor