By: TitApeX BoHan /October 23, 2026

The EU Now Wants a Call Within 24 Hours: What the Cyber Resilience Act Means Before You Commission an App or Connected Product

If your app, connected device or desktop software is sold in Europe, 11 September 2026 is a date worth remembering. From that day, the reporting obligations of the EU Cyber Resilience Act (CRA) took effect: when a product has a vulnerability that is being actively exploited, the manufacturer must file an early warning within 24 hours. ENISA, the EU cybersecurity agency, switched on a single reporting platform the same day. This is not distant regulatory news. It directly changes how you should commission software and what goes into your development contract.

Who the Cyber Resilience Act covers: not just hardware, apps too

A product designer in a bright studio holds a smartphone and a small connected home device, checking how they work together

The CRA applies to "products with digital elements" — hardware and software that connects to a network, directly or indirectly. Ireland's National Cyber Security Centre lists examples such as laptops, smart devices, operating systems, mobile apps and industrial IoT.

Three points are often misunderstood:

It is not only for European companies. What matters is whether the product is made available on the EU market, not where the company is based. A Taiwanese or American brand selling into Europe needs to take this into account.
Older products must report too. Products placed on the market before December 2027 are exempt from the new design rules, but if they are still on sale in the EU, the reporting obligations apply in full.
Pure cloud services need a case-by-case view. Typical online services are mostly handled by other rules, but a cloud backend that an app or device needs in order to work may be pulled into scope. Have legal counsel or an adviser confirm this for your product.

The full security-by-design requirements only apply from 11 December 2027. The "report when it happens" part has already started.

24 hours, 72 hours, 14 days: how the reporting clock runs

A security engineer types an urgent incident report late at night, a phone alert lying beside the laptop

According to the process summarised by Ireland's NCSC, reporting has three stages:

Early warning (within 24 hours): after becoming aware of an actively exploited vulnerability or a severe incident affecting product security, send a baseline notice without waiting for a full technical analysis.
Detailed notification (within 72 hours): add the initial severity assessment, likely cause and temporary mitigations.
Final report: for exploited vulnerabilities, within 14 days after a fix or workaround is available; for severe incidents, within one month of the detailed notification.

All reports go through ENISA's Single Reporting Platform, which routes them to the coordinating national CSIRT. Email is only a fallback when the platform is officially declared offline.

The hard part is not the form. It is the 24 hours. Knowing within a day which product, which version and how many users are affected only works if you already have that information on hand. Many brands outsource their app, then stop asking questions after launch. When something breaks, they have to start by asking the vendor which third-party components were even used. There is simply not enough time for that.

Four questions to ask before you commission development

If you are planning an app or connected product that will be sold in Europe, add these four questions to the brief alongside price and timeline:

1. Is there a component inventory?

Modern software relies heavily on open-source packages and third-party components. The CRA also says that when a third-party component is the problem, the final product's manufacturer must report once it confirms its product is affected. You need a clear component list (often called an SBOM) for every release, so you can tell within hours whether you are exposed.

2. Where do vulnerability reports come in?

Security researchers and users need a way to reach you. Is there a fixed security contact on your website? Who decides how severe a report is? Design this path before launch.

3. Can updates reach users quickly?

A fix only helps once it is delivered. Forced app updates and over-the-air firmware updates belong in the first version of the spec, not as an afterthought.

4. Who picks up the phone at midnight?

The 24-hour clock ignores office hours. Agree in advance on your vendor's response time, contact person and hand-off process during the maintenance period.

These questions complement a regular code security review. If you have not read it yet, pair this with "It Runs, But Is It Safe? Four AI Code Security Questions to Ask Before Commissioning Custom Software".

Between brand and vendor: put the responsibilities in the contract

A brand manager and a software vendor representative sign a development contract at a conference table

Under the CRA, the duty to report sits with the "manufacturer" — the party that places the product on the market under its own name. For most brands, that responsibility stays with the brand even when the code was written by a vendor.

At a minimum, the contract should spell out:

Security response times during maintenance: for example, how many hours the vendor has to deliver an impact assessment after an exploited vulnerability is found.
Delivery and upkeep of the component inventory: updated with every release and handed over to the brand.
Support period: security updates should be supported for as long as the product is on sale. Being transparent with users about support periods is itself a CRA priority.
Reporting roles: who files on the platform, who provides the technical data and who speaks publicly.

AI makes writing code faster every month. But deciding who is responsible and how fast they respond when something goes wrong is not something a tool can do for you.

Conclusion: treat reporting readiness as part of the product

A product team tests a connected device and its smartphone app together at a studio workbench

The message of the Cyber Resilience Act is clear: software is not finished at delivery; it has to be looked after for as long as it is sold. For brands, that is also an opportunity. Designing component management, update mechanisms and response processes in from day one makes a product steadier in the European market and easier for retailers and enterprise customers to trust.

When TitApeX plans custom systems and apps, we put these operational requirements into the blueprint alongside the interface design. If your product is heading for Europe, let's talk, or take a look at our services.