Mobile-First Companies Have the Most to Lose Under the Cyber Resilience Act, and the Most to Gain

Since 11 September 2026, an actively exploited flaw in your app starts a 24-hour reporting clock under the EU's Cyber Resilience Act. That's expensive if you don't know what's running, and an edge if you do.

For most companies, an app is a channel. For a mobile-first company, it is the business: the bank branch, the checkout counter, the boarding gate, the clinic waiting room.

Until this year, however, the law mostly treated it like a channel. The EU's Cyber Resilience Act (CRA) ends that, because it treats your app as a product with digital elements, regulated on the same footing as a router or a smart lock.

And part of it is already live. Since 11 September 2026, if a vulnerability in your app is being actively exploited, the clock to notify regulators starts the moment you become aware.

That will hurt some teams. Yet it is also, quietly, the most useful thing to happen to mobile app security in years.

Both are true, and which one you feel depends on what you do between now and December 2027. So here is the honest version of both sides.

The short answer: The Cyber Resilience Act applies to mobile apps offered to EU users. Since 11 September 2026, their manufacturers must report actively exploited vulnerabilities and severe incidents within 24 hours, and from 11 December 2027 those apps must ship without known exploitable vulnerabilities and with a software bill of materials.

Key takeaways

• Mobile apps on the EU market are products with digital elements under the CRA, wherever the company that makes them is based.
• Reporting has applied since 11 September 2026: an early warning within 24 hours, a notification within 72 hours and a final report after that.
• The rest of the CRA, including the SBOM and "no known exploitable vulnerabilities" rules, applies from 11 December 2027.
• Mobile teams feel it most, because they can't recall an app, they ship third-party SDKs and they run lean AppSec teams.
• Teams that know what is live, what is inside and what is exploitable can turn the CRA into a budget line and a sales argument.

What changed on 11 September, in brief

The CRA has been law since December 2024, and most of it applies from 11 December 2027. One part was pulled forward: the reporting obligations in Article 14 of the regulation, which have applied since 11 September 2026.

Here is what that reporting duty asks of a manufacturer:

• What to report: actively exploited vulnerabilities in the product, and severe incidents affecting its security.
• Where: through ENISA's Single Reporting Platform, to the national CSIRT designated as coordinator, with ENISA notified at the same time.
• How fast: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a fix being available (for vulnerabilities) or within one month (for incidents).
• Which apps: every in-scope product on the EU market, including versions released long before September. Exploitation a manufacturer already knew about before 11 September does not need to be reported retroactively, according to ENISA.
• What it costs to get wrong: fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, under Article 64.

Design note: turn the 24-hour, 72-hour and final-report deadlines into one timeline graphic. Alt text: "Cyber Resilience Act reporting timeline for mobile apps: 24-hour early warning, 72-hour notification, final report."

Is your app in scope? Almost certainly, if EU users can download it. The Commission's guidance of 27 July 2026 treats a downloaded smartphone app as a product with digital elements. It also counts the backend the app relies on as part of the product, when that backend is built by or for the manufacturer.

Moreover, that guidance works through a mobile banking app as one of its examples. By contrast, browser-only web apps, informational websites and products under their own regimes, such as medical devices and vehicles, sit outside the CRA.

Are you the manufacturer? If the app goes onto the EU market under your name, yes, wherever your headquarters are. A bank in Dubai, a travel platform in Singapore or a fintech in Austin with EU users is in the same position as a startup in Berlin.

Where it hurts: why the CRA bites harder when you are mobile-first

You cannot recall an app

A web team ships a fix and every user has it on the next page load. A mobile team ships a fix and waits: for store review, for the staged rollout, for the user who switched off auto-updates two years ago.

As a result, your "current" app is really a spread of versions across devices, regions and stores, and the exploited flaw may live in one you stopped thinking about long ago. The first hours of any report go to a question web teams never have to ask: which versions are still out there?

You are reporting on code you did not write

Analytics, payments, crash reporting, authentication, ads. A modern app is assembled as much as it is written, and every SDK in the bundle is now part of your product in the eyes of the regulator.

So when one of them is exploited through your app, it is your name on the report. From December 2027, you are also expected to tell the component's maintainer.

Twenty-four hours meets a two-person team

Many mobile-first companies run AppSec with a handful of people and no formal product security incident response team. The early warning is short, but it is not empty.

Even so, you need enough confidence that the exploitation is real, and enough clarity about where the affected app is available, to file something defensible. Doing that across a weekend, with a release in flight, is a different job from triaging tickets.

The duty outlives the app

Vulnerability handling is tied to the support period you declare. The Commission's guidance, however, indicates that the reporting duty continues while older versions remain on the market.

That means sunsetting an app does not close your exposure while old versions are still installed on phones in the EU.

Ambiguity is the default until 2027

The harmonized standards that will define "done" are still being written: as of October 2026, none has been cited in the Official Journal. Meanwhile, the Commission's guidance is non-binding, though market surveillance authorities are likely to lean on it.

For now, there is no certificate for "ready." There is only evidence that you behaved like a manufacturer who took it seriously.

The clone question nobody has answered

Fake and repackaged apps carrying your brand are a fact of life for any successful mobile product. Whether an exploited fake app triggers your reporting duty is not something the regulation answers cleanly, since it is not your product.

But your users will not make that distinction, and neither will the press. It belongs in your runbook before it belongs in a headline.

Where it pays off: what mobile-first companies gain

App security finally gets a budget line

In many companies, mobile testing is still an annual pen test, often bundled into a web engagement. The CRA turns it into a named regulatory exposure with a fine tied to global turnover.

That is a risk the CISO owns and the board will ask about. As a result, the case for investment shifts from "good engineering hygiene" to "this is our exposure, and this is what it costs to close it," and that case is far easier to win.

