The EU Cyber Resilience Act for software companies: what applies now, in December 2027, and how to prepare

The short answer: The Cyber Resilience Act (CRA) has applied in part since 11 September 2026. If you sell or give away software used in the EU (mobile apps, desktop apps, installable agents, firmware, and the backends those products need to work), you must already report actively exploited vulnerabilities and severe incidents within 24 hours. The bigger obligations start on 11 December 2027: secure-by-design requirements, an SBOM, a declared support period of normally at least five years, technical documentation and CE marking. A pure browser-based SaaS product is generally outside the CRA. Its client apps, agents and the APIs those depend on often are not.

This guide is for founders, CTOs and product leaders who need to know whether the CRA applies to them, what has to be in place and when, and roughly how much engineering effort it takes.

1. Key dates at a glance

The CRA is Regulation (EU) 2024/2847. It is a product regulation like the rules behind CE marking on electrical goods, but it covers hardware and software "products with digital elements".

Where we are on 5 November 2026: reporting has been mandatory for eight weeks. About 13 months remain before the full regime applies. Thirteen months is enough time to prepare properly, but not if a backlog of security debt or a large documentation gap is still waiting to be scoped.

2. What changed this autumn, and why it matters now

Three things happened in the space of seven weeks.

The reporting clock started. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents that affect the security of their products. This covers products already on the market. The Commission's summary states that reporting applies to all in-scope products made available in the EU, including those placed on the market before 11 December 2027.

The reporting platform went live. ENISA launched the initial operating capability of the Single Reporting Platform (SRP) on the same day. You submit once, and the notification reaches the right national CSIRT and ENISA.

The Commission published practical guidance. The 27 July 2026 guidance covers remote data processing, open source, "substantial modification", support periods and reporting. It includes 67 practical examples, many aimed at microenterprises and SMEs. It is non-binding, but it is the clearest statement so far of how the Commission reads the text.

Harmonised standards are the main thing still missing. In early July 2026 the Commission proposed pushing the 2026 drafting deadlines back by two months: to 31 October 2026 for horizontal and vulnerability-management standards, and 31 December 2026 for product-specific ones. Ratification of the first two horizontal standards, EN 40000-1-1 (vocabulary) and EN 40000-1-2 (principles for cyber resilience), was scheduled for 2 November 2026. In the trackers we checked, no CRA harmonised standard had yet been cited in the Official Journal, so the legal "presumption of conformity" is not yet available to anyone.

For the wider security news in the same week, see our weekly briefing of 4 November 2026.

3. Does the CRA apply to your product?

The CRA covers hardware and software products made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Almost all modern software has such a connection. The questions that actually decide scope are these: is the product supplied in the course of commercial activity, where does the software run, and who built the remote parts?

3.1 Mobile, desktop and installable software: in scope

If the software runs on the user's device, it is a product with digital elements. Being free does not take it out of scope: the definition of manufacturer covers products marketed whether for payment, monetisation or free of charge. Skadden's checklist names mobile apps directly as an example of connected software made available in the EU, including for free.

3.2 The backend your app needs: usually in scope

This is the part many teams miss. The CRA covers a product together with its "remote data processing solutions". These are remote services designed and developed by or for the manufacturer whose absence would stop the product performing one of its functions. Recital 11 of the Regulation uses the example most of our readers will recognise: a mobile application that needs an API or database provided by the manufacturer's own service. In that case the service falls within scope as a remote data processing solution.

Independent summaries of the Commission guidance describe a worked example using a mobile banking app. They are CRA Compliance Hub's breakdown and CRA Evidence's analysis:

In practice your API layer is part of the product, so its security falls under the CRA. Your AWS account as a whole does not: the Regulation says these requirements do not extend to the security of a manufacturer's network and information systems as a whole. That wider security is a matter for NIS2.

3.3 Pure SaaS and web apps: generally outside the CRA, often inside NIS2

Recital 12 says websites that do not support a product's functionality, and cloud services designed outside a manufacturer's responsibility, are not in scope. The same recital points SaaS, PaaS and IaaS providers to the NIS2 Directive, which covers cloud computing providers of medium size and above. According to an independent summary, the Commission guidance confirms that software merely accessed through a browser is not, on that basis alone, a product with digital elements.

The caveat matters. If your SaaS ships a desktop client, a browser extension, a mobile companion app or an on-premise agent, those parts are products, and the cloud functions they depend on may be pulled into scope with them. Workstreet's analysis adds a commercial point: even out-of-scope SaaS vendors will feel CRA pressure through customer supplier questionnaires.

