Something happened. When did you become aware?

The Cyber Resilience Act for a small software manufacturer, in twelve steps

Everything a ten-person company that ships installed software or a device has to do under the CRA, in the order to do it: the scope determination, the tier, the CSIRT and the enforcer, the reporting procedure that has applied since 11 September 2026, then the technical file, the 22 requirements, the SBOM, the support period, the CE mark and the declaration due by 11 December 2027. Each step with its article and the piece that explains it.

Which CSIRT do you report to under CRA Article 14? All 27 coordinators, as ENISA lists them

Every guide to the Cyber Resilience Act's reporting duty says 'notify your national CSIRT' and stops. Since 10 September 2026 ENISA publishes the CSIRT designated as coordinator for each of the 27 member states. Here is that list, the rule that picks the state, and the two states where the coordinator is not the national CSIRT.

How to file a CRA notification on ENISA's single reporting platform, from its own manual

The platform opened on 11 September 2026 at portal.cra-srp.enisa.europa.eu. Who can log in, which coordinator to pick, what each of the three submissions asks for, what the platform's own counter gets wrong, and when you may ask for dissemination to be delayed. Read from ENISA's guidance, FAQ, glossary and terms, not from a summary of them.

When does the CRA's 24-hour clock start? 'Becoming aware', from the Commission's guidance

The 24 and 72 hours run from the moment the manufacturer 'becomes aware', and the Regulation never says what that means. The Commission's guidance of 27 July 2026 does, in paragraphs 211 to 218: a reasonable degree of certainty, after an initial assessment, borrowed word for word from the NIS2 implementing regulation and the GDPR breach guidelines. What that makes of a customer email, a scanner alert, a listed CVE in a component, a bug-bounty zero-day, and a vulnerability you knew about before 11 September.

The CRA final report clock does not start when you become aware

Most write-ups of Cyber Resilience Act Article 14 give three deadlines from one starting point: 24 hours, 72 hours, 14 days. The first two run from awareness. The third does not, and for a vulnerability its anchor is a date that may not exist yet. Here is what the Regulation says, paragraph by paragraph.

Is your product in scope of the Cyber Resilience Act? Where SaaS sits

The most-asked CRA question is not how to report, it is whether the Regulation applies to you at all. Pure software as a service is out and inside NIS2; installed and downloadable software is in; remote processing a product cannot work without is back in. The determination is yours to make and record. Here is the text that decides it.

When is software 'placed on the market' under the CRA, and which of your builds is a product? The guidance's rule for standalone software

Everything in the CRA hangs on a date and a noun: the date a product is placed on the market, and whether what you ship is a product at all. For standalone software the Commission's guidance of 27 July 2026 answers both in paragraphs 13 to 21: a version is placed on the market once, when first offered, and every later download of it counts from that day; per-OS builds and feature bundles are separate products; a web app used in a browser is not a product, a browser extension or an installed client is. What that means for 11 December 2027, for betas, and for old versions you keep online.

Which parts of your backend are inside the CRA? Remote data processing, from the Commission's guidance

A product with digital elements includes its remote data processing solutions, and the Regulation defines them in one sentence. The Commission's guidance of 27 July 2026 turns that sentence into two cumulative tests, a boundary rule, a list of what is never in (CI/CD, HR, CRM, telemetry, websites), the SaaS, PaaS and IaaS cases, and a worked mobile banking example. For a software company with an app and a cloud, this is the line.

Who enforces the Cyber Resilience Act in your member state? 7 of 27 have said

The CRA is enforced nationally, by a market surveillance authority each member state designates and registers with the Commission. On 11 September 2026, the day the reporting duty applied, seven states had registered one. Here is the register, state by state, including the twenty that have not, and what that means for a small manufacturer asking who will come knocking.

Is your product important or critical under the Cyber Resilience Act? Annex III and IV in full

Once a product is in scope of the CRA it is default, important (class I or II) or critical, and the tier decides whether you can self-assess or need a notified body. Here are the 19, 4 and 3 categories verbatim from the Official Journal, what each tier changes under Article 32, and the one thing the tier does not change.

Default, important or critical: the 26 technical descriptions of Implementing Regulation 2025/2392, and the core-functionality test

Annex III and IV of the CRA name 26 product categories in a line each. Commission Implementing Regulation (EU) 2025/2392, in force since 21 December 2025, describes each one technically, and the Commission's guidance of 27 July 2026 says how to classify against them: by the product's core functionality, not by what it also does or what it integrates. All 26 descriptions verbatim, the guidance's six rules with its examples (SOAR is not a SIEM, a log viewer is not a SIEM, a router with a firewall is a router), and what the classification changes.