Readiness becomes a sales argument

EU banks, insurers and telcos that partner with or distribute your app will start asking how you handle CRA reporting. They will ask in the same security questionnaires that already slow your deals, much as they did for DORA.

So the companies that answer cleanly, with an inventory, an SBOM and a named process, will move through procurement faster. The ones still drafting a policy will wait.

It forces the inventory you needed anyway

Every app, every live version, every SDK in each of them. Most organizations cannot produce that list today, and it was a problem long before Brussels wrote it down.

In that sense, the CRA simply removes the option of not knowing.

The CRA asks a different question

This is the shift that matters most, and it is easy to miss. The September trigger is not a high score on a scanner report; it is an active exploitation.

Likewise, from December 2027, products must ship without known exploitable vulnerabilities. In other words, the regulation asks "is this real, and can it be reached?" before it asks "how bad would it be?"

Consider a team sitting on 400 open "high" findings with no view of which ones are reachable: it will struggle to answer that in 24 hours. The CRA gives security leaders formal cover to triage by what is real and reachable, and to stop treating the size of the backlog as the measure of risk.

The SBOM stops being paperwork

From December 2027, manufacturers must draw up a software bill of materials in a machine-readable format, covering at least the app's top-level dependencies. Built properly, per build and tied to each released version, it turns "are we affected?" from a two-day investigation into a lookup.

Better still, it doubles as one of the most persuasive documents you can hand to a customer's security team. It doesn't have to be public, but market surveillance authorities can ask for it.

Turning the cost into an advantage

Every pain point above traces back to four things a mobile-first company needs to know quickly. Get these right and the 24-hour clock becomes a process, not a scramble.

1. Know what is live

Answers: you cannot recall an app; the clone question.

Keep an inventory of every app and version available in public stores, including regional listings and third-party stores, refreshed on a set schedule. Flag versions that were never tested and listings impersonating your brand.

Then pair it with a minimum-supported-version policy and a forced-update path, so you can shrink the spread when it matters.

How we approach it: At Appknox, a mobile application security platform, Storeknox ⚑ (Product: add "(in beta)" here if confirmed) watches the app stores for your apps, unscanned versions and fake apps. That way, the version question has an answer before anyone asks it.

2. Know what is inside

Answers: code you did not write; the SBOM requirement.

Generate an SBOM for every build you release and store it against that version. When a component is reported as exploited, you search rather than investigate.

How we approach it: Appknox generates an SBOM from each app binary it scans. As a result, the bill of materials and the version it describes never drift apart.

3. Know what is exploitable

Answers: twenty-four hours; the different question.

Triage findings by reachability and proof of exploitation, with steps to reproduce, rather than by score alone. Track exploitable findings separately from the severity backlog, and make them the release gate.

How we approach it: KnoxIQ ⚑ (Product: confirm GA, or label it) validates SAST and DAST findings, prioritizes them by exploitability and adds remediation guidance. That way, teams act on what is real first.

4. Know who decides

Answers: the small team; the ambiguity.

Name a reporting owner and a deputy with the authority to file. Agree in advance what counts as "active exploitation" for your products, who brings in legal, and which fields of the report can be pre-drafted.

None of this needs a tool. All of it, however, needs to exist before the first report arrives.

What to do this quarter

Here are eight steps to put in place before the next exploited flaw starts your clock:

1. List every app you make available in the EU, including white-label and regional builds, and confirm which legal entity is the manufacturer.
2. Name a reporting owner and a deputy, and give them the authority to file without waiting for a meeting.
3. Set up access to ENISA's Single Reporting Platform and confirm which national CSIRT coordinates for you.
4. Pull a live-version inventory from the stores and your own analytics, and set a minimum supported version.
5. Generate an SBOM for every version still in meaningful use.
6. Add exploitability triage to your release gate, and report reachable findings separately from severity counts.
7. Publish a clear way for researchers to report vulnerabilities to you, such as a disclosure policy and a security contact (a security.txt file is one common way). The CRA expects a coordinated vulnerability disclosure policy from December 2027, but the reports it brings in will start your clock today.
8. Run a tabletop exercise against the 24-hour, 72-hour and 14-day timeline, with legal in the room.

The asymmetry

The CRA will be the bane of companies that treat September as a filing obligation. They will meet the 24-hour clock with a spreadsheet and a guess.

For everyone else, it is the first time the law has asked the question mobile security teams have been asking for years. Not "how bad is this?" but "is it real, and where is it running?"

December 2027 is fourteen months away. That is enough time to be on the right side of this, if you start with what is live.

See where one of your apps stands before the clock does. In a demo, we'll show you how Appknox maps live store versions, builds an SBOM for each release and puts exploitable findings first. Book a CRA readiness demo

Cyber Resilience Act FAQ

Does the Cyber Resilience Act apply to mobile apps?

Yes. The Commission's July 2026 guidance treats a downloaded smartphone app as a product with digital elements. If the app is offered to EU users under your name, you are its manufacturer under the CRA, wherever your company is based.

When do CRA reporting obligations start?

They have applied since 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, while most other CRA obligations apply from 11 December 2027.

How fast must you report an exploited vulnerability under the CRA?

An early warning is due within 24 hours of becoming aware, and a notification within 72 hours. A final report follows within 14 days of a fix being available, or within one month for a severe incident.

Does the CRA require an SBOM for mobile apps?

Yes, from 11 December 2027. Manufacturers must draw up a software bill of materials in a machine-readable format that covers at least the top-level dependencies, and market surveillance authorities can request to see it.

Who reports when a third-party SDK is exploited through your app?

You do, if the exploited flaw affects your app. From December 2027, you must also tell the SDK's maintainer about vulnerabilities you find in it.