Does the CRA Require Vulnerability Scanning from 11 September 2026? No, but It Does Require a Reporting Decision Process

A practical guide to CRA Article 14 from 11 September 2026: why vulnerability scanning is not a standalone legal duty, how manufacturers assess and report qualifying events, what customers can expect, and how security tools support the process in IT and OT.

The short answer

No. Article 14 of the Cyber Resilience Act (CRA) does not require a manufacturer to introduce vulnerability scanning on 11 September 2026. It does not prescribe a scanner, a scanning frequency, continuous threat-intelligence monitoring, dark-web monitoring, telemetry, or any other particular awareness channel.

The Commission-services implementation FAQ is unusually explicit on this point. It lists customer reports, researchers, authorities, threat intelligence, internal monitoring, scanning, and telemetry as examples of how a manufacturer may become aware of a reportable event, while clarifying that the examples do not imply an obligation to carry out those activities or monitor those channels merely to comply with Article 14 reporting.¹

But the complete answer is not simply no scanning required. To implement the awareness-based, time-limited obligation reliably, a manufacturer’s operating model must be able to:

1. receive and recognise a possible reportable event;
2. assess the signal promptly;
3. decide whether either Article 14 trigger is met;
4. record when it reached the legal awareness threshold;
5. submit progressively more detailed notifications within the statutory deadlines; and
6. inform impacted users and, where appropriate, all users.

That is a reporting decision process. The CRA does not use that expression or prescribe one particular workflow. It is the practical control derived from the need to recognise the two legal triggers, determine when awareness arises, and meet the resulting deadlines. Scanners and other security tools can support it, but they neither replace the decision nor determine its legal outcome.

ImportantThe precise proposition

The CRA does not impose a new, standalone vulnerability-scanning duty on 11 September 2026. It does make Article 14 applicable on that date. A manufacturer that receives a credible signal cannot treat the absence of a scanner result as the end of the assessment.

This article focuses on manufacturers, because Article 14(1) and (3) place the two mandatory reporting duties on them. Article 24(3) applies tailored reporting obligations to open-source software stewards in specified circumstances, and Article 15 allows voluntary notifications by other natural or legal persons. A customer, importer, distributor, maintainer, or integrator does not acquire the manufacturer’s Article 14 duty merely by using or servicing a product, although another CRA role or a separate incident-reporting regime may apply on the particular facts.²

What changes on 11 September 2026

The CRA applies generally from 11 December 2027, but Article 71(2) brings Article 14 into application fifteen months earlier, on 11 September 2026.³

Article 69(3) gives this early reporting obligation a broad product reach. It applies to all products with digital elements within CRA scope that were placed on the Union market before 11 December 2027, not only to products launched after the reporting date.⁴ The Commission guidance also explains that Article 14 reporting continues to apply after a product is no longer supported, even though the ordinary Annex I vulnerability-handling obligations may no longer apply to that product.⁵

The dates should therefore be separated carefully.

Date or status	What it means for this topic	What it does not mean
11 September 2026	Article 14 reporting and Article 14(8) user-information obligations apply to in-scope products, including earlier products under Article 69(3).	Every CRA design, documentation, conformity, SBOM, testing, and vulnerability-handling requirement becomes applicable on that date.
11 December 2027	The CRA applies generally. For products subject to the full regime, Article 13 and Annex I include vulnerability identification and documentation, an SBOM, regular security tests and reviews, coordinated vulnerability disclosure, security updates, and other lifecycle duties.	The law necessarily prescribes one commercial scanner, one scan frequency, or one universal technical method for every product.
Useful before either date	Product inventories, SCA, SBOMs, VEX, scanners, threat intelligence, telemetry, incident-response tooling, customer-support routing, and case management can make the legal process faster and more reliable.	Use of a tool by itself demonstrates CRA conformity or proves that an Article 14 report is required.

Table 1: The reporting date, the general application date, and voluntary readiness measures must not be collapsed into one obligation.

Annex I, Part II does require manufacturers subject to the full CRA regime to identify and document product vulnerabilities and components and to apply effective and regular security tests and reviews.⁶ A scanning capability may be a sensible, or in a particular risk context, necessary, way to implement those later requirements. The narrower point is that Article 14 does not itself switch on a universal scanning mandate in September 2026.

Other obligations can also lead to a different result. A contract, a sectoral rule, a customer requirement, NIS2 implementation, an applicable standard, or the manufacturer’s own risk assessment may require scanning or equivalent assurance. The answer in this article concerns the CRA Article 14 reporting obligation, not every legal or contractual duty that may apply to the organisation.

A scanner finding is not an Article 14 report

Article 14 contains two mandatory reporting triggers.

Trigger 1: an actively exploited vulnerability