CRA Annex I: the 22 essential requirements, as a checklist

Annex I of the Cyber Resilience Act is what your product has to meet from 11 December 2027 and what the technical file has to show. Part I is 14 product requirements, 13 of them 'where applicable' on the basis of your risk assessment; Part II is 8 vulnerability-handling requirements that always apply. Here they are as one table, with what each one asks and whether you may exclude it.

What goes in the CRA technical file: Annex VII, point by point

From 11 December 2027 every product with digital elements placed on the EU market needs technical documentation before it is placed, kept for ten years or the support period, whichever is longer. Annex VII says what it contains in eight points. Here they are, what each one actually asks for, the four documents Part II of Annex I presumes exist, and how long you keep it.

Does the CRA require an SBOM? Yes, and here is exactly what it says

Annex I, Part II, point 1 of the Cyber Resilience Act requires a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. It goes in the technical file, it is not published, and a market surveillance authority can ask for it on a reasoned request. The three sentences that decide it, and what they leave open.

What the CRA asks of you for your dependencies: due diligence, reporting upstream, and known exploitable vulnerabilities, from the Commission's guidance

A software product is mostly other people's code. The CRA makes the manufacturer responsible for the product as a whole and gives it three duties towards the components inside it: due diligence under Article 13(5), reporting vulnerabilities upstream and sharing fixes under Article 13(6), and placing the product on the market without known exploitable vulnerabilities. The Commission's guidance of 27 July 2026, sections 3.4, 7.3 and 9.2, says what each one takes and what it does not: no duplicate reports, no obligation to get your fix merged, and a definition of 'known' that includes the CVE database and the news.

CRA or NIS2: which one applies to a software company, and can it be both?

The Cyber Resilience Act regulates products placed on the market; NIS2 regulates entities that provide services. A software company can be under one, the other, both or neither, and the answer turns on two questions: do you place a product on the market, and are you a medium-sized or larger entity in a listed sector. The dates, the reporting clocks, the fines and the decision table, from the two texts.

NIS2 or CRA: which incident clock runs for a software company, and what makes an incident 'significant'

Both laws give you 24 hours, 72 hours and a month, and both start the clock when you 'become aware'. Almost everything else differs: what triggers it, who receives it, on which platform, and what counts. NIS2 Article 23 and Implementing Regulation 2024/2690 for the company that runs a cloud service; CRA Article 14 for the company that ships a product; both for the company that does both. The thresholds, criterion by criterion, and one procedure that satisfies the two.

Does software need a CE mark under the CRA? Yes, and Article 30 says where it goes

From 11 December 2027, a CE marking is required on every product with digital elements placed on the EU market, software included. For software the mark goes on the EU declaration of conformity or on the website accompanying the product, before it is placed on the market. What the mark asserts, who can affix it, when a notified body's number joins it, and what the declaration behind it must contain.

The EU declaration of conformity under the CRA: Annex V point by point, the simplified form, and a worked example

Article 28 makes the manufacturer draw up an EU declaration of conformity before the product is placed on the market, in the model structure of Annex V, and Article 28(4) makes signing it the act by which the manufacturer assumes responsibility for the product. The eight points of Annex V, the one-sentence simplified form of Annex VI, the rules around it (languages, the single declaration, product families, 10 years of retention), a worked example, and what a missing or incorrect declaration costs under Article 58 and Article 64.

Self-assessment under the CRA: what module A actually requires, from Annex VIII and the Commission's FAQ

Most software products will never see a notified body. They use module A, the internal control procedure of Annex VIII, and 'self-assessment' is the word everyone uses for it without saying what it contains. Annex VIII Part I is five points; the Commission's FAQ adds the list of activities, the fact that no test methodology is mandated, where a software product carries its CE mark, the two forms of the declaration of conformity, and the harmonised standards timeline that decides when self-assessment stops meaning 'against Annex I directly'.

Harmonised standards for the CRA: what request M/606 asks for, when, and what a manufacturer has today

Article 27 gives a presumption of conformity to products that follow harmonised standards cited in the Official Journal. On 3 February 2025 the Commission asked CEN, CENELEC and ETSI for 41 of them, with deadlines from 30 August 2026 to 30 October 2027; the three accepted on 3 April 2025. On 12 September 2026 the Commission's index of harmonised standards still has no entry for the Regulation, which for a class I product means no self-assessment route under Article 32(2). What was requested, the dates, and what to build against in the meantime.

