CRA Compliance Checklist for Software and App Teams

Guide · Compliance

If attackers use a security flaw in your software or app, EU law may already give you 24 hours to report it. That’s the Cyber Resilience Act (CRA), an EU law that sets security rules in two stages, and it probably applies to you if your business sells or offers software or an app in the EU.

Since 11 September 2026, you must be able to report actively exploited vulnerabilities within 24 hours. These are security flaws in your product that attackers are already using. By 11 December 2027, your product must meet the essential security requirements, with the documentation to prove it.

This checklist covers both, in the order a small software or app team would tackle them. For what the Act is and whether it applies to you, start with the Cyber Resilience Act for app teams.

Last reviewed 27 October 2026. Not legal advice.

Before you start: are you in scope?

• ☐ Your product is a “product with digital elements” made available in the EU in the course of a business. In plain words: software or hardware that connects to a device or network. Mobile apps, desktop software, games and firmware usually count, as long as they connect, directly or indirectly, to a device or network (Article 2(1)). Pure SaaS (software people use online, with nothing installed on their device) generally doesn’t (recital 12). But if your app needs a backend you built, or had built, to perform one of its functions, that remote processing counts as part of the product (Article 3(1)–(2) and recital 11).
• ☐ You’re the manufacturer. That means you develop it, or have it developed, and market it under your name, paid or free, as part of a commercial activity (Article 3(13) and 3(22)). Ads, in-app purchases, subscriptions or a related paid service usually count, in line with recital 15, which treats an intention to monetise as a sign of commercial activity. Where you’re based usually doesn’t matter. The Act covers products supplied for use on the EU market (Article 3(22)), and it sets out how a manufacturer with no EU base files reports (Article 14(7)).
• ☐ You know your category. Anything not on the Act’s lists of important or critical products (Annexes III and IV) is default. Default products can be self-assessed: you check them yourself (Article 32). Some product types, such as password managers, VPNs and network management tools, are important (class I or II) and need more. A few are critical.

Stage 1: live now (since 11 September 2026)

• ☐ You’ve decided who files reports. This is not a legal requirement, but you won’t meet the deadlines without it. The reports are an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a notification within 72 hours, and a final report within 14 days of a fix or mitigation being available (Article 14).
• ☐ You can reach the reporting platform. Reports go via ENISA’s single reporting platform. ENISA is the EU Agency for Cybersecurity. The reports reach the CSIRT designated as coordinator in the EU country where you have your main establishment. A CSIRT is a national team that responds to cyber incidents. Without an EU establishment, the Act sets the order: your authorised representative’s country, then your importer’s or distributor’s, then where most of your users are (Article 14).
• ☐ Severe incidents are covered too. An incident that affects your product’s security and is severe, as Article 14(5) defines it, follows the same 24h / 72h rhythm. The final report is due within a month of the notification (Article 14(3)–(4)).
• ☐ People can tell you about vulnerabilities. The 24-hour clock starts when you become aware of an exploited vulnerability. A published contact gives researchers and users a way to tell you. Publish one now; it’s required by 2027 anyway (Article 13(17) and Annex I, Part II, points 5 and 6).
• ☐ You’ve included products already on sale. The reporting duty applies to every product in scope, including those placed on the market before 11 December 2027 (Article 69(3)).
• ☐ You know how you’ll inform users about an exploited vulnerability or severe incident and what they should do (Article 14(8)).

Stage 2: by 11 December 2027

Products already on sale aren’t automatically exempt. An app that launched before December 2027 can still be caught, for example by a release that changes what it does. The legal detail is under “For engineers” below.

Security of the product (Annex I, Part I)

• ☐ Risk assessment written down and kept up to date. It drives which requirements apply and how (Article 13(2)–(4)).
• ☐ No known exploitable vulnerabilities when you release.
• ☐ Secure by default, with a way to reset to the original state.
• ☐ Automatic security updates switched on by default where applicable, with a clear, easy opt-out (Annex I, Part I). Keep them separate from feature updates where technically feasible (Annex I, Part II).
• ☐ Access control for data and functions, encryption of data at rest and in transit where relevant, and integrity protection (so data can’t be changed without you knowing).
• ☐ Data minimisation: only the data the product needs.
• ☐ Minimal attack surface (as few ways in for an attacker as possible) and security logging of relevant activity, with an opt-out for users.

Vulnerability handling (Annex I, Part II)

• ☐ A software bill of materials (SBOM): a list of the third-party code your product is built from. It must be in a common machine-readable format, covering at least your top-level dependencies. For apps, that typically includes the third-party SDKs you ship, since they are components of your product (Article 13(5)). SDKs are ready-made code kits from other companies.
• ☐ Fix vulnerabilities without delay, and test the product’s security regularly.
• ☐ Publish information about fixed vulnerabilities (security advisories).
• ☐ A coordinated vulnerability disclosure policy, and a published contact address for reports. The policy says how people should report flaws to you and how you’ll handle them. A security.txt file, defined in RFC 9116, is one machine-readable way to publish that contact.
• ☐ Distribute updates securely, promptly and free of charge.

