A useful release gate converts secure-development expectations into explicit pass, fail or exception decisions. It should be strict enough to prevent uncontrolled security risk from reaching users but flexible enough to allow documented, authorised risk decisions where a finding does not justify blocking release.
Security Release Gates Are an Implementation Control
The Cyber Resilience Act does not contain a provision requiring manufacturers to use a process named security release gate. The legal obligations instead concern product cybersecurity outcomes, risk-based development, testing, review and conformity evidence. A release gate is a practical implementation control that brings those activities together at the point where a product version is about to be distributed. ENISA's Secure by Design and Default guidance is expressly intended to support repeatable engineering and release processes.
- Do not describe release gates as a separately named CRA obligation.
- Use gates to enforce applicable product-security requirements.
- Connect the gate to the release candidate.
- Retain the resulting approval evidence.
A Release Gate Should Evaluate the Actual Release Candidate
Security approval should apply to the product version that will actually reach users. The gate should identify the release candidate, build or artefact being reviewed and connect it to the relevant source revision and security evidence. This prevents a situation where testing was performed on one build but a materially different artefact was distributed. The exact identity mechanism depends on the product, but the released version should be traceable to the evidence used for approval.
- Identify the release candidate.
- Identify the relevant source revision.
- Identify the final artefact.
- Connect security evidence to that artefact.
- Prevent uncontrolled changes after approval.
Confirm Required Security Tests Have Passed
The release gate should confirm completion of the security tests required for the product and version. That can include automated security regression tests, access-control tests, update-security tests, static analysis, dependency analysis and targeted manual tests. A high-risk product or major architecture change may also require deeper testing. The gate should distinguish a missing test from a test that ran and failed because the response to those situations may be different.
- Confirm required tests ran.
- Confirm blocking tests passed.
- Review failed security tests.
- Review missing or skipped required tests.
- Record approved exceptions.
Review Known Vulnerabilities Before Release
Annex I requires attention to known exploitable vulnerabilities and the broader CRA framework requires effective vulnerability handling. A release gate should therefore include visibility into known vulnerabilities affecting the release candidate. The objective is not simply to count vulnerability records. Teams should determine whether relevant findings are exploitable in the product context, whether fixes are available, whether remediation is required before release and whether any residual risk has been accepted through a controlled process.
- Review known vulnerabilities affecting the release.
- Assess exploitability in product context.
- Review available fixes.
- Determine whether findings block release.
- Document residual risk decisions.
Confirm Secure-Default Configuration
The release candidate should preserve the secure-default configuration defined during product development. Packaging, deployment templates and manufacturing steps can accidentally enable services, restore debug options or change permissions. A release gate can require confirmation that the actual distributed artefact has passed secure-configuration checks and reset behaviour remains consistent with the intended security baseline.
- Verify the distributed default configuration.
- Check enabled services.
- Check debug features.
- Check default permissions.
- Confirm required reset behaviour.
Review Dependency and Supply-Chain Findings
A release can introduce third-party risk through new or changed dependencies. The security gate should review relevant dependency-analysis results, known vulnerabilities, unsupported packages and unresolved package-policy violations. High-risk dependencies may require deeper investigation or replacement, while lower-risk findings may proceed with documented monitoring. The release record should preserve the state that was actually reviewed.
- Review dependency-analysis results.
- Review severe known vulnerabilities.
- Review unsupported components.
- Review prohibited package findings.
- Record approved exceptions.
Define What Actually Blocks Release
A gate is only useful when teams understand its decision rules. Manufacturers can define categories that automatically block release, categories requiring security approval and categories that can proceed without escalation. A confirmed critical authentication bypass may be an automatic blocker, while a lower-risk finding in a non-exposed component may require assessment rather than an automatic stop. Rules should reflect product risk rather than relying solely on one external severity score.
- Define automatic blockers.
- Define findings requiring security review.
- Define acceptable low-risk conditions.
- Use product context in decisions.
- Review the policy when incident experience reveals gaps.
Exceptions Should Be Explicit and Temporary Where Appropriate
There can be legitimate reasons to release with an unresolved finding, but the decision should be visible and authorised. A security exception can identify the finding, affected product, reason for proceeding, residual risk, compensating control, owner and review date. Time-limited exceptions can prevent temporary decisions from becoming permanent unnoticed. The ability to approve an exception should be restricted to appropriate roles rather than available as an ordinary developer bypass.
- Identify the finding or failed control.
- Document the reason for proceeding.
- Document residual risk.
- Name an approving owner.
- Use a review or expiry date where appropriate.
Human Approval Still Matters
Automated pipeline checks can make release gates faster, but not every cybersecurity decision can be automated. A scanner may identify a vulnerable component without knowing whether the vulnerable function is reachable. A penetration-test finding may require interpretation of product impact. A failed configuration check may reflect an approved product variant. Human security review should remain available where the evidence requires risk interpretation rather than forcing all decisions into a binary automation rule.
- Automate deterministic controls.
- Escalate ambiguous findings.
- Require appropriate approval for residual risk.
- Keep security decisions traceable.
The Gate Should Produce Release Evidence
The final gate should produce a concise record showing what was reviewed and who approved release. Useful evidence can include release version, artefact identity, required test status, vulnerability review, dependency status, secure-default checks, open findings, exceptions and approver. Existing CI/CD and issue-tracking systems can provide much of this evidence automatically. The objective is to preserve a defensible link between the released product and its security decision.
- Released product version.
- Artefact identity.
- Security-test status.
- Vulnerability status.
- Approved exceptions.
- Release approver.
- Approval timestamp.
A Release Gate Does Not Replace Conformity Assessment
A security release gate is an internal development control. It can generate valuable evidence for technical documentation and conformity preparation, but it does not replace the conformity assessment procedure required under the CRA. The gate answers whether the organisation's security criteria for the version have been satisfied or formally excepted. Conformity assessment addresses the broader legal determination that the product and relevant manufacturer processes meet the applicable CRA requirements.
- Treat the gate as an internal engineering control.
- Use its outputs as conformity evidence where relevant.
- Do not describe internal release approval as CE conformity assessment.
- Maintain the broader technical documentation.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.