26 terms, each with its article
Cyber Resilience Act glossary
The vocabulary Article 14 is written in, defined once. Where a term is the Regulation’s own, the article it comes from sits beside it. Where a term is ours rather than the law’s, it says so — using one of those with a regulator as though it were a legal category would be a mistake.
The reporting duty
- Actively exploited vulnerabilityArt. 14(1)
- A vulnerability for which there is reliable evidence that malicious code has been executed on a system without the system owner’s permission by exploiting it. One of the two events that trigger the Article 14 reporting duty.
- The duty turns on exploitation of your product, not on a component of yours appearing in a catalogue of vulnerabilities exploited somewhere. A catalogue match is a reason to assess; it is not the trigger.
- Article 14
- Severe incidentArt. 14(4)
- An incident having an impact on the security of a product with digital elements. The second event Article 14 covers, alongside an actively exploited vulnerability, and the one whose final report runs on a different clock.
- Article 14
- Becoming awareArt. 14(2)
- Also called awareness, when the clock starts
- The moment a manufacturer knows it has an actively exploited vulnerability or a severe incident. It is what starts the 24-hour and 72-hour clocks, and it is a recorded human decision rather than something a system infers.
- No feed, scan or cron sets this. A match opens an assessment; only a person deciding that the event is reportable sets the awareness time, because moving it moves three deadlines at once.
- Deadlines
- Early warningArt. 14(2)(a)
- The first of the three Article 14 filings, due 24 hours from awareness. A short notice: what the event is, and which member states the product is available in.
- Filing on the platform
- NotificationArt. 14(2)(b)
- The second filing, due 72 hours from awareness — the same starting point as the early warning, not 48 hours after it. It carries the product details, the nature of the exploit or incident, and any corrective measures taken so far.
- The ENISA platform’s own counter has shown a due time 72 hours after the early warning was submitted. The Regulation runs both clocks from awareness.
- Filing on the platform
- Final reportArt. 14(2)(c), Art. 14(4)(c)
- The closing filing. Its deadline depends on which event it closes: 14 days from a fix being available, or one month from the notification.
- This is the deadline most often got wrong. For a vulnerability the clock starts when a fix becomes available, not when you became aware — so a case can sit between the 72-hour notification and the start of this clock for an unbounded time. For an incident it starts when the notification was actually submitted.
- Deadlines
- Corrective or mitigating measureArt. 14(2)(c)
- A fix, or something that reduces the risk short of a fix. Its availability is what starts the 14-day final-report clock for an actively exploited vulnerability.
- Deadlines
- Single Reporting PlatformArt. 16(2)
- Also called SRP
- The one platform ENISA runs for filing all three Article 14 stages, reaching the coordinating CSIRT and ENISA together. Established under Article 16.
- It has no API. Every filing is a person typing into a web form inside the deadline, including at two in the morning on a Sunday.
- Filing on the platform
Who reports, and to whom
- ManufacturerArt. 3(13)
- Whoever develops or manufactures a product with digital elements — or has it developed for them — and places it on the market under their own name or trade mark. The Article 14 duty falls here, and nowhere else.
- Article 14
- CSIRTArt. 14(7)
- Also called Computer Security Incident Response Team
- The national team that receives your report alongside ENISA. Each member state designates one as coordinator for the purposes of Article 14.
- Where to report
- Most significant connectionArt. 14(7)
- How a manufacturer with no establishment in the Union works out which member state’s CSIRT is theirs, in order: where the authorised representative is established, then the importer, then the distributor, then where the largest number of users is.
- The order is a cascade, not a choice. You take the first one that applies to you.
- Non-EU manufacturers
- ENISAArt. 14(1)
- The European Union Agency for Cybersecurity. It receives every Article 14 filing alongside the coordinating CSIRT, and it runs the Single Reporting Platform the filings go through.
- Where to report
Products and classes
- Product with digital elementsArt. 3(1)
- Also called PDE
- A software or hardware product, and its remote data processing solutions, placed on the market as one thing. Installed software, firmware, mobile and desktop applications, libraries and SDKs, agents and connected devices.
- A hosted service you never ship is generally outside this, unless it is the remote data processing part of a product somebody installs.
- Scope check
- Support periodArt. 13(8)
- The period during which a manufacturer must handle vulnerabilities in a product it has placed on the market. A product still inside its support period is still reportable.
- There is no exemption for something released before the Regulation applied. Age is not what takes a product out of scope; the end of its support period is.
- Readiness
- Important, class I productAnnex III class I
- A category listed in Annex III class I — password managers, network management, VPNs, and the rest of that list. The class decides which conformity assessment route applies from December 2027.
- It does not change a single reporting deadline. Class and clocks are unrelated, and treating a class as an escalation is a common and expensive confusion.
- Product classes
- Important, class II productAnnex III class II
- A category listed in Annex III class II — hypervisors, firewalls, tamper-resistant microprocessors. A third-party conformity assessment route applies.
- Product classes
- Critical productAnnex IV
- A category listed in Annex IV. The narrowest class, and the one where a European cybersecurity certification scheme may be required rather than merely available.
- Product classes
- Conformity assessmentArt. 32(1)
- The procedure by which a manufacturer demonstrates that a product meets the essential requirements, ending in the EU declaration of conformity and the CE marking. Which procedure is open to you depends on the product’s class.
- It applies from 11 December 2027. The reporting duty arrived fifteen months earlier, which is why the two are so often confused.
- Product classes
Evidence and signals
- SBOMAnnex I Part II(1)
- Also called software bill of materials
- A machine-readable inventory of what a product is made of. The Regulation asks for one covering at least the top-level dependencies, in a commonly used format.
- Smaller than most vendors assume: the duty is the top level, not the full transitive graph. CycloneDX and SPDX both satisfy the format requirement.
- SBOM requirements
- KEV catalogue
- Also called Known Exploited Vulnerabilities
- CISA’s catalogue of vulnerabilities with evidence of exploitation in the wild. Not an EU instrument and not named in the Regulation, but the best public signal that something is being exploited somewhere.
- A component of yours appearing here is not a reportable event. It is exploitation of some software, not necessarily of your product, and Article 14 turns on yours.
- SBOM check
- EUVD
- Also called European Vulnerability Database
- ENISA’s own record of vulnerabilities, including which of them are being exploited. The European counterpart to the CISA catalogue, maintained by the agency that also receives every Article 14 report.
- The reporting form asks for a EUVD identifier where one exists and has no field for a KEV reference at all. The two catalogues overlap heavily and not entirely, so a watch built on one of them has a blind spot shaped like the other.
- SBOM check
- EPSS
- Also called Exploit Prediction Scoring System
- FIRST’s daily probability that a given vulnerability will be exploited in the next thirty days. A forecast, not an observation, and unlike a severity score it says nothing about how bad exploitation would be.
- SBOM check
- VEX
- Also called Vulnerability Exploitability eXchange
- A document stating whether a product is actually affected by a known vulnerability in one of its components — most usefully, that it is not.
- Here, a statement of “not affected” or “fixed” suppresses a match. “Under investigation” deliberately does not, and no statement retracts an alert that is already open: somebody is assessing it, and a document that silently closes that is how a real finding disappears.
- SBOM requirements
- Tier A, B and COurs, not the law’s
- How a match is ranked for attention: A is in the exploited catalogue or scores high on exploitation probability and raises an alert; B and C are recorded and interrupt nobody.
- This product’s own classification, not a legal category and not a severity rating. Using it with a regulator or a CSIRT as though it were regulatory vocabulary would be a mistake.
- Evidence packOurs, not the law’s
- A dated bundle of what was known, decided and filed for one case, with a verification code anybody holding it can check without an account.
- This product’s own artefact, not something the Regulation names. It is evidence for a reader — an auditor, a customer, an acquirer’s counsel — not a claim of compliance.
- Verify a pack
Knowing the words is not the same as being in scope
Whether Article 14 applies to what you ship turns on five questions. The answer comes with the article behind each step, and needs no account.
This produces evidence, timelines and drafts. It is not legal advice, and you remain the party responsible for reporting.