Article 14(1) actively exploited vulnerability notification

What Article 14(1) asks manufacturers to do once a product is being exploited

When attackers are actively exploiting a vulnerability in a product you placed on the EU market, Article 14(1) requires you to notify that vulnerability to the CSIRT designated as coordinator and to ENISA through the Single Reporting Platform, and the duty has applied since 11 September 2026. Under Article 3(42), an actively exploited vulnerability is one with reliable evidence that a malicious actor has used it in a system without the permission of the system owner, so a theoretical flaw or a proof of concept on a public list does not trigger the notification on its own. The notification runs in three steps: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available. Each step is sent to the same recipients at the same time, so your internal process must produce all three from one case record.

The clock starts when you become aware, and the regulation does not define that moment in the abstract. Commission guidance C(2026) 5252 says awareness arrives when an initial assessment gives you reasonable certainty of active exploitation, which means your triage process decides when the 24 hours begin. Decide in advance who performs that assessment, how quickly it must conclude, and what evidence (logs, telemetry, customer reports, threat intelligence) moves a case to the exploited category. Exploitation you already knew about before 11 September 2026 need not be reported retroactively, but anything that surfaces after that date falls under the clock.

The duty is hard in practice for three reasons. Triage has to be fast enough to meet a 24-hour early warning, which requires on-call ownership across engineering and security. Third-party components complicate awareness: the guidance says you must notify a component vulnerability only if it is actively exploited in your own product, so you need to confirm reachability and exploitation in your build, not just the upstream advisory. Finally, awareness is often unclear for weeks, with mixed signals from logs and customers. Confirm with your CSIRT coordinator how they expect early and partial information to be submitted, and confirm your Single Reporting Platform access, since it requires a personal EU Login account with multi-factor authentication and offers no API at initial release.

Which products, vulnerabilities and teams fall under the Article 14(1) duty

The Article 14(1) duty turns on three questions: which products are in scope, whether a specific vulnerability meets the legal test for active exploitation, and which people inside the manufacturer must act once the clock starts. The cards below take each question in turn, so a team can map its products and roles before the first notification is needed.

In-scope products regardless of placement date

The duty covers in-scope products whenever they were placed on the market. A product sold before 11 December 2027 is not exempt from reporting, even though the rest of the regulation reaches it only after a substantial modification. Build an inventory of every product with digital elements still supported in the field, including older versions and products sold through partners, and record which ones have a live update path. Those are the products where an exploited flaw can still reach users.

The Article 3(42) test for exploitation

A vulnerability counts as actively exploited only when there is reliable evidence that a malicious actor has used it in a system without the permission of the system owner. A proof of concept, a public exploit or a scanner signature does not meet that test by itself. Ask the product security team to document how it reviews telemetry, incident tickets and threat intelligence, and what evidence led to each decision, so the assessment can be shown later.

Third-party components in your own product

A flaw in a third-party or open-source component triggers notification only when it is actively exploited in the manufacturer's own product. If the vulnerable code path is unreachable or unexploited in your product, the Commission guidance says you may report it voluntarily under Article 15 instead. Check each component against how your product actually uses it, and keep a record of that reachability analysis alongside the SBOM.

Product security and PSIRT

The product security team or PSIRT owns the initial assessment that decides whether reasonable certainty of active exploitation exists. This is the point at which the 24-hour early warning clock is effectively running, so the team needs an on-call rota, a written triage procedure and authority to make the call without waiting for a committee. Confirm who signs off the assessment and how that decision is logged.

Engineering and release owners

The 72-hour notification and the 14-day final report depend on what the engineering team can describe and fix. Engineers need to state the affected versions, the root cause and whether a corrective or mitigating measure exists. Name the release owners for each product line and agree how a hotfix moves from diagnosis to a tested build, since the final report clock starts once that measure is available.

Legal, support and the lead CSIRT

Legal reviews the notification wording and confirms which Member State's CSIRT is the lead, since notifications go to the CSIRT where cybersecurity decisions are predominantly taken. Support must be ready to inform affected users and to answer questions in the same window. Where the manufacturer has no EU main establishment, Article 14(7) directs notifications to the authorized representative, then the importer, then the distributor, then the Member State where most users are. Confirm that order with counsel before an incident occurs.

