The Cyber Resilience Act: secure coding shifting from engineering concern to a legal obligation

For many years, secure coding has been treated as an engineering skill rather than a legal necessity. For obvious reasons, organizations invested in it to reduce the risk of incidents and stay out of headlines and thus protect their reputation. The EU Cyber Resilience Act (CRA), however, changes this fundamentally, shifting secure coding from a common and promoted practice to an enforceable legal obligation. For both technical leaders and executives, this shift has far-reaching implications, changing how software products are designed, developed and maintained.

CRA applies to (almost) all products with digital elements. This definition is broad enough to include most modern software systems. From standalone applications to embedded firmware and cloud-connected platforms, any product placed on the EU market that connects to the Internet – even if just indirectly – is within scope. It is, however, even more interesting to see what is NOT in scope: obviously, products for internal use (including testing tools), old versions of existing products, but also products from some specific domains, like defense, automotive or aviation, for which there are separate legislation and compliance schemes. It is also important to point out that free (non-commercial) open-source components are also exempted, but even then, your product depending on these components is not.

The regulation has been in force since 2024, with its obligations becoming progressively applicable between 2026 and the end of 2027. Conformity assessment bodies should be set up by mid-2026, reporting obligations start in September 2026, while it is fully applied from December 2027 on. When fully applied, cybersecurity failures resulting from poor coding practices can translate directly into non-compliance, financial penalties and even exclusion from the market.

The broader legal context raises the stakes further. The updated EU Product Liability Framework explicitly covers software and digital products, extending liability to damage such as data loss and corruption. Many of these harms arise directly from insecure coding. A vulnerability that leads to a breach is no longer just an operational incident: it can trigger regulatory penalties under CRA, and liability claims under product liability law. In this environment, insecure code effectively becomes a direct legal and financial risk.

What distinguishes the Cyber Resilience Act from earlier cybersecurity initiatives is its focus on how software is built, not just on the high-level controls or the operational policies. The regulation is primarily descriptive rather than prescriptive: it does not mandate specific tools or frameworks, but it does require outcomes that can be achieved through secure software engineering.

Secure coding as the foundation of Cyber Resilience Act compliance

At its core, the Cyber Resilience Act is built around a risk-based security model. It explicitly recognizes that software defects are inevitable and that no complex system can ever be perfectly secure. Therefore, the regulation does not require the absence of vulnerabilities in absolute terms – that would be a rather unrealistic requirement. Instead, it requires that products are placed on the market without known exploitable vulnerabilities and prescribes manufacturers to apply state-of-the-art measures – basically: best practices – to reduce cybersecurity risk.

Formulating the requirement like this directly ties legal compliance to coding practices. Vulnerabilities such as injection flaws, broken authentication, unsafe deserialization, or memory corruption are concrete consequences of bad design or implementation decisions, not just abstract compliance failures. Security holes ultimately “live” in the code. If a product fails to enforce security correctly, no risk assessment or documentation can compensate for the underlying engineering mistakes.

To put it differently, CRA turns secure coding into the primary mechanism through which manufacturers demonstrate due diligence. For executives, this means that a lack of attention paid to secure coding is no longer a purely technical quality concern, but a direct compliance risk. For technical leaders, it means that coding standards, architectural guidelines, and developer training are no longer optional enhancements, but core compliance controls.

Cybersecurity by design: from legal text to code

One of the most consequential principles introduced by CRA is cybersecurity by design. While this phrase appears frequently in regulatory language, its real meaning only becomes clear when translated into specific software engineering practices. It means that security requirements must be identified early, based on threat modeling and risk assessment, and then the architecture and implementation of the product should be aligned to these requirements.

This translation from legal requirement to technical reality happens through secure coding. Secure design principles such as the principle of least privilege, separation of privilege and separation of duties, or using fail-safe defaults are only effective if they are correctly enforced in code. A secure-by-default configuration is meaningless if the underlying implementation allows privilege escalation or bypasses validation logic. From a regulatory perspective, security requirements that are not reflected in the executable behavior of the product effectively do not exist.

The software development lifecycle perspective of CRA strengthens this connection further. Secure coding is not just a one-time effort confined to initial development. Manufacturers are required to maintain cybersecurity throughout the supported lifetime of a product. This assumes codebases that are maintainable, testable, and resilient to change. Poorly structured or insecurely written code increases the likelihood of vulnerabilities while also making remediation slower and more error-prone, increasing both operational risk and regulatory exposure.

In this sense, secure coding is now a compliance enabler. Code that follows established security principles and best practices is not only easier to audit or easier to patch but is also easier to defend from the forces of the dark side.

Vulnerability management, liability, and the cost of insecure code

CRA’s vulnerability management obligations make the relationship between secure coding and compliance rather explicit. Manufacturers must monitor vulnerabilities in their own software as well as in third-party and open-source components, assess whether those vulnerabilities are exploitable in their products, and remediate or mitigate risks without undue delay. In addition, all incidents should be reported. These tasks are only feasible if the codebase itself supports clear understanding of data flows, privilege boundaries, and component interactions. Any uncertainty increases the likelihood of over-reporting, under-reporting, or delayed remediation – all of which carry compliance risk under CRA.

Complementing the above, an additional requirement prescribes maintaining a Software Bill of Materials (SBOM), providing tangible proof on how deliberately and transparently a product has been assembled. Secure coding practices such as dependency version pinning, modular design, and minimal use of third-party code directly support SBOM accuracy. Conversely, ad hoc integration and poorly controlled dependencies can undermine both security and compliance.

Secure coding as governance

The most important shift introduced by CRA is, however, cultural rather than technical. Secure coding now needs executive oversight and is no longer a practice that can be left entirely to development teams. Since cybersecurity became a regulated product attribute, decisions about coding standards, tooling, training, and delivery timelines started to have governance implications as well.

To comply, everyone should take their stakes. Executives should recognize secure coding as a strategic investment that protects market access and reduces liability. Technical leaders should embed security deeply into engineering culture and the software development lifecycle, supported by measurable practices and continuous assurance. And of course, software engineers should be aware of the best practices all the time and have the appropriate skills to apply them and do responsible engineering.

Ultimately, the Cyber Resilience Act sends a clear and unambiguous signal to the market: insecure software is a recognized and regulated risk, not just an easy-to-ignore metric about “poor code quality”. Secure coding is the bridge between legal requirements and technical reality, and it is now one of the most important compliance controls an organization can have.