3.4 Bespoke software and internal tools: a grey zone

Commentators disagree here, so be careful with anyone who gives you a confident one-line answer. Some sources treat bespoke software built for a single customer as outside "placing on the market". Others, such as Advisori, argue that a custom contract is not a general exclusion and that only genuinely internal tools fall away. The text itself refers to arrangements between a manufacturer and a business user for a "tailor-made product", which suggests bespoke B2B products are expected to be in scope. Software your own staff use internally and that is never supplied to anyone else is the safest case for falling outside the Act.

3.5 Who is the "manufacturer" when a studio builds it for you?

The manufacturer is the person who develops a product, or has it designed or developed, and markets it under its own name or trademark. If an agency or studio builds your app and you publish it under your brand, you are the manufacturer. The CRA obligations sit with you. Your contracts with suppliers should make sure you can actually meet them.

Scope summary

4. The reporting obligation in detail

4.1 What triggers a report

There are two triggers, as ENISA defines them:

• Actively exploited vulnerability: there is reliable evidence that a malicious actor has exploited it without the system owner's permission. A vulnerability that is merely known, or has a high CVSS score, does not count.
• Severe incident: an incident that negatively affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions, and that meets the severity criteria in Article 14(5).

The clock starts when you become aware. ENISA notes, citing the Commission FAQ, that you need not report retrospectively if you knew about the exploitation before 11 September 2026. If you learn of it after that date, the duty applies even if the bug itself is old.

4.2 Deadlines

Source: European Commission and ENISA SRP FAQ.

4.3 Using the Single Reporting Platform: practical details

ENISA's FAQ contains several operational details worth knowing before you need them:

• Reporters need a personal EU Login account with multi-factor authentication. You can create one in advance.
• Each manufacturer has one Primary Assigned Representative and up to 20 Secondaries. Drafts are visible only to the person who wrote them, which matters if the person on call changes mid-incident.
• ENISA advises registering the manufacturer association only when you actually need to submit a notification. Registration takes minutes if the EU Login account already exists, and you can submit up to 20 notifications while verification is pending.
• There is no API at initial release. You can automate your internal workflow, but the submission itself is manual.
• If you choose the wrong coordinating CSIRT, the notification may be invalidated and you will have to resubmit it.

4.4 Which CSIRT if you are outside the EU

This matters for companies headquartered in the UAE, the UK, the US or elsewhere. Normally you report to the CSIRT of your main EU establishment, meaning the place where cybersecurity decisions about the product are mainly taken. With no EU establishment, ENISA sets out a fallback order: the member state where your authorised representative covers the most products, then where your importer or distributor places the most products, and finally the member state with the most users. A UAE-based app publisher whose largest EU audience is in Spain would, on that logic, end up with Spain's coordinating CSIRT. Work this out and write it in your runbook now, before an incident.

4.5 Relief for small companies

The Commission's summary notes that micro and small enterprises may not be fined for missing the 24-hour deadline. They can still be fined for failing to report at all, or for missing the 72-hour and final-report stages. Treat this as a cushion for a chaotic first day, not as a reason to skip the runbook.

One notification, many recipients: the CSIRT that receives your report passes it to the CSIRTs of every other member state where the product is available. A December 2025 delegated act sets the narrow cybersecurity grounds on which that onward sharing can be delayed.

5. Why this is more than paperwork: the threat data

Reporting deadlines measured in hours make sense against current exploitation data:

Verizon, Google/Mandiant and Black Duck all sell security products or services, so read their figures as vendor research. Even so, they point the same way. Exploitation is fast and rising, and much of it comes through third-party code. The CRA's main tools are SBOMs, coordinated disclosure, fast free security updates and mandatory reporting, and each one targets one of these trends.

6. The essential requirements, translated into engineering work

Annex I Part I lists what the product itself must do, based on your risk assessment. The table below turns each requirement into the work it usually means for a SaaS-plus-mobile team. The legal text is in the Regulation, and a readable annex reproduction is available.

Two of these catch teams out. Updates must be automatic by default and come with a clear opt-out. Logging must also offer an opt-out. Both need product decisions as well as code.

7. Vulnerability handling: SBOMs, disclosure and updates

Annex I Part II covers process rather than product properties. In practice it is the part most teams need to build from scratch.

7.1 Software bill of materials

You must draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. You are not obliged to publish it. Annex II only requires you to tell users where to find it if you choose to share it.

