Your Name on a Licensed APK Makes You Its Manufacturer. The First CRA Deadline Is 11 September.

Licence Android games, ship them under your own brand, and the EU Cyber Resilience Act treats you as the manufacturer — not the studio that built the code. The first hard obligation lands on 11 September 2026, and most catalogue licensees have never seen a bill of materials for a single title they publish.

The arrangement is ordinary. You licence a few hundred Android titles, put your own icon and store listing on them, publish to Google Play or a carrier store, and the studio that actually wrote the code never appears anywhere a player can see it. That invisibility is the product. It is also, under Regulation (EU) 2024/2847, the precise fact pattern that turns a licensee into a manufacturer.

Almost nobody in game licensing is discussing this. The full regulation does not bite until December 2027, which is far enough away to feel like someone else's problem. The reporting obligations bite in three weeks.

📅 The September Date Is the Small One. That Is Why It Will Catch People.

The CRA entered into force on 10 December 2024 and applies in full from 11 December 2027. Between those two dates sit two staging posts: notification procedures for conformity assessment bodies from 11 June 2026, and vulnerability and incident reporting from 11 September 2026. The European Commission's own summary of the regulation lays out the schedule plainly.

What kicks in next month is narrow. Manufacturers who become aware of an actively exploited vulnerability in their product, or a severe incident affecting its security, must file an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days, through the CRA single reporting platform to their national CSIRT and ENISA.

Read the trigger carefully, because it is narrower than the panic suggests. Not every CVE. Not every dependency bump. Exploitation in the wild, or a severe incident. A match-3 game is not a router, and qualifying events across a casual catalogue will be rare.

The problem is not the volume. It is that a 24-hour clock assumes you can answer, in an afternoon, the question is that library in any of our builds? For a licensed catalogue, that question is usually unanswerable.

🏷️ "Manufacturer" Is a Label You Acquire by Branding, Not by Coding

The definition is the whole argument. Under the CRA, a manufacturer is a person who develops or manufactures products with digital elements, or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark — and the regulation adds "whether for payment, monetisation or free of charge."

Every clause in that sentence is aimed at you.

• "Has products designed, developed or manufactured." Commissioning a studio, or licensing finished builds and directing how they are packaged, is squarely inside this.
• "Markets them under its name or trademark." This is what white-label means. It is not an incidental branding choice; it is the operative fact.
• "Free of charge." An ad-funded portal app that costs the player nothing does not escape.

If you would rather be a distributor, the regulation closes that door too. Article 21 provides that an importer or distributor is considered a manufacturer, and becomes subject to the manufacturer obligations in Articles 13 and 14, where it places a product on the market under its own name or trademark, or carries out a substantial modification of a product already on the market. Article 22 catches anyone else who substantially modifies a product and makes it available.

Whether a reskin counts as a "substantial modification" is genuinely arguable — the test in Article 3(30) is whether the change affects compliance with the essential requirements or alters the intended purpose, and swapping an icon and an ad network key may not clear it. But you never have to reach that argument. The branding limb of Article 21 is unconditional. Your logo on the store listing is sufficient.

The studio that wrote the game is a manufacturer for whatever it places on the market itself. It is not a manufacturer for your build. Your only recourse against the licensor is contractual, and only to the extent you wrote it in. Most catalogue agreements say nothing at all.

🌐 The Browser Saves You. The Wrapper Does Not.

This is where the analysis splits, and where operators running both a web portal and an app are about to discover they have one catalogue with two regulatory statuses.

The CRA governs "products with digital elements" placed on the market. Standalone software that can be downloaded and installed — a mobile app from an app store, a program downloaded from a website — is caught. Software consumed purely through a browser, with no local installation and not presented to the market as a distinct product, is generally treated as a service rather than a product, and falls outside. DLA Piper's February 2026 analysis of the scope boundary puts it in exactly those terms, and the Commission's application guidance published on 27 July 2026 develops the position further, including on when remote data processing solutions are pulled in because they are essential to a product's core function.

Translated into catalogue terms:

• An HTML5 portal served from your domain, games running in iframes, nothing installed — generally outside scope.
• The same catalogue as an APK on Google Play, a carrier store, an alternative Android store or an OEM preload — inside.
• The same catalogue wrapped in a WebView shell, an Electron kiosk build, or a PWA shipped through an app store — installable, therefore a product, therefore inside. The games did not change. The delivery did.
• The back end behind an installed app — leaderboards, save state, the ad and consent stack — comes along with it where it is essential to how the product functions.

Most licence agreements grant "all platforms" or "web and mobile" in a single clause and are silent on the distinction. That clause is now the difference between a service you host and a regulated product you manufacture. If you are weighing an HTML5 catalogue against an Android one, this belongs in the comparison alongside eCPMs and store fees.

📋 An SBOM for Code You Have Never Seen

Annex I, Part II of the CRA requires manufacturers to identify and document the components and vulnerabilities in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies. In practice that means SPDX or CycloneDX. The SBOM sits in your technical documentation and goes to authorities on request; it does not have to be published.

That obligation is part of the December 2027 essential requirements, not the September 2026 reporting duty. But the two are joined at the hip, and the practitioner consensus across the compliance tooling world is blunt about it: you cannot answer a 24-hour exploitation report about a component you have not inventoried.

Now consider what you actually receive in a catalogue deal. A signed APK. Sometimes a minified, obfuscated build. The top-level dependencies of a typical licensed Android game are not exotic — engine runtime, ad mediation SDK, one or two ad network adapters, an attribution SDK, a crash reporter, an analytics library, a push service, a consent management platform — but you did not choose any of them, you are not told when they change, and a version bump inside the studio's build pipeline reaches you as a new APK with no changelog.

