The Cyber Resilience Act (CRA) and your cryptography dependencies.

The Cyber Resilience Act, Regulation (EU) 2024/2847, is the European Union's product-cybersecurity law. It sets mandatory requirements for products with digital elements made available on the EU market, a category that covers hardware and software whose intended use includes a direct or indirect data connection to a device or network. The obligations fall on economic operators, principally the manufacturer that places a product on the market, and they apply whether the product is sold, monetized, or supplied free of charge.

For a company that ships a product containing the OpenSSL Library, the question that matters is what the Act requires of the product, and how a cryptographic dependency fits into it.

The timeline.

The Act entered into force on 10 December 2024, which started the clock without imposing immediate obligations. The framework for notifying conformity assessment bodies has applied since 11 June 2026. The reporting obligations apply from 11 September 2026, and they reach products already on the market, not only new ones. The remaining obligations, including the essential cybersecurity requirements, conformity assessment, CE marking, and technical documentation, apply in full from 11 December 2027, the end of a thirty-six month transition.

What the Act requires.

The essential requirements run to secure design and development, handling vulnerabilities across a defined support period, and shipping security updates over that period. A product has to be accompanied by technical documentation, including a software bill of materials, and it has to carry a conformity assessment and CE marking before it is placed on the market once the full obligations apply. No single tool or supplier produces compliance; the Act is largely a matter of process and documentation, and individual measures produce evidence for particular requirements.

The reporting obligation is narrower and sooner. From 11 September 2026 a manufacturer has to report actively exploited vulnerabilities and severe incidents to ENISA and its national CSIRT through ENISA's single reporting platform, with an early warning within 24 hours, a fuller notification within 72, and a final report once a corrective measure is available. The Act is enforced with administrative fines reaching, at the top tier, 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher.

Where open source sits.

The Act treats free and open-source software specifically. Software developed or supplied outside the course of a commercial activity is not covered, and for open source the test of commercial activity is monetization, not whether a project receives funding or contributions from commercial entities. A volunteer publishing code is outside the Act.

Between the exempt project and the full manufacturer, the Act creates a category it calls the open-source software steward. Under Article 3, that is a legal person, other than a manufacturer, that systematically and on a sustained basis supports the development of open-source software intended for commercial activities and ensures its viability. The definition is broad enough to cover the major open-source foundations. Stewards carry a lighter set of obligations under Article 24, centered on a documented cybersecurity policy and cooperation with market surveillance, rather than the full manufacturer regime.

What it means for a product that ships the OpenSSL Library.

The practical consequence is that your obligations extend to your OpenSSL Library dependency. You are responsible for handling vulnerabilities in the Library as it sits in your product, for shipping fixes within the support period you have committed to, which the Act floors at five years for most products under Article 13(8), and, from September 2026, for reporting actively exploited issues against the clock. The Act does not accept that the cryptography came from somewhere else.

This is where the maintenance status of the dependency stops being a background detail. A maintained version on a supported line has a path to the fix you are obliged to ship. A version that has reached end of life upstream does not, which makes the OpenSSL Library 3.0 series, reaching end of life on 7 September 2026, four days before the reporting obligation begins, a poor place to be when an advisory lands. For a team that cannot move off an end-of-life line in time, Extended LTS continues security fixes for it and keeps a supported path to the fix in place.

Where a support relationship fits.

A support relationship does not make a product CRA-compliant. Conformity, documentation, and CE marking are the manufacturer's, across the whole product. What it covers is the part of the obligation attributable to the OpenSSL Library: a maintained dependency, security updates across the support period, and advance notice of the issues that start the reporting clock, with the work done by the people who maintain the Library. If you ship cryptography into the EU and want to discuss how that fits your CRA obligations for the OpenSSL Library, get in touch.