Short answer: Annex I, Part I has one general requirement and thirteen specific ones, and for an app each can be turned into a concrete check you can run before every release.
- Annex I, Part I point (1) asks for an appropriate level of cybersecurity based on the risks. Point (2), requirements (a) to (m), applies on the basis of your risk assessment and where applicable.
- The requirements apply from 11 December 2027 (Article 71(2)). The reporting duties of Article 14 apply earlier, from 11 September 2026.
- OWASP MASVS is a useful source of concrete checks, but it is not a harmonised standard: it gives no presumption of conformity under Article 27(1). The mapping below is our own working aid.
- Two requirements, (h) availability and (i) impact on other networks, are mostly about backend and client design and sit largely outside MASVS.
What Annex I, Part I says
Article 13(1) of the Cyber Resilience Act requires manufacturers to ensure that a product with digital elements has been designed, developed and produced in accordance with the essential cybersecurity requirements of Part I of Annex I. Point (1) of that Part says products must be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks. Point (2) then lists thirteen requirements, (a) to (m).
Two things follow for an app team. First, the requirements describe outcomes, not technologies: the text says, for example, “state of the art mechanisms” for encryption, not a named algorithm. Second, point (2) applies “on the basis of the cybersecurity risk assessment” and “where applicable”, so the assessment is where you decide, and justify, how each requirement is met. See our guide on the CRA cybersecurity risk assessment.
Why MASVS, and what it is not
Under Article 27(1), a product that conforms to harmonised standards whose references have been published in the Official Journal is presumed to conform to the Annex I requirements those standards cover. As far as we have been able to verify, none has been cited yet for the Part I requirements; see our news item on the first EN 40000 standards.
Until then, app teams need something concrete to check against. The OWASP Mobile Application Security Verification Standard (MASVS) is a mobile-specific list of security controls, organised in groups: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and, since version 2.1.0, PRIVACY. Its controls are written as statements such as “The app securely stores sensitive data” (MASVS-STORAGE-1) or “The app only uses software components without known vulnerabilities” (MASVS-CODE-3).
MASVS was not written for the CRA, and nothing in the regulation refers to it. Meeting MASVS controls does not mean you meet Annex I, and meeting Annex I may need more than MASVS covers. Treat it as a checklist generator that you cite in your technical documentation as a specification you applied, together with what you did where it does not reach.
The checklist: Annex I, Part I, point (2)
For each requirement, the table gives the Annex I wording in short, checks an app team can run, and the MASVS controls to read. The checks and the mapping are our own working aid and are not an official correspondence. Record the result per app version.
| Annex I, Part I(2), in short | Checks for an app | MASVS controls to read |
|---|---|---|
| (a) No known exploitable vulnerabilities at release | Run a dependency scan on the release build's SBOM and on the backend before every release; block the release on known exploitable findings you have not triaged; record the result for that version. | MASVS-CODE-3 |
| (b) Secure by default, reset to original state | List every setting with a security effect and check its default; check what “reset” or “log out and clear” returns the app to; test a fresh install with no changes. | MASVS-PRIVACY-1, MASVS-PLATFORM |
| (c) Vulnerabilities fixable by security updates | Define how a fix reaches users (store release, remote configuration, backend fix); test a forced-update or update-prompt path for old versions; decide whether security updates can ship separately from feature updates. | MASVS-CODE-1, MASVS-CODE-2 |
| (d) Protection from unauthorised access; reporting of possible unauthorised access | Authenticate with established protocols; enforce authorisation on the server, never only in the app; protect sensitive operations with extra authentication; log failed and suspicious sign-ins on the backend. | MASVS-AUTH-1, MASVS-AUTH-2, MASVS-AUTH-3 |
| (e) Confidentiality of stored, transmitted or processed data | Inventory what the app stores locally and where; use the platform's secure storage for secrets and tokens; no secrets in the app bundle; TLS for all traffic; check logs, backups and screenshots for leaks of sensitive data. | MASVS-STORAGE-1, MASVS-STORAGE-2, MASVS-CRYPTO-1, MASVS-CRYPTO-2, MASVS-NETWORK-1, MASVS-NETWORK-2 |
| (f) Integrity of data, commands, programs and configuration; reporting of corruption | Validate and sanitise untrusted input; verify server responses and signed configuration; decide, from your risk assessment, whether to detect a tampered app or an untrusted platform and what the app does when it does. | MASVS-CODE-4, MASVS-NETWORK-1, MASVS-RESILIENCE-1, MASVS-RESILIENCE-2 |
| (g) Data minimisation | List every data item the app and its SDKs collect and the purpose of each; remove what the intended purpose does not need; request permissions only when needed. | MASVS-PRIVACY-1, MASVS-PRIVACY-2, MASVS-PRIVACY-3 |
| (h) Availability of essential and basic functions, also after an incident | Define the essential functions; test the app when the backend is slow, unreachable or rate-limiting; plan degraded or offline behaviour; load-test the backend the app depends on. | Mostly backend design; no direct MASVS group |
| (i) Limit negative impact on other devices or networks | Check retry and polling behaviour so that a failure cannot turn the app into a request flood; cap background activity and request rates. | Mostly backend and client design; no direct MASVS group |
| (j) Limit attack surfaces, including external interfaces | List exported components, deep links, custom URL schemes, WebViews and open ports; remove what is unused; restrict what remaining entry points accept; review requested permissions. | MASVS-PLATFORM-1, MASVS-PLATFORM-2, MASVS-PLATFORM-3 |
| (k) Reduce the impact of an incident with exploitation mitigation | Use short-lived, least-privilege tokens; keep a compromised client from reaching other users' data; keep platform exploit mitigations enabled in the build settings; separate secrets per environment. | MASVS-CODE, MASVS-RESILIENCE |
| (l) Record and monitor security-relevant activity, with a user opt-out | Decide which security events you log (access to or modification of data, services or functions); keep personal data out of logs; give users a clear way to opt out where logging relates to them. | MASVS-PRIVACY-3, MASVS-PRIVACY-4 (for what you record) |
| (m) Secure, easy and permanent removal of all data and settings; secure transfer | Offer in-app account and data deletion that also covers the backend; clear local data on sign-out or reset; protect any data export or transfer to another product. | MASVS-STORAGE, MASVS-PRIVACY-4 |
Point (1): the overall level
Point (1) is not a checklist item. It asks that the overall level of cybersecurity is appropriate to the risks. The practical way to show it is a short statement in the risk assessment that connects the threats you identified to the measures in the table above, and says why the residual risk is acceptable for this app.
Checks that cut across several requirements
- Components. Article 13(5) requires due diligence when integrating components from third parties, and Article 13(6) requires you to report a vulnerability you find in a component to whoever makes or maintains it. An SBOM per release makes requirement (a) checkable. See SBOM for Flutter apps and SBOM for React Native apps.
- The backend. The remote data processing solutions an app cannot work without are part of the product (see does the CRA apply to mobile apps?). Authorisation, logging, availability and data deletion mostly live there.
- Evidence. For each check, keep what proves it: a test result, a review note, a configuration file, a scan report, with the app version and date.
How to use this in practice
- Copy the thirteen rows into the “Annex I, Part I, point (2)” section of your risk assessment, one per app.
- For each row, write “applies” or “does not apply”, and a one- or two-sentence justification when it does not (Article 13(4)).
- For each applicable row, pick the checks, assign an owner and decide when they run: on every build, on every release, or after major changes.
- Read the MASVS controls listed for each row and note which you apply in full, in part or not at all, and why.
- Store the results with the technical documentation for that version, and update them when features, SDKs or backend interfaces change.
Try it on your own app: the free Shipmark scanner builds a CycloneDX SBOM from a lockfile in the browser and checks it against OSV.dev. Not sure the CRA applies? Use the six-question CRA check.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: Articles 13, 27, 71 and Annex I, Part I. Text read through the LawPlayer copy of the regulation.
- Independent guide to Regulation (EU) 2024/2847: Annexes, used to cross-check the summary of Annex I.
- OWASP MASVS and the OWASP MASVS releases (version 2.1.0 and the PRIVACY group).
- Fluid Attacks database of MASVS controls, used for the control statements.
- OWASP Developer Guide: MAS requirements, for the list of MASVS groups.
This guide summarises EU law and a voluntary security standard for practical use. The MASVS mapping is our own and not an official correspondence. It is not legal advice. Related: CRA risk assessment template · Disclosure policy · Does the CRA apply to apps? · First EN 40000 standards.
Originally published on shipmark.eu, where the guide is kept up to date. More guides for app teams: shipmark.eu/guides.
Top comments (0)