The manufacturer must report an actively exploited vulnerability contained in its product with digital elements once it becomes aware of it.

The CRA defines an actively exploited vulnerability as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner’s permission.⁷

This is not the same as:

• a CVE matching a component name and version;
• a high or critical CVSS score;
• a public proof of concept;
• a vulnerability described as exploitable under some conditions;
• a penetration tester successfully exercising a weakness with authorisation; or
• a scanner reporting that a package may be present.

Those findings can be urgent vulnerability-management inputs. They do not, without reliable evidence of malicious exploitation and the necessary connection to the manufacturer’s product, satisfy the Article 14(1) threshold.

For a third-party component, the Commission guidance makes the product connection particularly important. If the vulnerability cannot be exploited in the manufacturer’s product, for example because the vulnerable code is unreachable, or has not been exploited in that product, the current Commission interpretation does not treat it as a mandatory Article 14 report for that final-product manufacturer solely because the component is being exploited elsewhere.⁸ The manufacturer may still have vulnerability-handling, upstream-notification, remediation, contractual, or voluntary-reporting actions to take.

Trigger 2: a severe incident affecting product security

The second trigger is a severe incident having an impact on the security of the product with digital elements.

Under Article 14(5), an incident is severe where it:

• negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or
• has led, or is capable of leading, to malicious code being introduced or executed in the product or in a user’s network and information systems.⁹

This route matters because a manufacturer may face a reportable product-security incident before it has identified a particular CVE or proven the complete exploit chain. Conversely, a scanner can identify a vulnerability without any severe incident having occurred.

The two triggers must therefore be tested independently.

Awareness is a decision, not the arrival of an alert

Article 14 measures the 24-hour and 72-hour deadlines from the point at which the manufacturer becomes aware of the reportable event.

The Commission’s 2026 guidance interprets this point as follows: when a suspicious event or third-party report comes to the manufacturer’s attention, it should be assessed immediately. The manufacturer is regarded as aware when, after that initial assessment, it has a reasonable degree of certainty that:

• a vulnerability contained in its product is being actively exploited; or
• a severe incident has occurred and compromised the security of its product.¹⁰

The first unverified alert does not automatically start the statutory reporting clock. But this does not create an unlimited investigation period before the clock starts. The guidance emphasises prompt initial assessment, particularly where the possible vulnerability poses a significant risk.

This distinction is why a defensible process needs at least two timestamps:

• signal received, when the organisation first received information requiring assessment; and
• awareness reached, when the initial assessment produced reasonable certainty that an Article 14 trigger was met.

The record should also explain what occurred between those timestamps. A decision log that contains only the awareness time, with no record of the preceding triage, is weak evidence that the organisation assessed the signal promptly.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    SIGNAL["Signal from customer, maintainer,<br/>supplier, researcher, authority,<br/>scanner, telemetry or security team"]:::context
    ASSESS["Prompt initial assessment"]:::product

    ACTIVE["Test for reasonable certainty of an<br/>actively exploited vulnerability<br/>contained in the product"]:::test
    INCIDENT["Independently test for reasonable certainty<br/>of a severe incident affecting<br/>product security"]:::test
    TRIGGER{"Does either independent test<br/>meet its legal threshold?"}:::test

    NOREPORT["Record rationale; continue applicable<br/>vulnerability or incident handling;<br/>reassess if evidence changes"]:::context
    AWARE["Record awareness time(s), trigger(s),<br/>decision owner and evidence"]:::product
    REPORT["Applicable 24-hour early warning(s)<br/>then 72-hour notification(s)"]:::product
    FINAL["Applicable final report(s)<br/>and intermediate updates if requested"]:::product
    USERS(["Risk-based information<br/>to impacted users and,<br/>where appropriate, all users"]):::entity

    SIGNAL --> ASSESS
    ASSESS --> ACTIVE
    ASSESS --> INCIDENT
    ACTIVE --> TRIGGER
    INCIDENT --> TRIGGER

    TRIGGER -- No --> NOREPORT
    TRIGGER -- Yes --> AWARE

    AWARE --> REPORT
    REPORT --> FINAL
    AWARE -. Article 14(8) .-> USERS

    classDef entity fill:#dbeaf7,stroke:#285f8f,stroke-width:1.5px,color:#102a43;
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef context fill:#ffffff,stroke:#7a7a7a,stroke-width:1.5px,stroke-dasharray:5 5,color:#404040;

Figure 1: A signal starts prompt assessment; reasonable certainty that either statutory trigger is met starts the applicable Article 14 reporting clock.

The workflow in Figure 1 is deliberately progressive. Article 14 does not require the manufacturer to complete the entire technical investigation before notifying. It first requires a limited early warning, followed by a richer notification and then a final report.