How an assessor tests the Article 14(1) notification process

This table sets out what an assessor does for each part of the Article 14(1) notification duty, the evidence they ask for, and the findings they most often raise. Read it as a test plan: each row is an action the manufacturer should be able to show before an assessment or market surveillance inquiry. The main takeaway is that timestamps and recorded reasoning matter as much as the notifications themselves.

Test area	Assessor action	Evidence requested	Common finding
Awareness decision	Establish the date the manufacturer became aware of active exploitation and check it against the reasonable certainty standard in the guidance	Triage records, initial assessment memo, decision log with named approver and timestamps	No documented initial assessment, so the start of the 24-hour clock cannot be shown
24-hour early warning clock	Compare the awareness timestamp with the time the early warning was submitted through the platform	Platform submission receipt, ticket history, on-call escalation records	Early warning sent after 24 hours with no record of why the awareness point was set later
72-hour notification clock	Check that the vulnerability notification contains the required content and was filed within 72 hours of awareness	Submitted notification copy, drafting and review history, version record	Notification filed on time but missing details that the assessor expects to find
14-day final report clock	Confirm when a corrective or mitigating measure became available and whether the final report followed within 14 days	Patch or mitigation release record, release notes, final report submission receipt	Clock anchored to ticket closure instead of the date the fix or mitigation was available
CSIRT and recipient selection	Verify the Member State CSIRT chosen matches where cybersecurity decisions are predominantly taken, and that ENISA received the same notification	Governance records showing where decisions are made, platform copies, selection rationale	No rationale for CSIRT choice, or a non-EU manufacturer with no documented Article 14(7) fallback
Third-party component decisions	Test whether each third-party vulnerability was assessed for exploitation in the manufacturer's own product before deciding on mandatory notification	Component inventory cross-referenced to SBOM, reachability analysis, exploitation assessment per component	Components reported or dismissed without a recorded check of exploitation in the product
Voluntary reports under Article 15	Check that unreachable or unexploited component issues are handled as voluntary reports where chosen, and kept separate from mandatory notifications	Voluntary report log, classification rationale, distinction between the two reporting paths	Voluntary and mandatory reports mixed together, making the mandatory population impossible to reconstruct
Pre-11 September 2026 knowledge	Establish what the manufacturer knew before 11 September 2026 and confirm that earlier knowledge was not reported retroactively	Dated vulnerability records, earlier incident tickets, first-knowledge timeline frozen at the cut-off date	Records altered or backdated after the cut-off, or no dated history to show what was known
Access and credential control	Confirm named staff hold personal EU Login accounts with multi-factor authentication and that submissions are traceable to individuals	Account roster, MFA enrollment evidence, access review records, submission audit trail	Shared accounts used for platform submissions, or no record of who filed each notification

Implementing the reporting path before the first exploited vulnerability

This sequence gives a manufacturer a tested route for Article 14(1) notifications before a real exploitation case arrives, so the 24-hour, 72-hour and 14-day clocks start with people, accounts and templates already in place. Each step ends with a checkable output that the compliance lead can sign off.

