Summary
- Manufacturers must apply Article 14 from 11 September 2026, including to covered products sold before that date. The general commencement date, 11 December 2027, does not defer these duties. Open-source software stewards enter their separate reporting regime on that later date. (CRA, arts. 14, 24(3), 69(3), 71.)
- Scope turns on commercial supply of a connected product and the supplier's legal role. Installed software and necessary manufacturer-controlled remote processing can qualify. A service label, free licence, small workforce, or non-EU headquarters supplies no general exemption. (CRA, arts. 2(1), 3(1), (2), (13), (22), 14(7); recitals 11-20.)
- Two independent triggers require assessment: reliable evidence of malicious exploitation of a contained vulnerability, and a severe incident affecting product security. The incident test includes specified potential effects; confirmed customer damage is unnecessary. An ordinary vulnerability discovery alone does not establish either trigger. (CRA, arts. 3(42)-(44), 14(1), (3), (5).)
- Early warnings are due without undue delay and within 24 hours of awareness; fuller notifications have a 72-hour outer limit. Vulnerability final reports follow availability of a corrective or mitigating measure, within 14 days. Incident final reports are due within one month after the fuller notification. Later stages need not duplicate relevant information already supplied. (CRA, art. 14(2), (4).)
- Reporting through ENISA's Single Reporting Platform reaches the designated national coordinator and ENISA. Manufacturers also owe a separate user-information duty. An upstream supplier's filing does not automatically discharge an integrating manufacturer's duty. (CRA, art. 14(1), (3), (7), (8); Commission services, CRA implementation FAQs, version 1.4, section 5.4, 4 September 2026.)
- Restrictions on onward disclosure protect sensitive information under defined conditions. They do not authorise manufacturers to postpone the initial statutory filing until a patch exists. The receiving coordinator decides whether dissemination may be delayed. (CRA, art. 16(2), (4), (5); Delegated Regulation (EU) 2026/881, arts. 3-5.)
- Article 64's administrative-fine provisions apply from 11 December 2027. The corrected small-business exception concerns missed 24-hour deadlines, not every reporting failure. It exempts qualifying microenterprises and small enterprises from the specified fines, without cancelling their duties. (CRA, arts. 64(2), (10), 71; Corrigendum, OJ L 2025/90555, 2 July 2025.)
- Launch preparations require a manual filing route, authorised personnel, independent deadline tracking, and an outage procedure. ENISA's September guidance identifies limitations in platform counters and account access. A single internal incident record can support several legal assessments, but each recipient and trigger needs separate confirmation. (CRA, art. 14; ENISA, Single Reporting Platform FAQs, questions 9, 15, 25, 26, updated 9 September 2026.)
Analysis by Issue
Commencement and products already in use
Article 14 applies before the CRA's general product-compliance duties. The Parliament and Council enacted a general application date of 11 December 2027, with express exceptions. Manufacturer reporting begins on 11 September 2026; Chapter IV on conformity assessment bodies began applying on 11 June 2026. A manufacturer cannot postpone Article 14 because its conformity assessment or CE-marking programme targets 2027. (CRA, art. 71.)
Legacy products remain within the reporting perimeter. Article 69(2) generally conditions the CRA's application to products placed before 11 December 2027 on a subsequent substantial modification. Article 69(3) exempts Article 14 from that condition. Consequently, the absence of a new sale, update, or substantial modification does not itself exempt an older covered product. The specific transitional exception controls that result. (CRA, art. 69(2), (3).)
The reporting duty does not retrospectively impose every technical requirement on those products. Commission services confirm that legacy-product reporting does not itself activate the separate vulnerability-handling obligations. An obsolete build environment or expired commercial support arrangement therefore requires two decisions: what Article 14 requires the manufacturer to disclose, and what separate law or contract requires it to repair. Article 14 does not exempt products merely because their support has ended. (CRA, arts. 13, 14, 69(3), 71; Commission services, CRA implementation FAQs, version 1.4, section 5.3.)
Awareness has its own temporal boundary. ENISA states that pre-existing knowledge of active exploitation before 11 September 2026 does not create an automatic retrospective reporting requirement. A vulnerability discovered earlier can become reportable when the manufacturer learns of malicious exploitation after commencement. The relevant chronology must distinguish discovery of the weakness from awareness of exploitation. A later, separate severe incident requires its own assessment. (CRA, art. 14(1)-(5); ENISA, Single Reporting Platform FAQs, questions 12, 13.)
Commercial supply and the software boundary
A business first needs an identifiable product supplied on the Union market in a commercial activity. Under Article 3(22), supply can be for payment or free of charge. Article 2(1) requires an intended or reasonably foreseeable direct or indirect data connection to a device or network. Internet connectivity is unnecessary. A local application that exchanges data with another device can meet that condition. Products developed exclusively for internal use require a different assessment because market supply may be absent. (CRA, arts. 2(1), 3(1), (8)-(10), (21), (22); Commission services, CRA implementation FAQs, sections 1.1-1.3, 1.5.)
Commercially supplied software can qualify independently of hardware. A downloaded client, mobile application, browser extension, or separately supplied component must be assessed on its actual delivery and functionality. The manufacturer definition also covers commissioned development followed by marketing under the manufacturer's own name or trademark. Outsourcing coding therefore does not settle which entity owes Article 14 duties. The contract, branding, release process, and supply arrangements must identify that entity. (CRA, art. 3(1), (6), (13), (22).)
Pure remote services require a product nexus. The statutory definition includes remote processing where the manufacturer designs and develops the relevant software, or assumes responsibility for its design and development. Its absence must prevent the product from performing at least one function. Article 3(2) does not limit this test to a core function. A necessary cloud backend can therefore form part of an installed product even when a third party hosts the infrastructure. (CRA, art. 3(1), (2); recitals 11, 12.)
The strongest argument for excluding browser-only services rests on that distinction between a supplied product and remotely accessed functionality. The Commission distinguishes browser-only applications from software supplied for local execution in its nonbinding guidance. Browser access alone does not bring the service within the CRA; necessary remote processing for another covered product can do so. A delivery-model conclusion must remain conditional until the architecture and product functions are established. (CRA, art. 3(1), (2); recitals 11, 12; Commission, C(2026) 5252, Annex, paragraphs 20, 21.)
Product classification does not restrict reporting to the CRA's important or critical categories. Articles 7 and 8 apply principally to conformity assessment and certification. Article 14 applies to manufacturers of covered products without requiring either classification. A software vendor should therefore complete the basic scope assessment even when its product appears outside Annexes III and IV. (CRA, arts. 7, 8, 14, 32.)
Exclusions and specialised products
Sectoral exclusions attach to products meeting the specified legislation, rather than to every supplier serving that sector. Article 2 exempts products covered by the Medical Devices Regulation, the In Vitro Diagnostic Medical Devices Regulation, and Regulation (EU) 2019/2144. It also exempts products certified under the civil-aviation legislation and equipment within the Marine Equipment Directive. A general-purpose application sold to a hospital or vehicle manufacturer does not establish those conditions. (CRA, art. 2(2)-(4).)
A further exclusion covers products within Regulation (EU) No 168/2013 on two- or three-wheel vehicles and quadricycles. It preserves CRA coverage for the specified L1e vehicles designed to pedal. Other exclusions concern identical replacement parts made to the same specifications, exclusively national-security or defence products, and products specifically designed to process classified information. A dual-use product requires examination of the exclusivity condition. (Delegated Regulation (EU) 2025/1535, art. 1; CRA, art. 2(6), (7).)
Equivalent sectoral security requirements do not create a manufacturer's unilateral exemption. Article 2(5) permits the Commission to specify exclusions or limitations by delegated act. Electronic health record amendments also require care: Regulation (EU) 2025/327 changes documentation and conformity provisions, without displacing Article 14. No product-specific facts establish a sectoral exclusion. A product-specific assessment must identify the applicable instrument and satisfy its conditions. (CRA, art. 2(5); Regulation (EU) 2025/327, arts. 104, 105.)
Manufacturers, open-source participants, and corporate groups
Open-source licensing does not decide whether the supplier is a manufacturer. Commercial supply remains central, while the recitals distinguish non-monetised open-source development, financing, contribution, and distribution. Funding from a commercial user or regular releases do not alone establish commercial supply. Nor does a person's contribution to code under another party's responsibility automatically make that contributor a manufacturer. These distinctions prevent an assessment based solely on licence type or developer participation. (CRA, art. 3(13), (22), (48); recitals 17-20.)
A steward must be a legal person other than a manufacturer. Its purpose must include sustained, systematic support for developing specific free and open-source products intended for commercial activities. It must also ensure those products' viability. Article 24(3) conditions its vulnerability duty on involvement in development. Its severe-incident and user-information duties concern incidents affecting systems it provides for that development. Those duties begin on 11 December 2027. A commercial manufacturer cannot obtain the later commencement date merely by describing itself as a steward. (CRA, arts. 3(14), 24(3), 71; Commission services, CRA implementation FAQs, section 5.5.)
Corporate allocation must follow the entity that meets the statutory definition. ENISA permits a coordinated notification across a manufacturer's branches or subsidiaries. Separate entities manufacturing different affected products must still establish that their respective duties were discharged. A non-EU manufacturer remains subject to the product-market test; Article 14(7) expressly provides its reporting route. Supplier agreements should identify who investigates, supplies technical facts, and files on each manufacturer's behalf. Those arrangements cannot replace the statutory scope assessment. (CRA, arts. 3(13), 14(1), (3), (7); ENISA, Single Reporting Platform FAQs, question 8.)
An importer or distributor does not owe the manufacturer's Article 14 duty merely because it handles the product. Its actual activities must be tested against the manufacturer definition. Under Articles 21 and 22, rebranding and substantial modification can trigger further manufacturer duties after the general commencement date. A business should distinguish its existing manufacturer status from a status arising under those later provisions. (CRA, arts. 3(13), 21, 22, 71.)
Active exploitation and component dependencies
The vulnerability trigger requires reliable evidence of actual malicious exploitation, rather than a severity score or theoretical exploitability. Article 3(42) requires exploitation in a system without the system owner's permission. A published vulnerability identifier, proof of concept, or authorised security test does not alone satisfy every element. The manufacturer's own environment need not be compromised: the definition refers to exploitation in a system, without limiting it to that manufacturer or an EU victim. (CRA, arts. 3(42), 14(1); recital 68.)
The manufacturer must connect that evidence to a vulnerability contained in its product. Upstream component exploitation requires assessment of the shipped component, configuration, and execution path. Commission services state that no mandatory notification arises where the vulnerability cannot be exploited in the finished product. This interpretation limits a broader reading based on mere component presence. A defensible exclusion needs technical support; the absence of reported customer attacks does not establish that exploitation is impossible. (CRA, art. 14(1); Commission services, CRA implementation FAQs, section 5.4.)
Each affected manufacturer's duty remains separate. An upstream component vendor's report does not automatically satisfy the integrating vendor's obligation for its own product. A noncommercial open-source component can also generate a reportable vulnerability in a commercial finished product. The upstream developer's exclusion does not transfer to that finished product. Shared evidence and coordinated submissions can reduce inconsistent descriptions, but each manufacturer must establish that its own required notification was made. (CRA, arts. 3(1), 14(1), (2); Commission services, CRA implementation FAQs, section 5.4.)
Severe incidents and awareness
A severe incident can require reporting without an actively exploited vulnerability. Either condition in Article 14(5) can trigger that duty. One concerns negative effects, or the capacity for negative effects, on protection of sensitive or important data or functions. The protected attributes are availability, authenticity, integrity, and confidentiality. The other concerns introduction or execution of malicious code in the product or a user's network and information systems, including the capacity to produce that outcome. Either route can suffice. (CRA, arts. 3(43), (44), 14(3), (5).)
The product-security nexus prevents every corporate cyber event from becoming a CRA report. A compromise of a release system can qualify where it threatens the security of distributed products. A corporate outage without that connection does not establish Article 14(3). Conversely, the manufacturer cannot require actual customer loss, personal-data disclosure, or a confirmed malicious actor before considering the severe-incident route. The statutory test includes potential effects and does not confine incidents to deliberate attacks. (CRA, art. 14(3)-(5); recital 69.)
The awareness assessment should separate an unverified signal from information sufficient to establish the statutory trigger. Commission services identify several possible information sources and do not prescribe a specific monitoring channel under Article 14 alone. Prompt technical assessment may be necessary to establish whether the product is affected. An internal approval meeting supplies no statutory reset for knowledge already acquired by the manufacturer. The company's escalation process should preserve the original signal, assessment, and reason for the recorded awareness time. (CRA, art. 14(1)-(4); Commission services, CRA implementation FAQs, section 5.1.)
A single event may satisfy both reporting tracks. Successful interference with software distribution can produce a severe incident and reveal an actively exploited vulnerability. The manufacturer should assess each trigger separately and record any different awareness times. It should use the platform's applicable reporting paths rather than assume that selecting one category necessarily discharges the other. The legal conclusion depends on the event's elements, not its internal incident label. (CRA, art. 14(1)-(5).)
Reporting stages and separate final-report clocks
For an actively exploited vulnerability, the manufacturer must send an early warning without undue delay and within 24 hours of awareness. Where applicable, it identifies the Member States in which the product was made available. The fuller notification follows without undue delay and within 72 hours of the same awareness event. It includes, as available, general product information, the nature of the exploit and vulnerability, and corrective or mitigating measures taken. The available information also covers measures users can take and, where applicable, information sensitivity. (CRA, art. 14(2)(a), (b).)
The vulnerability final report is due no later than 14 days after a corrective or mitigating measure becomes available. It addresses the vulnerability's severity and effects, available information about the malicious actor, and the security update or other corrective measures. A usable mitigating measure can start this period before a permanent patch exists. The fuller and final stages contain exceptions where the relevant information was already supplied. The manufacturer should verify completeness before relying on either exception. (CRA, art. 14(2)(b), (c).)
For a severe incident, the early warning has the same 24-hour outer limit. It must indicate whether unlawful or malicious acts are suspected and, where applicable, the relevant Member States. Within 72 hours of awareness, the manufacturer supplies available information about the incident's nature, an initial assessment, and measures taken. The notification also addresses available user measures and, where applicable, information sensitivity. Previously supplied relevant information need not be duplicated under the express exception. (CRA, art. 14(4)(a), (b).)
The severe-incident final report is due within one month after submission of the fuller notification, unless the relevant information was already supplied. Its required content covers the incident's severity and effects, the likely threat or root cause, and applied and ongoing mitigation measures. This period runs from the actual submission, even when the manufacturer files before the 72-hour limit. One month must not be rewritten as 30 days. Article 14 does not permit a general postponement of that report until the investigation is complete. (CRA, art. 14(4)(c).)
The 24-hour and 72-hour figures are outer limits, subject to the separate requirement to act without undue delay. They are measured from awareness, rather than cumulatively from the preceding report. Missing forensic details do not justify waiting for a finished investigation before the early warning. The coordinator may request an intermediate report with relevant status updates. A reporting plan therefore needs continuing case ownership after the first two submissions. (CRA, art. 14(2), (4), (6).)
Reporting destination and authority to file
The manufacturer must notify the designated national CSIRT coordinator and ENISA simultaneously through the Single Reporting Platform. A CSIRT is a computer security incident response team. Under Article 14(7), the primary national connection is the EU establishment where product-cybersecurity decisions are predominantly taken. If that establishment cannot be determined, the relevant EU establishment is the one with the highest employee count. Registered office, sales volume, or the location of the first affected customer does not automatically control that first test. (CRA, art. 14(1), (3), (7).)
Without an EU main establishment, the manufacturer must apply the statutory sequence. The relevant Member State first follows its authorised representative for the highest number of products. Failing that connection, it follows the importer placing the highest number on the market, then the distributor making the highest number available. The final alternative is the Member State with the highest number of users. These are ordered alternatives. Where the highest-user fallback applies, Article 14(7) permits subsequent actively exploited vulnerability and severe-incident notifications to go to the same coordinator that received the first notification. ENISA warns that choosing the wrong coordinator can invalidate a report and require resubmission. (CRA, art. 14(7); ENISA, Single Reporting Platform FAQs, question 18.)
The platform's Assigned Representative is an operational account role. It must not be confused with the CRA's legally defined authorised representative, whose role depends on an EU establishment and written mandate. ENISA permits one Primary Assigned Representative and up to 20 Secondary Assigned Representatives per manufacturer. The primary account can see submitted reports; secondary accounts generally see their own. Drafts remain visible only to their creator. A manufacturer should plan backup access around those permissions; registration does not transfer legal responsibility. (CRA, arts. 3(15), 14; ENISA, Single Reporting Platform FAQs, question 9; AR Interface functions, View the Dashboard, 7 September 2026.)
User information and security-sensitive disclosure
Notification to authorities does not exhaust Article 14. The manufacturer must inform impacted users and, where appropriate, all users about the vulnerability or incident. Where necessary, it must identify corrective or mitigating measures users can deploy. Where appropriate, it must use structured, machine-readable information that users can process automatically. Article 14(8) requires timely information, without a universal 24-hour or 72-hour customer-notice deadline. The coordinator can intervene where the manufacturer fails to act in time. (CRA, art. 14(8).)
User communications require a separate decision about recipients and useful protective action. A public advisory can reach users whose identities the manufacturer lacks, while a targeted notice can address known affected deployments. Neither method is automatically sufficient in every case. Under Article 14(8), the receiving coordinator may inform users if the manufacturer's delay warrants proportionate and necessary intervention. The manufacturer should retain the message, recipient rationale, distribution evidence, and any correction. Those records are recommended evidence of performance, not a newly asserted statutory retention period. (CRA, art. 14(8).)
A manufacturer concerned about disclosing an unpatched weakness should use the CRA's confidentiality procedures. Article 16 requires security controls and restricted handling of information concerning unpatched vulnerabilities. The receiving coordinator can delay onward dissemination for justified cybersecurity reasons. That discretion concerns authority handling after notification. It does not create a manufacturer-controlled extension of Article 14's submission deadlines or a general commercial-confidentiality exemption. (CRA, arts. 14(2), 16(2), (4), (5).)
Delegated Regulation (EU) 2026/881 permits dissemination delays under specified conditions. Any delay must be limited to the period strictly necessary. Under Article 3, the coordinator must assess information sensitivity, establish that dissemination risks outweigh security benefits, and reject sharing restrictions as inadequate. At least one additional condition must apply. The manufacturer may have informed the coordinator that an effective measure is expected within 72 hours. If no effective measure is available within that period, Article 3(a) requires dissemination to the relevant CSIRTs. Alternatively, the notified information is deemed sufficient, in light of the nature of the notified actively exploited vulnerability, to create an exploitation technique, or the coordinator can share enough partial information for adequate protective measures. The fourth route concerns coordinated vulnerability disclosure in which the receiving coordinator acts as a trusted intermediary. Article 4 permits a delay to a particular receiving CSIRT where a cybersecurity incident casts doubt on its ability to ensure the confidentiality of the notified information, or the initial coordinator has sufficient reason to consider that ability inadequate. Article 5 permits a delay in dissemination via the platform where ENISA has informed the CSIRTs Network of a cybersecurity incident casting doubt on the platform's ability to ensure confidentiality, until ENISA informs that Network that this ability has been restored. The applicable condition also determines when dissemination must resume. A manufacturer should support any request with concrete security facts. (Delegated Regulation (EU) 2026/881, arts. 3-5.)
A narrower procedure governs particularly exceptional circumstances in a 72-hour vulnerability notification. Article 16(2) permits three grounds. The first concerns malicious exploitation in the coordinator's Member State, with none known in another Member State. The other grounds concern likely disclosure contrary to that State's essential interests, or imminent high cybersecurity risk from further dissemination. ENISA initially receives the fact of notification, general product information, the general nature of the exploit, and the fact that security grounds were raised. The coordinator controls wider access; ENISA must recommend full dissemination if it identifies systemic internal-market security risk. This procedure does not remove the notification obligation or extend to every severe-incident report. (CRA, art. 16(2); ENISA, Single Reporting Platform guidance on particular exceptional circumstances.)
Article 2(8) separately limits compelled supply of information whose disclosure would conflict with essential Member State security interests. It concerns national security, public security, or defence. No facts establish that exception here. A manufacturer invoking it should identify the protected State interest and the information concerned, rather than assert ordinary commercial secrecy. (CRA, art. 2(8).)
Other reporting laws and contractual notices
The same technical event can require reporting under NIS2 and the CRA. Covered entities assess significant service incidents under NIS2; manufacturers assess the separate product-security triggers under Article 14. A cloud provider's entity-level notification or a customer's NIS2 report therefore does not automatically discharge a product manufacturer's Article 14 duty. National transposition, entity scope, and any applicable sector-specific rules need separate verification before a business can establish its NIS2 obligations. (CRA, art. 14; Directive (EU) 2022/2555, arts. 2-4, 23.)
Personal-data breaches require a separate controller or processor assessment. Under the GDPR, a controller ordinarily notifies the competent supervisory authority without undue delay and, where feasible, within 72 hours of awareness. The exception applies where the breach is unlikely to create a risk to individuals' rights and freedoms. A processor must notify its controller without undue delay; high-risk breaches can require communication to affected individuals. These recipients and thresholds differ from Article 14. A CRA user notice should not be assumed to satisfy them. (Regulation (EU) 2016/679, arts. 33, 34; EDPB, Guidelines 9/2022, version 2.0, paragraphs 29, 44-48, 81.)
Financial-sector customers may also need information for DORA reporting of major ICT-related incidents to their competent authorities. Supplying software to such a customer does not by itself make the vendor the financial entity responsible for that report. Contractual incident-notice and assistance clauses need their own examination. No customer contract, insurance policy, or outsourcing arrangement was supplied, so no contractual deadline can be stated. (Regulation (EU) 2022/2554, art. 19(1); European Supervisory Authorities, JC 2024 108, paragraph 51.)
Enforcement, fines, and the commencement gap
Manufacturers must comply with Article 14 from September 2026, while the CRA's general penalty provisions apply later. Under Article 64(2), relevant noncompliance can attract fines up to EUR 15 million. For an undertaking, the alternative ceiling is 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Article 64 applies from 11 December 2027 under Article 71. Presenting those CRA fines as already applicable on the reporting commencement date would therefore collapse two different dates. (CRA, arts. 64(2), 71.)
The absence of that earlier CRA fine provision does not establish immunity under every applicable law. No Member State's implementation measures, existing enforcement powers, or remedies have been assessed for a particular manufacturer. Under Articles 52 and 54, national authorities must cooperate with CSIRTs and ENISA. They can require corrective action and, under the relevant conditions, restrict supply or require withdrawal or recall. Their application and the legal basis for any pre-2027 measure require separate attention. A business should not treat the phased commencement as permission to disregard Article 14. (CRA, arts. 52, 54, 64, 71.)
The July 2025 corrigendum changes the scope of the fine exception in Article 64(10). It replaces the reference to paragraphs 3-9 with paragraphs 2-9. Qualifying microenterprises and small enterprises therefore receive the stated protection for failure to meet the two 24-hour deadlines. The provision does not extend that protection to medium-sized enterprises, missed 72-hour or final-report deadlines, or the user-information duty. The separate steward exception covers the administrative fines specified there. Neither exception deletes the underlying obligations. Eligibility requires the CRA's enterprise-size definition, including the treatment of partner and linked enterprises. The absent ownership and financial records prevent a business-specific eligibility finding. (CRA, arts. 3(19), 64(10), recital 5; Corrigendum, OJ L 2025/90555, 2 July 2025.)
Failure to report and responsibility for the underlying security defect also require separate analysis. Article 17(4) prohibits increased liability arising from the mere act of notification. That protection does not excuse unsafe products or other breaches. Its own application must be read with Article 71 rather than presumed to begin with Article 14. Damages, contractual liability, privilege, and insurance consequences depend on additional law and facts absent here. A report should distinguish verified findings from provisional assessments without concealing required information. (CRA, arts. 14, 17(4), 71.)
Operational readiness at commencement
ENISA plans to open the platform on 11 September 2026. Its September guidance describes mandatory manufacturer reporting at launch, without the Article 15 voluntary-reporting function or an application programming interface. Filing is through the web interface in English. Assigned Representatives need EU Login with multifactor authentication. ENISA advises registering the manufacturer when a first report is needed; staff can prepare their individual login credentials in advance. Validation runs alongside filing. Published ENISA materials state different unverified-report caps; the applicable cap should be confirmed with the coordinator. (ENISA, Single Reporting Platform FAQs, questions 4, 9, 15, 24, 27-30, updated 9 September 2026; ENISA, AR User registration, General Notes, 8 September 2026; AR Interface functions, Add an Association with an Additional Manufacturer Association through Settings, 7 September 2026.)
Manufacturers should keep legal deadlines outside the platform's reminder logic. ENISA states that its initial 72-hour counter runs 48 hours after the early warning is submitted. An early warning filed 12 hours after awareness therefore produces a reminder at hour 60, although the statutory outer limit remains hour 72. The illustration is derived: 12 + 48 = 60. The no-undue-delay requirement still applies. ENISA also reports no current automated counter for the vulnerability final report. (CRA, art. 14(2), (4); ENISA, Single Reporting Platform FAQs, question 26.)
An outage procedure should preserve attempted-submission times and the information ready for filing. ENISA advises submission once the platform returns and permits direct contact with the designated coordinator when immediate communication is necessary. It also requires the subsequent platform submission. That operational advice does not state a statutory deadline extension or guarantee that an alternative communication discharges Article 14. Prompt authority contact and a retained outage record reduce uncertainty about what the manufacturer could submit and when. (CRA, art. 14(7); ENISA, Single Reporting Platform FAQs, question 25.)
A workable internal process should assign a product-security lead to assess the technical trigger and maintain the case chronology. Legal or compliance staff should resolve the manufacturer, scope, recipient, and parallel-law questions. A named filer and backup need authority to submit within the available time, without awaiting a full investigation. Customer communications and engineering teams should own user notices and the date when a corrective or mitigating measure becomes available. These staffing allocations are recommendations for performing Article 14; the CRA does not require those job titles. (CRA, art. 14(1)-(8).)
The manufacturer should retain a product-level decision record linking affected versions, exploitation evidence, incident effects, and the awareness determination. It should also retain submitted reports, receipt records, user communications, dissemination requests, and the two distinct final-report calculations. No standalone fixed retention period under Article 14 governs that entire file. Retention should instead account for applicable legal duties, necessary evidence, confidentiality, and personal-data requirements. A rehearsal should test the actual account permissions and manual reporting sequence before the organisation relies on them during an incident. (CRA, art. 14; ENISA, Single Reporting Platform FAQs, questions 9, 25, 26.)