The practical reporting decision process

1. Establish the product and legal perimeter

Before an event occurs, identify:

• which products with digital elements fall within the manufacturer’s CRA perimeter;
• product families, models, software releases, firmware versions, remote data-processing solutions, and relevant dependencies;
• products already placed on the market, including legacy and unsupported products;
• the Member States in which each product has been made available, to the extent known;
• the manufacturer entity and its CRA main establishment; and
• the coordinating CSIRT endpoint that will be selected through the Single Reporting Platform (SRP).

Without this mapping, the security team can discover a real exploit and still lose critical hours determining whether the affected code belongs to a regulated product, which legal entity is the manufacturer, and where the notification must go.

2. Create a controlled intake route

The September obligation does not require monitoring every possible channel. The internal process should nevertheless route security-relevant information that the organisation actually receives.

Potential sources include:

• customer support and field-service tickets;
• maintainers, managed-service providers, system integrators, and distributors;
• product-security and coordinated-disclosure mailboxes;
• supplier and component-maintainer notifications;
• SOC, CSIRT, incident-response, fraud, and abuse teams;
• researchers, authorities, and sector information-sharing groups;
• threat intelligence, telemetry, scanners, SCA, and CI/CD controls where used; and
• media or public reporting that identifies the manufacturer’s product.

The control objective is not watch everything. It is prevent credible product-security information already received by the organisation from remaining trapped in the wrong queue. Service-desk personnel do not need to make the Article 14 legal determination; they need an escalation rule that recognises possible exploitation or product compromise.

3. Open an event record immediately

The initial record should preserve:

Record element	Why it is needed
Source, receipt time, and original evidence	Preserves what the organisation knew and when it knew it.
Product, version, configuration, component, and deployment context	Tests whether the issue is contained in or affects a particular product.
Alleged activity and indicators	Separates a vulnerability finding from evidence of malicious exploitation or an incident.
Customer, site, and affected Member States, where known	Supports investigation, the early warning, and user communication.
Containment and safety constraints	Prevents evidence collection or remediation from increasing IT, OT, physical, or operational risk.
Assigned assessor and decision owner	Makes the hand-off and accountability explicit.
Signal and awareness timestamps	Separates intake from the point at which the legal reporting clock begins.
Decision, rationale, confidence, and unresolved questions	Makes both report and no-report decisions reviewable.

Table 2: Minimum event record for an Article 14 assessment.

4. Perform the prompt initial assessment

The assessment should answer the following questions, treating the vulnerability route in questions 2 and 3 and the severe-incident route in question 4 independently:

1. Does the information relate to an in-scope product for which the organisation is the manufacturer?
2. Is there a vulnerability contained in that product, rather than only a generic component match or an issue in an unrelated service or customer system?
3. Is there reliable evidence of malicious exploitation without the system owner’s permission?
4. Independently, has an incident occurred that meets either severity condition in Article 14(5)?

The assessor should use the information reasonably available at that stage. Product architecture, SBOM data, build manifests, VEX statements, configuration information, customer logs, forensic artefacts, supplier information, and threat intelligence can all contribute. No single source has automatic legal priority.

5. Make and time-stamp the determination

The process should identify who is authorised to conclude that the manufacturer has reached a reasonable degree of certainty. In a smaller manufacturer, this may be one product-security lead with legal escalation. In a larger group, it may be a small incident decision team.

The team should avoid two opposite errors:

• premature certainty, where every scanner alert is declared reportable without testing the statutory conditions; and
• deferred certainty, where the manufacturer waits for complete root-cause analysis even though reliable evidence already establishes a reportable event.

Once reasonable certainty is reached, record the time immediately. That timestamp controls the Article 14 deadlines.

6. Report progressively, not after the investigation is complete

For an actively exploited vulnerability, the manufacturer submits through the SRP:

• an early warning without undue delay and in any event within 24 hours of awareness;
• a vulnerability notification without undue delay and in any event within 72 hours of awareness, unless the relevant information was already provided; and
• a final report no later than 14 days after a corrective or mitigating measure becomes available.¹¹

For a severe incident, it submits:

• an early warning without undue delay and in any event within 24 hours of awareness;
• an incident notification without undue delay and in any event within 72 hours of awareness; and
• a final report within one month after submission of the 72-hour incident notification.¹²

The coordinating CSIRT may request an intermediate report. The operational owner should therefore keep the authority submission, technical investigation, remediation, and user-communication workstreams linked to the same case.