Germany's BSI is the most detailed national reference so far. Its TR-03183 technical guideline has a part dedicated to SBOMs, now at version 2.1.0. According to LegacyMind's analysis, that version requires new SBOMs in CycloneDX 1.6 or later, or SPDX 3.0.1 or later, so SPDX 2.3 no longer qualifies. In the US, CISA's 2026 Minimum Elements for an SBOM added fields such as component hash algorithm, licence, SBOM tool name and generation context.

Practical tip: generate SBOMs in CI for every release artefact (mobile build, desktop installer, backend container) rather than once a quarter. An SBOM that does not match what shipped is little help in the first hour of an incident. Remember the Black Duck finding that a sixth of components arrive outside package managers. Vendored and AI-pasted code needs a deliberate inventory step.

7.2 Coordinated vulnerability disclosure

You need a policy on coordinated vulnerability disclosure and a published contact for reports, and Annex II requires a single point of contact in your user information. The simplest piece of infrastructure is a `security.txt` file in the format defined by RFC 9116, linked to a short disclosure policy and a monitored inbox.

7.3 Security updates

Annex I Part II asks for remediation "without delay", security updates shipped separately from feature updates where technically feasible, secure distribution, free security updates (unless agreed otherwise for tailor-made B2B products), and public advisories once a fix is out. For a team on a two-week release train this has a concrete consequence: you need a hotfix path that skips the feature pipeline, including expedited app-store review requests and a forced minimum version in your mobile clients.

8. Support periods: the commercial decision hidden in the law

You must set a support period, handle vulnerabilities throughout it, and state its end date (month and year) clearly at the time of purchase. Article 13(8) sets the norm at at least five years, or longer if the product is expected to be used for longer. A shorter period is acceptable only where the expected use is shorter, such as an app built for a single event.

This has three effects for software businesses:

1. Maintenance becomes a legal commitment. A five-year security support obligation is a staffing plan. It has to survive team changes, a pivot and, in some cases, the sale of the product. Our software maintenance and support guide covers how to resource it.
2. Versions matter. Practitioners note that software with many releases may need a support period per version. Forcing users onto the latest version (normal for mobile apps and SaaS-style desktop clients) keeps the number of supported versions small. Long-lived on-premise versions multiply it.
3. Liability follows. The Regulation notes that, under the revised Product Liability Directive, a lack of security updates that causes damage could trigger the manufacturer's liability.

9. Product classes and conformity assessment

Most software is in the default category and can self-assess (the "module A" internal control procedure) before signing an EU declaration of conformity and affixing the CE marking. Stricter routes apply to products listed in Annexes III and IV. Their technical descriptions are set out in Implementing Regulation (EU) 2025/2392.

Sources: Annex III and IV text and the Commission summary.

Classification depends on core functionality. A CRM with a login screen is not an identity management system. A product whose main purpose is identity or access management is. There is also an exception for free and open-source products in Classes I and II: they can self-assess if their technical documentation is public.

The standards gap bites hardest in Class I. Until harmonised standards are cited in the Official Journal, a Class I manufacturer has no standard to self-assess against and may need a notified body. If your product is near that line, start talking to conformity assessment bodies now rather than in late 2027.

The technical documentation (Annex VII) covers the product description, design and vulnerability-handling processes, the risk assessment and test results. Manufacturers must keep it for ten years and provide it to market surveillance authorities on request.

10. Penalties and enforcement

Member states set the penalties, within the caps in Article 64:

Source: Innovatech Legal and Rickert summarising Article 64.

Fines are not the only tool. National market surveillance authorities can require corrective action or withdrawal, and can run coordinated cross-border "sweeps" of particular product types. For an app publisher, being removed from sale in the EU matters far more than a capped fine.

11. How the CRA fits with NIS2, GDPR and the Digital Omnibus

• NIS2 covers the security of your organisation and services. For SaaS companies of medium size or larger it is often the more relevant regime. The CRA covers the security of products you place on the market. One company can be subject to both.
• GDPR breach notification (72 hours to the data protection authority) runs in parallel. A single incident can trigger a CRA early warning, a GDPR notification and NIS2 reporting at once, with different recipients and forms.
• Digital Omnibus. In November 2025 the Commission proposed a single-entry point for incident reporting that would build on the CRA platform and cover NIS2, DORA and other regimes. It is a proposal, not current law. Plan for today's separate channels.

Our guide to cybersecurity services explains how these obligations usually divide between internal teams and outside specialists.

12. Step by step: a 13-month plan to December 2027

The effort figures below are indicative planning ranges for a small product team (a few engineers, one product, a mobile app and a backend). They are not benchmarks. A portfolio of products, old codebases or a Class I classification will push them up.