Define awareness criteria in writing
The product security lead, with legal counsel, writes the internal test for when the manufacturer becomes aware of active exploitation. The Commission guidance (C(2026) 5252, section 9.1) ties awareness to an initial assessment that gives reasonable certainty of exploitation, so the criteria should name the evidence sources, who runs the initial assessment and how the decision is recorded. Done when the criteria are approved, versioned and linked from the vulnerability handling procedure.
Assign triage roles and notification clocks
Name an owner for intake, an assessor for the initial assessment, an approver who can make the awareness decision out of hours, and a notifier who submits to the platform. Each role gets a deputy. The team records the time each clock starts from the awareness decision, not from the first alert. Done when a current roster and a clock log template exist, and someone outside the product team confirms that the roster covers weekends and holidays.
Select the CSIRT and confirm platform access
Identify the CSIRT of the Member State where cybersecurity decisions are predominantly taken, or follow the Article 14(7) order when there is no EU main establishment. Then confirm that each notifier holds a personal EU Login account with multi-factor authentication, since ENISA states that the platform requires it. Ask ENISA's current FAQ whether any access changes apply. Done when every named notifier has signed in once and the CSIRT choice is recorded with its reasoning.
Prepare notification templates for each stage
Draft three templates matching the early warning, the vulnerability notification and the final report. The early warning covers the fields the manufacturer can know within 24 hours, the notification adds the affected product versions, exploitation evidence and mitigation status, and the final report covers the corrective or mitigating measure and its availability date. Keep the platform in English, since ENISA's FAQ states it is available in English only. Done when the templates are reviewed by legal counsel and stored where the notifier can open them without the main ticketing system.
Rehearse the path in a tabletop exercise
Run a tabletop with the roster, using a hypothetical exploitation scenario (illustrative only) that includes a third-party component. The exercise tests whether the team can decide awareness, submit an early warning, log the clock and decide whether a third-party vulnerability is actually exploited in the manufacturer's own product, which triggers the notification duty. Record gaps in an action log with owners. Done when the exercise report lists each gap, its owner and a closure date agreed with the sponsor.
Set up the final report workflow
Define how the team tracks the corrective or mitigating measure, records when it becomes available and prepares the final report within the 14-day window. The workflow should link the remediation ticket to the notification record so the availability date is evidenced. Confirm with counsel whether any user-facing advisory should be published alongside. Done when a sample case moves from early warning to final report in the tracking tool with each date and approval captured.
Keep the evidence and review the path
Store the criteria, roster, CSIRT decision, platform access records, templates, exercise report and sample case as one controlled evidence set. Review the set when the roster changes, when the guidance is updated or when the product changes materially. The product security lead signs the review. Done when the evidence index shows the owner and last review date for each item, so an assessor or market surveillance authority can trace the whole path.

When the clock starts: awareness, initial assessment and reasonable certainty

The 24-hour early warning under Article 14 runs from the moment a manufacturer becomes aware of active exploitation, and section 9.1 of the Commission's guidance in C(2026) 5252 says awareness arises when an initial assessment gives the manufacturer reasonable certainty that the vulnerability is being actively exploited. Suspicion, an unexplained log entry or a single unverified report does not start the clock by itself. The clock also depends on the definition in Article 3(42): there must be reliable evidence that a malicious actor exploited the vulnerability in a system without the permission of the system owner. Your product security team, not your partner or your auditor, decides whether that threshold has been crossed for a given case.

Because the 24-hour, 72-hour and 14-day deadlines all depend on that judgment, the organization must record the initial assessment as it happens. Write down who triaged the report, what evidence was reviewed, which product versions and components were checked, the conclusion reached, and the timestamps for first receipt, assessment start and the point at which reasonable certainty was reached. Tickets in a PSIRT or case management system, with immutable timestamps and named approvers, usually serve this purpose. Ask your tooling owner to confirm that these records cannot be silently edited, because an assessor or market surveillance authority will ask how the timeline was reconstructed.

The same guidance says exploitation a manufacturer already knew about before 11 September 2026 does not have to be reported retroactively. The obligation is forward-looking: it applies to exploitation that becomes known to you from that date. Two actions follow. First, establish a baseline of known exploited vulnerabilities as of that date so the record shows what was excluded and why. Second, confirm with legal counsel how the boundary applies where exploitation was first identified before the date but a fix or confirmed evidence emerged afterward, since that is a case where the facts, not the label, decide the outcome.

Evidence that shows Article 14(1) notifications were made on time

Article 14(1) notifications are judged by timing, so the evidence has to show when the manufacturer became aware, what it did next, and when each submission reached the platform. The cards below cover the records that prove those points, and they should be kept current between incidents rather than assembled after one occurs.

Triage records with timestamps

Keep the alert or report that first raised the question, the triage ticket, and every status change with its time and author. The 24-hour early warning clock depends on when the manufacturer became aware, so these timestamps are the starting point for any timing question. Check that clocks are synchronized across the ticketing, monitoring and vulnerability tools, and that edits to timestamps are logged rather than overwritten.

Awareness assessment memo

Record the initial assessment that decided whether there was reasonable certainty of active exploitation. Commission guidance C(2026) 5252 treats that point as the moment of awareness, so the memo should name the evidence reviewed, the reviewer, the decision and the date. Store it with the triage record so an assessor can see the reasoning, not only the outcome.

Platform submission receipts