As checked on 16 August 2026, the Commission states that the SRP will be operational by 11 September 2026 and that functional and security testing is under way. ENISA states that the public URL will be provided at launch and that Assigned Representatives will authenticate through EU Login. An EU Login account can be created in advance, but ENISA advises manufacturers and open-source software stewards to begin SRP registration and representative validation only when they need to submit a specific notification. Validation proceeds in parallel with reporting and does not prevent submission. Organisations should therefore identify primary and backup representatives, prepare EU Login accounts, determine the relevant CSIRT jurisdiction, and prepare approval arrangements and report data without attempting premature SRP registration.¹³¹⁴

7. Inform users through a separate, risk-based workstream

Article 14(8) requires the manufacturer, after becoming aware of a reportable vulnerability or incident, to inform impacted users and, where appropriate, all users. Where necessary, the information must include mitigation and corrective measures that users can deploy.¹⁵

This is not identical to the authority notification and does not require indiscriminate publication of exploitable detail. The Commission guidance treats the communication as risk-based and proportionate, particularly for sensitive and essential environments where premature technical disclosure may increase risk.¹⁶

The customer communication process should be able to identify affected versions and deployments, provide safe interim measures, control disclosure, update the advice as facts change, and preserve a record of who was informed.

8. Close the case with an evidence-based outcome

The case record should conclude with one of three outcomes:

• mandatory Article 14 report: with awareness basis, submissions, user communications, corrective measures, and final report;
• not currently reportable: with the statutory condition that was not established, remaining vulnerability or incident actions, and a reassessment trigger; or
• voluntary notification considered: under Article 15, with a recorded decision.

A not currently reportable conclusion should not silently close remediation. Reportability and vulnerability handling are separate questions.

What customers can legitimately expect from manufacturers

Article 14 does not turn a product manufacturer into the operator of the customer’s network, plant, machine, or information system. From 11 September 2026, it does, however, create an event-driven duty to inform impacted users, and, where appropriate, all users, when the manufacturer becomes aware of an actively exploited vulnerability or severe product-security incident. Once the full CRA regime applies to a particular product, Article 13 and Annexes I and II add lifecycle duties concerning secure-use information, support-period transparency, vulnerability handling, and security updates.

The division of responsibility begins from two facts:

• the manufacturer controls the product’s design, components, supported versions, security architecture, vulnerability analysis, updates, and authoritative product information; and
• the customer controls, or delegates control over, the actual deployment, configuration, connectivity, users, operational constraints, logs, and decision to install a corrective measure.

The manufacturer should therefore manage the cybersecurity of the product for which it is responsible. The customer must manage the cybersecurity of the environment in which that product operates. Neither side can perform its function reliably without timely information from the other.

The applicable date determines the customer’s legal baseline

The customer’s CRA expectations must be tied to the relevant product population and application date.

Article 14 applies early and broadly, while the full CRA lifecycle baseline depends on when the particular product was placed on the market or substantially modified. ¹⁷

Product or service situation	What the customer can expect under the CRA	Important limit
Any in-scope product from 11 September 2026, including a product placed on the market earlier	If the manufacturer becomes aware of an actively exploited vulnerability or severe product-security incident, impacted users, and, where appropriate, all users, must be informed and, where necessary, given deployable mitigation or corrective measures.	Article 14 does not create a general security-support, scanning, monitoring, or patching service for every legacy product.
Product placed on the market under the full CRA regime from 11 December 2027	Secure product design, vulnerability handling during the support period, secure updates, user instructions, support-period disclosure, a vulnerability contact, conformity information, and the other applicable Article 13 and Annex I requirements.	The requirements are risk-based and product-specific; not every Annex I measure applies identically to every product.
Product placed on the market before 11 December 2027 and not subsequently substantially modified	Article 14 reporting and user-information duties apply, but the full product and lifecycle requirements are not retroactively imposed merely because the product remains in use.	Stronger legacy-product support must arise from an existing contract, another legal regime, a voluntary manufacturer commitment, or a new agreement.
Managed service, maintenance, continuous monitoring, on-site response, or customer-specific integration support	Whatever the contract expressly requires.	These services do not arise automatically from the manufacturer’s CRA status.

From September 2026: customers can expect an actionable warning when Article 14 is triggered

Once the manufacturer becomes aware of an actively exploited vulnerability or severe incident, Article 14(8) creates a user-information duty separate from reporting to the authorities. The manufacturer must inform impacted users and, where appropriate, all users; where necessary, it must also communicate mitigation and corrective measures that users can deploy.¹⁸

The statutory 24-hour and 72-hour deadlines apply to regulatory notifications, not directly to customer communications. Article 14 does not set a universal customer-notification deadline measured in hours. Nevertheless, Article 14(8) requires users to be informed, and its CSIRT backstop expressly addresses a failure to do so in a timely manner. A process that withholds deployable protective action while pursuing a lengthy complete investigation would therefore be difficult to reconcile with a timely, risk-based application of the provision.

