Shipmark Join the free beta
How it works

Free tools

SBOM scanner SBOM checker Does the CRA apply? Annex I checklist Reporting deadlines security.txt generator Support period GitHub Action

Learn

Guides CRA news Pricing FAQ Join the free beta

Shipmark / Free tools

CRA Annex I checklist for mobile apps

The essential cybersecurity requirements of the Cyber Resilience Act, one by one, for one app version: status, evidence and a report you can keep.

Annex I of the Cyber Resilience Act has two parts. Part I lists the security properties a product must have: thirteen requirements, (a) to (m), that apply on the basis of your risk assessment and where applicable. Part II lists eight vulnerability handling duties for the manufacturer. They apply from 11 December 2027 (Article 71(2)). Go through each one, mark where the app stands, note the evidence, and export the result.

Everything stays in your browser: nothing you enter is sent or stored. Closing the page clears it, so download the JSON file to continue later.

The app version

Part I: security properties of the app

Point (1) asks for an appropriate level of cybersecurity based on the risks. Point (2) lists the requirements below. Where one does not apply to your app, Article 13(4) asks for a clear justification in the technical documentation, so the checklist asks you to write one.

(a) No known exploitable vulnerabilities at release

Made available on the market without known exploitable vulnerabilities.

Checks for an app
  • 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 scan result for that version.

MASVS controls to read: MASVS-CODE-3

(b) Secure by default, with a reset to the original state

Made available with a secure by default configuration, including the possibility to reset the product to its original state (unless otherwise agreed for tailor-made products).

Checks for an app
  • List every setting with a security effect and check its default.
  • Check what reset, or sign out and clear data, returns the app to.
  • Test a fresh install with no changes.

MASVS controls to read: MASVS-PRIVACY-1, MASVS-PLATFORM

(c) Vulnerabilities can be fixed through security updates

Vulnerabilities can be addressed through security updates, including, where applicable, automatic updates that are on by default, with a clear and easy opt-out, user notification and the option to postpone.

Checks for an app
  • Define how a fix reaches users: store release, remote configuration or backend fix.
  • Test the forced-update or update-prompt path on an old version.
  • Decide whether security updates can ship separately from feature updates.

MASVS controls to read: MASVS-CODE-1, MASVS-CODE-2

(d) Protection from unauthorised access

Protection from unauthorised access by appropriate control mechanisms, such as authentication, identity or access management systems, and reporting of possible unauthorised access.

Checks for an app
  • 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 controls to read: MASVS-AUTH-1, MASVS-AUTH-2, MASVS-AUTH-3

(e) Confidentiality of stored, transmitted and processed data

Protect the confidentiality of stored, transmitted or otherwise processed data, for example by encrypting it with state of the art mechanisms.

Checks for an app
  • Inventory what the app stores locally and where.
  • Use the platform's secure storage for secrets and tokens; no secrets in the app bundle.
  • Use TLS for all traffic.
  • Check logs, backups and screenshots for leaks of sensitive data.

MASVS controls to read: 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

Protect the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against unauthorised manipulation or modification, and report corruptions.

Checks for an app
  • 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 then.

MASVS controls to read: MASVS-CODE-4, MASVS-NETWORK-1, MASVS-RESILIENCE-1, MASVS-RESILIENCE-2

(g) Data minimisation

Process only data that is adequate, relevant and limited to what is necessary for the intended purpose of the product.

Checks for an app
  • List every data item the app and its SDKs collect, with the purpose of each.
  • Remove what the intended purpose does not need.
  • Request permissions only when they are needed.

MASVS controls to read: MASVS-PRIVACY-1, MASVS-PRIVACY-2, MASVS-PRIVACY-3

(h) Availability of essential functions, also after an incident

Protect the availability of essential and basic functions, also after an incident, including resilience and mitigation measures against denial-of-service attacks.

Checks for an app
  • 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.

MASVS controls to read: Mostly backend design; no direct MASVS group

(i) Limited impact on other devices and networks

Minimise the negative impact of the product on the availability of services provided by other devices or networks.

Checks for an app
  • Check retry and polling behaviour, so a failure cannot turn the app into a request flood.
  • Cap background activity and request rates.

MASVS controls to read: Mostly backend and client design; no direct MASVS group

(j) Limited attack surfaces, including external interfaces

Designed, developed and produced to limit attack surfaces, including external interfaces.

Checks for an app
  • List exported components, deep links, custom URL schemes, WebViews and open ports.
  • Remove what is unused and restrict what the remaining entry points accept.
  • Review the permissions the app requests.

MASVS controls to read: MASVS-PLATFORM-1, MASVS-PLATFORM-2, MASVS-PLATFORM-3

(k) Reduced impact of an incident through exploitation mitigation

Designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques.

Checks for an app
  • Use short-lived, least-privilege tokens.
  • Make sure a compromised client cannot reach other users' data.
  • Keep platform exploit mitigations enabled in the build settings; separate secrets per environment.

MASVS controls to read: MASVS-CODE, MASVS-RESILIENCE

(l) Recording and monitoring of security-relevant activity

Provide security-related information by recording and monitoring relevant internal activity, including access to or modification of data, services or functions, with an opt-out mechanism for the user.

Checks for an app
  • Decide which security events you log.
  • Keep personal data out of logs.
  • Give users a clear way to opt out where the logging relates to them.

MASVS controls to read: MASVS-PRIVACY-3, MASVS-PRIVACY-4

(m) Secure removal of all data and settings, and secure transfer

Users can securely and easily remove all data and settings on a permanent basis and, where such data can be transferred to other products or systems, the transfer is done securely.

Checks for an app
  • 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 controls to read: MASVS-STORAGE, MASVS-PRIVACY-4

Part II: vulnerability handling

These are duties of the manufacturer for the whole support period, so they have no “does not apply” option.

(1) Components identified and documented, with an SBOM

Identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies.

Checks for an app
  • Generate an SBOM from the lockfiles for every release build and keep it with that version.
  • Check that it covers the app's native dependencies as well as the cross-platform ones.
  • Check the SBOM's fields with the SBOM checker.
(2) Vulnerabilities fixed without delay

Address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, provide security updates separately from functionality updates.

Checks for an app
  • Set triage and fix targets by severity, and write them down.
  • Watch the components in your SBOM for new advisories between releases, not only at release time.
  • Make sure you can ship a security-only release from a maintenance branch.
(3) Regular security tests and reviews

Apply effective and regular tests and reviews of the security of the product.

Checks for an app
  • Run dependency and static analysis in CI on every build.
  • Review or test the app against MASVS before major releases and on a fixed schedule.
  • Keep the dates and results with the version they cover.
(4) Fixed vulnerabilities disclosed publicly

Once a security update is available, share and publicly disclose information about fixed vulnerabilities: a description, information to identify the affected product, the impacts, the severity and clear information that helps users remediate. Publication may be delayed in duly justified cases until users could apply the patch.

Checks for an app
  • Have a place for security advisories, for example a page or a section of the release notes.
  • Use a template with the five elements the text lists.
  • Write down the reason whenever you delay publication.
(5) Coordinated vulnerability disclosure policy

Put in place and enforce a policy on coordinated vulnerability disclosure.

Checks for an app
  • Publish a disclosure policy for your apps (see the disclosure policy guide).
  • Name who receives reports and how fast you answer.
  • Test the process once with an internal report.
(6) A contact address for vulnerability reports

Facilitate the sharing of information about potential vulnerabilities in the product and in third-party components it contains, including by providing a contact address for reporting vulnerabilities.

Checks for an app
  • Publish a security.txt file (the free generator writes one).
  • Show the security contact in the app or the store listing.
  • Agree how you pass findings in third-party components to their maintainers.
(7) Secure distribution of updates

Provide mechanisms to securely distribute updates, so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, automatically.

Checks for an app
  • Protect store accounts and signing keys: two-factor sign-in, few people with access.
  • Protect the CI release pipeline and its secrets.
  • Have a minimum-version check or forced-update path in the app.
(8) Security updates without delay, free of charge, with advice

Disseminate security updates without delay and, unless otherwise agreed for a tailor-made product, free of charge, with advisory messages giving users the relevant information, including on potential action to take.

Checks for an app
  • Never put a security fix behind a paid upgrade.
  • Tell users in the app or release notes what the update fixes and what to do.
  • Check that devices on your supported OS versions can install the fix.

0 of 21 answered

0 of 21

How to use the result

The report is a working document, not a declaration of conformity. Put it next to the cybersecurity risk assessment of that version (see the risk assessment guide and template), turn every “Partly” and “Not yet” into a task with an owner, and run the checklist again for each release that changes features, SDKs or backend interfaces. For the reasoning behind each row and the MASVS mapping, read CRA Annex I for mobile apps.

OWASP MASVS is a useful source of concrete checks, but it was not written for the CRA and is not a harmonised standard, so applying it does not give a presumption of conformity. The checks and the MASVS links are our own working aid.

Requirement (a) and Part II point (1) start with knowing what is inside the app. Shipmark keeps an SBOM and daily vulnerability checks for every client app. Founding agencies use it free until 1 April 2027.

Join the free beta

Sources

The checklist summarises the Annex I wording in short; the regulation's text is what counts. It is a planning aid, not legal advice. Related: CRA Annex I for mobile apps · SBOM checker · security.txt generator · Support period calculator.