The Cyber Resilience Act (CRA) expressly allows unfinished software such as alpha, beta and release-candidate builds to be made available for testing before the normal conformity route is complete, but this is not a blanket exemption for anything labelled “beta”. Article 4(3) requires the software to be offered only for the limited period needed for testing and to carry a visible indication that it does not comply with the CRA and is not available for purposes other than testing.
For manufacturers, the practical question is therefore not whether a build has a pre-release label. It is whether the release is genuinely controlled as a testing-only build, whether the applicable conditions are documented, and whether security and vulnerability handling continue during the test period.
The testing route is narrow and conditional
The CRA's normal rule is that products with digital elements may be made available on the market only when they meet the applicable essential cybersecurity requirements and the other conditions set by the Regulation.
Article 4(3) creates a specific exception for unfinished software used for testing. It allows Member States to permit such software to be made available before compliance is complete when two core conditions are met:
- the software is available only for the limited period required for testing; and
- a visible sign clearly indicates both that the software does not comply with the CRA and that it will not be available for purposes other than testing.
Article 4(4) adds an important boundary: this testing exception does not apply to safety components covered by other Union harmonisation legislation.
The CRA's main provisions, including Article 4, apply from 11 December 2027. The Commission's July 2026 implementation material is non-binding guidance intended to help organisations prepare for those obligations before that date.
Alpha, beta and release-candidate labels are not the legal test
Recital 37 explicitly mentions alpha versions, beta versions and release candidates as examples of unfinished software that can be made available for testing. But the recital does not turn those labels into automatic legal categories.
An engineering team may call a build “beta” even when it is offered broadly, used indefinitely or relied on in ordinary production. Conversely, a narrowly controlled test build can be unfinished even if the internal versioning scheme uses a different label.
Operationally, the manufacturer should therefore document the facts behind the testing status rather than relying on naming alone. Useful questions include:
- What exactly is being tested?
- Who is permitted to receive or use the build?
- When does the testing period begin and end?
- What event or evidence ends the test?
- Is the build clearly separated from the normal production release?
- What notice tells users that it is non-compliant and testing-only?
- What happens to the test build after the testing period closes?
The stronger the answers, the easier it is to show that the release was genuinely limited to testing rather than an ordinary market release carrying a pre-release label.
Perform the cybersecurity risk assessment before external testing
Recital 37 says that a manufacturer making unfinished software available for testing should release it only after performing a risk assessment. It also says the manufacturer should, to the extent possible, comply with the security requirements relating to product properties.
That matters because unfinished does not mean uncontrolled. A test build may contain incomplete features, temporary interfaces, additional logging or diagnostic functions that change its attack surface. It may also be distributed to users outside the development organisation, creating conditions that did not exist in internal testing.
A practical pre-release risk review should record at least:
- the exact build, artifact or release candidate being assessed;
- intended test purpose and expected users;
- known incomplete features or security controls;
- temporary interfaces, credentials, debug functions or diagnostic services;
- external services and remote data processing required by the test;
- known vulnerabilities and unresolved security findings;
- data handled during the test;
- expected deployment environment and exposure;
- compensating controls or restrictions applied to the test; and
- the criteria for deciding that the residual test risk is acceptable.
This is an engineering recommendation for making the CRA's risk-oriented expectations operational. The depth of the review should reflect the product, test scope and exposure rather than becoming a fixed checklist applied identically to every build.
Keep vulnerability handling active during the test period
Recital 37 also says manufacturers should apply vulnerability-handling requirements to the extent possible for unfinished testing software.
That means a beta programme should not become a gap between normal development security and post-release security. The manufacturer still needs a practical way to receive, assess and act on vulnerabilities found during the test.
For each testing release, define:
- where testers report security issues;
- who owns vulnerability intake and triage;
- how affected test versions are identified;
- how exploitability and impact are assessed;
- when a finding blocks further distribution of the test build;
- how testers receive corrected builds or mitigation instructions;
- how security decisions and their rationale are retained; and
- how unresolved findings transfer into the next release decision.
A useful evidence trail connects the vulnerability report to the exact test build, the technical assessment, the resulting decision and the replacement or final release. That prevents a finding discovered in one candidate from being lost when several test builds move quickly through the same programme.
Make the testing-only status visible to users
Article 4(3) requires a visible sign that clearly communicates two points: the software does not comply with the CRA and it is not available for purposes other than testing.
The Regulation does not prescribe one universal user-interface pattern for that notice. The implementation should therefore match how the software is distributed and used.
Depending on the product, evidence of the notice could include:
- text shown on the download or enrolment page;
- a testing programme agreement;
- a prominent release note or package description;
- an in-product banner or first-run notice;
- an administrator-facing deployment warning; or
- another visible mechanism that reaches the person receiving the test software.
The important control is not decorative wording. The manufacturer should be able to show that the recipient was clearly informed of the testing-only and non-compliant status for that exact release.
Retain the notice text and a record of where it was displayed. If the wording or distribution channel changes between test builds, preserve the version that applied to each build rather than overwriting the historical record.
Put an end date or exit condition on the test
The operative rule allows unfinished software only for the limited period required for testing. An open-ended “beta” programme creates a different risk profile from a controlled evaluation with a defined purpose and exit condition.
A release record should therefore identify either a planned end date or a concrete event that closes the test. Examples include:
- completion of a defined user-validation cycle;
- collection of a specified set of test results;
- completion of interoperability or compatibility testing;
- closure of identified blocking defects;
- expiry of a controlled access programme; or
- replacement by a later test build.
The test may need to be extended when evidence is still missing, but the extension should be a documented decision tied to the remaining testing need. Automatically extending a beta indefinitely weakens the argument that the software is available only for the period required for testing.
Do not force users onto testing-only versions
Recital 37 says manufacturers should not force users to upgrade to versions released only for testing.
That is a useful release-governance boundary. A testing build is intended to gather evidence and feedback before ordinary availability; forcing production users onto it would undermine that separation.
In practice, preserve a stable supported path for users who are not participating in the test. If a beta is distributed through an update mechanism, make participation intentional and distinguish the testing channel from the normal production channel.
Where a security issue requires urgent action, the manufacturer should decide how to protect supported users without treating a testing-only build as the only mandatory upgrade path. The exact response depends on the affected product, available mitigations and lifecycle state.
Build a release evidence package for every test version
A lightweight evidence package makes the testing status auditable later and reduces reliance on memory when multiple candidates are released in quick succession.
For each alpha, beta or release candidate made available externally, retain:
- product, variant and release identifier;
- immutable artifact hash or equivalent release binding;
- release date and testing period;
- stated test purpose and intended test population;
- visible testing-only and non-compliance notice;
- cybersecurity risk assessment;
- known incomplete controls and accepted limitations;
- vulnerability status at the release decision;
- security test results relevant to the candidate;
- tester security contact and intake process;
- restrictions or compensating controls;
- owner who approved the test release;
- exit criteria and final disposition; and
- links to later builds that supersede the candidate.
This package is not a substitute for the CRA technical documentation or conformity assessment required for ordinary market placement. Its purpose is narrower: to show why the unfinished build was distributed as a controlled test and what security information supported that decision.
Know when the testing route no longer fits
Article 4(3) does not define a numerical maximum number of testers or a fixed maximum number of days. The boundary instead depends on the facts: testing purpose, limited duration and clear testing-only status.
That means manufacturers need a reassessment point when the operating model changes. Revisit the Article 4(3) basis if:
- the build becomes the default download or normal update;
- customers begin relying on it for ordinary production use;
- access expands beyond the defined testing population;
- the original testing purpose has been completed;
- the programme continues without a documented testing need;
- the visible testing-only notice is removed; or
- the organisation intends to sell, bundle or otherwise supply the build as a normal product release.
At that point, the manufacturer should determine whether the product is moving from controlled testing into ordinary market availability and apply the relevant CRA requirements accordingly. The label on the version should follow the legal and operational reality, not define it.
Practical pre-release gate
Before an unfinished external release, a product team can use the following short gate:
- Confirm that the release is genuinely for testing.
- Define the test scope, recipients and limited period.
- Bind the decision to the exact build or artifact.
- Complete and retain the cybersecurity risk assessment.
- Record known vulnerabilities and incomplete security controls.
- Verify the visible testing-only and non-compliance notice.
- Confirm vulnerability intake, triage and update channels.
- Keep production users on a separate supported path.
- Define exit criteria and ownership for closing or extending the test.
- Reassess the CRA status before the build becomes an ordinary release.
The gate should be evidence-producing. A checked box without the underlying risk assessment, notice, artifact identity or vulnerability record is much weaker than a decision that can be reconstructed from retained records.
Testing-only releases also create a traceability problem: risk assessments, artifact hashes, visible notices, vulnerability decisions and exit criteria need to stay tied to the exact build. AA-sec is designed around traceability between requirements, evidence, decisions and exact product or lifecycle context; the MVP scope includes release lifecycle workflows, release blockers and evidence packages. AA-sec does not decide whether Article 4(3) applies or whether a test build may be made available on the market.
Key takeaway
The CRA does allow unfinished alpha, beta and release-candidate software to be made available for testing, but the safe operational model is controlled and temporary. Article 4(3) requires a limited testing period and a visible notice that the software is non-compliant and testing-only, while Recital 37 points manufacturers toward a prior risk assessment, security requirements and vulnerability handling to the extent possible.
Treat every external test build as a release decision with its own evidence. Define why the build is being tested, who receives it, how long the test lasts, what security state is known, how vulnerabilities are handled and what ends the programme. That makes the transition from unfinished testing software to an ordinary release explicit rather than accidental.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- Cyber Resilience Act - Implementation — European Commission