"We cannot ship beta versions anymore, they do not yet meet all CRA requirements." I hear this regularly in conversations with manufacturers these days. The concern is understandable. The conclusion is wrong. It costs innovation speed.
What does the CRA say about unfinished software?
The Cyber Resilience Act regulates "products with digital elements", that is, hardware and software made available on the EU market. The central concept here is "placing on the market", the first actual availability on the EU market.
What many do not know: the CRA explicitly excludes unfinished software from this regulatory framework, under certain conditions. Recital 24 of the regulation states that software not yet finalised and provided only for testing purposes does not count as placing on the market. Article 19 CRA fleshes this out and names two conditions under which test software (alpha, beta, release candidate) does not fall under the full conformity duties.
This is not a grey area and not a loophole. It is a deliberate legislative decision to avoid blocking software development processes. Anyone who knows this exemption and applies it correctly can continue to run their testing programmes, legally certain and without conformity overhead for every intermediate version.
For context: a comprehensive overview of the CRA and its core requirements is in our CRA guide.
Why the misconception slows down innovation processes
The mistake arises from too broad a reading of the CRA. Manufacturers see that products with digital elements must meet extensive security requirements, and conclude that every released software version must meet those requirements immediately.
That holds for products actually placed on the market. But for software explicitly made available for testing, this does not apply across the board. The difference does not lie in the technical state of the software, but in its intended purpose and the way it is provided.
An example from practice: a manufacturer of industrial controllers develops a new firmware generation for its machine controls. Three existing customers from machinery construction are meant to test the beta in controlled production environments, real operation, real stress test, real feedback. This is irreplaceable for product development. If the manufacturer now assumes they can only release the beta after a full CRA conformity assessment, they lose months. And the customer waits.
That is not the legislator's intent. It is, however, the consequence of a widespread misconception.
Myth vs. fact
Myth: The CRA bans the release of beta versions and unfinished software because they do not yet meet all security requirements.
Fact: Article 19 CRA explicitly allows the provision of test software. The condition is that the software is available only for the time necessary for testing and that it carries a clear notice that it does not meet CRA requirements and is intended exclusively for testing purposes.
The two conditions for CRA-compliant beta releases
Article 19 CRA names two cumulative conditions. Both must apply. One alone is not enough.
1. Time limitation to what is necessary. The test software may only be available for as long as the testing purpose actually requires. That sounds self-evident but in practice is often the weakest link. Anyone who opens a beta channel and lets it run for months or years leaves the protection of this exemption. Concretely this means: define an upfront runtime for the beta programme. Document it. Make sure the software is no longer obtainable after expiry or after the testing programme ends. A beta version that sits in the download portal for another six months after the official product launch is no longer a test. It is a non-compliant product. A clear time boundary also matters because it may need to be documented in case of dispute. Supervisory authorities will not only look at the label, but at the actual course of the testing programme. For what non-compliance under the CRA means, see our article on CRA penalties and fines.
2. Clear notice of testing character and missing conformity. The test software must carry a clear notice that it does not meet CRA requirements and is provided exclusively for testing purposes. This notice must be visible and unambiguous. What is not enough: a line in the release notes, a footnote disclaimer in a PDF attachment, or a general beta label without specific CRA reference. What is enough: an explicit notice that appears at download, installation, or in the interface itself, phrased so that an informed user can unambiguously place the regulatory status of the software. A useful phrasing in practice is: "This software is a pre-release for testing purposes. It does not meet the requirements of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) and may only be used as part of this testing programme until [date]." In addition, you should obtain a written test agreement from beta participants documenting the testing character and usage restrictions.
What does this mean for your CRA roadmap?
The exemption for test software is already relevant today, and will become more so over the coming months. Two deadlines are decisive.
From 11 September 2026, the reporting duties for actively exploited vulnerabilities and severe security incidents enter into force. This also affects software already on the market. Anyone who has by then drawn clear lines between test software and production software is in a markedly better position, both operationally and from a documentation perspective.
From 11 December 2027, the CRA applies fully. Anyone who has by then established conformity processes for all real products can preserve the exemption for test software as a real advantage: faster feedback cycles, more customer involvement in development, without having to treat every intermediate step as a regulatory event.
For how to structure your compliance roadmap up to these deadlines, see our article on the CRA compliance roadmap 2026 to 2027.
Important: The exemption for test software does not release you from the later conformity duties for the finished product. A CE marking and a full conformity assessment remain required for the final product. And anyone handling vulnerabilities cleanly already in the beta phase (keyword vulnerability management) will find that the path to conformity of the final product is significantly shorter.
Frequently asked questions
Does the exemption also apply to open source beta releases? In principle yes, as long as the two conditions are met: time-limited availability and a clear notice. The CRA has its own specific rules for open source software in some places. What matters is that the provision of the test version is clearly marked as such and that availability is genuinely time-limited.
Do I still have to create an SBOM for a beta version? A full SBOM in the sense of CRA requirements is not mandatory for test software that falls under the Article 19 exemption. For internal development documentation and the later conformity assessment of the final product, an early SBOM is, however, sensible. Our SBOM guide for IoT manufacturers provides a practical starting point.
What if a customer uses the beta in production although that was not intended? That is a real risk. This is why a test agreement with clear usage restrictions is important, not only as legal protection but as an active steering instrument. If a manufacturer knows or should know that beta software is de facto being used in production, they leave the protection of the exemption.
How long may a beta phase last at most? The CRA does not name a concrete time limit. The benchmark is the actual test purpose. A beta phase of three to six months for a concrete test programme is generally unproblematic. An open beta channel without an end date is problematic.
Do I need formal approval to provide test software? No. Article 19 CRA is a directly applicable exemption, not an approval requirement. It is the manufacturer's responsibility to meet the conditions and document them.
Conclusion
The exemption for test software in the CRA is a well-designed instrument that protects innovation processes, when you know it and apply it correctly. Anyone who shuts down beta versions out of misplaced caution harms not only their own development process, but also forgoes customer feedback at a phase where changes are still cheap.
Two conditions, implemented correctly, are not bureaucratic overhead. They are good product development practice.
A structured CRA compliance platform helps document the status of every software version (test or product) unambiguously and systematically steer the transitions between development phase and regulatory conformity, before the deadline tips from theory into practice. More at /cra-compliance-assessment.
Every Friday I debunk a CRA myth here.