How long is the CRA support period? At least five years, and three other clocks attached to it

Article 13(8) of the Cyber Resilience Act requires a support period of at least five years, or the expected time in use if shorter, during which vulnerabilities are handled. Its end date must be shown at purchase, at least the month and year. Security updates must stay available for ten years or the support period. And the technical file, declaration and user information are kept for the same. The four clocks, from the text.

Which update puts your existing software under the CRA? Substantial modifications, from the Commission's guidance

Software placed on the market before 11 December 2027 stays outside the CRA's design and conformity duties until it is substantially modified. The Commission's guidance of 27 July 2026 says what that means for a software update in paragraphs 103 to 113 and 122 to 124, with eleven worked examples: a risk not in your risk assessment, not the size of the diff. Security updates are generally out; a 'remember me' checkbox can be in. What to write into every release, and what the first substantial modification does and does not trigger.

What you have to report under the CRA: the two triggers, as the Regulation defines them

Article 14 has two triggers and both are defined in the text. An actively exploited vulnerability is one with reliable evidence that a malicious actor has exploited it in a system without the owner's permission (Article 3(42)). A severe incident is one that affects, or can affect, the product's ability to protect sensitive data or functions, or that leads, or can lead, to malicious code in the product or a user's systems (Article 14(5)). What is in, what is out, and the duty to tell users that comes with both.

Does the CRA apply to open-source software? Three cases, and the light regime for stewards

The Cyber Resilience Act reaches free and open-source software only when it is supplied in the course of a commercial activity. A non-monetised project is out. A company that ships a product built on open-source components is a manufacturer of that product. And foundations and companies that sustain open-source products intended for commercial use are 'open-source software stewards' under Article 24: a cybersecurity policy, cooperation with authorities, and a narrowed reporting duty, with no CE mark and no technical file. The recitals and the article, quoted.

Is your open-source project 'commercial' under the CRA? The Commission's seven tests, with its examples

The CRA reaches free and open-source software only where it is supplied in the course of a commercial activity, and the Regulation leaves 'commercial' to two recitals. The Commission's guidance of 27 July 2026, section 3, turns them into seven tests: a price, a paid edition or open core, monetising other services or personal data, support services, donations, sponsorship, and not-for-profit status, with 22 examples. Where a maintainer, an open-core company and a foundation each land, and what a pull request makes you.

What the CRA asks of importers and distributors, and when it makes them the manufacturer

If you resell software or devices into the EU rather than build them, Articles 19 and 20 of the Cyber Resilience Act give you a checklist to run before the product goes on sale, a duty to pass vulnerabilities to the manufacturer, a duty to tell authorities about significant risks, and ten years of record-keeping. Article 21 turns you into the manufacturer the moment you sell under your own brand or substantially modify the product. The obligations, from the text.

The EU's own CRA machinery, on the day the duty started: 0 notified bodies, 0 harmonised standards, 7 of 27 enforcers

The Cyber Resilience Act asks manufacturers to be ready. Here is how ready the institutions it depends on were on 11 and 12 September 2026, read from the Commission's own registers: no conformity assessment body notified under the CRA, no harmonised standard published in the Official Journal, seven member states with a registered market surveillance authority, thirteen with a notifying authority, and the coordinator CSIRT list published the day before, with two states naming a body other than their national CSIRT. What that means for a manufacturer with a class I product, and what to record.

The CRA cybersecurity risk assessment: what Article 13 actually requires, and the one output it must produce

Article 13(2) to (4) of the Cyber Resilience Act make the risk assessment the document every other CRA obligation hangs off. It must analyse risks from the intended purpose, foreseeable use and conditions of use over the expected time in use; state whether and how each Part I, point 2 requirement applies; say how Part I, point 1 and Part II are applied; be documented, kept updated over the support period, and included in the technical file, with a clear justification for every requirement left out. The four paragraphs, and a one-page structure that satisfies them.

The coordinated vulnerability disclosure policy the CRA requires: three provisions, and a one-page policy that meets them

Annex I, Part II, point 5 of the Cyber Resilience Act requires every manufacturer in scope to put in place and enforce a coordinated vulnerability disclosure policy. Article 13(17) requires a single point of contact for reporting that is easy to find and not limited to automated tools; Annex II, point 2 requires the contact and the policy's location in the user information; Annex VII, point 2(b) puts both in the technical file. What each provision asks, what a policy must say, and what it must not promise.