CRA readiness starts in the codebase: seven questions that expose the gaps

The EU Cyber Resilience Act (CRA) is usually discussed as a policy or reporting challenge. For organizations building products with digital elements, its practical impact lands much closer to the code: in pull requests, build pipelines, release approvals, dependency records and test suites. A company cannot credibly report an exploited vulnerability if it cannot say which versions are affected, which component introduced the exposure, or whether the fix actually worked in the running product.

Deadlines already in force

Manufacturers of in-scope products with digital elements have had to report actively exploited vulnerabilities and severe incidents through the EU reporting process since September 11. Broader CRA obligations begin to apply in December 2027. The more useful question for engineering leaders is whether their delivery system can produce reliable security outcomes and prove it, and that answer rarely sits in a single tool. It comes from repeatable controls embedded in the software lifecycle.

From policy to observable controls

Many organizations already have secure development policies; the gap is between what the policy says and what the codebase, pipeline and release evidence can demonstrate. One practical way to find that gap is to assess each control at four maturity levels: not evidenced, ad hoc, standard, and enforced. "Standard" is the key threshold, because a control that depends on one knowledgeable engineer or a spreadsheet is not dependable at the speed of modern delivery.

Seven questions that expose readiness gaps

The article proposes seven codebase-focused checks: are secure defaults built in; can teams spot security-sensitive changes like authentication or cryptography; can every release be traced to its exact source revision and dependencies, with SBOMs as one part; do applicable checks run before code merges; can serious findings block a build or release; do tests exercise hostile behavior such as malformed input; and do release tests validate runtime protection such as update integrity and rollback protection?

Prioritize by exposure, and account for AI

The assessment should lead to a risk-weighted plan. A missing secure default in an internet-facing product may deserve immediate attention, while a gap in pre-merge automation for a low-risk internal component is less urgent. The factors are product exposure, criticality of affected functions, exploitability and the number of released versions affected. Agentic development raises the stakes: in Sonar's State of Code Developer Survey, 96% of developers said they do not fully trust AI-generated code, yet only 48% said they always verify it before committing.

The CRA is a regulatory obligation, but cyber resilience is an engineering discipline. Organizations that build evidence-producing controls into their codebase will be better positioned to meet reporting duties and prevent the incidents that make them necessary.