9 October, 2026
?Every standard in the EN 40000 series, and most of the Cyber Resilience Act itself, leans on a specific set of defined terms: “manufacturer,” “vulnerability,” “substantial modification,” “support period.”
Get one of these wrong in your technical documentation or your risk assessment, and you’re not just using loose language, you may be misapplying a legal obligation. This page walks through what EN 40000-1-1 is, why a vocabulary standard exists at all, and what the CRA’s own definitions actually say, verbatim, for the terms that come up most in compliance work.
What is EN 40000-1-1?
EN 40000-1-1 is the first project (PT1) in the EN 40000 series, officially titled “Cybersecurity requirements for products with digital elements, Part 1-1: Vocabulary.” Its scope, as recorded in its CEN project documentation, is to provide “the terms and definitions commonly used in the cybersecurity requirements for products with digital elements family of standards.”
In practice, that means it’s the reference point of every other EN 40000 document, and a fair amount of the CRA itself, points back to when it needs a term to mean the same thing everywhere.
It doesn’t set requirements of its own. There’s nothing in EN 40000-1-1 to “implement” the way there is in prEN 40000-1-4’s control catalogue. Its job is narrower and, in a compliance program, easy to underrate: making sure that when your engineering team, your legal team, and a notified body all use the word “vulnerability,” they mean the same thing.
Why a vocabulary standard matters in practice
It’s tempting to treat a terminology document as the least important part of a standards family. That’s a mistake for two reasons specific to the CRA.
First, the CRA’s own definitions in Article 3 of the regulation carry legal weight now, independent of when any EN 40000 standard is published. Getting the definition of “manufacturer” or “substantial modification” wrong in your internal documentation isn’t a style issue, it can mean you’ve scoped your own obligations incorrectly.
Second, consistent terminology is what makes the rest of the series usable together. EN 40000-1-2’s risk-assessment process, EN 40000-1-3’s vulnerability handling requirements, and prEN 40000-1-4’s control catalogue all assume the reader already knows what “significant cybersecurity risk” or “exploitable vulnerability” specifically means. EN 40tij000-1-1 is where that shared meaning is supposed to live.
Key CRA definitions explained
The terms below are quoted directly from Article 3 of the Cyber Resilience Act, verified against the official regulation text on EUR-Lex. These are the CRA’s own binding legal definitions, not EN 40000-1-1’s paraphrase of them, since the CRA already applies today and the standard is still in draft. Once EN 40000-1-1 is formally published, it’s expected to align with this same wording rather than introduce a competing set of meanings.
Product with digital elements.
“A software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.” This is the CRA’s core scope term, if your offering doesn’t fit this definition, the rest of the regulation may not apply to you at all.
Manufacturer.
“A natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge.” Note the last clause: giving something away for free doesn’t put you outside this definition.
Economic operator.
“The manufacturer, the authorised representative, the importer, the distributor, or other natural or legal person who is subject to obligations” under the CRA. Manufacturer-specific obligations (like the ones on EN 40000-1-2 and EN 40000-1-3) are one category inside this broader term, not a synonym for it.
Open-source software steward.
A distinct category from “manufacturer”: “a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products.” Worth knowing precisely if your organization maintains open-source components others rely on.
Cybersecurity risk.
“The potential for loss or disruption caused by an incident,” expressed as a combination of the magnitude of that loss or disruption and the likelihood of the incident occurring. This is the concept EN 40000-1-2’s risk-assessment process exists to operationalise.
Significant cybersecurity risk.
A cybersecurity risk which, “based on its technical characteristics, can be assumed to have a high likelihood of an incident that could lead to a severe negative impact.” The CRA treats this as a higher bar than ordinary cybersecurity risk, not every risk your assessment surfaces meets this threshold.
Vulnerability, exploitable vulnerability, and actively exploited vulnerability.
These three terms are easy to conflate but trigger different obligations. A vulnerability is simply “a weakness, susceptibility or flaw… that can be exploited by a cyber threat.” An exploitable vulnerability is one that “has the potential to be effectively used by an adversary under practical operational conditions,” a narrower, more urgent category. An actively exploited vulnerability is narrower still: one for which “there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” It’s this last category that starts Article 14’s 24-hour reporting clock, not any vulnerability in general.
Software bill of materials.
“A formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements.” The specific mechanism EN 40000-1-3’s vulnerability-identification obligation is built around.
Support period.
“The period during which a manufacturer is required to ensure that vulnerabilities of a product with digital elements are handled effectively,” in line with the Part II essential requirements. This is the term behind the “at least five years” figure covered on the EN 40000-1-2 page.
Substantial modification.
“A change to the product with digital elements following its placing on the market, which affects the compliance of the product… or which results in a modification to the intended purpose.” A substantial modification can trigger a fresh conformity assessment, so this definition’s boundaries matter more than they might first appear.
Conformity assessment and CE marking.
Conformity assessment is “the process of verifying whether the essential cybersecurity requirements set out in Annex I have been fulfilled.” CE marking is the resulting declaration: a mark “by which a manufacturer indicates that a product… and the processes put in place by the manufacturer are in conformity with the essential cybersecurity requirements set out in Annex I.”
This isn’t the complete list, Article 3 runs to more than 40 defined terms in total, but it covers the ones that show up most often across the essential requirements and the rest of the EN 40000 family.
How it fits with -1-2, -1-3, and -1-4
Think of the four EN 40000-1 documents as a stack, with this one underneath the other three rather than alongside them:
- EN 40000-1-1 (this page) supplies the shared terms the other three rely on.
- EN 40000-1-2 sets the risk-based principles and lifecycle process.
- EN 40000-1-3 covers vulnerability handling once a product is on the market.
- prEN 40000-1-4 supplies the technical security controls.
You won’t implement EN 40000-1-1 the way you’ll implement the other three. Its value is in making sure the terminology in your technical documentation, risk assessments, and supplier contracts matches what the regulation and the rest of the series actually mean.
How to use this standard now
You don’t need EN 40000-1-1 to be published to start using consistent terminology, the CRA’s own Article 3 definitions are binding today.
- Audit your existing documentation against Article 3, not internal shorthand. If your technical files, risk assessments, or supplier contracts use “vulnerability” or “manufacturer” loosely, align the wording now rather than after an audit finds the gap.
- Get specific about where you sit as an economic operator. Manufacturer, importer, distributor, and open-source software steward carry different obligations under the CRA, know which one, or ones, actually applies to you.
- Use the vulnerability-severity ladder deliberately. Vulnerability, exploitable vulnerability, and actively exploited vulnerability aren’t interchangeable, and only the last one starts the Article 14 reporting clock. Build that distinction into your internal escalation process, not just your glossary.
- Keep a running record, not a one-time glossary. A shared, documented vocabulary is easiest to maintain as part of the same process you’re already using to track risk assessments and component inventories, which isexactly what SAMMY’s Product Risk and Compliance (PRC) capability is built for.
Not sure where you stand as an economic operator?
Run the free CRA Scope Assessment in SAMMY, takes about 3 minutes, and tells you exactly where your product and your organization’s role stand. Check your scope →
FAQ
Is EN 40000-1-1 mandatory?
The standard itself is voluntary. The definitions it’s expected to mirror, in Article 3 of the CRA, are already binding law, independent of the standard’s publication status.
What’s the difference between “vulnerability” and “exploitable vulnerability” under the CRA?
A vulnerability is any weakness that could be exploited. An exploitable vulnerability is one that could realistically be used by an adversary under real operating conditions, a narrower, higher-concern category. Neither term alone triggers the 24-hour reporting deadline, only an actively exploited vulnerability does.
Does “manufacturer” include companies that give their software away for free?
Yes, “free of charge” alone doesn’t exempt you, the CRA’s manufacturer definition explicitly covers products marketed “whether for payment, monetisation or free of charge.” But don’t stop there: if your organization’s actual role is providing sustained support for an open-source product’s development, rather than developing and marketing a product under your own name, you may instead be an open-source software steward, a separate category under Article 3(14), not a free-software version of manufacturer. The distinction carries real weight: Article 24 holds stewards to a lighter, tailor-made regime, a documented cybersecurity policy and cooperation with market surveillance authorities, plus narrower reporting duties, rather than the full Annex I essential requirements and conformity assessment that apply to manufacturers, and stewards can’t affix the CE marking to the products they support. Which category actually applies to you depends on your role in a given product, not on whether money changes hands.
How is EN 40000-1-1 different from the CRA’s own Article 3?
Article 3 is the CRA’s own binding legal definitions, already in force. EN 40000-1-1 is the harmonised standard meant to mirror and formalise that same vocabulary for use across the rest of the EN 40000 series, it’s not a competing or updated set of meanings.
Manage and demonstrate CRA compliance with SAMMY
The EU Cyber Resilience Act is here. SAMMY walks you through the requirements, tracks your evidence as you go, and produces the documentation you need to show conformity.
- Review CRA requirements
- Demonstrate compliance with evidence
- Generate legal documentation
Explore CRA compliance in SAMMY →
