Tag: Security
All blog posts with this tag.
- 07 Sep, 2026
Cyber Resilience Act: preparing incident reporting for software, scripts and SDKs
The Cyber Resilience Act is progressively becoming operational for software publishers. From 11 September 2026, manufacturers in scope will have to report actively exploited vulnerabilities and severe incidents that impact the security of products with digital elements. For a B2B SaaS company, analytics tool, JavaScript script, SDK or component distributed to customers, the topic should be analysed carefully. It would be wrong to assume that every SaaS service is automatically covered in the same way. It would also be risky to wait until December 2027 before organising incident response. This article is not a legal qualification. It gives product, security and engineering teams a practical preparation method when they distribute software or components used by customers. What changes on 11 September 2026 The European Commission states that, as of 11 September 2026, manufacturers must report certain events concerning products with digital elements: actively exploited vulnerabilities and severe incidents affecting product security. The timelines are short:early warning without undue delay and within 24 hours of becoming aware; vulnerability notification within 72 hours; final report within the applicable deadline, including 14 days after a corrective measure or mitigation becomes available for an actively exploited vulnerability, or within one month of the 72-hour notification for certain severe incidents.Notifications go through the CRA Single Reporting Platform, operated by ENISA, and are routed to the competent CSIRTs according to the applicable rules. The important point is that these reporting obligations arrive before the full application of the main product obligations under the Cyber Resilience Act. They should be prepared now, even if other parts of the regime come later. Why scripts and SDKs deserve attention Analytics teams often think first about the security of the main application: authentication, dashboard access, exports and databases. But the product surface can include other elements:a JavaScript script installed on customer sites; a client-side or server-side SDK; an open-source library maintained by the vendor; a connector or plugin; an API used to collect or expose data; an admin interface capable of changing injected code.These elements do not automatically have the same legal qualification. But they belong in the security inventory, because a vulnerability in a distributed component can affect multiple customers at once. For an analytics product, the collection script is especially sensitive. It runs on third-party websites, in visitors’ browsers, and may be updated centrally. A distribution flaw, compromised build or unauthorised modification could have a broader impact than a broken chart in a dashboard. Do not confuse a bug, a vulnerability and a severe incident Not every technical issue is a CRA report. A broken chart, a loading problem or an aggregation error is not necessarily an actively exploited vulnerability or a severe security incident. The first step in the runbook should therefore be qualification.Situation Question to askFunctional bug Does it affect product security or only user experience?Internally found flaw Is it exploitable, exposed, fixed or communicated?Actively exploited vulnerability Is there evidence of real exploitation?Security incident Does it have a severe impact on product security or users?Personal-data incident Does it also require separate GDPR breach assessment?The risk runs both ways. Under-reporting a truly serious issue exposes the organisation. Reporting every unqualified bug creates noise and weakens response discipline. The decision should be documented even when the conclusion is that no report is required. The minimal runbook to prepare A useful runbook must be concrete. It should not merely say “notify legal”. It should allow the team to act in the first hours. 1. Component inventory List products, scripts, SDKs, plugins and connectors distributed or made available to customers. For each one, document the internal owner, repositories, build pipeline, update mechanism, exposed customers, critical dependencies and communication channels. 2. Qualification criteria Define a simple grid: whether security is affected, whether exploitation is observed, potential impact, customer scope, corrective measure availability, technical evidence and possible parallel obligations. 3. Decision team Identify who can qualify the event: engineering, security, product, leadership, legal and the DPO when personal data is involved. Backups should be known. Weekends and holidays should be covered. 4. Timestamping The deadline starts when the organisation becomes aware. The team must record when it had enough information to suspect or qualify the event. A ticket without a reliable timestamp will make compliance harder to demonstrate. 5. Evidence and logging Preserve logs, versions, build hashes, deployed artefacts, exploitation traces, customer messages, internal alerts and qualification decisions. The evidence should be sufficient to reconstruct the timeline. 6. Reporting channel The Single Reporting Platform is operated by ENISA. Teams should know who has the necessary access, which information is needed and what to do if the primary access path is unavailable. ENISA has indicated that there is no API planned at this stage, which makes human procedures even more important. 7. Customer communication Regulatory reporting does not replace customer communication. Prepare concise templates: what is known, what remains uncertain, what customers should do and when the next update will come. Analytics and third-party scripts An analytics script should be treated as a sensitive asset, even when it collects limited data. It may be embedded in public pages, conversion funnels or authenticated environments. The security of the script therefore matters not only to the vendor but also to the sites that install it. Concrete controls include:separation of rights between application code, build pipeline and script publication; dependency review; signing or integrity controls for artefacts where relevant; detection of unexpected changes; fast rollback capability; mitigation or disabling procedure; documentation of versions deployed to customers.These practices are useful beyond the CRA. They reduce operational risk and make crisis communication more reliable. What to decide now Teams that wait for the first incident to organise their response will lose time in the first 24 hours. Those are exactly the most constrained hours. By the end of September, a software team should be able to answer four questions:Which customer-distributed components could be in scope? Who qualifies an actively exploited vulnerability? Who can submit a notification within the deadline? How can the decision timeline be proven?If these answers do not exist, the topic is not yet under control. Conclusion The Cyber Resilience Act should not be reduced to a distant 2027 deadline. Reporting obligations applying from 11 September 2026 already require manufacturers in scope to prepare. For SaaS and analytics vendors, the priority is not to panic or to assume everything is automatically covered. The priority is to inventory components, qualify roles, prepare the runbook and document decisions. A good reporting process is not only a regulatory response. It is evidence of product maturity. FAQ Does the CRA apply to every SaaS dashboard? Not automatically. The qualification depends on the product, the role of the organisation and the way software components are placed on the market or provided. The article is a preparation checklist, not a legal classification of every SaaS case. Should every security bug be reported through the CRA process? No. The reporting duty discussed here concerns actively exploited vulnerabilities and severe incidents with a security impact, according to the CRA framework. Ordinary bugs still need internal handling, but they should not be confused with regulatory reporting triggers. Why should analytics teams care? Analytics stacks often include scripts, SDKs, API keys, client-side configuration and third-party dependencies. Even when the legal obligation falls elsewhere, teams need clear incident routing and supplier contacts. SourcesEuropean Commission - Cyber Resilience Act reporting obligations European Commission - Cyber Resilience Act summary ENISA - CRA Single Reporting Platform FAQ