Keep the confirmation or acknowledgment generated each time a notification is submitted to ENISA's Single Reporting Platform, together with the account used. The platform requires a personal EU Login account with multi-factor authentication, so the receipt should identify the person who submitted. Confirm with the platform's FAQ how receipts are issued, since the platform had no API at initial release.

Copies of each notification and report

Archive a copy of the early warning, the vulnerability notification and the final report exactly as submitted, with the submission time beside each one. The final report is due within 14 days after a corrective or mitigating measure is available, so the record should also show the date that measure was released. Versioned copies make it possible to show what was reported at each stage.

CSIRT and ENISA routing decisions

Document which CSIRT received each notification and why. The choice follows where the manufacturer's cybersecurity decisions are predominantly taken, or the Article 14(7) order for manufacturers without an EU main establishment. Record any delay in passing a notification on under Delegated Regulation (EU) 2026/881, including the reasoning and the expected mitigation date, because the receiving CSIRT's decision depends on it.

Third-party component determinations

For each vulnerability in a third-party component, keep the determination that it was or was not actively exploited in the manufacturer's own product. Only exploitation in the product triggers mandatory notification, so the record should show the reachability analysis, the exploitation check and the decision. Voluntary reports under Article 15 should be logged separately so they are not confused with mandatory ones.

Exercise records

Keep records of tabletop or simulated runs of the notification process, covering who receives an alert, who signs off the awareness decision, and who submits to the platform. Each exercise should note the elapsed time against the 24-hour, 72-hour and 14-day steps and the gaps found. Exercise records show that the process works before a real case, and they give reviewers evidence that the team has rehearsed the timeline.

Open-source tools that support triage and case records

An actively exploited vulnerability notification is only as good as the record behind it. A case record shows when the manufacturer became aware, what the initial assessment concluded and which corrective or mitigating measures were prepared. DFIR-IRIS is a self-hosted, LGPL-3.0-or-later case management tool that fits this role. It keeps each case as a single record of assets, indicators of compromise, tasks and evidence, with a full audit trail of changes.

One case per vulnerability: Assets, indicators, tasks and evidence sit in one record, so the reasoning behind the awareness date can be reviewed later.
Consolidated timeline: The tool builds an investigation timeline from case entries, which helps reconstruct the 24-hour, 72-hour and 14-day clock.
Evidence logging: Evidence entries are logged with SHA-256 verification and chain of custody.
Alert triage: Alerts from SIEM, EDR and REST sources can be triaged into cases.
Report generation: Reports are generated from case data, which can support internal sign-off before a submission.

IRIS is a record-keeping tool, not a reporting channel. Confirm the current release and its audit trail configuration in your own environment before relying on it as evidence.

What meeting the reporting duty costs in money and effort

The main cost of Article 14(1) is not the platform. The process is the expensive part, and most of it is one-time design work followed by recurring operational capacity. One-time items include defining how the manufacturer's product security team decides that a vulnerability is actively exploited, writing the internal escalation path, deciding who can submit to the Single Reporting Platform, and agreeing the content of the early warning, notification and final report. Legal review of those decisions, particularly how the manufacturer records when it became aware and how it handles third-party components, is usually a one-time expense with occasional refreshes when the Commission or ENISA issues further guidance. Recurring items include on-call triage capacity that can act inside 24 hours, staff time for each exploitation case through to the 14-day final report, and periodic tabletop exercises to keep the 24-hour clock realistic.

Tooling is mostly a one-time build with recurring upkeep. Case management, threat intelligence sharing and vulnerability tracking can be self-hosted, and the costs are the engineering to integrate them, the hosting, and the staff who maintain them. Ask any external provider to separate implementation fees from ongoing support and upgrades. Costs rise when a product has many third-party components, because each exploitation signal must be traced to whether it reaches the manufacturer's own product. They fall when the product's SBOM and vulnerability data are already machine-readable, and when on-call duties can be shared across an existing security operations rota rather than hired separately.

Fines set the cost of getting this wrong. Article 64 sets maximum administrative fines of EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, for breaches of Articles 13 and 14, so the process is worth budgeting even for smaller manufacturers. Ask any external partner for a fixed-scope quote that lists the process design, tooling integration, exercises and documentation as separate deliverables, and confirm who owns the resulting procedures. The organization keeps accountability for every notification, even when an implementation partner prepares the process. Only the organization's own staff can decide to submit.