The initial customer notice can therefore be provisional. It should distinguish confirmed facts, current assessments, and unresolved questions rather than wait for complete root-cause analysis.

The CRA does not prescribe a fixed customer-advisory template, but an operationally useful notification will normally identify, to the extent known:

• the affected product families, models, software or firmware versions, components, and configurations;
• whether the product is confirmed affected, not affected, or still under investigation;
• the functionality, interface, or deployment condition required for exposure;
• the likely consequences for confidentiality, integrity, availability, authenticity, safety, or essential functions;
• indicators of compromise or detection guidance where disclosure is safe and useful;
• immediate containment measures, including functions, interfaces, accounts, certificates, or remote connections that should be restricted;
• temporary workarounds or compensating controls;
• the available security update or other corrective measure, together with its identity and integrity-verification method;
• installation prerequisites, operational effects, recovery precautions, and known residual risks; and
• the authoritative channel and expected timing of subsequent updates.

The manufacturer may legitimately limit exploit detail, target information to affected customers, or delay wider public disclosure where broader dissemination would materially increase exploitation risk. Particularly in energy, manufacturing, transport, healthcare, and other sensitive environments, legitimate transparency does not require publication of an operational exploit recipe before customers have had a reasonable opportunity to protect themselves.¹⁹

Conversely, a generic message stating only that “a cybersecurity issue is under investigation” is not enough for a customer that must determine whether particular equipment is exposed and whether immediate containment is necessary.

Under the full CRA regime: customers can expect a managed product-security lifecycle

For products subject to the CRA’s full application, the customer can expect more than event-driven notification.

The full CRA baseline gives customers product identity, secure-use information, support transparency, vulnerability handling, and corrective measures, not an outsourced security-management service. ²⁰

Customer expectation	CRA baseline	What it does not automatically provide
Identifiable product and responsible manufacturer	Product type, batch, serial number or another identifier; manufacturer identity and contact details; CE marking; and an EU declaration or simplified declaration of conformity.	Proof that the customer’s complete deployed system is secure or IEC 62443 compliant.
Direct vulnerability contact	An easily identifiable single point of contact through which users can communicate rapidly with the manufacturer, including to report vulnerabilities. Communication cannot be restricted exclusively to automated tools.	A guaranteed 24/7 response time, named engineer, or incident-response SLA.
Secure-use information	Intended purpose, assumed security environment, essential functions, security properties, known or foreseeable circumstances creating significant risks, and instructions for secure commissioning, operation, updating, and decommissioning.	A complete customer-specific network design, hardening project, or operational risk assessment.
Transparent support horizon	The type of technical security support and the support-period end date, stated clearly at the time of purchase. During that period, the manufacturer must handle product and component vulnerabilities effectively.	Unlimited or indefinite support. For long-lived industrial products, however, five years should not be treated automatically as sufficient where the expected use is materially longer.
Risk-based vulnerability handling	Processes for internal and external vulnerability reports, coordinated vulnerability disclosure, component due diligence, regular security tests and reviews, and remediation without delay in relation to the risk.	A guarantee that no vulnerability will exist or that every finding will receive a separate patch.
Secure corrective measures	Secure update distribution and, where security updates are available, dissemination without delay, free of charge, unless otherwise agreed with a business user in relation to a tailor-made product and accompanied by an advisory explaining relevant user actions.	Installation by the manufacturer, customer-specific validation, a maintenance window, rollback assistance, or compatibility testing against every integrated system.
Availability of issued updates	A security update issued during the support period must remain available for at least ten years after issue or for the remaining support period, whichever is longer.	A ten-year support period or ten years of new vulnerability remediation after the support period ends.
Information about fixed vulnerabilities	Once an update is available, information about the fixed vulnerability, affected products, impact, severity, and remediation must generally be disclosed, subject to justified security-related delay.	Immediate public disclosure of all technical details before mitigation is available.
Integration information where applicable	If the product is intended for integration into another product with digital elements, the manufacturer must provide the information necessary for the integrator’s CRA compliance.	Automatic access by every end customer to the manufacturer’s complete architecture, source code, risk assessment, or technical file.

The manufacturer must prepare an SBOM, a cybersecurity risk assessment, technical documentation, and conformity evidence. The CRA does not, however, give every customer an automatic right to receive the full SBOM, risk assessment, source code, penetration-test reports, or technical file. Annex II expressly treats user access to the SBOM as dependent on the manufacturer deciding to make it available. Additional disclosure may nevertheless be justified by procurement risk, the customer’s NIS2 or sectoral obligations, an IEC 62443 assurance case, or the need to integrate and operate the product safely; in those circumstances, access and confidentiality should be defined contractually.

