If you build software outside the European Union and any of it ends up running on a European customer's machine, embedded in a device sold in Europe, or installed and operated by a European buyer, there is a regulation with your name on it and a deadline roughly a month away. It is the Cyber Resilience Act, and the part that bites first is not CE marking. It is a 24 hour reporting clock that starts on 11 September 2026.
Most CRA coverage aimed at startups makes one of two mistakes. It either treats December 2027 as the deadline, so you file the whole thing away, or it dumps the entire regulation on you at once, conformity assessment machinery included, which is genuinely not due until 2027. Neither helps a six person team decide what to do this month.
This post covers what a non-EU startup needs working before 11 September 2026, what is safe to defer, and how to tell whether the CRA touches you at all. Every obligation cites the regulation or an official Commission or ENISA source. Where I am giving practitioner judgement rather than citing the text, I have labelled it inline.
Quick context: what the CRA is and when it actually applies
The Cyber Resilience Act is Regulation (EU) 2024/2847, adopted 23 October 2024. It sets horizontal cybersecurity requirements for what it calls products with digital elements: hardware or software with a direct or indirect logical or physical data connection to a device or network, placed on the EU market in the course of a commercial activity. It is product safety law pointed at software, which is why it comes with CE marking, declarations of conformity, and market surveillance authorities rather than a data protection style regulator.
It applies in phases rather than on one date. Chapter IV, covering the notification of conformity assessment bodies, applied from 11 June 2026. The reporting obligations in Article 14 apply from 11 September 2026. Everything else, including the essential requirements in Annex I, the technical documentation, and the CE marking, applies from 11 December 2027. The Commission's CRA policy page is the canonical reference for the schedule.
That split is the single most useful thing to know about the CRA right now. December 2027 is a build project. September 2026 is an operational readiness question, and it is answerable in a couple of focused weeks.
1. Step zero: work out whether you are in scope at all
A lot of founders assume the CRA applies to them because they have European users. For a pure SaaS product, that is usually wrong. The CRA regulates products placed on the market, and software delivered purely as a hosted service the customer never installs is generally treated as a service, not a product. DLA Piper's analysis of the SaaS boundary walks through where that line sits and how easily it moves.
The trap is the remote data processing solution. If you ship something the customer installs, an agent, an SDK, a desktop or mobile app, a self-hosted appliance, a CLI, and your backend performs processing without which that installed thing does not function, the backend is pulled into scope alongside it. The ORC Working Group's community FAQ devotes a whole section to it.
Note the commercial activity qualifier too. Open source published without monetisation is outside scope, but if you sell support, hosting, or a commercial edition of your own open source project, read the open source steward obligations in Article 24 before concluding you are clear.
Takeaway: write down every artefact a European customer installs or embeds, not every product you sell. If that list is empty, the CRA is background reading. If it has one line on it, keep going.
2. The date that matters is September 2026, not December 2027
If you are in scope, the reporting obligation applies to your product from 11 September 2026 regardless of when it shipped. It is not gated on the December 2027 requirements, it is not gated on you having completed a conformity assessment, and it does not wait for a new release. A product you placed on the EU market years ago is covered the moment an actively exploited vulnerability in it comes to your attention. Crowell and Moring's client alert on the countdown makes this point about legacy products directly.
This is why the sequencing advice most startups get is backwards. Teams are told to start with SBOM tooling and a conformity assessment plan, both December 2027 obligations, while the thing that can generate a regulatory failure next quarter is an unstaffed 24 hour clock. Practitioner opinion: for a pre-seed or seed team, an SBOM you generate in CI but never look at is worth less right now than a written answer to who files the early warning at 02:00 on a Saturday.
Takeaway: split your CRA work into a September track and a December 2027 track, and do not let the larger December track absorb the attention the September track needs first.
3. What actually starts the clock
Two things trigger a report, and neither is what most engineers assume. The first is an actively exploited vulnerability: a vulnerability in your product where there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. A vulnerability you found in an audit and patched quietly is not this. A CVE published against a dependency you use is not this either, unless there is evidence of exploitation affecting your product.
The second is a severe incident having an impact on the security of your product: an incident that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions, assessed against the criteria in Article 14. The Article 14 reporting breakdown is a useful plain language version of both definitions.
The word doing the most work in the whole obligation is aware. The clock starts when you have a reasonable degree of certainty that one of these conditions holds. Not when you have confirmed root cause, not when you have a patch, not when legal has signed off. That is a deliberately low bar, and it is why a reporting obligation is really a detection and triage obligation wearing a compliance hat.
Takeaway: put both definitions, verbatim, into your incident runbook, and make the on-call engineer's first triage question a CRA question rather than a severity question.
4. The 24, 72 and 14 timeline, and what each report contains
Three stages, all measured from awareness. Within 24 hours, an early warning: the notification type, your name, the affected product, a title, and for incidents whether you suspect malicious acts. Within 72 hours, a fuller notification: the nature of the vulnerability or exploit, your initial assessment, any corrective measures taken, and any mitigations users can apply themselves. Then a final report, due no later than 14 days after a corrective measure becomes available for an actively exploited vulnerability, or within one month for a severe incident. The Commission's reporting obligations page is the authority on these deadlines.
Read the 24 hour report carefully and you will notice how little it asks for. It is a heads up, not an analysis. You are not expected to know root cause, blast radius, or the fix. That matters operationally, because the failure mode I would expect from a small team is not missing the deadline through negligence. It is missing it because someone waited until they understood the problem well enough to write something they were not embarrassed by. Practitioner opinion: pre-write the early warning as a template with five blanks and a rule that it goes out incomplete rather than late, and reserve the engineering judgement for the 72 hour notification, where it is actually being asked for.
Takeaway: treat the 24 hour early warning as a notification task with a fixed form, not an investigation deliverable.
5. Non-EU manufacturers: your authorised representative picks your CSIRT
Reports go through the CRA Single Reporting Platform, which ENISA is responsible for establishing under Article 16, to your coordinating CSIRT. That CSIRT then shares the notification with CSIRTs in other territories where the product is available, and with ENISA. ENISA's SRP page is the place to watch for platform status.
Here is the bit that catches non-EU teams. The coordinating CSIRT is determined by your main establishment in the Union, and if you do not have one, by the establishment of your authorised representative, the entity you appoint by written mandate under Article 18 to hold documentation and deal with market surveillance authorities. A startup in Bengaluru, Singapore, Dubai or Austin that has not appointed one does not merely lack a compliance nicety. It lacks the address that decides where its reports go.
The platform itself has had a bumpy run in. Community tracking through mid-2026 reported the SRP was not yet live as the deadline closed in. You cannot register before it opens, but you can decide now who holds the account and make sure that person is reachable out of hours.
Takeaway: appoint the authorised representative first, because it resolves the CSIRT question, and nominate the two humans who will hold SRP credentials.
6. The awareness pipeline is the real September deliverable
An obligation that starts on awareness is only as good as the paths by which awareness arrives, and in most small teams those paths exist but are not wired to anything. A researcher emails an address nobody owns. An abuse report lands in a support queue and gets tagged as a billing question.
The concrete work is short. Publish a coordinated vulnerability disclosure contact and route it to a real rota, not an alias with no owner. A security.txt file under RFC 9116 costs an hour and makes you findable by the people most likely to hand you a report. Then define in writing who is allowed to declare awareness, because if everyone can, nobody does.
The second half is telemetry that can distinguish exploitation from noise. You do not need a detection platform for this. You need enough log retention on the product's own paths, and enough alerting on authentication and privilege changes, that when a researcher tells you something is being exploited you can reach a reasonable degree of certainty in hours rather than days. Practitioner opinion: at seed stage the binding constraint here is retention and searchability, not detection sophistication.
Takeaway: before September, ship a disclosure contact, a named awareness owner, and log retention long enough to confirm or rule out exploitation.
7. SBOM and vulnerability handling under Annex I Part II
Annex I Part II sets the vulnerability handling requirements, and it is the part of the December 2027 package worth starting early because it feeds the September work. It requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used machine readable format covering at least the top level dependencies of the product. It also requires addressing vulnerabilities without delay, applying effective and regular tests, publicly disclosing fixed vulnerabilities with remediation information, and having a coordinated disclosure policy.
Commonly used machine readable format in practice means SPDX or CycloneDX. The regulation does not name a format, and you should not wait for it to. Generating one in CI is a small job and it pays for itself the first time a dependency advisory lands and someone asks whether you ship the affected version.
Takeaway: note the phrase "at least the top level dependencies". The floor is lower than the transitive-everything SBOM tooling vendors describe, so add generation to CI now at top level scope, store the artefact per release, and treat depth as a later optimisation.
8. The support period, and the dependencies that will expire under you
Article 13 requires manufacturers to determine a support period during which vulnerabilities are handled effectively, reflecting how long the product is reasonably expected to be in use. That period must be at least five years unless the product's expected lifetime is shorter, and the end date of the support period has to be communicated to users. The Commission's legislative summary covers this alongside the user information obligations.
Five years is a long time in a dependency tree. If you ship something in 2028 on a runtime whose upstream support ends in 2030, you have quietly signed up to keep it patched for the remaining stretch, or to a migration you have not planned. Anyone who has carried a product on an end of life runtime knows how that goes.
Practitioner opinion: the useful exercise is not a support policy document. It is putting the upstream end of life dates for your top ten dependencies next to your intended support period in one table and looking at the gaps.
Takeaway: pick a support period you can defend, then check it against upstream end of life dates before publishing it.
9. Penalties, proportionality, and what not to over-build yet
Article 64 sets administrative fines of up to 15 million euro or 2.5 percent of total worldwide annual turnover, whichever is higher, for breaching the essential requirements in Annex I or the obligations in Articles 13 and 14. Lesser infringements carry a lower cap. The regulation also directs authorities to consider the size of the economic operator, explicitly including micro, small and medium enterprises, when setting an amount. That is a real proportionality lever, not a licence to ignore the obligation.
Now the deferral list. As of mid-2026 no CRA harmonised standard had been cited in the Official Journal, so the Article 27 presumption of conformity was not yet available for any product category, and the Commission had proposed pushing the 2026 standardisation deadlines back. Building a conformity assessment programme against standards that do not exist yet is the clearest way to waste a quarter.
Takeaway: do the reporting readiness work now, and hold the conformity assessment work until the standards are cited in the Official Journal.
Summary: what is due when
| Obligation | Applies from | What a non-EU startup actually does |
|---|
| Scope determination | Now | List every artefact a European customer installs, plus any backend essential to it |
| Authorised representative (Art. 18) | Before you report | Appoint by written mandate; this fixes your coordinating CSIRT |
| Exploited vulnerability and severe incident reporting (Art. 14) | 11 Sep 2026 | 24 hour early warning, 72 hour notification, 14 day or one month final report via the SRP |
| Coordinated disclosure channel (Annex I Part II) | Prerequisite for Sep | Published contact, security.txt, named awareness owner and rota |
| SBOM, top level dependencies (Annex I Part II) | 11 Dec 2027 | Start now in CI, SPDX or CycloneDX, one artefact per release |
| Support period, minimum five years (Art. 13) | 11 Dec 2027 | Pick a defensible period, check it against upstream end of life dates, publish it |
| Technical documentation, conformity assessment, CE marking | 11 Dec 2027 | Defer detailed work until harmonised standards are cited in the Official Journal |
| Penalties (Art. 64) | With each obligation | Up to 15m euro or 2.5 percent of worldwide turnover; SME size is a stated factor |
By stage
Pre-seed. Spend a day on scoping and stop there if the answer is no. If you do ship an installed artefact, the September package is one focused week: representative, disclosure contact, awareness owner, report template. Do not buy compliance software.
Seed. Same package, plus SBOM in CI and log retention long enough to answer the exploitation question. This is also where the support period starts costing real money, because the dependency choices you make now are the ones you will be patching in 2031.
Series A. You probably have an EU establishment or are about to, which changes the CSIRT answer, and you have enterprise buyers who will ask for your CRA position in security review long before December 2027. Give the technical documentation and conformity assessment track a real owner, and start it once the first harmonised standards are cited.
The short version
Scope it honestly, because most pure SaaS is out and most installed software is in. If you are in, September 2026 is an operational readiness problem rather than an engineering programme: an authorised representative, a disclosure channel that reaches a human, a named person who can declare awareness, and a report template that goes out incomplete rather than late. The larger build waits for December 2027 and for standards that do not exist yet.
If you want a second pair of eyes on whether the CRA touches your product and what the September package looks like for your stack, I do a short no-obligation review and tell you what I would do first. No NDA needed for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for pre-seed and seed startups across India, the GCC, Singapore, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.
Methodology note. Dates, obligations and article numbers come from Regulation (EU) 2024/2847 and the European Commission's CRA policy page, reporting obligations page, and summary of the legislative text. Single Reporting Platform status is from ENISA and community tracking at cyberresilienceact.eu. Scope and open source questions draw on the ORC Working Group's CRA FAQ and DLA Piper's SaaS boundary analysis. No client environments, audit counts, engagement outcomes, or currency figures beyond the penalty caps stated in the regulation appear anywhere in this post. Sequencing advice and stage recommendations are practitioner judgement, labelled inline, not official guidance. This is not legal advice; scope determination for a specific product is a question for counsel. Standardisation timelines and platform readiness were still moving through 2026, so verify current status before acting.