Where organizations miss the Article 14(1) clock

The 24-hour early warning clock starts when a manufacturer becomes aware of active exploitation, so most missed deadlines trace back to decisions made before any incident occurs. The gaps below cluster around four questions: when awareness starts, who assesses third-party components, where notifications go, and who can file them. Each card pairs a gap with a fix you can verify before the first notification is due.

No defined awareness criteria

Article 14(1) turns on when a manufacturer becomes aware of active exploitation. Commission guidance C(2026) 5252 says awareness follows an initial assessment that gives reasonable certainty of exploitation. Without a written definition of that assessment, teams debate the start time after the fact. Write down who runs the initial assessment, what evidence triggers it, and the maximum time allowed before a decision is recorded.

Third-party exploitation not assessed

A vulnerability in a third-party component must be notified only if it is actively exploited in the manufacturer's own product. Teams often treat every advisory on a library as a reportable event, or ignore advisories entirely because the vendor is responsible. Maintain a triage step that checks reachability and exploitation in your product, and record the result so the decision not to notify is defensible.

No named CSIRT route

Notifications go to the CSIRT of the Member State where cybersecurity decisions are predominantly taken. Manufacturers without an EU main establishment must follow the order in Article 14(7), which runs through the authorized representative, importer, distributor and then the Member State where most users are. Confirm the designated CSIRT and the fallback chain in advance, and name the individual who files the notice.

Unrecorded awareness timestamps

Regulators and auditors reconstruct the clock from records, not recollection. A notification that cannot show when the initial assessment concluded, when the early warning was sent, and when each later step occurred is hard to defend. Log each event with a timestamp in a case record that captures the source of the signal, the assessor, and every decision. A case management tool with an audit trail, such as DFIR-IRIS, can hold this record.

Shared or non-MFA platform accounts

ENISA's Single Reporting Platform is accessed with a personal EU Login account protected by multi-factor authentication, and its FAQ describes the platform as English only with no API at initial release. Shared logins break individual accountability, and an account without MFA exposes reporting credentials. Issue named accounts to each authorized reporter, enforce MFA, and confirm a backup reporter can file within the 24-hour window.

Final reports untied to fixes

The final report is due within 14 days after a corrective or mitigating measure is available, so the start of that period depends on a documented fix date. Teams that release a patch without recording its availability, or that wait for full remediation across all versions, lose track of the deadline. Tie each vulnerability case to a release record that shows when the measure became available and to whom it was delivered.

How much work and cost does Article 14(1) add, and what can we do ourselves?

Can our own team run Article 14(1) reporting without outside help?

Yes, in principle. Article 14(1) places the notification duty on the manufacturer, so your organization decides who reports, and nothing in the regulation requires an external party. What your team needs is a defined process that starts when a vulnerability is actively exploited, a named person with authority to file, and access to the ENISA Single Reporting Platform through a personal EU Login account with multi-factor authentication. The hard part is rarely the form. It is recognizing exploitation early enough to meet a 24-hour early warning, which depends on monitoring, triage and fast internal decisions. Confirm the reporting route with your CSIRT and your counsel before relying on it.

What does an implementation partner actually do for this duty?

A partner prepares the systems and evidence that let your team meet the duty. For Article 14(1), that typically means designing the intake and triage workflow, configuring open-source case management and vulnerability tracking so exploitation signals become cases with timestamps, drafting the internal playbook and decision records, and running tabletop exercises. DeployOpen implements these platforms inside your own infrastructure. It does not file notifications on your behalf, decide whether a vulnerability is actively exploited, or issue any attestation. Those decisions and filings stay with your organization, and the scope and deliverables are agreed in writing before work starts.

Can we outsource Article 14(1) reporting to a third party?

You can outsource supporting work, but not accountability. Monitoring, triage, drafting and technical analysis can be shared with a service provider, while the manufacturer remains responsible for the notification and its accuracy. Before outsourcing, check the contract for who holds the reporting decision, how fast the provider must escalate, how case data is stored and who can access it, and what happens if the provider is unavailable on a Friday evening. Ask counsel whether any engagement changes how the manufacturer's obligations are described to authorities.

What does Article 14(1) cost to set up, and what recurs?

