Skip to content
Knowledge base

Cyber Resilience Act (CRA): 3 vulnerability definitions you need to know

The Cyber Resilience Act (CRA) regulation introduces stringent new requirements for vulnerability management. There has been a lot of confusion surrounding the topic, so we have prepared a concise FAQ that explains the three key definitions of vulnerabilities from Article 3 of the CRA. Understanding

Marcin Godula Marcin Godula

Shortcuts

What is the Cyber Resilience Act (CRA) and why is it worth knowing?

The Cyber Resilience Act (CRA) is a new landmark European Union regulation aimed at enhancing the security of all products with digital elements sold within its borders. From software to IoT devices to operating systems, the CRA imposes a series of stringent cybersecurity obligations on manufacturers that must be met throughout the product lifecycle. The regulation is of fundamental importance to any company creating or marketing such products, as non-compliance with its requirements can result in a sales ban and severe financial penalties.

One of the most key, and most questionable, areas regulated by the CRA is vulnerability management. The way an organization will have to identify, classify and respond to vulnerabilities in its products will change fundamentally. Understanding the precise definitions introduced by the regulation is the first and most important step to building an effective compliance strategy.

At the center of this change are three definitions of vulnerability, all contained in Article 3 of the regulation. A precise distinction between them makes it possible to understand what actions need to be taken in certain situations - from routine risk management, to withholding supplies, to mandatory reporting to EU authorities. The following FAQ aims to organize this knowledge and present it in an accessible manner.

📚 Read the complete guide: SOC: Security Operations Center - czym jest, jak działa, jak wybrać

What are the three key definitions of vulnerability according to the CRA?

The Cyber Resilience Act regulation introduces a vulnerability hierarchy to reflect the level of risk a vulnerability poses to end users. Instead of treating all detected vulnerabilities equally, the CRA forces manufacturers to assess the real threat and prioritize actions. Understanding these categories is key, as very different responsibilities are provided for each.

All three definitions can be found in Article 3 of the CRA. They are:

  • “Primary” vulnerability - a broad term that includes any potential weakness.

  • Vulnerability exploitable - a vulnerability that poses a real and practical threat.

  • Actively exploited vulnerability - a vulnerability that has already been used by cybercriminals in a real-world attack.

Each of these definitions implies a different set of actions, from the standard vulnerability management process, to the immediate need to issue a patch, to the obligation to report the incident to national and EU CERTs. Correct vulnerability classification thus becomes the foundation of an effective and legitimate product security process.

What is a “primary” vulnerability?

The CRA’s definition defines a vulnerability as “a weakness, vulnerability or flaw in a product with digital elements that can be exploited by a cyber threat.” This is the broadest possible definition, which includes any potential vulnerability, regardless of its criticality or real likelihood of exploitation.

In practice, this is any vulnerability identified by the scanner, any entry in the CVE (Common Vulnerabilities and Exposures) database, and any other weakness reported by security researchers or users. When you first run a vulnerability scanner on your product, you may receive hundreds or even thousands of results - all of which, according to the CRA, fall within this definition.

Most of these “basic” vulnerabilities may not pose a serious threat to your particular product in its typical operating environment. However, the regulation requires the manufacturer to have a process to manage them all: identifying them, assessing the risk and deciding on next steps.

What is an “exploitable vulnerability” (vulnerability)?

The second definition is already much narrower and refers to vulnerabilities that “can be effectively exploited by an adversary under practical operational conditions.” This is a category of vulnerabilities that pose a real and serious threat to your product. This is no longer a theoretical vulnerability, but a practical avenue that an attacker can use to compromise your system.

The key phrase here is “under practical operating conditions.” This means that the assessment of whether a vulnerability is exploitable is up to the manufacturer and must be made in the context of the specifics of the product and its anticipated usage environment. The same vulnerability in one component may be critical and insignificant in another if the component is not exposed to an external attack.

External sources such as exploitability assessments (e.g., within CVSS), as well as public directories such as CISA KEV (Known Exploited Vulnerabilities) or the EUVD directory created by ENISA, can help in the decision-making process. If a vulnerability is on such a list, it is almost certain that it should be classified as exploitable.

What is an “actively exploited vulnerability” (actively exploited vulnerability)?

This definition is the most critical and refers to a vulnerability “for which there is credible evidence that the malicious actor has exploited it on a system without the consent of the owner of that system.” Simply put, this is a situation where a vulnerability in your product has already been used in a real-world attack on one of your customers.

It is easiest to think of this category in terms of a security incident, not just the vulnerability itself. “Actively exploited” means that something bad has already happened. It could be an alert from a customer’s SOC system indicating that your product has been used as an attack vector into the corporate network, or a confirmed incident with real losses in which a vulnerability in your software played a key role.

These cases are likely to be rare, but require an immediate and decisive response. Information about an actively exploited vulnerability triggers the most stringent procedures under the regulation, including mandatory notifications to national and EU authorities.

What responsibilities does the CRA impose in managing “core” vulnerabilities?

For the broadest category of vulnerabilities, the CRA requires manufacturers to implement and maintain a systematic process for managing them, according to Annex I, Part II of the regulation. This means that each company must regularly scan its products for new publicly disclosed vulnerabilities and analyze those reported by external researchers.