Customers remain responsible for the deployed environment

A manufacturer’s advisory identifies the product-side risk. The customer must connect that information to the equipment actually deployed.

This normally requires the customer, or a formally delegated maintainer or managed-service provider, to:

1. maintain an inventory linking physical assets to product models, serial numbers, software and firmware versions, components, configurations, and support status;
2. determine whether the affected functionality is enabled, reachable, or exposed in the actual architecture;
3. search for relevant indicators and preserve operational and forensic evidence;
4. contain an active compromise or reduce exposure without creating unacceptable safety or availability consequences;
5. test the update or workaround in a representative environment;
6. approve and deploy it under operational change control;
7. verify successful installation and continuing system operation;
8. document any temporary exception or residual risk; and
9. perform any separate NIS2, DORA, data-protection, contractual, or sectoral incident assessment.

In an OT environment, the customer may reasonably refuse immediate or automatic installation where an update has not been validated against safety, availability, process-control, or vendor-support constraints. That decision does not eliminate the manufacturer’s duties to provide a secure corrective measure and adequate information, but it leaves the customer responsible for controlling the interim exposure.

Maintenance and integration do not make responsibility disappear

Customers often buy a complete machine, plant, storage system, automation platform, or managed service through an EPC contractor, system integrator, distributor, or maintainer rather than directly from every component manufacturer.

The contractual chain must therefore identify:

• which legal entity is the manufacturer of each product;
• whether the integrator is also the manufacturer of the final integrated product;
• who receives manufacturer advisories;
• who maps an advisory to deployed assets;
• who may contact the manufacturer directly;
• who assesses system-level and safety consequences;
• who tests, approves, deploys, and verifies corrective measures; and
• who performs the customer’s own regulatory notifications.

A maintainer can perform these activities, but delegation of the work does not automatically transfer the customer’s statutory responsibilities or the manufacturer’s CRA duties. A contract in which the manufacturer informs the maintainer, while the maintainer has no duty to notify the asset owner promptly, creates a predictable control failure.

For critical equipment, both the asset owner and the authorised maintainer should normally receive security advisories, with a clear rule governing confidential information and emergency escalation.

Stronger operational expectations must be made contractual

Where the customer needs more than the CRA product baseline, it should convert the need into measurable procurement and maintenance requirements. Depending on criticality, these may include:

• maximum acknowledgment, assessment, advisory, and remediation times by severity;
• a 24/7 product-security escalation route;
• notification to named operational, cybersecurity, and asset-management recipients;
• SBOM delivery in CycloneDX or SPDX and updated SBOMs for each release;
• VEX or equivalent product-specific vulnerability-applicability statements;
• advance notification of security-relevant component, architecture, cloud-service, or support changes;
• digitally signed update packages, hashes, offline update procedures, rollback instructions, and recovery images;
• compatibility and regression testing against an agreed reference configuration;
• security log specifications, time synchronisation, event export, forensic preservation, and indicators of compromise;
• rules for remote access, emergency intervention, credential use, session recording, and revocation;
• on-site or remote incident-response assistance;
• support-period extension, end-of-support notice, migration assistance, and obsolescence planning;
• obligations flowing through to subcontractors and component suppliers; and
• evidence supporting IEC 62443, NIS2, sectoral, safety, or customer-specific assurance requirements.

These commitments are legitimate customer requirements, especially for essential or long-lived industrial systems. They should not, however, be represented as obligations that the CRA automatically imposes in every commercial relationship.

ImportantThe defensible division of responsibility

The manufacturer owns product truth and product remediability: what the product contains, whether it is affected, how it can be corrected, and how long it is supported.

The customer owns deployment truth and the operational decision: where the product is installed, how it is configured, what it is connected to, whether compromise is present, and when a mitigation can be deployed safely.

A maintainer or managed-service provider owns only the activities expressly delegated to it. Cybersecurity fails at the interfaces when any of these responsibilities is assumed rather than documented.

What common security signals mean

The examples below are simplified. The actual decision depends on evidence and product context.

