NEW: CRA vulnerability reporting begins 11 September 2026 — is your product ready? Check now →

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.

Is Your Product CRA Ready?

Get a free personalised CRA compliance briefing for your specific product type — delivered to your inbox. No spam, no sales calls.

  • Understand your exact product category (default, Class I, or Class II)
  • Get a checklist of your specific obligations and deadlines
  • Receive guidance on SBOM, vulnerability management, and reporting
  • Early access to our CRA Compliance Manager tool (launching 2026)
  • Weekly CRA news digest — ENISA updates, regulatory guidance

Get Your Free CRA Brief

Takes 60 seconds · Completely free

🔒 No spam. Unsubscribe anytime. Processed in accordance with GDPR.