The CRA cybersecurity risk assessment for mobile apps, with a template
Updated 9 November 2026 · 10 min read · Based on Regulation (EU) 2024/2847 and the Commission's CRA FAQ
Short answer: every app in scope needs a written cybersecurity risk assessment, and it decides how the rest of the CRA applies to that app.
- Article 13(2) requires manufacturers to assess the cybersecurity risks of each product and to use the result throughout planning, design, development, production, delivery and maintenance.
- Article 13(3) sets the minimum content: intended purpose, reasonably foreseeable use and conditions of use, expected length of use, and how each Annex I requirement applies.
- No method is prescribed. A threat model you can explain and defend is enough, as long as all relevant risks are covered and documented.
- If an Annex I, Part I requirement does not apply to your app, you must say why (Article 13(4)). The vulnerability handling requirements of Part II always apply during the support period.
- The assessment goes into the technical documentation, is updated during the support period and is kept for at least 10 years. The obligation applies from 11 December 2027.
What Article 13 requires
Article 13(1) of the Cyber Resilience Act obliges manufacturers to design, develop and produce products with digital elements in accordance with the essential cybersecurity requirements of Annex I, Part I. The risk assessment is the tool the regulation gives you to do that. Four paragraphs matter:
| Provision | What it says, in short |
|---|---|
| Article 13(2) | Assess the cybersecurity risks of the product. Take the outcome into account during planning, design, development, production, delivery and maintenance, with a view to minimising risks, preventing incidents and minimising their impact, including on users' health and safety. |
| Article 13(3) | Document the assessment and update it as appropriate during the support period. Set out its minimum content (see the next section). |
| Article 13(4) | Include the assessment in the technical documentation (Article 31 and Annex VII) when the product is placed on the market. Where an essential requirement does not apply, include a clear justification. |
| Article 13(7) | Systematically document relevant cybersecurity aspects, including vulnerabilities you become aware of and relevant information from third parties, proportionately to the product and its risks, and update the risk assessment where applicable. |
According to the Commission's CRA FAQ (section 4.1.1), the assessment applies to all products, whether default, important or critical, and covers the whole product, including its remote data processing solutions where they are in scope. For an app, that means the backend it cannot work without is part of the analysis, not only the code that ships to the phone. The FAQ also stresses that the assessment covers risk treatment across the lifecycle, not only the initial identification of risks.
The minimum content, applied to an app
Article 13(3) lists what the assessment must contain "at least". This is how each element translates for a typical mobile app:
| Article 13(3) element | What to write for a mobile app |
|---|---|
| Intended purpose | What the app is for and who uses it: for example, customers checking orders and paying, or field staff recording inspections. |
| Reasonably foreseeable use and conditions of use, such as the operating environment or the assets to be protected | Supported OS versions and devices, rooted or jailbroken phones, public Wi-Fi, shared devices, offline use. Assets: accounts and session tokens, personal data, payment flows, API keys, the backend itself. |
| Expected length of time the product will be in use | How long users realistically keep using a given version. This also feeds the support period under Article 13(8). |
| Whether and how Annex I, Part I, point (2) applies, and how it is implemented | One line per requirement (a) to (m): applies or not, why, and which measures implement it. See the table below. |
| How Annex I, Part I, point (1) is applied | How the overall level of security is made appropriate to the risks you identified. |
| How the vulnerability handling requirements of Annex I, Part II are applied | Your SBOM, remediation, testing, disclosure, contact address and update distribution, described for this app. |
The Commission FAQ (section 4.1.4) adds that you must look beyond the use you intend and consider how an average user might reasonably use the product. Where users can change settings in a way that removes security features, you must assess and treat that risk and warn users in the information required by Annex II, point 5. Section 4.1.5 treats reasonably foreseeable misuse, such as use on an insecure network, the same way.
No method is prescribed
The CRA does not mandate a specific methodology. The Commission FAQ (section 4.1.2) leaves the choice of method to the manufacturer, provided all relevant risks are addressed and documented so that market surveillance authorities can verify them. Threat models should fit the intended purpose and foreseeable use: a product for critical infrastructure may need to consider advanced persistent threats, while consumer products typically have a lower risk profile.
For most app teams, a structured threat model of the app, its backend and its third-party SDKs, with a likelihood and impact rating per threat and the chosen treatment, is a practical way to meet this. What matters is that the reasoning is written down and that each Annex I requirement is traced to it.
How the assessment decides which Annex I requirements apply
Annex I, Part I, point (2) says products shall meet its requirements "on the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable". The Commission FAQ (section 4.1.3) explains the consequence: the manufacturer decides from the assessment which of these requirements are relevant, while the vulnerability handling requirements of Part II apply throughout the support period.
The table lists the thirteen requirements, the question to answer for an app, and the OWASP MASVS control groups that are a practical place to look for concrete checks. The MASVS mapping is our own working aid, not an official correspondence; harmonised standards for the CRA have not yet been published.
| Annex I, Part I(2) | Question for your app | Where to look in MASVS |
|---|---|---|
| (a) No known exploitable vulnerabilities at release | Do any of the app's or backend's components have known vulnerabilities when you ship? | MASVS-CODE |
| (b) Secure by default configuration, with reset to original state | Are the defaults the safe ones? Can the user return the app to its original state? | MASVS-PLATFORM, MASVS-PRIVACY |
| (c) Vulnerabilities addressable through security updates | How do fixes reach users, and can you force or prompt an update when a fix matters? | MASVS-CODE |
| (d) Protection from unauthorised access, reporting of possible unauthorised access | Login, session handling, authorisation on the backend, detection of suspicious sign-ins. | MASVS-AUTH |
| (e) Confidentiality of stored, transmitted and processed data | Encryption at rest on the device, TLS to the backend, secrets in the app bundle. | MASVS-STORAGE, MASVS-CRYPTO, MASVS-NETWORK |
| (f) Integrity of data, commands, programs and configuration | Can data, requests or the app itself be modified without detection? | MASVS-NETWORK, MASVS-RESILIENCE |
| (g) Data minimisation | Does the app collect only what its intended purpose needs, including through SDKs? | MASVS-PRIVACY |
| (h) Availability of essential functions, resilience against denial of service | What happens to core functions when the backend is attacked or degraded? | Mostly backend design; outside MASVS |
| (i) Minimise negative impact on other devices or networks | Can the app or its backend be used to harm other services, for example through excessive requests? | Mostly backend design; outside MASVS |
| (j) Limit attack surfaces, including external interfaces | Exported components, deep links, WebViews, unused permissions and endpoints. | MASVS-PLATFORM |
| (k) Reduce the impact of incidents with exploitation mitigation | Platform hardening, least privilege for tokens, limiting what a compromised client can do. | MASVS-CODE, MASVS-RESILIENCE |
| (l) Record and monitor security-relevant internal activity, with a user opt-out | Which security events you log on the backend and in the app, and how users can opt out. | MASVS-PRIVACY (for what you log) |
| (m) Secure and easy removal of all data and settings, and secure transfer where possible | Can users delete their account and local data? Is data export protected? | MASVS-STORAGE, MASVS-PRIVACY |
The MASVS project describes its own profiles in the same spirit: applying them fully or partially is a risk-based decision, and deviations should be justified and documented. MASVS also assumes that threat modelling is already in place and does not replace it, so it supports your assessment rather than being one.
When a requirement does not apply
Article 13(4) requires a clear justification in the technical documentation for any essential requirement that is not applicable. The Commission FAQ (section 4.1.3) gives examples of valid reasons: the requirement is incompatible with the nature of the product, or there is no risk that it would mitigate. A product that does not process personal data for its intended use may not need the related safeguards; if misuse could still create significant risks, the user information must say so (Annex II, point 5).
Write the justification next to the requirement, in one or two sentences, and link it to the risk it relies on. "Not applicable" without a reason is the weakest possible answer to a market surveillance authority.
A template for a mobile app
This structure covers everything Article 13(3) asks for and fits into Annex VII, point 3 of the technical documentation. Keep one document per app, or per variant where variants differ in components or functions.
- Product and version. App name, platforms, version or version range covered, the backend services that are part of the product, and the date and author of this revision.
- Intended purpose and users. What the app does, who uses it, and in which context.
- Foreseeable use, conditions of use and misuse. Devices and OS versions, networks, rooted or jailbroken devices, shared phones, settings users can change, plausible misuse.
- Assets to protect. Accounts, credentials and tokens, personal data, payment flows, business data, the backend, signing keys.
- Expected length of use. How long a version stays in use, with the information you relied on. Cross-reference the support period you declare.
- Architecture and components. A short diagram or description of the app, backend and third-party SDKs, with a reference to the SBOM for this version.
- Threats and risk rating. One row per threat: description, affected asset, likelihood, impact, resulting risk.
- Risk treatment. For each risk: the measures taken, the residual risk, and whether users must be informed (Annex II).
- Annex I, Part I, point (1). A short statement of how the overall level of security matches the risks identified above.
- Annex I, Part I, point (2), requirements (a) to (m). For each one: applies or not, the justification if not, and the implementing measures and evidence (tests, reviews, configuration).
- Annex I, Part II, vulnerability handling. How you produce the SBOM, fix and release, test, disclose, receive reports and distribute updates for this app.
- Standards and specifications used. Anything applied in full or in part, such as OWASP MASVS, and what you did where none applies.
- Revision log. Date, what changed and why: new feature, new vulnerability, test result, third-party information.
Keeping it up to date
Article 13(3) requires the assessment to be updated as appropriate during the support period, and Article 13(7) requires you to update it where applicable when you document vulnerabilities and third-party information. The Commission FAQ (sections 4.1.6 and 4.1.8) adds that updates include those following regular tests and reviews, that user instructions should be updated to match, and that redesigns must be reflected in the documentation.
In practice, review the assessment at each release that changes features, permissions, SDKs or backend interfaces, after each security test, and whenever a vulnerability or advisory affects one of your components. A dated revision log makes these reviews visible.
Where it lives and for how long
| Point | Rule |
|---|---|
| Part of the technical documentation | Article 13(4) and Annex VII, point 3: an assessment of the risks against which the product is designed, developed, produced, delivered and maintained, including how Annex I, Part I applies. |
| Ready before release | Technical documentation is drawn up before the product is placed on the market (Article 13(12), Article 31). |
| Retention | At least 10 years after placing on the market, or the support period if that is longer (Article 13(13)). |
| Combined assessments | One assessment may serve several EU laws, or each law may have its own, as long as you can show compliance with each (Commission FAQ 4.1.1; Article 13(4) for products also subject to other Union acts). |
| Harmonised standards | They do not replace the assessment. You remain responsible for checking that a standard covers all the risks of your product (Commission FAQ 4.1.7). |
The obligations of Article 13 apply from 11 December 2027. Apps released before then and still being updated are worth assessing early, because the work feeds the support period, the SBOM and the technical documentation at the same time.
What app teams should do now
- Pick one app and fill in the template above for its current version. The first one takes the longest; the rest reuse most of the structure.
- Generate an SBOM for that version, so the component and vulnerability sections rest on facts rather than memory.
- Decide which party is the manufacturer and therefore owns the assessment: see agency or client: who is the manufacturer?
- Record the expected length of use and use the free support period calculator for the related dates.
- Add a review of the assessment to your release checklist.
Start the component part of your assessment: see what is inside one of your apps and whether any dependency has known vulnerabilities.
Open the free scannerSources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: Article 13(1)–(4), (7), (12), (13), Annex I and Annex VII. Text consulted via the SpringLex consolidated reader (Annex I, Annex VII).
- European Commission, FAQs on the Cyber Resilience Act, section 4.1: risk-based approach and risk assessment, as published by the Open Regulatory Compliance Working Group. Commission staff work, not legally binding.
- European Commission: guidance to support the implementation of the CRA, C(2026) 5252, 27 July 2026, which also covers risk assessment requirements.
- OWASP Mobile Application Security Verification Standard (MASVS) and Using the MASVS.
This guide summarises EU law and non-binding Commission material for practical use. It is not legal advice. Related: Does the CRA apply to mobile apps? · Who is the manufacturer? · CRA vulnerability reporting · SBOM for Flutter apps · SBOM for React Native apps.