Signal or event	Article 14 conclusion on those facts	Required process response
A scanner identifies a high-severity CVE in a package apparently present in the product; there is no evidence of malicious exploitation.	Not an actively exploited vulnerability solely on that basis.	Confirm component identity, version, reachability, configuration, exposure, and risk; perform applicable vulnerability handling; monitor for new evidence.
A public report says a third-party component is exploited in other products; the component is in this product, but there is no reliable evidence that the vulnerability has been exploited in this product.	Under the current Commission guidance, not a mandatory final-product report solely on those facts.	Assess immediately; confirm containment and exploitability; contact the supplier; remediate or mitigate as applicable; reconsider if product-specific exploitation evidence appears.
A customer provides reliable logs showing a malicious actor exploited a vulnerability in the manufacturer’s product without permission.	Likely reportable once the initial assessment gives reasonable certainty.	Record awareness, start the 24-hour and 72-hour workflow, preserve evidence, investigate, mitigate, and inform users.
A customer reports unusual activity but cannot yet connect it to the product or malicious exploitation.	A signal, not necessarily awareness of a reportable event.	Triage promptly, collect targeted evidence, record the assessment, and avoid waiting for perfect forensic certainty once the trigger is established.
An authorised penetration test or good-faith researcher demonstrates exploitation, with no evidence of malicious use.	Not an actively exploited vulnerability merely because the test succeeded.	Apply any vulnerability-handling and remediation obligations applicable to the product; consider voluntary notification where appropriate; protect coordinated disclosure.
A compromised product update mechanism introduces malicious code into users’ systems, but the precise vulnerability is not yet known.	May be a severe incident even before a CVE or complete exploit chain exists.	Test Article 14(5) immediately; report if reasonable certainty is reached; coordinate containment, update trust, recovery, and user action.
The vulnerability was known before 11 September 2026, but the manufacturer first becomes aware of active exploitation after that date.	Potentially reportable. Knowledge of the vulnerability and awareness of active exploitation are different facts.	Apply the post-date awareness assessment and deadlines.
The manufacturer had already become aware of the active exploitation before 11 September 2026.	The Commission guidance says Article 14 does not require retroactive reporting of that already-known exploitation.	Preserve the transition record and assess any new event or separate obligation on its own facts.

Table 3: A tool finding, a vulnerability, active exploitation, and a severe incident are different decision objects.

How scanners, SBOMs, VEX, telemetry, and threat intelligence help

The legal trigger remains evidence and product context. Tools shorten the path to that evidence.

Vulnerability scanners and SCA

Network, host, container, firmware, source-code, and dependency scanners can identify possible weaknesses and affected components. They are useful for prioritisation and can reveal information that warrants an Article 14 assessment. They usually do not prove that a malicious actor exploited the vulnerability, and false positives, version ambiguity, backported fixes, unreachable code, and configuration differences can affect the result.

SBOM and VEX

An SBOM helps answer is the component present, in which product and version? A VEX statement can help answer is this known vulnerability considered exploitable or affected in this product state, and why? Neither proves malicious exploitation. Together, they can dramatically reduce the time needed to assess a supply-chain alert within a 24-hour reporting environment.

Telemetry and detection

Product or service telemetry can provide direct exploitation indicators, but only where it is lawful, technically appropriate, securely designed, and correctly interpreted. Absence of a telemetry alert is not proof that exploitation did not occur, particularly for disconnected, customer-managed, privacy-sensitive, or legacy products.

Threat intelligence

Threat intelligence can connect a vulnerability to real malicious campaigns, affected versions, indicators, and adversary behaviour. The assessor still needs to establish the required relationship to the manufacturer’s product and evaluate the reliability of the evidence.

Case management and evidence retention

The least glamorous tool may be the most important: a case system that links the original signal, product state, evidence, decisions, timestamps, authority reports, user communications, corrective measures, and closure rationale. Article 14 is a timed decision process, so unstructured email chains are a fragile control.

The IT/OT complication: scanning can itself be a risk

In industrial and operational-technology environments, the absence of a universal CRA scanning mandate is especially important. An aggressive network or protocol scan can overload a legacy controller, disrupt a fragile device, trigger safety functions, or violate the operator’s change-control rules.

That does not justify weaker reporting governance. It changes the evidence plan.

A manufacturer may need to work through:

• customer or maintainer logs;
• passive network monitoring;
• controlled reproduction in a representative test environment;
• firmware and configuration analysis;
• field-service and remote-support records;
• supplier evidence; and
• a carefully authorised on-site test.

The internal playbook should therefore specify who can request evidence from the operator, who approves intrusive testing, how safety and production constraints are managed, and how a maintainer or integrator escalates a suspected product compromise to the manufacturer. The Article 14 trigger does not change because the product is installed in OT; the safe route to reliable evidence often does.

Minimum readiness pack for 11 September

An organisation does not need to complete its entire 2027 CRA conformity programme before the reporting date. It does need a working Article 14 operating model.

At minimum, prepare:

