Cyber Resilience Act

Regulation (EU) 2024/2847 and the eSeGeCe component libraries. Last updated: August 2026

Where the CRA stands today

Regulation (EU) 2024/2847 entered into force on 10 December 2024, and its obligations arrive in stages:

11 June 2026. The rules on notifying conformity assessment bodies take effect, so the assessment infrastructure starts to exist.

11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and the relevant CSIRT, with an early warning inside 24 hours, a fuller notification inside 72 hours, and a final report once a corrective measure is available.

11 December 2027. The essential cybersecurity requirements, the vulnerability handling requirements, the technical documentation, the EU declaration of conformity and the CE marking all apply in full.

Until December 2027 no product on the market carries a CRA declaration of conformity, because the framework that issues one is still being put in place. Any supplier claiming a completed CRA conformity assessment today is describing something that does not yet exist. What we can do now, and what this page is for, is give you the evidence your own assessment needs.

Product classification

The eSeGeCe component libraries are not listed in Annex III or Annex IV of the Regulation. They are not operating systems, hypervisors, container runtimes, firewalls, intrusion detection systems, VPNs, identity management systems, password managers, boot managers, public key infrastructure, network management systems or any other important or critical class.

They therefore fall in the default category, where conformity is established by the manufacturer under the internal control procedure of Module A rather than by a notified body. For your file, this means integrating our components does not by itself pull your product into a higher conformity assessment class. How your own product is classified depends on what your product does.

Who is responsible for what

You are the manufacturer of the product you place on the EU market, and the CE marking and declaration of conformity for that product are yours. Two articles govern the relationship between us:

Article 13(5). You must exercise due diligence when integrating components sourced from third parties, so that they do not compromise the cybersecurity of your product. The material below is what we provide for that purpose.

Article 13(6). If you find a vulnerability in a component you have integrated, you must report it to whoever maintains that component. For our code, that channel is described in our vulnerability disclosure policy.

What we provide for your due diligence

Complete source code. Every licence includes the full Delphi and C++ Builder source of the components you use. You are not asked to trust a binary, you can review, audit, instrument and rebuild everything you ship. For an Annex I assessment this is the strongest evidence a component supplier can offer, and most commercial component vendors do not provide it.

An SBOM on request. Annex I Part II point 1 requires us to draw up a bill of materials covering at least the top level dependencies and to keep it in our technical documentation, it does not require us to publish it. We maintain ours in CycloneDX format for every release and provide it on request, so it can go straight into your own inventory. Ask through our security page.

A coordinated vulnerability disclosure policy. Published, with a single point of contact, acknowledgement and assessment targets, and a disclosure window, as required by Annex I Part II point 5.

A documented change history. Every release ships a history file recording what changed, including security relevant changes, so you have a written trail of what was fixed and when.

A support period. Security fixes for a major version remain available for at least five years from its release, which meets the minimum in Article 13(8).

Secure by default

Annex I Part I asks that a product be delivered with a secure default configuration, that it protect itself against denial of service, and that its attack surface be minimised. That work is already visible in the product. Recent releases made the WebSocket server rate limit incoming control frames, bounded the number of simultaneous connections instead of accepting an unlimited number, added a maximum request body size to the HTTP/2 server, and restricted browser origins allowed to call an MCP server. Transport security is available through OpenSSL or, on Windows, through SChannel with no external library to deploy at all. These defaults were tightened because they are the right defaults, not because a deadline required them.

What we are preparing

Ahead of the deadlines above we are working towards the technical documentation described in Annex VII, the EU declaration of conformity of Annex V, the CE marking where it applies to us, the information and instructions to users of Annex II, and the internal process for the Article 14 reporting duties that begin in September 2026. We will publish the results here as they are completed. Harmonised standards under the Regulation are still being drafted, and we will align with them once they are available.