September is here, and for different people it means different things—kids begin their school years, teens are off to university, and manufacturers of products with digital elements that sell them in the European Union are getting ready for mandatory reporting of actively exploited vulnerabilities and severe security incidents affecting their products.
The European Commission gave businesses time to prepare, but the deadline can still sneak up on you, particularly for organizations that are not used to regulated product security. If you’re feeling unprepared, the best place to start is to establish where you are now and turn your gaps into a focused action plan.
Before we jump into what to do, let’s examine what’s about to happen.
In practical terms, from 11 September 2026, manufacturers will be required to report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. Three components matter here: who has to report, where the report goes and what triggers the obligation.
Who & where to submit: A manufacturer of products with digital elements that are in scope of CRA must notify regulators about any actively exploited vulnerability contained in its product with digital elements that it becomes aware of. The notification should be submitted through the Single Reporting Platform and made available simultaneously to the Computer Security Incident Response Team (CSIRT) designated as coordinator and to ENISA.
What: An actively exploited vulnerability is defined as “a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” It's important to remember that even though it's an organization's call to action, the regulator will also be making their own call during audits/assessments to figure out if appropriate action was taken.
Severe incidents also have a specific framing in the regulation. An incident having an impact on the security of a product with digital elements is considered severe where:
(a) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or
(b) it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements.
Both have to be reported through a Single Reporting Platform during the first 24 hours after an organization has become aware of the occurrence of a security event.
Now, let's look at how to assess where you stand today—whether you're ready, what extra steps you need, and what carries you forward to 2027.
Assessing your codebase’s CRA readiness
To assess your codebase’s CRA readiness, use the following seven questions:
Are secure defaults encoded in the codebase, with security controls enabled and unnecessary capabilities disabled?
Are changes to security-critical code and configuration identified, reviewed and tested?
Can every release be traced to its exact source, build inputs and dependencies?
Must every code change pass the applicable security checks before it can merge?
Can the build or release be blocked when serious security findings remain?
Do automated tests exercise security-critical code against misuse and hostile input?
Do release tests verify the security behavior implemented by the code?
For each question, assess the current control as:
Not evidenced: absent or unknown.
Ad hoc: partial, inconsistent or manually dependent.
Standard: defined, evidenced and consistently applied.
Enforced: automated where appropriate and able to prevent progression.
An answer below Standard indicates that the control is not yet reliably established.
The reporting relevance describes how the control supports the Article 14 obligations applying from 11 September 2026, it does not mean that Article 14 expressly requires that particular codebase control.
1. Secure defaults
Question: Are secure defaults encoded in the codebase, with security controls enabled and unnecessary capabilities disabled?
If below Standard: The codebase does not reliably establish a secure initial state. Security may depend on users, operators or deployment teams changing permissions, disabling features or correcting insecure settings.
Reporting relevance: Secure defaults reduce the likelihood that an unsafe initial configuration results in an actively exploited vulnerability or severe incident that must be reported.
Broad CRA fit: Annex I, Part I, point 2(b) requires products to be made available with a secure-by-default configuration, subject to limited exceptions.
2. Security-sensitive changes
Question: Are changes to security-critical code and configuration identified, reviewed and tested?
If below Standard: Security-sensitive changes may enter the codebase without being recognized or receiving the additional review and testing they require.
Reporting relevance: Identifying security-sensitive changes makes it easier to investigate how a vulnerability or incident was introduced, determine the affected versions and explain the corrective action taken.
Broad CRA fit: Supports the effective and regular security testing and review required by Annex I, Part II, point 3.
3. Release traceability
Question: Can every release be traced to its exact source, build inputs and dependencies?
If below Standard: The organization may be unable to establish exactly what code and third-party components are present in a release, making vulnerability assessment, remediation and component inventory less reliable.
Reporting relevance: Release traceability helps identify affected versions and components, assess the impact of a vulnerability and determine the appropriate corrective or mitigating measure.
Broad CRA fit: Annex I, Part II, point 1 requires manufacturers to identify and document product components and vulnerabilities, including through an SBOM covering at least top-level dependencies. Exact build traceability goes beyond the minimum wording but supports an accurate inventory for each release.
4. Pre-merge security checks
Question: Must every code change pass the applicable security checks before it can merge?
If below Standard: Security checks are absent, inconsistent or dependent on individual teams, allowing changes to enter the main codebase without the required security assessment.
Reporting relevance: Pre-merge checks help find weaknesses before they reach a released product and potentially become actively exploited. They support prevention rather than the reporting process itself.
Broad CRA fit: Supports regular security testing and review under Annex I, Part II, point 3 and helps prevent releases containing known exploitable vulnerabilities under Annex I, Part I, point 2(a).
5. Release enforcement
Question: Can the build or release be blocked when serious security findings remain?
If below Standard: Security findings may inform release decisions, but they do not reliably prevent code with unresolved serious weaknesses from being shipped.
Reporting relevance: Blocking a release with unresolved serious findings reduces the likelihood that a known weakness enters the market and later becomes actively exploited or contributes to a severe incident.
Broad CRA fit: This supports Annex I, Part I, point 2(a), concerning known exploitable vulnerabilities, and Annex I, Part II, point 2, concerning the remediation of vulnerabilities without delay. Blocking thresholds and controlled exceptions should reflect the product’s cybersecurity risk assessment.
6. Testing against misuse
Question: Do automated tests exercise security-critical code against misuse and hostile input?
If below Standard: Testing mainly covers expected behaviour and may not reveal how security-critical code responds to malformed input, abuse cases or deliberate attempts to bypass controls.
Reporting relevance: Security testing can expose vulnerabilities before active exploitation and help establish their severity, impact and the effectiveness of a proposed fix.
Broad CRA fit: This supports the effective and regular testing required by Annex I, Part II, point 3 and helps verify relevant Annex I, Part I properties, including access control, data protection, attack-surface reduction and exploit mitigation.
7. Runtime security behaviour
Question: Do release tests verify the security behaviour implemented by the code?
If below Standard: The release process does not reliably demonstrate that security-critical behaviour—such as update integrity, rollback protection, isolation, secure deletion or resilience under stress—works as intended at runtime.
Reporting relevance: Runtime testing helps determine whether an incident meets the severity threshold, assess its effect on the product and verify that corrective or mitigating measures work as intended.
Broad CRA fit: Supports Annex I requirements relating to secure updates, confidentiality, integrity, availability, resilience, and security-event monitoring, together with the effective and regular testing requirement in Annex I, Part II, point 3.
Once you understand the current status of your codebase, prioritize your key actions. Address the important gaps before they turn into compliance problems, weighted by how much of your product's risk sits behind each control. A missing secure default on an internet-facing product moves ahead of a missing pre-merge check on an internal tool. Revisit the questionnaire on a fixed cadence so that Standard today does not quietly slip back to Ad hoc by next audit.
How can Sonar help manufacturers prepare for the Cyber Resilience Act?
Preparing for CRA based on the questionnaire above may sound overwhelming, particularly if the controls are spread across multiple tools or executed manually. Given the volume of code that needs to be assessed (and the number of potential issues that may need to be addressed) a predominantly manual approach is unlikely sustainable. Adoption creates another challenge: when compliance-related work requires a separate workflow or introduces significant friction, it is less likely to be applied consistently, creating avoidable gaps.
Because a missed control can allow a vulnerability to reach a released product, security checks should be placed inside the workflows already used by software developers and AI coding agents. SonarQube supports this model by bringing analysis, review and enforcement into IDE/agentic generation loop, pull request and CI/CD workflows, while producing evidence that codebase security controls are operating consistently.
For CRA codebase readiness, that support breaks down as follows:
Consistent security baseline: Centrally managed quality profiles define which reliability and security rules apply.
Earlier feedback and constraints for developers and coding agents: Connected analysis brings centrally managed rules into the IDE, while Sonar Vortex guides and verifies AI-generated changes against the organization’s standards inside the agentic coding loop, allowing issues to be identified before code is committed or submitted for review.
Component transparency: Software composition analysis identifies direct and transitive dependencies and known dependency risks. CycloneDX or SPDX SBOMs provide component inventories, and separate VEX information records assessed vulnerability status.
Vulnerability identification and remediation: Static analysis, secrets detection and infrastructure-as-code analysis identify weaknesses in code and configuration, while Hunter Agent extends detection to business-logic, access-control and authentication flaws. Gitar supports remediation in new code, and SonarQube Remediation Agent addresses the existing backlog.
Preventive enforcement: Quality gates and pull request decoration provide a pass-or-fail signal based on defined conditions for code, including security findings and dependency risks, making sure that no sub-par code is able to pass to production.
Testing visibility: Test coverage data and supported external analysis results provide additional evidence of regular testing and review.
Evidence and reporting support: Analysis history, quality gate results, issue status and remediation records help evidence operating controls and identify affected code, dependencies and corrective measures.
Together, these capabilities support accelerated codebase-side readiness for the 11 September 2026 reporting deadline by improving issue discovery, affected version analysis and remediation evidence, while establishing the preventive controls needed for broader CRA readiness ahead of 11 December 2027.
But how do we know that it works for code created by AI agents?
Easy: developer workflow powered by Sonar has been tested repeatedly at enterprise scale over our 16+ year history, with agentic acceleration capabilities being highly regarded by major market players in 2026. At Cisco, an internal agent uses SonarQube issue context to plan fixes and create pull requests, helping resolve 27,000 issues in three months. A global financial institution requires AI-assisted teams to use its SonarQube pipeline across approximately 20,000 engineers and 8,500 projects. Freshworks applies quality gates across more than 2,000 repositories as AI adoption grows, while Xero applies the same standards to human- and AI-generated code across 3,500 repositories. At IMSA, the same model supports mandatory checks across more than 2,000 projects. Across these organizations, verification is not slowing delivery; it is helping human- and AI-generated code scale with greater control.
How to get ready for Cyber Resilience Act
The reporting deadline lands on 11 September 2026, and the broader CRA obligations follow on 11 December 2027. Both are close enough that the tooling you pick now is the tooling you will still be relying on then. SonarQube is built for that stretch: consistent baselines inside the workflows your software developers and AI agents already use, and an evidence trail that makes readiness demonstrable at audit.
Talk to our team about getting CRA-ready—and give procurement enough runway that it does not become the delay factor you did not plan for.