Manufacturers now have 24 hours for an initial CRA report: Poland's CSIRT NASK coordinates submissions

Full application of the EU Cyber Resilience Act begins on 11 December 2027, but one of its most consequential mechanisms is already operating. Since 11 September 2026, manufacturers of products with digital elements have had to report actively exploited vulnerabilities and severe security incidents. An initial warning is due within 24 hours of becoming aware of the event.

Reports go through the Single Reporting Platform launched by ENISA. In Poland, CSIRT NASK performs the national coordination role. For manufacturers of software, mobile apps, internet-connected devices and other digital products, a procedure that amounts to “fix now and document later” may no longer meet the applicable requirements.

The new reporting clock

Poland’s Ministry of Digital Affairs describes four principal deadlines. Within 24 hours, the manufacturer submits an early warning about an actively exploited vulnerability or severe incident. Within 72 hours, it follows with a fuller notification covering the product, the nature of exploitation and remedial or mitigating action taken or available.

For a vulnerability, the final report is due within 14 days of making a fix or mitigation available. For a severe incident, the final-report deadline is one month after the initial notification. The coordinating CSIRT may request additional progress reports.

The obligation is not limited to sending a form to an authority. Manufacturers must also inform users about identified vulnerabilities or incidents and the measures available to reduce risk. Customer communication therefore has to develop alongside technical investigation.

What must be reported

The mechanism covers an actively exploited vulnerability known to the manufacturer and a severe incident affecting product security. The ministry explains that an incident is severe when it negatively affects or may affect the availability, authenticity, integrity or confidentiality of important or sensitive data or functions, or when it has led or may lead to malicious code being introduced or executed in the product, network or user’s systems.

Not every researcher report automatically follows the same route. Active exploitation and incident severity are important thresholds. A manufacturer therefore needs a documented triage process connecting product security, incident response, legal counsel, the business owner and communications.

The first 24 hours begin before certainty

The largest organisational risk is waiting for a complete root-cause analysis. An early warning is designed for a moment when some facts remain unknown. The team must describe what it detected, which product may be affected, why the threshold may be met and what it has done, without guessing attribution or scale.

The company should pre-assign the person authorised to start the process, an out-of-hours deputy, the platform-account owner, legal support for threshold analysis and the approver for customer communications. These roles must still function at weekends, during holidays and when the primary collaboration system is unavailable.

A decision log is essential. It should record when the first credible signal arrived, who was informed, available evidence, threshold assessment, reports submitted and the reasons for any change in position. This is not paperwork for its own sake; it allows the organisation to reconstruct why it treated an obligation as triggered or not triggered.

What manufacturers need before an incident

Without a product and version inventory, scope cannot be established quickly. A manufacturer should know which releases are supported, the components they contain, where code is shared and how to reach users. A sales-maintained mailing list is not a substitute for technical product mapping.

The vulnerability-intake process needs a monitored channel, escalation rules and protection for reporters. The team should be able to distinguish a report requiring reproduction from evidence of active exploitation in customer environments. It also needs the ability to build, sign and distribute an update securely.

Contracts with component and service suppliers should require rapid information sharing. A manufacturer may be under a reporting deadline even where the root cause sits in a library, cloud service or partner module. Responsibility cannot be managed effectively with a simple clause saying that a subcontractor owns all security risk.

What changes for customers

A customer does not file the manufacturer’s report merely because it uses the product, but it must be ready to receive and act on a notice. It needs a product owner, current security contact, deployed-version data and a rapid update path. Without those controls, even a timely vendor warning may sit in the mailbox of someone who has left the company.

Procurement should ask suppliers about their security contact, vulnerability disclosure policy, support period, update distribution and advisory format. A generic statement that a product is “CRA compliant” offers limited assurance. Specific answers, an example advisory and clear responsibilities for both parties are more useful.

Individual users benefit from improved communication only when they update their devices and act on legitimate vendor notices. A vulnerability message is not automatically phishing, but it should be verified through the official website or application rather than an unexpected message link.

Rehearse before the clock starts

A useful exercise can begin with a researcher report, customer alarm or evidence of malicious exploitation online. The team has to identify versions, make a threshold decision, prepare the early warning, plan a fix and draft a user notice. Only that sequence shows whether 24 hours is realistic.

The scenario should also test the tension between speed and confidentiality. Too little information prevents customers from protecting themselves, while excessive detail before a fix may increase risk. The decision requires coordinated judgement rather than automatic publication of an entire technical report.

Organisations can clarify roles, deadlines and communications through an incident-response tabletop exercise. Product teams should complement it with a vulnerability disclosure programme and connect product obligations with the broader Polish NIS2 implementation.

Source facts and Breachroad conclusions

The Polish Ministry of Digital Affairs notice confirms the reporting start date, scope, 24-hour, 72-hour, 14-day and one-month deadlines, the ENISA platform, CSIRT NASK’s Polish role and the date of full CRA application.

The proposed roles, decision log, contractual controls and exercise design are Breachroad conclusions. This article is not legal advice; the applicability of the CRA to a particular organisation and event should be assessed against the regulation and the facts of the case.