Effective security review is risk-based and occurs at useful decision points. Architecture changes need architectural review, security-sensitive implementation changes need appropriate code review, dependency changes need supply-chain review, and release decisions need visibility into unresolved security findings.
The CRA Explicitly Refers to Security Reviews
Annex I Part II point 3 requires manufacturers to apply effective and regular tests and reviews of the security of products with digital elements. Article 13 also requires the cybersecurity risk assessment to influence development and maintenance. The Regulation does not prescribe one mandatory review meeting or review template. Manufacturers can therefore integrate security review into their engineering process, provided the resulting approach is effective, regular and appropriate to the product and its cybersecurity risks.
- Annex I Part II point 3 expressly refers to security reviews.
- Reviews should be effective rather than purely procedural.
- Reviews should occur regularly across the relevant lifecycle.
- The depth of review can reflect product risk and change significance.
Architecture Review Should Happen Before Structural Decisions Harden
Architecture review is most valuable before interfaces, privilege boundaries and trust relationships become expensive to change. A security architecture review can examine exposed services, administrative paths, data flows, update mechanisms, cryptographic boundaries, third-party components and failure behaviour. Reviewers should compare the design with the cybersecurity risk assessment and security requirements, identifying where assumptions are unsupported or controls are missing.
- Review external interfaces.
- Review trust and privilege boundaries.
- Review sensitive data flows.
- Review update and recovery mechanisms.
- Record unresolved architecture risks.
Review the Threat Model When Architecture Changes
A threat model can become stale when the product gains a new API, cloud integration, remote-management feature, privilege path or third-party component. Security review should therefore include the threat model when changes affect attack paths or security assumptions. The reviewer should ask whether new entry points exist, whether trust boundaries moved, whether previously accepted risks changed and whether new security requirements or tests are needed.
- Identify changed attack paths.
- Review new entry points.
- Review changed trust boundaries.
- Update mitigations where required.
- Update related security tests.
Code Review Should Focus on Security-Sensitive Changes
Routine peer review improves quality, but some changes deserve explicit security attention. ENISA highlights authentication, authorisation, cryptography, parsers and external interfaces as examples of security-sensitive areas. Teams can use code ownership rules, specialist reviewers or security checklists for these changes. The review should examine whether the code preserves the intended security boundary and handles failure or malicious input safely rather than focusing only on code style.
- Identify security-sensitive modules.
- Use appropriate reviewers.
- Review authentication and authorisation changes.
- Review cryptographic and parser changes.
- Review changes affecting external interfaces.
Dependency Changes Need Security Review Too
Software development increasingly depends on third-party components. Adding, replacing or substantially upgrading a dependency can change product risk even when internally written code changes very little. Review should consider known vulnerabilities, maintenance status, privilege, transitive dependencies, package source and whether the component expands the attack surface. High-impact components may need stronger approval than ordinary low-risk libraries.
- Review new dependencies.
- Review major dependency upgrades.
- Review known vulnerabilities.
- Review package provenance where relevant.
- Review privilege and attack-surface consequences.
Configuration and Infrastructure Changes Can Be Security-Sensitive
A secure codebase can still become insecure through configuration or infrastructure changes. Security reviews should therefore include changes to default settings, deployment templates, access controls, build pipelines, signing configuration, cloud permissions and secret handling where those elements affect product cybersecurity. ENISA's playbook recommends governed change processes with review, testing, approval and rollback planning for security-sensitive components.
- Review security-relevant configuration changes.
- Review build and signing changes.
- Review cloud and infrastructure permissions.
- Review secret-management changes.
- Plan rollback for significant security changes.
Security Findings Need a Controlled Disposition
A review is useful only if findings lead to action. Each meaningful finding should be classified, assigned and either remediated or accepted through a documented risk decision. High-risk findings should not disappear into ordinary engineering backlog without visibility. The disposition should identify the product version affected, owner, expected remediation and any compensating control or reason for accepting residual risk.
- Record meaningful findings.
- Assign an owner.
- Track remediation.
- Document accepted residual risk.
- Connect findings to the affected product version.
Release Review Should Consider Unresolved Security Work
A release security review should determine whether the product is ready to move from development into distribution. It can consider completion of required security tests, unresolved vulnerabilities, open review findings, secure-default verification, dependency status and known exceptions. The decision should be risk-based rather than assuming that every minor finding automatically blocks release. At the same time, unresolved security-sensitive changes should be visible to the people responsible for approving the version.
- Review required security-test results.
- Review unresolved security findings.
- Review dependency and vulnerability status.
- Review security-sensitive exceptions.
- Record the release-security decision.
Reviews Should Be Regular Without Becoming Ritual
The CRA uses the words effective and regular rather than prescribing one fixed calendar frequency. A manufacturer can therefore combine scheduled reviews with event-driven review triggers. High-risk architecture may justify periodic review, while a significant authentication redesign can justify an immediate targeted review regardless of the calendar. The review programme should be frequent enough to detect meaningful security problems while remaining connected to actual product changes.
- Use risk-based review depth.
- Define important change triggers.
- Use periodic review where appropriate.
- Avoid reviews that only confirm paperwork completion.
- Adjust the process when repeated defects reveal gaps.
Retain Review Evidence That Explains Decisions
Useful review evidence can include the scope of the review, product version or change identifier, reviewers, findings, remediation actions, accepted risks and approval status. Existing engineering systems such as pull requests, architecture decision records and issue trackers can provide this evidence if records remain accessible and traceable. The goal is not to duplicate normal engineering records into a separate compliance database, but to show that security reviews were performed and that their findings influenced the product.
- Review scope.
- Product version or change reference.
- Review participants.
- Security findings.
- Remediation or risk decisions.
- Approval status.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.