Compliance catalysts: Why Secure-by-Design has become inevitable

The phrase ‘secure-by-design’ has become a bit of a buzzword in recent months, thanks in no small part to the EU Cyber Resilience Act, which looks set to turn it into a mandatory requirement across the EU. But it’s not a new idea. Secure-by-design has been a principle for decades, but still, most organisations have failed to implement it. 

 

And it’s not surprising when you consider the immense pressure most development teams are under. As innovation has sped up, development cycles have shortened, with security often bolted on at the end in an effort to save time. While security teams might be doing their best to advise, developers simply lack the time and investment needed to translate these requirements into code and working practices, focusing instead on the short-term time gain. 

 

But the CRA is just the latest in a long line of cyber-security regulations. It’s not the first, and it’ll be far from the last that developers have to contend with. And if they continue to avoid secure-by-design principles, they’ll find themselves in the same scenario again and again. Time might be saved at the start of the development process, but once products are released and vulnerabilities are found or software updates are needed, the patchwork fixes will be lengthy and costly. Instead, if developers take the time now to embed a secure-by-design approach, they won’t just be able to adhere to the CRA and future regulations but will see development cycles speed up as a result. 

 

The reality of post-launch software maintenance

Today’s development cycles are increasingly condensed, with teams often under pressure to innovate at speed to keep pace with rapidly changing landscapes. As a result, most of the attention is placed on the first half of a product’s lifecycle, on developing the product and shipping it. It’s only once the product is out there in the market and vulnerabilities are inevitably unearthed that updates are required, and when new security assessments are needed, that attention turns to the security of the product. 

 

The practical reality of delivering these post-launch updates is that it all depends on strict component tracking. To ensure these fixes are developed and sent to the right users, teams need to be able to generate a Software Bill of Materials (SBOM) to identify exactly which components and versions are included in a deployed product. Those components need to be actively managed too, and even though much of a product’s codebase can include open-source components outside a manufacturer’s direct control, responsibility for fixing a given issue stays with the manufacturer, which is no small task across a product built from potentially thousands of components. So that when a new security incident does occur, developers and end users alike can use the SBOM to determine if the vulnerability actually applies to them and which specific product versions require a patch. But these functionalities need to be built from day one of development in order to provide secure support for future updates and vulnerability management across the full product lifecycle.

 

This support is even more crucial in the case of complex products such as industrial machines that can often take half a decade just to develop. Even across the development cycle alone, it becomes impossible to work with just one software version, not to mention the decades of support these products often require. Before teams even account for the inevitability of vulnerabilities, they need to establish a clear update philosophy and embed the security infrastructure needed to support the necessary upgrade path. 

 

And even on less complex products, firmware or software updates years into the lifecycle can be challenging, particularly without strong compatibility guarantees between versions, since every fix then risks additional integration work downstream. If an update solves one issue but introduces a new bug, not only can users become understandably frustrated, but support costs could increase, and in severe cases, products could even be recalled. In order to avoid this, features like automated testing, architecture verification, and continuous integration pipelines need to be built into products and built to last long after the initial launch. 

 

Security isn’t something that can be solved with individual patches and updates; it’s an ongoing challenge that developers need to address from the first day of work on a product.

 

Secure-by-design and Faster-by-design?

Arguably, one of the biggest barriers to the adoption of secure-by-design is the sheer number of cyber-security regulations that companies need to adhere to. There’s often a misconception that each new regulation slows down processes, adding new requirements to follow, but the CRA is different. Yes, it has new requirements for improved vulnerability management, automatic updates, and technical documentation, but rather than leaving room for spot fixes, it pushes manufacturers to embrace cyber-security as a critical element of a product’s entire lifecycle. 

 

Certainly, some cyber-security fixes in the past might have had extended timelines, but there’s almost certainly a chicken-and-egg scenario at play there. In complex software projects, outdated code structures and security shortcuts can quietly snowball into technical debt, with vulnerabilities and structural flaws becoming inadvertently baked into the system. So when a new flaw is found that requires an update to address, that debt turns a routine task into a costly delay that has a knock-on effect on compliance and development schedules. Sure, the flaw itself might have sparked the delay, but the cause is the years of legacy spot patches that have come before. 

 

But in a project following a secure-by-design approach from day one, this debt doesn’t get the chance to snowball. Bugs are caught and addressed at the coding phase, and post-launch fixes become simpler and faster to execute. Catching these security issues, bugs, and potential compliance failures earlier might seem like more work at the start, but it’s far easier to address these issues while the code is still being written. It cuts down significantly on both the debugging time and the manual labour used in lifecycle management, reduces the cost and risk of post-launch fixes, freeing up both time and resources for functional innovation on the next product. 

 

Moving cyber-security to the front

With secure-by-design approaches still hard to come by, the CRA could be a landmark regulation, and not just because it marks the first time that manufacturers in the EU will share common ground. The shift in design approach that it could represent is long overdue, and necessary to create complete product lifecycles that don’t stop at launch. And with the CRA’s vulnerability and incident reporting obligations now in force since September 11th, and full compliance required by December 2027, secure-by-design just became inevitable for development teams.

 

While it will be no small adjustment, it’s a necessary one. By updating their processes, practices, and security setups in line with the CRA, companies can enable faster, smoother development with vulnerability management, documentation, and security assessments embedded from day one. New product development processes can continue, unhindered by the usual late-stage vulnerabilities of the last iteration, making way for new innovation. With the CRA, perhaps we can finally put aside the assumption that innovation and cyber-security are mutually exclusive, proving instead that they are mutually beneficial.

 

---

 

Maurice Kalinowski is Product Director at Qt Group 

 

Main image courtesy of iStockPhoto.com and matejmo