• an accountable reporting owner and named deputies;
• a product, version, manufacturer-entity, Member-State, legacy, and support-status map;
• a documented escalation route from support, field service, maintainers, suppliers, SOC, PSIRT, and engineering;
• an initial-assessment checklist covering both Article 14 triggers;
• a rule for determining and recording the awareness time;
• a case record with evidence, decisions, approvals, and deadlines;
• the correct CRA coordinating-CSIRT jurisdiction and SRP representative arrangements;
• pre-approved 24-hour, 72-hour, final-report, and user-communication templates;
• a customer and maintainer contact strategy, including sensitive IT/OT sites;
• links to product architecture, build, dependency, SBOM, VEX, vulnerability, and deployment evidence where available;
• an out-of-hours escalation path; and
• a tabletop exercise that starts with an ambiguous customer or supplier report, not an already-classified incident.

The tabletop should test whether the organisation can answer, under time pressure:

What product is affected, what evidence do we have, which Article 14 condition may be met, when did we reach reasonable certainty, who can approve the notification, where do we report, and which users need safe action now?

The exact answer to the headline

The CRA does not require vulnerability scanning merely because 11 September 2026 arrives. The Commission-services FAQ states that scanning and monitoring are possible awareness channels, not activities that Article 14 automatically mandates.

But Article 14 cannot be implemented as a statement that we report what we happen to know. It requires an operating capability that converts a received signal into a prompt, evidence-based determination; records when awareness arose; reports progressively within short deadlines; and communicates proportionately with users.

A scanner can help find the signal. An SBOM can help map it. VEX can help qualify it. Telemetry and threat intelligence can help establish what happened. None of them makes the legal decision.

The core control is the reporting decision process, owned, documented, supplied with product evidence, connected to customers and maintainers, and tested before the first real event.

NoteImplementation support

For manufacturers and industrial organisations, the useful deliverable is a tested process rather than a generic reporting policy. Product-role mapping, customer and maintainer escalation, IT/OT evidence paths, awareness criteria, SRP readiness, reporting templates, and a realistic tabletop exercise should be designed as one operating model.

NoteInterpretive status

The CRA text is legally binding. The cited Commission and ENISA implementation materials clarify its practical application but are not legally binding. This article distinguishes their interpretations from requirements stated directly in Regulation (EU) 2024/2847.

See also cybersecurity longforms

The December 2025 Cyberattack on Poland’s Energy Sector

A detailed reconstruction of the incident, the malware, and the wider significance for energy and OT security

Cyber Resilience Act: The New Product-Security Baseline

Scope, legal roles, secure design, conformity, reporting, and lifecycle assurance across the digital-product supply chain

When an AI Evaluation Became a Cyber Intrusion

The OpenAI–Hugging Face incident and the two regimes of agentic cyber risk

See also regulation and compliance longforms

Cyber Resilience Act: The New Product-Security Baseline

Scope, legal roles, secure design, conformity, reporting, and lifecycle assurance across the digital-product supply chain

The EU Digital Battery Passport: Who Is Affected, What Must Be Done, and When

A practical guide to product scope, organisational responsibilities, data obligations, and the February 2027 deadline

See also posts

After the Hugging Face Intrusion: What the New Technical Record Changes

A technical update to the July 2026 reconstruction, based on OpenAI's Black Hat account and subsequent primary disclosures

The Withdrawal of HAWK

How a Galois involution cut the effective key-recovery dimension and ended a NIST post-quantum signature candidate

AI Mathematics Crosses the Systems Boundary

A technical commentary on proof abundance, research agents, and the infrastructure now inside the experiment

When Digital Trust Gets a Deadline

The U.S. 2030 post-quantum cryptography order, enterprise cryptographic debt, and why a federal mandate matters beyond America

When Vulnerability Databases Become Triage Systems

NIST’s NVD update, record CVE growth, and the economics of AI-scaled cyberattacks

Quantum Cryptography at the Edge of Feasibility: Resource Estimates, Architectural Divergence, and Systemic Risk

An analysis of the Google and Oratomic results on Shor’s resource estimates and their implications for the convergence of quantum circuit optimization, error correction, and hardware architectures

Footnotes

1. European Commission services. (2026). FAQs on the Cyber Resilience Act implementation, version 1.3, Section 5, especially questions 5.1–5.4. Shaping Europe’s digital future. Official FAQ page

2. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

3. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

4. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

5. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication

6. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

7. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

8. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication

9. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

10. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication

11. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

12. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

13. European Commission. (2026). Cyber Resilience Act—Reporting obligations. Shaping Europe’s digital future. Official implementation page

14. European Union Agency for Cybersecurity. (2026). Single Reporting Platform (SRP), including FAQs updated 3 August 2026 and Assigned Representative guidance updated through 14 August 2026. ENISA. Official SRP page

15. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

16. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication

17. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

18. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text

19. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication

20. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), in particular Article 3, points (40)–(44); Articles 13–16; Article 24(3); Article 69(2)–(3); Article 71(2); and Annexes I and II. Official Journal of the European Union. Official text