The Cyber Resilience Act: your product, not your estate

What the CRA regulates

Regulation (EU) 2024/2847 sets cybersecurity requirements for products with digital elements — software and hardware placed on the EU market, together with their remote data processing solutions. It is product legislation in the CE-marking tradition: conformity assessment under Article 32, an EU declaration of conformity under Article 28, the CE marking under Article 30, and market surveillance under Article 52. The nearest relatives are the toy and machinery directives, not NIS2.

That parentage decides who carries the duties. The obligations fall on the manufacturer — Article 13 runs to twenty-five paragraphs of them — with importers and distributors picking up their own duties further down the chain, and Article 24 giving open-source software stewards a deliberately lighter regime. There is no "entity in scope" test the way NIS2 has one: if you place an in-scope product on the EU market, you are in.

The substance sits in Annex I. Part I lists the security properties the product itself must have — secure-by-default configuration, protection of confidentiality and integrity, minimisation of attack surface, and the rest. Part II lists the vulnerability handling requirements: an SBOM covering at least the product's top-level dependencies, remediating vulnerabilities without delay, a coordinated disclosure policy, and secure distribution of security updates.

Official text: Regulation (EU) 2024/2847

The dates, and the one that arrives first

The Regulation entered into force on 10 December 2024 and applies in full from 11 December 2027. Two pieces arrive earlier: Chapter IV, on notified bodies, has applied since 11 June 2026 — and Article 14, the reporting obligation, applies from 11 September 2026.

Article 69(2) softens the picture for existing products: anything placed on the market before 11 December 2027 is caught only if it is substantially modified after that date. Then Article 69(3) takes the softening away for the piece that matters soonest — by way of derogation, Article 14 applies to all in-scope products already on the market. The reporting duty is not deferred to 2027, and it is not limited to new products.

So the first CRA obligation most manufacturers will feel is a clock: from 11 September 2026, an actively exploited vulnerability in a product you shipped years ago starts a 24-hour timer. At the time of writing that is five weeks away.

The penalty ceiling gives the dates their weight. Article 64(2) sets administrative fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher, for non-compliance with Annex I or with Articles 13 and 14.

Article 14, in practice

Two triggers, one pipeline. A manufacturer that becomes aware of an actively exploited vulnerability in its product, or of a severe incident having an impact on the product's security, notifies the CSIRT designated as coordinator and ENISA simultaneously, via the single reporting platform established under Article 16.

The phrase carrying the load is "becoming aware". A manufacturer that learns of exploitation on day one and starts drafting on day six has already missed two deadlines. Meeting a 24-hour clock is a property of your detection and escalation path, not of your legal team — which makes it the one part of Article 14 you can rehearse in advance.

Article 13: the duties behind the CE mark

Article 13 is the manufacturer's core obligation set. The product must be designed, developed and produced in accordance with the essential requirements of Annex I, on the basis of a documented cybersecurity risk assessment that is kept updated and that informs which Annex I requirements apply and how they are implemented.

Article 13(8) adds the commitment with the longest tail: a support period, determined by how long the product is expected to be in use, and — without prejudice to that assessment — at least five years, unless the expected use time is shorter. For that whole period, vulnerabilities in the product and its components must be handled in accordance with Annex I Part II. A support period is a promise about your engineering organisation years from now, which is why it belongs in product planning and not in a compliance binder.

Around this sit due diligence on third-party components, technical documentation, the conformity assessment route — self-assessment for the default class, third-party involvement for important and critical products — the declaration of conformity, and the CE marking. All of it is the manufacturer's own work, and none of it can be observed from outside.

The line most compliance marketing blurs

NIS2 regulates an entity. DORA regulates a financial entity and its ICT suppliers. Both ask questions about an organisation, and an organisation leaves observable traces — certificates, DNS records, mail policies, handshakes. That is why an outside-in monitor can honestly supply part of the evidence for those two frameworks.

The CRA asks a question about the shipped artifact. An external monitor has never seen your product: not its binary, not its update mechanism, not its default configuration, not its dependency tree. An organisation can hold a flawless external estate and still ship a non-conformant product — and the reverse is just as possible.

The honest consequence: no monitoring product, ours included, can claim CRA conformity coverage. What external monitoring can do is narrower — evidence a small number of Annex I properties as they appear on the manufacturer's own estate, clearly labelled as being about the estate, plus one genuinely operational contribution: the detection speed that Article 14's clocks assume you have.

What SkyQon evidences, stated exactly

SkyQon's evidence report carries a CRA section — it is not a separate product. The section opens with a scope statement saying, in as many words, that it is not a statement of CRA conformity and that SkyQon does not assess products. It maps exactly two Annex I properties, and the mapping text below is rendered verbatim into the signed PDF from a versioned regulatory mapping.

Two rows, both carrying the same label. Each also carries a scope note in the report stating what the requirement governs inside the product — confidentiality protections in the shipped artifact, secure boot, signed updates — and that SkyQon does not observe any of it. The section's second half is the list of obligations that remain entirely yours, enumerated because a gap you declared reads very differently from a gap an assessor finds.

Beyond the report, continuous monitoring makes one operational contribution to Article 14: detection with timestamps. A 24-hour early-warning clock is survivable when awareness arrives from monitoring rather than from a customer, and the dated record of when you became aware is itself the first artifact a regulator will ask about.

What stays entirely yours

The report names these because manufacturers routinely assume an existing corporate security programme already covers them. It generally does not — they are product-side duties, and every one of them is quoted or derived from the Official Journal text.

• A product SBOM — machine-readable, covering at the very least the product's top-level dependencies (Annex I Part II (1)). A cryptographic inventory of your estate is a useful input to this work; it is a different artifact about a different system, and it does not discharge the duty.
• Remediating product vulnerabilities without delay — including security updates shipped separately from functionality updates where technically feasible (Part II (2)).
• A coordinated vulnerability disclosure policy — put in place and enforced (Part II (5)). An existing corporate security policy is generally not this.
• Secure distribution of security updates — disseminated without delay and free of charge, with advisory messages (Part II (7) and (8)).
• Secure-by-default configuration and updates by default — design-time product properties (Part I (2)(b) and (2)(c)) that no external observer ever sees.
• Article 14 reporting itself — the notifications to the coordinating CSIRT and ENISA are yours to make; monitoring can start your clock honestly, not submit for you.

A practical sequence

• Classify your products first. Which of what you ship is a product with digital elements, which class it falls into, and which conformity route follows. Everything else in the CRA is scoped by this answer.
• Rehearse the Article 14 clock before September 2026. Run the drill: exploited vulnerability reported on a Friday evening — who becomes aware, when, and who has the platform credentials to file within 24 hours. The installed base is in scope, so this is not gated on your next release.
• Build the SBOM from the build system, not from a survey. Hand-assembled dependency lists rot; Annex I asks for something a pipeline can regenerate on every release.
• Decide the support period as a product decision. Five years of vulnerability handling is an engineering commitment. Price it, staff it, and write down which components you depend on third parties for.
• Publish the disclosure policy. A coordinated vulnerability disclosure policy is cheap to write, visible to everyone, and one of the first things a market surveillance authority can check without asking you anything.
• Keep estate evidence and product conformity in separate folders. Both are real work. Mixing them is how over-claims happen, and an over-claim on a CE-marked product is a conversation with a market surveillance authority.

Common questions

Companion guide: NIS2 Article 21(2) — what counts as evidence · DORA — what counts as technical evidence