Security by Design: Core Principles for Product Teams
The Regulatory Wake-Up Call: Why “Security as an Afterthought” Is History
I attended an ANSSI briefing last year where an official articulated something I had long suspected: “Built-in security is no longer an architectural option — it’s a regulatory obligation.” In Germany, the BSI would likely put it in exactly the same terms.
The EU’s Cyber Resilience Act (CRA) has been in force since October 2024 — and it is fundamentally changing the rules of the game. Product teams that have treated security as the final step before launch are now facing a structural problem: the CRA makes Security by Design a binding requirement with real market consequences. Anyone who is not compliant simply won’t be allowed to sell their product on the European market.
France and Germany are acting as regulatory pioneers here. ANSSI and BSI had already published product security guidelines even before the CRA — the BSI TR-03183 on the cyber resilience of products is a concrete example. For product teams today this means: security belongs in the backlog from the very first sprint — not as a separate workstream, but as an integral part of every user story.
What Security by Design Really Means – Beyond the Buzzword
Before we talk about regulation, we need to separate three concepts that are regularly conflated in product meetings:
- Security by Design means that security requirements shape architectural decisions from the outset.
- Security by Default means that products are securely configured on delivery — no open ports, strong default passwords, minimal permissions.
- Reactive security measures are what teams do after an incident has occurred or a pentest has uncovered vulnerabilities.
Only the first two address the problem structurally. The core principles that operationalise Security by Design are:
- Least Privilege: every component, every user, every service is granted only the rights it actually needs.
- Defense in Depth: multiple independent security layers — if one fails, the next one holds.
- Fail Securely: in case of an error, the system should transition into a safe state rather than exposing data.
- Attack Surface Minimisation: unnecessary features, open interfaces and unused services are consistently removed.
One important point that many software teams overlook: the CRA does not only apply to classic software products. Embedded systems, IoT devices, industrial control systems — all connected products with digital elements fall within its scope. A smart home device manufacturer faces the same requirements as an enterprise software vendor.
Regulatory Requirements in Practice: What the CRA Demands from Product Teams
The CRA defines concrete obligations for manufacturers. The most relevant for product teams:
- Vulnerability management across the entire product lifecycle — including a defined process for disclosure and remediation (Vulnerability Disclosure Policy).
- Security updates must be made available for a minimum period — the CRA speaks of up to five years, depending on the expected useful life.
- Declaration of conformity and technical documentation are mandatory, not optional.
The risk classification under the CRA is decisive here: products are divided into standard products, critical products class I (e.g. password managers, browsers, VPN software) and critical products class II (e.g. hypervisors, firewalls, industrial control systems). Class II products require an external conformity assessment by a notified body — that is significantly more demanding in both operational and financial terms.
The CRA does not exist in a vacuum. Product teams also need to keep an eye on the interfaces with NIS2, the Radio Equipment Directive (RED) for radio equipment, and the European Cybersecurity Certification Framework (EUCC). Anyone developing a connected product with a radio interface may find themselves subject to three regulatory frameworks simultaneously.
Embedding Security by Design Operationally: From Theory to Product Practice
The most common mistake: teams read the regulatory requirements and ask themselves how they can produce compliance documents. The right question is: how do we change our development process?
Threat Modeling is the entry point. Methods such as STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) or PASTA (Process for Attack Simulation and Threat Analysis) help teams identify threats systematically — before a single line of code is written. A threat modeling workshop at the start of a new feature costs half a day. A security redesign after launch costs weeks.
The Secure Development Lifecycle (SDL) integrates security gates into the development process. In agile environments, this specifically means: security acceptance criteria in user stories, automated security checks in the CI/CD pipeline, and regular security reviews as part of the Definition of Done — not as a separate process that costs velocity.
Tooling is well available today:
- SAST (Static Application Security Testing) analyses code for known vulnerability patterns.
- DAST (Dynamic Application Security Testing) tests running applications against attack vectors.
- SCA (Software Composition Analysis) identifies vulnerabilities in third-party libraries.
- The SBOM (Software Bill of Materials) documents all software components — and is explicitly addressed as a requirement by the CRA.
Organisational Prerequisites: Security as a Team Responsibility
This is where it gets uncomfortable: a single security team cannot carry product security on its own. The capacity is missing, the proximity to the code is missing, and the incentives are misaligned.
The Security Champions model is the more practical alternative: developers from each team who receive in-depth security training and act as multipliers. They translate abstract security requirements into concrete implementation decisions — and they sit in the same daily standup as the rest of the team.
The governance question remains unresolved in many organisations: who bears responsibility for product security — the CISO or the CPO? The honest answer is: both, with clearly defined responsibilities. The CISO sets the framework and standards; the CPO carries operational responsibility for implementation in the product. Where this accountability is unclear, exactly the organisational gap emerges that the CRA is designed to address.
Typical Pitfalls and How Product Teams Avoid Them
“Compliance is not security.” — You hear that often in security circles, and it’s true. But the reverse also applies: a lack of compliance is a market risk.
The Security Theatre anti-pattern is familiar to anyone who has been through audits: checklists are ticked off, documentation is produced — but actual risk reduction never happens. Experienced auditors recognise this. They don’t just look at documents; they ask: which vulnerabilities were found last quarter, how quickly were they remediated, and what did the team learn from them?
The cost trap of late-stage security is well documented: NIST demonstrated early on that security flaws remediated only after deployment are on average 30 times more expensive than preventive measures in the design phase. On top of that, a retroactive security fix in a connected IoT product may require a firmware update that has to be coordinated and rolled out across millions of devices.
Missing technical documentation is no longer a trivial matter under the CRA. Market surveillance authorities can request documentation — and anyone unable to provide it risks having their product withdrawn from the market.
Takeaways & Next Steps: How Your Product Team Can Start Today
The three immediate measures I would recommend to every product team:
- Schedule a threat modeling workshop — for your current product or the next major feature. Invest half a day, capture threats in a structured way.
- Establish an SBOM process — which third-party libraries are in use, which versions, which known vulnerabilities? This is the basis for CRA-compliant documentation.
- Assess your CRA maturity — which product category applies to your product, which obligations arise from that, and where are the current gaps?
The CRA transition period runs until the end of 2027 — that sounds far off, but for companies with complex product portfolios it is already tight today. Those who start their analysis now have a choice. Those who wait no longer do.
EACG supports product teams with regulatory classification, the implementation of a Secure Development Lifecycle and preparation for CRA conformity — from gap analysis through to technical documentation. A non-binding initial consultation provides orientation before regulation becomes a question of deadlines.
Guest contribution. Tech journalist, EACG is the regulatory source. Unpaid.