No fee for the ENISA platform itself is part of the supplied facts, so confirm the access and usage terms directly with ENISA. Your costs fall into four groups: internal staff time to define the process and train responders, tooling (open-source tools carry licence costs of zero, but you still pay for hosting, administration and storage), an implementation engagement if you use one, and ongoing monitoring, drills and updates to the playbook. Setup costs are largely one-time. Monitoring staffing, exercises and tool maintenance recur. The largest cost driver is how many products you place on the EU market and how many third-party components each one contains, since each exploitation signal must be traced back to the affected product. Ask any partner for a fixed-scope quote listing deliverables, environments and responsibilities.

How much time do we need before the first reporting exercise?

No duration for setup is established in the supplied facts, so plan around the milestones you control. The duty has applied since 11 September 2026, which means preparation is already time-bound. A practical sequence is to confirm your CSIRT coordinator, assign owners, document the awareness test, deploy case management and intake, then run a tabletop exercise against a hypothetical exploitation scenario. Each step depends on your current tooling, product count and internal approval cycles. Ask any partner for a schedule with dated milestones, and ask ENISA or your CSIRT which reporting tests or exercises they recommend.

What do we need to provide to get reporting work done?

The work depends on information only your organization holds. You will need an inventory of in-scope products and their versions, a list of third-party components with ownership and contacts, an existing SBOM or a plan to produce one, access to vulnerability feeds and telemetry, and named decision makers who can approve a notification within the required window. You also need legal review of the notification content, a route to the affected users, and a way to record the time you became aware. Missing inventory data is the most common reason setup runs longer than planned, so start there.

Does Article 14(1) require a full internal security operations team?

Not necessarily, but you need reliable coverage for the windows in the regulation. The 24-hour early warning means someone must be able to act on exploitation evidence within that period, including outside business hours. A small organization can meet this with an on-call rota, a documented escalation path and a partner or retainer covering out-of-hours triage. Larger manufacturers with many products will need more formal staffing. Confirm with counsel and your CSIRT how they expect coverage to be demonstrated, since the supplied facts do not set a staffing level.

Which questions should we put to ENISA, our CSIRT or counsel first?

Start with the questions the supplied facts leave open. Ask your CSIRT which Member State coordinator receives your notifications and how they handle delayed dissemination. Ask counsel how to document the moment you became aware, how to treat a third-party component exploited in your product, and whether historical exploitation is in scope. Ask ENISA about platform access, account administration for multiple staff, and any planned API. Record each answer in writing, because your evidence file is what you will show if a market surveillance authority later asks how you met the duty.

How DeployOpen prepares the reporting path for your team

DeployOpen prepares the internal path that lets a manufacturer meet the Article 14(1) notification duty, from deciding who is aware and when to running the reporting steps on the ENISA platform. The organization keeps ownership of its decisions and its filings, and DeployOpen prepares the systems, records and procedures that support them.

How we scope

Confirm which products are in scope and where each one was placed on the market, since the Article 14 duty covers in-scope products regardless of placement date.
Map the internal roles for triage, initial assessment, CSIRT selection and sign-off, and agree them in the written scope before work starts.
Record the engagement scope, deliverables and timeline in writing, with fixed-scope terms and any ongoing retainer agreed up front.

How we build

Set up a case workflow on a self-hosted platform, such as DFIR-IRIS, that tracks assets, indicators, tasks and evidence for each suspected exploitation.
Connect vulnerability findings from scanners and tools to a single register, such as DefectDojo, so exploitation status can be recorded and reviewed.
Build decision records that capture when reasonable certainty of active exploitation was reached, so the timing of each notification can be shown later.

How we hand over

Deliver written procedures for the 24-hour early warning, 72-hour notification and 14-day final report, with named owners for each step.
Document the platform access steps, including personal EU Login accounts with multi-factor authentication, and confirm who holds each account.
Provide a tested checklist for third-party component cases and for informing affected users, with the evidence trail kept in the case record.

How we support

Ask whether ongoing support is needed to keep procedures current as the Commission guidance and ENISA platform materials evolve.
Available as a retainer for periodic review of triage records, exercises of the reporting path and updates to tooling after upgrades.
Confirm with your legal and compliance advisers which filings, timing decisions and regulator contacts stay with your organization.