Step 1: Inventory and scope (weeks 1–2)

List every product, version, client and backend you supply in the EU. For each, apply the remote data processing test, decide who the manufacturer is, and note whether any core functionality appears in Annex III. Effort: 2–5 days of a senior engineer plus a product owner.

Step 2: Make reporting work now (weeks 1–3)

This step is already legally required, so do it in parallel with Step 1.

• Create EU Login accounts with MFA for at least two named people.
• Identify your coordinating CSIRT using ENISA's main-establishment rules, and write it down.
• Write a one-page runbook covering who decides that something is "actively exploited", who files the 24-hour warning, and where the facts are gathered.
• Run a tabletop exercise on a realistic scenario, such as an exploited flaw in a popular library you ship.

Effort: 3–5 days, mostly senior engineering and leadership time.

Step 3: Publish a disclosure route (weeks 2–4)

Publish a CVD policy and a `security.txt` file, set up a monitored security inbox, and define triage service levels. Effort: 2–4 days.

Step 4: SBOMs in CI (weeks 3–6)

Generate CycloneDX or SPDX SBOMs for every release artefact. Store them alongside builds, and feed them into vulnerability monitoring so you know within hours whether a newly exploited CVE affects you. Effort: 2–5 days per technology stack.

Step 5: Risk assessment and Annex I gap analysis (months 2–3)

Do a cybersecurity risk assessment per product and map each Annex I requirement to evidence or to a gap. An independent software audit is a quick way to get an honest baseline. Effort: 1–3 weeks per product.

Step 6: Remediate (months 3–10)

Fix the gaps, with priority on secure defaults, the update mechanism, authentication, logging and data deletion. This is the most variable step: from a few weeks for a modern, well-kept codebase to many months for older systems. If remediation turns into a rebuild, read our legacy modernisation guide before committing.

Step 7: Separate security releases (months 3–6)

Build a hotfix pipeline that is independent of feature releases. Add minimum-version enforcement to mobile apps, plus signed updates and staged rollouts for desktop software. Mature DevOps practice makes this cheap; without it, it is painful. Effort: 1–3 weeks.

Step 8: Define support periods (month 4)

Set end-of-support dates per product, and if needed per version, then align contracts, pricing pages and app-store listings. This is a leadership decision, informed by engineering capacity.

Step 9: Technical documentation and user information (months 8–12)

Assemble the Annex VII file and the Annex II user information. Keep both versioned alongside the code. Effort: 2–6 weeks across the team.

Step 10: Conformity assessment and CE marking (months 11–13)

Self-assess, or engage a notified body if you are Class I without applicable standards, or Class II. Then sign the declaration of conformity. Aim to finish before October 2027 so there is slack.

Readiness checklist

13. Trade-offs, and when not to over-invest

• Pure SaaS with no client software: do not build a CRA programme you do not need. Check NIS2, keep good disclosure habits, and prepare answers for customer questionnaires.
• Do not build an integration with the reporting platform. There is no API yet. A good runbook and two trained people are worth more.
• Do not wait for the standards. Annex I is specific enough to act on now. The harmonised standards will refine how you show compliance, not reverse the requirements.
• Think hard before a long on-premise support tail. Offering five years of support on several long-lived versions is a real cost. Sometimes the right decision is to shorten the version tail before the deadline rather than document it.
• Older products placed on the market before December 2027 only take on the full requirements if they are substantially modified after that date, but reporting already applies. A planned major rewrite in 2028 is a CRA project whether or not you call it one.
• Small companies have help. Member states may run training, testing and regulatory sandboxes for SMEs. ENISA has also published a Secure by Design and Default Playbook for smaller firms.

14. How Authect approaches it

We treat the CRA as an engineering problem first and a documentation problem second. Most of what the Act asks for (current dependencies, a real update path, secure defaults, logging and data deletion that work) is what well-run products should have anyway. The documentation is easier to write when the engineering is already in place.

Every Authect project is led by a senior engineer. The founders are hands-on from the first conversation onwards, so the people you talk to are the people building your product. We use AI to speed up delivery, and an engineer reviews every line. For CRA readiness that usually means:

• a scope and gap review of your apps and backends, through our cyber security and audit work;
• building the missing pieces: SBOM pipelines, hotfix paths, update enforcement, authentication and logging;
• ongoing support and evolution to cover the support period you commit to.

You own your code, infrastructure and designs from day one, so your CRA technical file describes systems you control. You can work with us as a fixed-price project, in monthly sprints, or through support and evolution. If you are unsure whether your product is in scope, talk to the founders. All conversations start online.