The Cyber Resilience Act for Mobile Apps

The Cyber Resilience Act (CRA) is a regulatory framework of the European Union (EU), which applies to both hardware and software products made available on the EU market. While the text entered into force on 10 December 2024, reporting obligations became active on 11 September 2026. This blog, while not exhaustive, aims to provide clarifications to mobile app developers and publishers as to the scope, deadlines, and compliance requirements of the CRA.

Key CRA dates

What is the Cyber Resilience Act (CRA)?

The Cyber Resilience Act (CRA) is a European regulation focused on strengthening the European Union’s approach to cybersecurity by shifting the responsibility of “cybersecurity” from the user to the organizations putting the product on the market. Software and hardware products must be “designed, built and maintained to a defined cybersecurity standard”, and the manufacturer “must be able to demonstrate it”.

What does this look like in practice? Broadly speaking, the CRA mandates the following steps for any manufacturer of hardware and software products (which we’ll explore more in detail later in this blog):

• Performing a cybersecurity risk assessment: the manufacturer must assess all the cybersecurity risks and threats related to their product.
• Meeting the essential cybersecurity requirements: based on the risk assessment, the manufacturer must implement the relevant cybersecurity requirements into the various stages of development and production of their product.
• Carry out a conformity assessment procedure: before releasing the product, the manufacturer needs to demonstrate compliance with the CRA by performing a conformity assessment.
• Define a support period and report vulnerabilities: once the product is on the market, the manufacturer needs to communicate a support period during which any issues will be handled, as well as report discovered vulnerabilities in a timely manner.
• Draft technical documentation: the manufacturer needs to document each step of this process (outcome of the risk assessment, which cybersecurity requirements were implemented and why, how vulnerabilities will be disclosed and handled, etc.).

It’s also important to note that there currently aren't any overlaps between the CRA and existing regulations as it pertains to mobile app developers. If a manufacturer already complies with DORA, for example, they will have some of the effort cut out for them by having governance and risk management processes. But they are still required to comply with each step of the CRA individually.

The legal text behind the CRA is intentionally broad and all-encompassing in its language, which can make it tricky to fully grasp how it may or may not apply to your business. That is why, in the following sections, we use the example of a FinTech mobile app and answer the following questions:

1. Does my mobile app need to comply with the CRA?
2. If so, what are the mandatory requirements I need to fulfill, and what are the deadlines?
3. What are the tools and processes I can use to have a CRA-compliant mobile app?

First, let’s take a quick look at who the CRA applies to and the main deadlines for compliance.

Does the CRA apply to my mobile app?

The CRA applies to all “products with digital elements”. By and large, this means all software and hardware products, including all mobile applications. There are, however, a few caveats worth noting:

• The CRA only applies to products with a “data connection to a device or network”. This means that, for example, a dishwasher with embedded firmware to control the cleaning cycles, but without the ability to connect to other devices or networks, falls outside the scope of the CRA.
• The product needs to be “made available on the market”. This means that tools developed only for internal purposes are excluded from the CRA.
• Products made available before 11 December 2027 are not required to comply with the CRA unless any substantial changes are made after that date. For a mobile application, an update to patch a bug does not qualify as a substantial change. However, an update that introduces new functionalities (for example the ability to pay through the app) would qualify as a substantial change, and would, therefore, need to comply with the CRA going forward.

While the CRA entered into force on 10 December 2024, the text will only become fully applicable as of 11 December 2027, with reporting obligations (more on those later) coming into effect from 11 September 2026.

What CRA requirements apply to my mobile app today?

Let us now take a look at how the CRA applies to mobile apps.

How to make a mobile app CRA-compliant: a FinTech example

For this, we will take the example of a FinTech company, who plans on releasing a mobile app in January 2028. Because the app ships after 11 December 2027, every CRA obligation applies from day one. The mobile app will allow users to buy and trade stocks and cryptocurrencies.

The first step for any mobile app developer who needs to comply with the CRA is to perform a cybersecurity risk assessment. The goal here is to determine the risk profile of your mobile app, which will then dictate which of the requirements apply and to what extent. This is an analytical exercise that should happen during the design phase and needs to be included in the technical documentation.

For our stocks and crypto-trading app, some of the threats and risks might include:

• a malicious clone of the app that abuses accessibility services to initiate fraudulent transactions.
• a malware that will target the app to steal the user’s login credentials.
• deepfakes that allow attackers to bypass biometric authentication and the KYC process, leading to the opening of fraudulent accounts.

In order to comply with the CRA, the risk assessment will, of course, need to be much more extensive than this. Companies are allowed to use whichever risk assessment framework or methodology they desire, as long as it is documented in the technical documentation.

Once the cybersecurity risk assessment has been completed, mobile app developers can identify the cybersecurity requirements they will need to implement. The list of these requirements can be found in Annex Ⅰ of the Cyber Resilience Act. In the case of our FinTech mobile app, these requirements should include:

• releasing the app without known exploitable vulnerabilities.
• building a secure-by-default app (such as implementing strong authentication and access controls)
• protecting the confidentiality of stored and processed data.
• designing and developing the app in such a way as to minimize the attack surface

Again, the language here is intentionally broad, which leaves enough room for mobile app developers to choose the tools best suited to their threat model.

Under the CRA, mobile apps fall under the “self-assessment procedure”, meaning that they are free to perform their own relevant tests and testing procedures to ensure compliance with the identified requirements. For mobile app developers, the OWASP Mobile Application Security Verification Standard (MASVS) acts as the de facto checklist for a secure mobile app. Techniques such as static and interactive analysis, as well as manual pentesting, are typically used to ensure alignment with those standards.

Notable exceptions such as VPNs, password managers, and browsers are considered a higher-risk category and require that the conformity assessment be carried out by a notified third party. You can check if your mobile app falls into this category in Annex Ⅲ of the CRA.

Once the mobile app is live, the publisher needs to have a procedure in place detailing how vulnerabilities will be handled. In the case of our FinTech app, this would include:

• identifying the app's components, including a software bill of materials (SBOM).
• fix vulnerabilities without delay and ship security updates free of charge.
• testing the app regularly.
• publishing information about fixed vulnerabilities.
• maintaining a coordinated vulnerability disclosure policy and a contact point for reports.

The company must also declare a support period, which must be at least five years unless the app is expected to be used for less time.

Up until this point, we’ve covered obligations that only come into effect on 11 December 2027 onward. However, reporting obligations regarding vulnerabilities came into effect on 11 September 2026. These include:

• remediating vulnerabilities without undue delay.
• disclosing vulnerabilities as soon as an update is available.
• providing a point of contact for disclosing security issues.

This entire process and the policy for handling vulnerabilities needs to be documented in the technical documentation.

Every step above, from the risk assessment to the vulnerability-handling policy, goes into technical documentation. The manufacturer must keep it for at least 10 years after release, or for the support period if that is longer.

How Guardsquare helps mobile app developers achieve CRA compliance

Broadly speaking, the CRA requires two things from mobile app developers:

1. Mobile apps should be secure by design.
2. Development teams should be able to find, fix, and report vulnerabilities in a timely manner.

Guardsquare does not make an app compliant on its own; however, Guardsquare covers several requirements directly and generates audit-ready build reports for your technical documentation.

If your app is required to comply with the Cyber Resilience Act, contact a Guardsquare expert today to learn more about how we can help you.