Security by Design is a systemic choice
In many projects, the initial focus is on functions, deadlines and budgets. Security requirements are added once key product decisions have already been made. Scanners, penetration tests and checklists remain important. However, they cannot prevent risks that have already arisen as a result of fundamental architectural and design decisions.
Security by Design therefore begins with questions such as: What data and functions need to be protected? Who is authorised to access them? Where do data or actions cross a trust boundary? What would be the consequences of a function being misused? And what security properties must apply regardless of specific implementation details?
This structured analysis is often referred to as threat modelling. It is crucial to identify relevant risks at an early stage and to derive requirements, architectural decisions and tests from them.
One example is the separation of capabilities: a service authorised to read sensitive data does not automatically require unrestricted access to external systems. A file upload does not require execution rights. The more clearly such boundaries are defined in the design, the less security depends on every component reacting correctly in every situation.
Furthermore, recurring security decisions should not have to be re-evaluated in every project. Centralised solutions for authentication, secrets management, logging or secure CI/CD pipelines create what are known as ‘paved roads’ or ‘golden paths’. Improvements to these standard pathways benefit many applications simultaneously.
The secure path must be simple and well supported. If it is too complicated or too slow, bespoke solutions will emerge and, in the worst case, ‘shadow IT’ will develop outside the intended platform and governance processes.
Early security makes costs more predictable
Frequently cited cost factors of ten, thirty or even a hundred do not tell the whole story. What matters is not so much a blanket multiplier as the scale of the changes involved. In the case of security, this is often particularly extensive, as security affects architecture, data flows, authorisations, interfaces, testing and operations all at once.
Prior to implementation, a decision may affect just a single requirement or an architectural diagram. Later on, code, data models, tests, documentation and deployment may also be affected. After going live, patch distribution, support, incident response and regulatory obligations are added to the mix.
Security by Design therefore does not make secure development cost-free. The advantage lies in integrating the necessary effort into the development process in a predictable manner and distributing it across multiple applications through reusable components.
The effectiveness of such investments should be assessed on the basis of results. The number of scans, reviews or threat models initially merely indicates activity. It is more meaningful to assess whether relevant risks have been identified earlier, insecure solutions replaced and entire classes of errors reduced.
From best practice to regulatory requirement
Security by Design has long since ceased to be merely a voluntary best practice. NIS2 requires affected organisations to implement appropriate measures to manage cyber risks. These include risk analyses, security in procurement, development and maintenance, as well as procedures for assessing the effectiveness of the measures taken.
Threat modelling approaches such as STRIDE or PASTA help to identify risks, derive measures and document decisions in a traceable manner. If development, approval and verification processes are embedded within the organisation-wide ISMS, responsibilities and risk acceptance levels can be managed consistently. However, an ISMS does not replace product-specific risk assessment; rather, it provides the organisational framework for its implementation.
For manufacturers of products with digital elements, the Cyber Resilience Act becomes more specific: it requires a product-specific cybersecurity risk assessment across the entire life cycle and demands that the measures derived from this are implemented and documented in a traceable manner.
This changes the role of documentation. Organisations must be able to demonstrate which risks they have identified, what decisions they have derived from them, and how they have verified the effectiveness of the measures.
Frameworks and guidelines help to translate these elements into structured processes. The BSI’s IT-Grundschutz contains specific requirements in CON.8 ‘Software Development’; BSI TR-03185 supplements these with guidelines for a secure software lifecycle. OWASP SAMM and the NIST Secure Software Development Framework support the organisational design of a secure development lifecycle. Which reference is appropriate depends on the product and its area of application; however, they are no substitute for addressing the actual risks.
Auditability is therefore not achieved through a documentation drive shortly before an audit or market launch. It arises as the result of a consistently applied development process.
Security does not end with the go-live
Even an application developed securely does not automatically remain secure. Components are subject to new vulnerability reports, threats evolve, and systems are expanded or used in ways other than originally planned.
Security by Design must therefore be combined with secure operations. This includes patch and vulnerability management, monitoring, backup and recovery, incident response, and regular reviews of the original security assumptions. Centralised platforms, libraries and infrastructure templates must also be continuously maintained.
The aim is not merely to have an application that is secure on the day of its launch, but a development and operations model that maintains security throughout the entire lifecycle.
Conclusion: Secure decisions must be scalable
Security by Design means designing products, platforms and processes in such a way that secure decisions are made reliably and reproducibly. Secure software is not created by a single test shortly before go-live, but through a development model in which the secure approach becomes the standard approach and decisions can be substantiated in a traceable manner.
