Guide · 15 Apr 2026 · 12 min read
CRA for mobile app developers: a practical guide
What Android and iOS developers actually need to do to comply with the EU Cyber Resilience Act — from SBOM and CE marking through to vulnerability disclosure.
If you publish an Android or iOS app and EU users can install it, the EU Cyber Resilience Act (CRA) applies to you. The good news is that almost every mobile app sits in the default category and can self-assess. The less-good news is that “self-assess” still means producing real artefacts: a Software Bill of Materials, a Declaration of Conformity, a vulnerability-disclosure policy, and a documented security update mechanism.
This guide is the shortest path from “we ship a mobile app” to “we are CRA-ready by 11 December 2027”.
1. Confirm you’re in scope
If you tick all of these, you are in scope:
- The app is software with a network connection (direct or indirect)
- It is placed on the EU market — i.e. installable from EU app stores or via direct distribution to EU users
- There is commercial intent — sales, ads, paid features, sponsored development
Free apps from a registered company are in scope. Hobby projects published on F-Droid or GitHub from an individual maintainer typically are not.
2. Classify the app
Most apps are default-category products. You self-assess against the 21 essential requirements in Annex I.
A subset of apps falls into Class I — Important. The triggers most likely to catch a mobile app:
- Identity-management functionality (a password manager, an SSO client)
- Network management (a VPN client, a router-companion app)
- Privacy tooling that markets itself on cybersecurity properties
If you are Class I, you can still self-assess — but only if you fully apply the relevant harmonised standards. Without those, you need a notified body.
3. Generate an SBOM in CI
This is non-negotiable. Use CycloneDX unless you have a strong reason not to. Output the SBOM on every build, store it alongside the artefact, and treat it as audit evidence.
For Android, cyclonedx-gradle-plugin does the job. For iOS, the SBOM is more painful — Xcode does not produce one natively, but cyclonedx-cli plus a Package.swift introspection step works. Capture both first-party code and bundled SDKs.
4. Publish a vulnerability-disclosure policy
The CRA requires a way for security researchers to report vulnerabilities. The bare minimum is a /.well-known/security.txt file on your marketing domain plus a triage email or form. Define internal SLAs: time-to-acknowledge, time-to-triage, time-to-fix. You don’t need to be Apple — you do need to be reachable and responsive.
5. Wire up a security update mechanism
App-store distribution does most of the work for you, but be explicit about it in your technical documentation. Document:
- That security updates ship through the platform’s standard update channel
- Your typical end-to-end SLA from triage to released update
- How users learn that an update contains a security fix
- Your plan for end-of-support windows (the CRA expects support throughout the product lifetime)
6. Draft the Declaration of Conformity
Use the template in Annex V of the regulation. Required fields: product description, manufacturer details, statement of compliance with Regulation 2024/2847, conformity-assessment procedure, harmonised standards applied, signatory and date.
Publish it as a versioned PDF on your marketing site (/legal/cra-doc-v1.pdf) and link it from the app store listing or the in-app About screen. CE marking for software lives in those documents — not on a sticker.
7. Register with the ENISA SRP before September 2026
Reporting obligations begin 11 September 2026. From that date, an actively exploited vulnerability or a severe incident triggers the 24h / 72h / 14d timeline. You don’t want to be reading SRP docs at 3 a.m. — register the manufacturer profile in advance, run a tabletop exercise, decide who has authority to file.
TL;DR for mobile-app teams
- Most apps: default category, self-assess
- Generate SBOM in CI on every build
- Publish a security.txt + triage process
- Draft the DoC against Annex V
- CE-mark via app-store listing and in-app docs
- Register on the ENISA SRP before September 2026
- Be ready by 11 December 2027
If any of this feels heavy, that is what the Compliance Manager is for — but you can absolutely do it yourself.