A CVE is a shared identifier for a publicly known security vulnerability — one record per flaw, so that everyone discussing it knows they mean the same thing. It is a name, not a judgment: severity scoring is a separate system. The EU Cyber Resilience Act (CRA) is a law that makes security a legal duty for products with digital elements sold in the EU: secure design, vulnerability handling, security updates, and incident reporting, with obligations arriving between September 2026 and December 2027.
The two fit together simply: CVEs are the vocabulary the industry uses to talk about vulnerabilities, and the CRA is the obligation to act on them.
Suppose a memory error is found in a software library that thousands of products ship. The person who found it calls it one thing, the library’s maintainers call it another, a security vendor gives it a third name, and a device maker’s support team cannot tell whether the three reports describe one problem or three. Everything in this guide exists to solve that confusion and its consequences.
This article explains what a CVE is, what the Cyber Resilience Act is, why each exists, and how they meet — written for engineers meeting these terms for the first time.
What is a CVE?
CVE stands for Common Vulnerabilities and Exposures. The system was launched in 1999 by MITRE, a US non-profit research organisation, to give the industry one authoritative reference method for publicly known vulnerabilities. The rule is simple: one CVE record for each vulnerability. When a flaw receives an identifier such as CVE-2024-1086, every advisory, patch note, scanner report, and news article about that flaw can use the same name, and everyone knows they are discussing the same problem.
A CVE record is deliberately minimal: an identifier, a description of the flaw, the affected product and versions, and references. Note what it does not contain — a verdict on how dangerous the flaw is for you.
Severity is handled by a separate system, CVSS (Common Vulnerability Scoring System), which assigns a score from 0 to 10, and by databases such as the US National Vulnerability Database (NVD) that enrich CVE records with scores and metadata. The distinction matters: the CVE programme aims to catalogue every vulnerability, dangerous or trivial, so a CVE existing against a product tells you nothing about risk by itself.
💡 Key insight: A CVE is a shared name, not an alarm. It tells you a flaw is publicly catalogued; whether that flaw matters for your system depends on your version, configuration, and use — an assessment the CVE itself does not make.
Who assigns these identifiers? Organisations called CVE Numbering Authorities (CNAs). Vendors, security companies, and — increasingly — open-source projects themselves act as CNAs for their own code: the Linux kernel, curl, and the Python project have all taken this role, so that no outside party can assign a CVE against their code without their involvement. The Linux kernel’s decision to become a CNA in 2024 changed the volume and meaning of kernel CVEs considerably, and we have covered what that means for device makers in Kernel CVEs and the EU Cyber Resilience Act.
What is the Cyber Resilience Act?
For decades, connected products could be sold with known vulnerabilities, no update mechanism, and no obligation to fix anything after the sale. Routers, cameras, and appliances stayed in service for years while their software went without updates, and the cost of the resulting incidents fell on users. The Cyber Resilience Act is the EU’s response: a regulation that makes cybersecurity a legal requirement for nearly every product with digital elements placed on the EU market, hardware and software alike.
In plain terms, the CRA requires manufacturers to design products securely, to ship them without known exploitable vulnerabilities, to keep a documented process for handling vulnerabilities discovered later, to provide security updates through the product’s support period, and to report actively exploited vulnerabilities and severe incidents to the authorities.
Compliance becomes part of CE marking — the same conformity regime that already covers safety and electromagnetic compatibility. Non-compliance carries fines of up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher.
The dates to know:
| When | What applies |
|---|---|
| Dec 2024 | The CRA entered into force. |
| Sep 2026 | Reporting obligations begin: actively exploited vulnerabilities and severe incidents must be reported, starting with an early warning within 24 hours. |
| Dec 2027 | Full obligations apply: secure design, vulnerability handling, security updates through the support period, and conformity assessment as part of CE marking. |
💡 Key insight: The CRA’s real change is not any single requirement — it is that practices which used to be voluntary good engineering, such as shipping updates and tracking vulnerabilities, become conditions for selling the product at all.
How CVEs and the CRA fit together
The two systems have different origins — one from the security community in 1999, one from EU lawmaking in 2024 — but they depend on each other. The CRA obliges a manufacturer to handle vulnerabilities in its product and its components; CVEs are how those vulnerabilities are named, tracked, and referenced in practice.
When an auditor or customer asks how a product deals with known vulnerabilities, the working answer is a process built around CVE feeds: watch the identifiers relevant to your components, assess each against your product, fix what matters, and document the decision. For teams shipping Linux devices, the practical consequences — including how to handle the kernel’s large CVE volume — are the subject of our companion article linked above.
A short glossary
| Term | Meaning |
|---|---|
| CNA | CVE Numbering Authority — an organisation authorised to assign CVE identifiers, often the vendor or project responsible for the affected code. |
| CVSS | Common Vulnerability Scoring System — a separate standard that rates a vulnerability’s severity from 0 to 10; not part of the CVE record itself. |
| NVD | National Vulnerability Database — a US government database that enriches CVE records with severity scores and metadata. |
| SBOM | Software Bill of Materials — a machine-readable list of every software component in a product, so vulnerabilities can be mapped to what you actually ship. |
| ENISA | The EU Agency for Cybersecurity — the body that, with national authorities, receives the vulnerability and incident reports the CRA requires. |
For engineers building a career in embedded systems, this material is no longer optional background — vulnerability handling is becoming part of the everyday definition of shipping a product. The platform skills it rests on are the ground TECH VEDA’s Embedded Linux Fast-Track covers for engineers entering the field.
Key takeaways
- A CVE is one shared identifier per publicly known vulnerability, created so that everyone discussing a flaw means the same thing; it carries no severity verdict of its own.
- Severity lives in separate systems — CVSS scores and databases such as the NVD — and always depends on your product’s version, configuration, and use.
- CVE identifiers are assigned by CNAs, and major open-source projects including the Linux kernel now act as their own.
- The CRA makes secure design, vulnerability handling, security updates, and incident reporting legal requirements for products sold in the EU, tied to CE marking and backed by significant fines.
- The two systems depend on each other: CVEs are the vocabulary of vulnerabilities, the CRA is the obligation to act on them.
Frequently asked questions
Is every CVE dangerous?
No. The CVE programme catalogues every publicly known vulnerability, from trivial to critical, and the record itself carries no severity rating. Whether a CVE matters for you depends on whether your product contains the affected component and version, and how it is used.
Who assigns CVE identifiers?
CVE Numbering Authorities — vendors, security organisations, and open-source projects authorised by the CVE programme. Projects such as the Linux kernel, curl, and Python assign CVEs for their own code, so no outside party can do so without their involvement.
Does the CRA apply to products made outside the EU?
Yes. The CRA applies to products with digital elements placed on the EU market, wherever they are developed or manufactured. A device designed in India or the US must meet the requirements to be sold in the EU, in the same way CE marking already works.
What happens if a manufacturer does not comply with the CRA?
Non-compliant products can be withdrawn from the EU market, and fines reach up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher, for violations of the essential requirements.
Further reading
- CVE Program — overview and mission and MITRE — 25 years of the CVE Program
- European Commission — Cyber Resilience Act
- Kernel documentation — how the Linux kernel assigns CVEs
- TECH VEDA — Kernel CVEs and the EU Cyber Resilience Act (the embedded-specific consequences)