You can decompile and infer. That is a guess with a file listing attached, not documentation. The only durable answer is a delivery obligation: SBOM per title, per build, in a named format, refreshed on every update. Modern build tooling emits CycloneDX as a pipeline step, so it costs the licensor almost nothing.

⏳ A Five-Year Support Period Against a Twelve-Month Licence

Article 13(8) requires manufacturers to determine a support period during which vulnerabilities in the product, including in its components, are handled. The floor is five years, unless the product's expected lifetime is demonstrably shorter, and buyers must be told the end date — month and year — at the point of purchase.

Set that against how catalogue licences are actually written. A non-exclusive bulk licence commonly runs 12 months with renewal. A source-code deal is often perpetual but carries no obligation on the studio to ship you anything ever again. Either way, your right to receive a patched build has an expiry date that has nothing to do with how long your app stays installed on players' phones.

That leaves three honest positions:

1. Negotiate patch delivery that survives termination for titles already published, running to the support period you declare. This is the clean fix and it is not a big ask.
2. Declare a short support period and mean it — then pull the app at the end. Legitimate under the regulation if the lifetime genuinely is shorter, but a games app advertising a twelve-month support horizon is a commercial problem before it is a legal one.
3. Take source and the right to modify. This is what a source-code deal is for, and security maintenance is a better argument for buying one than the reskinning pitch usually made.

What is not a position: declaring five years because it is the default number, while holding a licence that ends in month twelve.

🔍 Six Clauses for the Next Renewal

None of this requires a new legal team. It requires six lines in a schedule that most catalogue agreements do not currently have:

1. SBOM delivery — per title, per build, SPDX or CycloneDX, regenerated on every update.
2. A named security contact at the licensor with a response window short enough to feed a 24-hour early warning. A shared sales inbox does not qualify.
3. Vulnerability notification flow-down — the licensor tells you when a component in a build already delivered to you is affected, rather than quietly fixing it in the next release.
4. Post-termination patch delivery for published titles, for the length of the support period you declare.
5. Step-in rights — if the licensor fails to patch within a defined window, you get source and the right to rebuild. Escrow logic, applied to security rather than insolvency.
6. A third-party component warranty — that the studio holds redistribution rights for every SDK and library in the build, with the list attached.

Ask for the ad SDK list as a separate line item. It is the component set most likely to change without anything else in the build changing, and it is the one Google will judge you on.

📱 Two More Deadlines Sitting in the Same Quarter

If the CRA still feels abstract, two Play Store rules make the same point in a language every publisher already understands: the obligation follows the person whose name is on the listing.

From 31 August 2026, new apps and app updates submitted to Google Play must target Android 16 (API level 36) or higher, with extensions available on request to 1 November 2026. Recompiling against a new target API is not something a licensee can do to a binary. It is done by whoever holds the source. If your licensor has moved on, that title is frozen at its last version — no updates, no fixes, no new ad SDK.

Separately, Google Play flags SDK versions with policy problems or known vulnerabilities, and the Play Console documentation is explicit that new app versions containing a flagged version cannot be released until the developer switches to a compliant one. Again: not your code, entirely your release blocker.

The scale of enforcement is not small. Google reported preventing over 1.75 million policy-violating apps from being published in 2025 and banning more than 80,000 developer accounts. A banned account is your account, not the studio's.

And Google's own developer policy has said for years what the CRA now says in EU law: if you include third-party code in your app, you are responsible for that code and for that third party's data practices, and you are responsible for the accuracy of the Data safety declaration covering everything the embedded SDKs collect. Whether that responsibility is realistic is a fair question — a 2023 study presented at ARES examined 400 popular apps and found none fully compliant with GDPR and ePrivacy consent requirements, with nearly half contacting third-party tracker domains before any consent was given, and earlier work by Kollnig and colleagues in 2021 found 71.3% of sampled Android apps contacting known tracker hosts at launch, before the user touched anything. Realistic or not, that responsibility sits with the publisher.

✅ What to Do Before 11 September

Three weeks is enough for the parts that matter, and none of them require a lawyer to start.

First, split your inventory. List every product you make available in the EU and mark each one installable or browser-only. The browser-only column is probably out of scope. The installable column is the work.

Second, write to every licensor whose titles are in that second column. Ask three questions: what are the top-level components in the builds you have shipped us, who do we contact about a security issue and how fast do they answer, and will you supply patched builds for titles we have already published if this licence lapses. The quality of the answers will tell you more about the licensor than any demo reel. A studio that can produce a component list in a week is a studio with a build pipeline. A studio that goes quiet is telling you what your support period can honestly be.

Third, decide and record your support period per product, and make sure the licence underneath it actually reaches that far. If it does not, fix it at the next renewal — this is the cheapest moment this clause will ever be, because right now it reads as housekeeping rather than as leverage.

Catalogue licensing has spent a decade competing on title count and price per game. The next round of differentiation is duller and more useful: which licensors can tell you what is inside the software they sold you. That question is now on a statutory timetable, and the people who have to answer it are the ones whose brand is on the icon.

🌲 Where This Touches Forestry Games

Forestry Games has licensed HTML5 and Android games since 2017 and develops HTML5 titles in-house, which means the questions above are answerable for a meaningful part of the catalogue rather than routed to a third party. If you are reviewing a catalogue or comparing licence terms with the CRA timetable in mind, raise the component and support-period questions during evaluation rather than after signature — they are far easier to negotiate before a term sheet exists.

Primary sources referenced above: the European Commission's summary of the Cyber Resilience Act (Regulation (EU) 2024/2847), DLA Piper's February 2026 analysis of the SaaS-versus-product boundary, and Google's Play Console target API level requirements.