Author: TJC Group Content team
From 11th September 2026, manufacturers of products with digital elements covered by the EU Cyber Resilience Act (CRA) will face a new reporting obligation. When they become aware of an actively exploited vulnerability or a severe security incident that meets Article 14 criteria, the first notification must be submitted within 24 hours.
For software developers, including companies building products for SAP environments, it is now mandatory to know what is reportable, and how the required information reaches the authorities within the deadline. When customers identify such issues, they need to inform the supplier.
Key takeaways
- CRA Article 14 reporting obligations apply from 11 September 2026.
- The CRA applies to relevant hardware and software products with digital elements made available on the EU market.
- Manufacturers must report certain actively exploited vulnerabilities and severe security incidents affecting products with digital elements.
- An initial early warning is required without undue delay and within 24 hours of becoming aware.
- A more detailed notification follows within 72 hours.
- Not every vulnerability triggers Article 14. The reporting requirement for vulnerabilities applies where there is reliable evidence of malicious exploitation.
- Reports are submitted through the European Union Agency for Cybersecurity (ENISA)CRA Single Reporting Platform, with the relevant CSIRT designated as coordinator.
- For SAP partners that develop their own software products, preparation should focus on rapid assessment, defined ownership, documentation and escalation.
What is the EU Cyber Resilience Act?
The Cyber Resilience Act (CRA) is an EU regulation designed to strengthen the cybersecurity of hardware and software products with digital elements made available on the European market.
The European Commission proposed the legislation on 15 September 2022. The final regulation entered into force on 10th December 2024, while most provisions will become fully applicable from 11th December 2027. The Article 14 reporting requirements arrive earlier, from 11th September 2026.
The CRA aims to establish cybersecurity requirements for the development and maintenance of digital products, while giving users better information about the security of the products they buy and use.
Cybersecurity responsibilities do not end when software is released. Manufacturers must also put in place the right processes to identify vulnerabilities, handle security incidents, maintain products, and provide security updates throughout the relevant product lifecycle.
Article 14 adds a time-sensitive reporting obligation to that wider responsibility.
For software developers in the SAP ecosystem, the CRA becomes particularly relevant where they develop and place their own products with digital elements on the EU market.
What does CRA Article 14 require?
Article 14 focuses on two specific types of security events.
Actively exploited vulnerabilities
An actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner.
This does not mean that every vulnerability discovered in a software product becomes an Article 14 report. The distinction depends on evidence of exploitation rather than vulnerability discovery alone.
For example, a development team may identify a weakness during internal testing and correct it before there is evidence of malicious exploitation. The vulnerability still requires appropriate handling, but it does not meet the Article 14 definition of an actively exploited vulnerability simply because it exists.
This is not the same as simply discovering a CVE or vulnerability. A CVE affecting UI5, Node.js, Java, a SAP BTP dependency, or an ABAP component is not automatically reportable under Article 14. The same applies to an exploit published on GitHub, a penetration-test finding, a PoC demonstrated by an authorised researcher, or a bug-bounty report with no evidence of malicious use. The CRA Hub FAQ specifically distinguishes good-faith security research from malicious exploitation.
Severe security incidents
Article 14 also covers severe incidents having an impact on the security of a product with digital elements.
ENISA describes an incident affecting product security as one that negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of its data or functions. Article 14 then establishes the threshold for when that incident is considered severe.
CRA Article 14 defines a severe incident as one that can affect sensitive/important data or functions, or where it has led or could lead to malicious code being introduced/executed in the product or the user’s network.
The underlying definition of an “incident” comes from the NIS2 Directive, and it refers to “an event compromising availability, authenticity, integrity or confidentiality”. In other words, a purely theoretical vulnerability is not itself an incident.
A routine software error or minor technical problem should not automatically be treated as an Article 14 event. The manufacturer needs to assess the nature of the incident and its actual or potential security impact.
When does the reporting clock start?
The reporting process begins when the manufacturer becomes aware of the actively exploited vulnerability or severe security incident.
This makes internal escalation particularly important.
A security concern may first reach a developer, support team, customer-facing employee or cybersecurity specialist. If the organisation does not have a clear route for escalating potential Article 14 events, part of the reporting window may pass before the right team becomes involved.
Article 14 reporting timeline
| Reporting stage | Actively exploited vulnerability | Severe security incident |
|---|---|---|
| Early warning | Within 24 hours of awareness | Within 24 hours of awareness |
| Detailed notification | Within 72 hours of awareness | Within 72 hours of awareness |
| Final report | No later than 14 days after a corrective or mitigating measure becomes available | Within one month after the 72-hour notification |
The European Commission and ENISA both confirm these reporting stages.
What Article 14 means for software developers and SAP partners
For organisations developing software in the SAP landscape, Article 14 makes security-event qualification a time-sensitive process.
Rapid vulnerability assessment
Development and security teams need to distinguish between:
- an ordinary software defect;
- a vulnerability requiring remediation;
- an actively exploited vulnerability;
- a security incident; and
- an incident severe enough to meet the Article 14 criteria.
The objective is to ensure that potentially reportable events reach the appropriate people quickly enough for a decision to be made.
Who owns the response?
Manufacturers must now designate the person(s) or team(s) responsible for:
- assessing whether the incident must be reported; and
- duly reporting it to ENISA within the 24-hour window
Keeping a clear record of the response
A reliable record of the response should also be retained. It should be possible to establish when the issue was first identified, when the manufacturer became aware of it, which product and version were affected, what evidence was available and how the initial security assessment was reached.
ENISA’s current Single Reporting Platform guidance includes fields covering areas such as the product, product version, awareness time, impact, mitigation and event-specific information.
What Article 14 means for SAP customers
Are SAP customers compelled to report actively exploited product vulnerabilities? The answer is no. Under Article 14 of the EU Cyber Resilience Act (CRA), an ordinary SAP customer is not obliged to report vulnerabilities in TJC Group or SAP products to ENISA or a national CSIRT. Still, customers should inform suppliers, such as TJC Group, so that we can act on it.
Article 14 primarily places reporting responsibilities on manufacturers, but customers also have an interest in understanding how their software providers handle serious security events.
On a separate note, SAP customers may have separate incident-reporting obligations under legislation such as NIS2, DORA, GDPR, sector-specific rules, etc.
How is TJC Group preparing for the CRA Article 14?
We have reviewed the requirements of CRA Article 14 and put the right processes in place to respond within the 24/72 hours window. If TJC Group becomes aware that a vulnerability in a TJC product has been actively exploited maliciously and the criteria outlined earlier in this article are met, we will duly report it to ENISA via the CRA Single Reporting Platform. We apply the same mechanism when we identify a problem in our internal systems.
If your organisation runs a TJC Group product and you would like to have more information about who to contact in case Article 14 should be activated, please contact your local TJC representative and we will get in touch with you promptly.
TJC Group, ISO 27001-certified
TJC Group achieved ISO 27001 certification in 2024 after establishing an Information Security Management System, or ISMS, aligned with the requirements of the standard.
ISO 27001 provides an internationally recognised framework for managing information-security risks through defined policies, controls and processes.
TJC Group’s certification reflects its commitment to protecting the confidentiality, integrity and availability of sensitive information and to continually maintaining and improving its ISMS.
ISO 27001 certification does not replace the specific obligations introduced by the CRA, but it provides a structured foundation for managing information-security risks, responsibilities and processes.
Cybersecurity across the SAP landscape
Cybersecurity is not limited to incident response. It also covers how products are developed, vulnerabilities are assessed, access is controlled, systems are maintained and information is protected throughout its lifecycle.
These wider priorities are explored further in TJC Group’s guide to data security in 2026.
Cybersecurity also intersects with SAP data management. Reducing unnecessary exposure, controlling access to historical information and maintaining appropriate environments all contribute to a stronger security posture. The relationship between data archiving and cybersecurity is particularly relevant in this context.
Older applications may also continue to create exposure even when they are no longer actively developed, which is why legacy system security remains relevant alongside newer CRA obligations.
Further guidance is available across TJC Group’s cybersecurity resources.
Conclusion
CRA Article 14 tells manufacturers what they must do when they discover serious cybersecurity problems affecting their digital products. A manufacturer must report actively exploited vulnerabilities affecting its products to the relevant national CSIRT and ENISA.
Article 14 does not require manufacturers to report every “severe vulnerability”. It requires reporting of two specific things:
- an actively exploited vulnerability; and
- a severe incident having an impact on the security of the product.
SAP customers can report a severe incident to the manufacturer by getting in touch with the designated point of contact. SAP customers are not obliged to do so; however, it is in their best interest to inform the manufacturer as soon as possible so that action can be taken.
If you are a TJC Group customer and have any questions about CRA Article 14, do not hesitate to contact us.
Sources of information
European Commission: Cyber Resilience Act
European Commission: CRA reporting obligations
ENISA: CRA Single Reporting Platform FAQs
ENISA Frequently Asked Questions
Cyber Resilience Act Article 14
Cyber Resilience Act guide for software developers
FAQ's
Q1. When does CRA Article 14 apply?
Answer:
The Article 14 reporting obligations apply from 11 September 2026. Most of the CRA’s wider requirements become fully applicable from 11 December 2027.
Q2. What is an actively exploited vulnerability?
Answer:
It is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner.
Q3. What is considered a severe security incident?
Answer:
A severe incident is assessed against the criteria in Article 14. The underlying definition covers incidents that negatively affect, or are capable of negatively affecting, a product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions.
Q4. Who needs to report under CRA Article 14?
Answer:
The obligations discussed here apply to manufacturers of products with digital elements that fall within the scope of the CRA.
Whether they apply to a particular software company depends on its role and the product concerned.
Q5. How quickly must an event be reported?
Answer:
The initial early warning must be submitted without undue delay and, in any case, within 24 hours of awareness. A more detailed notification follows within 72 hours.
Q6. Where are CRA Article 14 notifications submitted?
Answer:
Notifications are submitted through ENISA’s CRA Single Reporting Platform. The manufacturer selects the appropriate CSIRT designated as coordinator when making the submission.
Q7. Does Article 14 apply to products already on the market?
Answer:
Yes. ENISA clarifies that the reporting obligations apply from 11 September 2026 to EU products with digital elements falling within the scope of the CRA, including relevant products placed on the market before the CRA becomes fully applicable in December 2027.
Q8. How is TJC Group preparing for the Cyber Resilience Act (CRA) Article 14?
Answer:
We have informed our customers about the updates on Article 14 of the Cyber Resilience Act and we have put in place the right mechanism to act on it should we have to. TJC Group is already ISO 27001-certified, which means that an Information Security Management System is in place to efficiently manage any threats or cybersecurity incidents as an ongoing operational responsibility