The manufacturer must have a formal responsible disclosure process that allows third parties to safely report vulnerabilities found. Then, for each vulnerability identified, the company must conduct a risk assessment to determine whether it is exploitable in the context of the product. Based on this assessment, a decision is made on next steps - whether it is necessary to notify customers or whether a security patch should be prepared.

If the vulnerability requires the issuance of a fix (patch), the manufacturer is obliged to publicly disclose information about the vulnerability, but only after the relevant security feature has been made available to customers. These obligations will apply to products with digital components marketed from December 2027.

What should be done about “exploitable vulnerabilities”?

The presence of a exploitable vulnerability in a product has much more serious consequences. According to one of the key requirements of the CRA (Annex I, Part I), products placed on the market must not have any known vulnerabilities of this type. This means that the discovery of such a vulnerability effectively prevents the sale or further delivery of the product to customers.

If such a vulnerability is identified in a product that is already on the market, it loses CRA compliance. The manufacturer is obliged to fix the vulnerability as soon as possible by issuing a security update. Otherwise, he will no longer be able to sell the product and may be forced to withdraw it from the market.

As with the underlying vulnerabilities, once the patch is delivered, the manufacturer is required to publicly disclose information about the vulnerability as part of the responsible disclosure process. These requirements, like the previous ones, will take full effect in December 2027.

Vulnerabilities in the Cyber Resilience Act

Type of vulnerabilityDefinition ofExampleKey dutyBasicAny potential weakness, flaw or vulnerability.Vulnerability scanner result, CVE database entry.Have a management process: identification, risk assessment, possible correction.Possible to useA vulnerability that can be effectively used by an attacker in practice.Vulnerability from the CISA KEV list or with a high exploitability rating.Prohibition of product marketing; obligation to correct immediately.Actively usedA vulnerability that has already been used in a real-world attack on a client’s system.A security incident in which the product was an attack vector.Report to national CERT and ENISA within 24 hours; take corrective action.

What are the procedures for reporting “actively exploited vulnerabilities”?

If an actively exploited vulnerability is identified, a special reporting procedure specified in Article 14 of the CRA is triggered. The manufacturer is required to immediately notify the relevant national CERT team (in Poland it is CERT Poland) and the European Union Cyber Security Agency (ENISA) of the incident. Notification must take place no later than 24 hours after knowledge of the incident.

In addition to the notification itself, the manufacturer must, of course, take immediate corrective action to eliminate the threat and protect users. This means preparing and distributing a security patch as a matter of priority and informing its customers about the risk and available remedies.

Remarkably, this is the only obligation under the CRA that also applies to products placed on the market prior to the entry into force of the regulation (so-called “legacy products”), as specified in Art. 69. This means that even if your product was sold many years ago, you will be required to report such incidents from the time this regulation takes effect.

What are the key deadlines for implementing CRA requirements?

Understanding the timeline for when the various provisions of the Cyber Resilience Act will take effect is key to properly planning adaptation efforts. The regulation provides a transition period to give manufacturers time to prepare for the new stringent requirements, but some obligations will take effect earlier than others.

The earliest and one of the most important deadlines is September 2026. From that date, in accordance with Article 71, the procedure for reporting actively exploited vulnerabilities (Article 14) will take effect. This means that starting from that date, manufacturers will have to report such incidents to CERT and ENISA, including for historical products.

Full implementation of most of the remaining obligations, including requirements for managing “baseline” and “exploitable” vulnerabilities (under Annex I), will take place in December 2027. From that point on, all new products with digital elements launched in the EU market will have to be fully compliant with the Cyber Resilience Act.

How can nFlo help you prepare for the Cyber Resilience Act?

Preparing an organization for the requirements of the Cyber Resilience Act is a complex process that requires not only technical expertise, but also an in-depth understanding of the new regulations and their impact on business processes. At nFlo, our mission is to support businesses in building digital resilience, and our services are directly aligned with the challenges posed by the CRA.

Our team of experts can help your company conduct a gap analysis, identifying areas where current lifecycle management processes deviate from the regulation’s requirements. We can help you design and implement formal vulnerability management procedures, including a responsible disclosure policy and a risk assessment and vulnerability classification system.

We also offer support for product security audits and penetration testing to proactively identify vulnerabilities before they become a problem once the CRA goes into effect. With our partnership and knowledge backed by experience, your organization can not only achieve compliance with the new law, but also significantly improve the security of its products, building customer confidence and a competitive advantage in the marketplace.

Learn key terms related to this article in our cybersecurity glossary:

Learn More

Explore related articles in our knowledge base:

Explore Our Services

Need cybersecurity support? Check out:

Tags:

Vulnerabilities Cybersecurity Compliance SOC Network

Share:

Talk to an expert

Have questions about this topic? Get in touch with our specialist.

Sales Representative
Grzegorz Gnych

Grzegorz Gnych

Sales Representative

+48 664 003 003grzegorz.gnych@nflo.pl
Response within 24 hours
Free consultation
Individual approach

Providing your phone number will speed up contact.

Want to Reduce IT Risk and Costs?

Book a free consultation - we respond within 24h

Response in 24h Free quote No obligations
Book a Call +48 22 487 86 36

Or download free guide:

Download NIS2 Checklist