Support period and information for users

• ☐ Support period decided: how long you’ll keep fixing security flaws. At least five years, unless the product is expected to be used for less. State the end date where users can see it before they buy or download (Article 13).
• ☐ Each security update stays available for at least ten years after you release it, or for the rest of the support period if that’s longer (Article 13).
• ☐ User information (Annex II): who you are, your contact point for vulnerabilities, intended use, the support period and how to install updates.

Proof

• ☐ Technical documentation (Annex VII): design, risk assessment, how each requirement is met, the SBOM, test results.
• ☐ Conformity assessment: the check that your product meets the rules. Self-assessment for default products. Other categories may need an outside body; see “For engineers” below.
• ☐ EU declaration of conformity signed, and CE marking applied. The CE marking is the mark that shows a product meets EU rules. For software, it goes on the declaration of conformity or on the product’s website (Article 30).
• ☐ Kept for ten years after the product is placed on the market, or for the support period if that’s longer (Article 13).

Notes for app teams

• SDKs are usually your responsibility. The CRA asks you to take care when integrating third-party components, and to report and fix vulnerabilities you find in them (Article 13(5)–(6)). So a vulnerability in an analytics or ads SDK you ship is typically treated as a vulnerability in your product. Keep a list of every SDK and its version per release.
• App store updates help, but aren’t the whole story. The App Store and Google Play can deliver your updates. But the CRA still asks you to fix vulnerabilities without delay, distribute updates securely, and make security updates available free of charge (Annex I, Part II, points 2, 7 and 8).
• Stale apps are a risk. In our measurement of European app publishers (snapshot of 26 September 2026), 8.7% of small publishers’ apps in the charts (315 of 3,606) hadn’t been updated in a year. For large publishers it was 1.2% (6 of 481).
• A second EU law adds liability. For products placed on the market after 9 December 2026, the EU’s revised Product Liability Directive (Directive (EU) 2024/2853) can leave you liable for a defect caused by a lack of software updates needed to keep the product safe. That applies where the updates are within your control as the manufacturer (Articles 2(1) and 11(2)(c)).
• Many small teams start from zero on disclosure. In the same snapshot of 26 September 2026, only 12.1% of the 3,082 small publishers of chart-listed apps we could check (373) published any way to report a vulnerability (see the study). How we measure explains how these figures are produced.

For engineers: the legal detail

When a product already on sale is caught

“Placed on the market” applies to each individual unit, not to a product model (Article 3(21) and recital 38). So device units sold from 11 December 2027 must meet these requirements even if the model launched earlier. Article 69(2) only spares units placed on the market before that date, unless they are substantially modified.

For apps, a release that changes the intended purpose, or adds cybersecurity risks your risk assessment didn’t cover, is likely to count as a substantial modification. Security fixes and minor changes such as new languages generally are not (Article 3(30) and recital 39).

The Commission published guidance on this on 27 July 2026: C(2026) 5252 (the guidance itself, a PDF), section 4.3, “Software updates as substantial modifications”. It says the test is not the size of a change but its “potential adverse impact on the cybersecurity risk profile” of the product (paragraph 107). Its own app example: adding a ‘remember me’ login that stores tokens on the device, with risks the risk assessment didn’t consider, is a substantial modification (Example 44). A security update that keeps the intended purpose and adds no new risks generally is not (paragraph 108). The guidance is non-binding, so take advice before treating an app that launched earlier as exempt.

Conformity assessment routes (Article 32)

• Default: self-assessment.
• Important class I: self-assessment only if you apply a harmonised standard or equivalent, otherwise a third party.
• Important class II and critical: third-party assessment or certification.

Frequently asked questions

What are the Cyber Resilience Act requirements?

Two sets. The essential cybersecurity requirements for the product itself (Annex I, Part I), and requirements for how you handle vulnerabilities over its life (Annex I, Part II). On top of those come reporting, user information, technical documentation and a declaration of conformity.

When do I need to be CRA compliant?

Reporting has applied since 11 September 2026, including for products already on the market. Everything else applies from 11 December 2027 (Article 71(2)) to each unit placed on the market from then, and to earlier units that are substantially modified (Article 69(2)). For an app that ships regular releases, plan for the full requirements.

Can a small company self-assess?

Yes, for products in the default category: anything not on the Act’s lists of important or critical products (Annexes III and IV; Article 32). Company size doesn’t change the requirements, but micro and small enterprises get some relief. For example, they can use a simplified technical documentation form once the Commission sets it out in an implementing act (Article 33(5)). And Article 64(10)(a) says fines “shall not apply” to them for missing the 24-hour early-warning deadline. Its opening words refer to “paragraphs 3 to 9” of Article 64, while the fines for Article 14 are in paragraph 2, so take advice before relying on it.

Is an SBOM mandatory under the CRA?

Yes. Manufacturers must draw one up covering at least the product’s top-level dependencies, and keep it in the technical documentation. It doesn’t have to be published.

Last reviewed 27 October 2026. Source: Regulation (EU) 2024/2847 (the Cyber Resilience Act). This is general information about the Regulation, not legal advice for your situation.