Cyber Resilience Act reporting obligations have applied since September 11, 2026. Under Article 14 of Regulation (EU) 2024/2847, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform: an early warning within 24 hours, then a notification within 72 hours. Software vendors selling into Europe should expect buyers to ask about it now.
Below: the dated timeline with article numbers, who is in scope (including the unsettled SaaS question), what buyers are likely to ask and six steps for go-to-market teams. Every date and obligation comes from the regulation on EUR-Lex, the European Commission's CRA pages and guidance, or ENISA.
What applies from September 11, 2026, and what applies later
The CRA entered into force on December 10, 2024, but Article 71(2) switches its parts on at different dates. Status as of September 14, 2026.
| Date | What applies | Article | Source |
|---|---|---|---|
| December 10, 2024 | Regulation enters into force | 71(1) | European Commission |
| June 11, 2026 | Chapter IV: notification of conformity assessment bodies | 35 to 51; 71(2) | EUR-Lex |
| September 11, 2026 | Manufacturers report actively exploited vulnerabilities and severe incidents, including for products placed on the market before December 11, 2027 | 14; 69(3); 71(2) | European Commission, ENISA |
| December 11, 2027 | Full application: essential cybersecurity requirements in Annex I, vulnerability handling, conformity assessment, market surveillance, and reporting by open-source software stewards under Article 24(3) | 71(2) | Commission FAQ, sections 5.5 and 7.1 |
The reporting clocks under Article 14
| Step | Actively exploited vulnerability, Article 14(2) | Severe incident, Article 14(4) |
|---|---|---|
| Early warning | Within 24 hours of becoming aware, naming the Member States where the product is made available, where applicable | Within 24 hours, including whether unlawful or malicious acts are suspected |
| Notification | Within 72 hours: the product, the nature of the exploit and vulnerability, and corrective or mitigating measures, including ones users can take | Within 72 hours: the nature of the incident, an initial assessment and corrective or mitigating measures |
| Final report | No later than 14 days after a corrective or mitigating measure is available | Within one month after the 72-hour incident notification |
- Where reports go. Simultaneously to the CSIRT designated as coordinator and to ENISA, via the Single Reporting Platform established under Article 16 (Article 14(1), (3) and (7)). A manufacturer with no main establishment in the EU uses the CSIRT of a Member State set by an order in Article 14(7), starting with where its authorized representative is established.
- What counts. An actively exploited vulnerability is one with "reliable evidence that a malicious actor has exploited it" (Article 3(42)). An incident is severe if it harms, or could harm, the product's ability to protect sensitive or important data or functions, or leads to malicious code running (Article 14(5)).
- When the clock starts. The Commission's July 27, 2026 guidance says a manufacturer becomes aware once an initial assessment gives it a reasonable degree of certainty. It adds that exploitation known before September 11, 2026 need not be reported retroactively.
- Telling users. Article 14(8) requires informing impacted users and, where appropriate, all users. The guidance says this is risk-based and does not necessarily mean public disclosure.
Who is in scope, and the SaaS question
What counts as a product with digital elements
Article 2(1) applies the CRA to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Article 3(1) defines the product as "a software or hardware product and its remote data processing solutions," including components placed on the market separately. Article 2 then sets exclusions, including products covered by certain other EU laws, such as the Medical Devices Regulation. The Commission's FAQ gives examples: downloadable apps and programs, firmware, and software shipped with hardware. Scope follows the EU market, not the vendor's headquarters.
Remote data processing and pure SaaS
Article 3(2) defines remote data processing as processing at a distance, with software designed and developed by or under the responsibility of the manufacturer, "the absence of which would prevent the product with digital elements from performing one of its functions."
- Recital 12 says cloud solutions are remote data processing solutions only if they meet that definition. Cloud features a device maker provides so users can control the device at a distance are in scope. Cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements are not. It adds that the NIS2 Directive applies to cloud computing services, including SaaS, PaaS and IaaS.
- The Commission's FAQ (section 1.2) says standalone SaaS designed outside the responsibility of a manufacturer of a product with digital elements is not itself such a product, but services that meet the remote data processing definition are in scope. The FAQ also states that it is not authoritative.
- The July 27, 2026 guidance (section 8.1) sets two cumulative questions: would the product lose a function without the processing, and was the software designed and developed by the manufacturer or under its responsibility? Examples of such functions include sending commands to a device, synchronizing files, onboarding, configuration, updates and identity and access management. Third-party SaaS built into a product is treated like a component, and internal systems such as CRM, HR and CI/CD pipelines are not remote data processing.
What that means for a SaaS vendor
- Installable software made available in the EU, such as desktop or mobile apps, endpoint agents, on-premises editions or firmware, fits the FAQ's examples of products with digital elements when the other conditions are met. A cloud back end you build that the product needs to perform a function can be part of that product.
- Browser-only SaaS with nothing installed is, on the Commission's reading, not itself a product with digital elements. That is guidance, not a court ruling.
- Mixed offerings, such as a platform plus a mobile app, browser extension, SDK or on-premises connector, are where the official texts do not give one answer for every architecture. Get legal advice before telling a buyer you are in or out of scope. Whether NIS2 applies to your company is a separate question.
What European buyers will ask
Expect CRA questions in security questionnaires, vendor risk reviews and late-stage calls, alongside the third-party risk questions that followed this year's SaaS incidents, covered in our post on SaaS breaches as buying triggers. These are the questions we expect, not survey results:
- Is your product a product with digital elements under the CRA, and on what basis?
- Who decides when you are "aware", and can you meet the 24-hour and 72-hour clocks?
- Which Member State's CSIRT receives your notifications?
- How and when will you tell us if we are an impacted user?
- Do you publish a coordinated vulnerability disclosure policy and a contact for vulnerability reports? Annex I, Part II requires both from December 11, 2027 for products placed on the market from that date.
- Can you provide a software bill of materials? Annex I, Part II, point (1) requires one covering at least top-level dependencies on the same timeline.
- If you say you are out of scope, how do you handle vulnerabilities and incidents anyway, and what will the contract commit to?
Six steps for vendor go-to-market teams
- Confirm scope with counselMap every product against Articles 2 and 3.
- Publish a dated disclosure pageSecurity contact, policy and CRA status.
- Build a CRA readiness packOne approved document set for sales.
- Train SDRs and AEsAccurate answers and a clear escalation path.
- Add answer-ready FAQsSo AI search repeats you accurately.
- Review quarterlyGuidance and standards are still arriving.
1. Confirm scope with counsel
List everything you make available in the EU: web app, mobile apps, agents, browser extensions, SDKs and on-premises editions. For each, record whether it is a product with digital elements, which cloud services pass the two-question test for remote data processing and which third-party SaaS you treat as components. Name who declares awareness and who submits to the Single Reporting Platform. Get counsel's sign-off and date it.
2. Publish a dated security and vulnerability disclosure page
Include a contact for vulnerability reports, your coordinated vulnerability disclosure policy, how customers hear about vulnerabilities and incidents, and a short CRA status statement with a "last reviewed" date. Say what you have done and when, and avoid blanket labels like "CRA compliant." Treat it as a conversion page, linked from the footer, the demo request flow and security content, and test it like one with conversion rate optimization.
3. Prepare a CRA readiness pack for sales
One approved set: the scope position, a one-page summary of the Article 14 process with roles and clocks, user notification commitments, the disclosure policy, software bill of materials plans, how you will set support periods under Article 13(8) and how you vet third-party components. Store it next to your security questionnaire answers with an owner and a date. Our B2B SaaS programs put packs like this in front of evaluators before procurement asks.
4. Train SDRs and AEs on accurate answers
Three rules: never claim scope or compliance beyond the approved statement, know the two dates that matter (September 11, 2026 and December 11, 2027) and hand detailed questions to security or legal. A safe answer: "Reporting under Article 14 has applied since September 11, 2026. Our scope position for this product is in our CRA readiness pack, reviewed by counsel on [date]. I will bring in our security lead for anything beyond that." Cybersecurity vendors whose products help manufacturers meet these obligations should hold outbound claims to the same standard.
5. Add answer-ready FAQs for AI search
Evaluators may also ask AI assistants whether a vendor is covered by the CRA. If your site says nothing, the answer rests on guesswork. Publish short, dated question-and-answer blocks on the trust page that match your approved position, so answer engines have something accurate to quote, as part of your AEO, GEO and SEO work.
6. Review quarterly
The Commission's implementation page lists standardization deliverables for Q3 2026 and more by October 30, 2027, and the FAQ is a living document, last revised July 1, 2026. Each quarter, and after any new guidance, recheck scope, the page, the pack and the scripts, then update every "last reviewed" date.
This is not legal advice
This post summarizes Regulation (EU) 2024/2847, European Commission guidance and FAQs, and ENISA material as of September 14, 2026. It is not legal advice. The Commission's FAQs say they are not authoritative, and only the Court of Justice of the European Union can authoritatively interpret EU law. Have counsel confirm whether and how the CRA applies to your products before you publish a statement or answer a buyer.
Where Lemniscate fits
Lemniscate Growth builds revenue pipeline for B2B SaaS, AI and cybersecurity vendors from the US, India, Singapore and the GCC, many of which sell into Europe. We turn approved security positions into trust pages, sales enablement and AI search answers, then point ABM and outbound at the accounts that will ask. The Aavenir case study shows the approach for an enterprise SaaS platform: search and website content took it from single-digit to tens of qualified meetings a month. Book a free growth audit to map what your trust content, sales team and AI search answers should say.
