The EU Cyber Resilience Act: Your 2026 Deadlines for Apps and SDKs
5 Jun 2026 · 8 min read · Erik van Kammen
Most of the attention on EU app regulation has gone to privacy and the app stores. The Cyber Resilience Act, or CRA, has stayed in the background, and that is a mistake, because it is one of the broadest pieces of software law the EU has ever passed. It applies to almost any product with digital elements placed on the EU market, which includes a large amount of commercial software, and it comes with real obligations: secure-by-design requirements, a duty to handle vulnerabilities for the life of the product, and a reporting regime with a 24-hour clock. The first hard deadline is closer than most teams realize. From September 11, 2026, you have to report actively exploited vulnerabilities, and that is a matter of months away, not years. This post lays out the full timeline, explains who is actually covered, and gives you a way to get ready.
What the Cyber Resilience Act is, in plain terms
The CRA is Regulation (EU) 2024/2847. It entered into force in December 2024, and its obligations phase in over the following three years. The core idea is simple: if you sell a product that contains software, you are responsible for its cybersecurity, not just at the moment of sale but across its supported lifetime.
It works a lot like the CE marking regime for physical goods. Products that meet the essential cybersecurity requirements get a CE mark and can be sold across the EU. Products that do not, cannot. The difference is that this time the "product" can be pure software.
Does it cover apps and SDKs?
This is where teams get caught out. The CRA covers "products with digital elements", and that phrase is deliberately wide. It includes software products and their remote data-processing solutions when they are made available on the market in the course of a commercial activity.
In practice, a paid app, a commercial SDK, or a connected-device companion app can all fall within scope. There are some boundaries. Pure software-as-a-service is mostly handled by other EU rules rather than the CRA itself, and non-commercial open-source software gets lighter treatment. But the moment open-source is monetized or shipped as part of a commercial product, the responsibility attaches to whoever places it on the market. If you bundle third-party SDKs into a product you sell, their security becomes part of your problem.
The full timeline you need to plan around
The CRA does not switch on all at once. There are three dates that matter.
| Date | What applies | What it means for you |
|---|---|---|
| December 11, 2024 | The regulation entered into force | The clock started. Nothing was immediately enforceable, but the deadlines below were set. |
| September 11, 2026 | Reporting obligations apply | You must report actively exploited vulnerabilities and severe incidents to the authorities, on a tight timeline, including for products already on the market. |
| December 11, 2027 | Full obligations apply | The essential cybersecurity requirements, conformity assessment, CE marking, SBOM and lifecycle vulnerability handling all become mandatory. |
The September 11, 2026 date is the one to circle. It is the first point where doing nothing becomes a legal violation, and it applies to existing products, not just new ones.
The September 2026 reporting duty, in detail
From September 11, 2026, manufacturers have to report two things: actively exploited vulnerabilities in their products, and severe security incidents affecting them. The timeline is aggressive and modelled on incident-response best practice.
You submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident. You follow that with a fuller notification within 72 hours. Then you provide a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability, or within a month for a severe incident.
To hit a 24-hour clock, you cannot start figuring out your reporting process when the incident hits. You need to know, in advance, which products you ship, what is inside them, who is responsible for triage, and where the report goes. That preparation work is what makes this deadline a 2026 problem even though the heavier requirements land in 2027.
Why the SBOM requirement matters before its own deadline
The CRA expects manufacturers to maintain a software bill of materials, an SBOM, that lists the components inside a product. The SBOM requirement is formally part of the 2027 obligations, so it is tempting to defer it.
That is a trap. To report an actively exploited vulnerability from September 2026, you have to know whether your product even contains the affected component. Without an up-to-date SBOM and some form of automated vulnerability tracking, you cannot answer that question quickly, and the 24-hour clock will run out while you are still grepping through dependencies. In effect, SBOM readiness is something you need in place around the 2026 reporting deadline, well before its official 2027 date.
What the 2027 obligations will require
When the full requirements land at the end of 2027, a compliant product with digital elements will need several things in place.
It must be designed and built to meet the essential cybersecurity requirements, which cover things like secure default configuration, protection against unauthorized access, and data confidentiality and integrity. It must ship with no known exploitable vulnerabilities. It needs a documented vulnerability-handling process and a way to deliver security updates across the support period you have declared. It needs an SBOM. And depending on how the product is classified, it needs a conformity assessment, after which it can carry the CE mark.
What this means for your SDK supply chain
The CRA quietly pushes responsibility down the dependency tree. If you ship a product, you are accountable for the security of the third-party components inside it, including the SDKs you did not write. That means you need to know what you are shipping, track vulnerabilities in those components, and be able to update or replace a component when it turns out to be vulnerable.
This is the same discipline that good supply-chain security has always asked for, but now it has a legal deadline attached. If you have never produced an inventory of your third-party code, that is the first piece of work. Our guide to auditing third-party SDKs goes into how to build that inventory and what to look for.
How to get ready in time
There is a sensible order to this.
- Establish scope. List the products you place on the EU market commercially and decide which are products with digital elements under the CRA.
- Build an SBOM for each one. You need to know your components before you can do anything else.
- Stand up vulnerability tracking. Continuously match your components against known vulnerability data so you find out fast when one is affected.
- Write your incident-reporting runbook now. Define who triages, who decides, and where the report goes, so the 24-hour clock is survivable.
- Plan your update channel. Make sure you can actually ship a security fix to users within your declared support period.
Trying to do all of this by hand across a real product does not scale, especially the vulnerability tracking, which never stops moving. A platform like AppCompliance can scan your app and the SDKs inside it, build and maintain a component inventory, match those components against known vulnerabilities, and alert you the moment something you ship becomes exploitable. That is exactly the capability the September 2026 reporting duty assumes you already have.
FAQ
When does the Cyber Resilience Act take effect?
It entered into force in December 2024 and phases in. Reporting obligations apply from September 11, 2026, and the full set of obligations, including CE marking and SBOM requirements, applies from December 11, 2027.
Does the CRA apply to mobile apps and SDKs?
It can. The CRA covers products with digital elements placed on the EU market commercially, which can include paid apps, commercial SDKs and connected-device companion apps. Pure SaaS is largely covered by other rules, and non-commercial open source gets lighter treatment.
What has to be reported from September 2026?
Actively exploited vulnerabilities and severe security incidents. You file an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a fix for an exploited vulnerability, or within a month for a severe incident.
What is an SBOM and do I need one?
A software bill of materials is a list of the components inside your product. It is formally required from December 2027, but in practice you need one around the September 2026 reporting deadline, because you cannot quickly report on a component you have not inventoried.
Are open-source components covered?
Non-commercial open source is treated more lightly. But once open source is monetized or shipped inside a commercial product, responsibility attaches to whoever places that product on the market, which usually means you.
How do I start preparing now?
Scope your products, build an SBOM for each, set up continuous vulnerability tracking, write your incident-reporting runbook, and confirm you can ship security updates within your declared support period.