Written by Sebastien Deleersnyder

Threat Modeling for CRA Compliance: Article 13, Annex I & Security by Design

As a senior security leader, you’re tasked with steering your organization through a rapidly evolving regulatory landscape. The EU Cyber Resilience Act (CRA) – which entered into force on December 10, 2024, and applies in full from December 11, 2027 – mandates strong cybersecurity practices for every product with digital elements sold in the EU.

How can you meet these requirements strategically, without ballooning costs or stifling innovation? The answer lies in threat modeling. More than just a technical exercise, threat modeling is the structured methodology that satisfies CRA Article 13(2)’s risk-assessment mandate, enables security by design across the product lifecycle, and produces the technical documentation the law requires – in a single workflow.

This article shows how a threat modeling program, scaled across your product portfolio, turns CRA compliance from a cost center into a strategic advantage.

CRA Compliance Timeline: When You Need to Be Ready

The EU Cyber Resilience Act has a phased enforcement schedule that determines how much time manufacturers have to build CRA-ready security programs. Knowing these dates shapes your threat modeling investment plan.

The CRA entered into force on December 10, 2024. From that moment, the law is legally binding but most obligations are not yet enforceable – this is the build-out window during which manufacturers establish their threat modeling, documentation, and vulnerability handling capabilities.

From September 11, 2026, the reporting obligations in Articles 14 and 15 apply. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA within 24 hours of becoming aware. Building the threat-model-driven vulnerability intake process before this date is non-negotiable.

From December 11, 2027, the full CRA applies. Every product with digital elements placed on the EU market must meet the essential cybersecurity requirements in Annex I, must carry a CE marking based on a successful conformity assessment, and must be backed by the technical documentation Article 31 requires – including the cybersecurity risk assessment that Article 13(2) mandates.

For most manufacturers, the practical horizon is the 18-24 months between now and Q4 2027: enough time to build a threat modeling program from scratch, IF the program starts in 2026. Organizations that wait until Q3 2027 face a forced consultant-heavy implementation and significantly higher cost.

Threat Modeling and CRA Article 13(2): From Compliance Obligation to Strategic Advantage

Regulators now expect what savvy CISOs have long valued: proactive risk assessment at every stage of product development. In fact, Article 13(2) of the CRA explicitly requires manufacturers to “undertake an assessment of the cybersecurity risks associated with a product” and to use its outcomes throughout “the planning, design, development, production, delivery and maintenance phases” of the product.

In other words, threat modeling is not optional – it’s baked into the law’s core. But beyond ticking a compliance box, threat modeling delivers strategic value. By systematically identifying potential threats and design flaws early, you can align security measures directly with business risk. This risk-based alignment is exactly what Article 13(2) envisions, and it transforms a compliance obligation into a strategic advantage. Rather than treating CRA requirements as a checklist of controls, forward-thinking organizations use threat modeling to drive smart investments: focusing on the threats that matter most to the business and customers. This approach ensures you’re not over-engineering low-risk areas, but rather delivering security where it counts, maximizing ROI on security efforts. In sum, threat modeling turns Article 13(2) into action, helping you meet the CRA’s risk assessment mandate while strategically safeguarding what’s critical.

Enabling Security by Design Across the Product Lifecycle

One of the CRA’s driving principles is security by design – building products that are secure from the ground up and throughout their lifespan. Threat modeling is the practical engine that powers this principle. Security by design is really just thinking about security in every phase of development – in the requirements phase you consider relevant standards and the risks to defend against, then in the architecture phase you might do a threat model to see how an attacker could abuse the design… and so on through coding, testing, and deployment.

By weaving threat modeling into each stage of your development lifecycle, security stops being an afterthought and becomes an integral design parameter. This approach isn’t just theory; it’s emphasized in both the CRA text and industry guidance. The CRA obliges manufacturers to integrate cybersecurity “during the design and development phase” of products, embodying security by design (The CRA, explained – Cyber Resilience Act). In practical terms, this means your teams should be identifying threats and defining controls from the moment product requirements are drafted, through architecture and implementation, to release and maintenance.

The payoff is huge: studies show that catching and fixing security issues early (during design or coding) is vastly cheaper than late-stage fixes. IBM’s System Sciences Institute estimates a 100x cost multiplier; Security Compass reports up to 640 times more to remediate a vulnerability discovered in production versus during coding (The High Costs of Delaying a Security by Design Program – Security Compass). Threat modeling helps you identify issues at the design stage – before a single line of code is written – thereby avoiding costly rework and last-minute scrambles. Moreover, it reinforces a development culture where everyone, from architects to developers, thinks like a security practitioner. This cultural shift toward “secure by design” not only satisfies CRA expectations but also yields more resilient products and fewer fire-drills down the road.

Risk-Based Prioritization of CRA Annex I Requirements (and Knowing What to Exclude)

Not all CRA essential requirements will carry equal weight for your product – and that’s by design. The Act’s Annex I lists high-level security outcomes (from protecting data and access control to ensuring resilience against attacks), but it’s up to manufacturers to implement appropriate controls based on their risk assessment (Security by Design and by Decree).

Threat modeling provides the risk insight needed to prioritize these requirements intelligently. For example, Annex I requires products to “protect the availability of essential functions, including through resilience and mitigation measures against denial-of-service attacks”. This is an important baseline — but what if your threat model reveals that a sophisticated DoS attack on your particular product would have minimal impact or is mitigated by your cloud infrastructure? Instead of blindly pouring resources into extreme anti-DoS measures, you might decide to implement basic rate-limiting and then focus more effort on controls for higher-impact threats (like hardening authentication, if your model shows that’s a prime target). The CRA allows such flexibility, as long as you justify it. In fact, the law explicitly states that your cybersecurity risk assessment must indicate which essential requirements apply and how you implemented them “as informed by the cybersecurity risk assessment”. If a certain requirement is deemed not applicable, you must document a clear justification in your technical files.

Threat modeling arms you with this exact justification. It documents why you chose to address certain risks and perhaps accept or mitigate others through compensating controls. In practice, this means you can even exclude a particular Cybersecurity Requirement as listed in Annex I (2) (for instance, an advanced anti-DoS mechanism) if your threat modeling evidence shows the risk is low and is addressed by other means – and remain compliant by recording that rationale. The result is a risk-prioritized security strategy: you’re fully meeting CRA requirements, but doing so in a way that optimizes resources and avoids one-size-fits-all security. This targeted approach can also streamline your certification or conformity assessment process, since auditors will see a well-reasoned risk-based implementation rather than a haphazard or checkbox approach.

How Threat Modeling Maps to Specific CRA Annex I Requirements

The CRA’s Annex I lists essential cybersecurity requirements at a high level – access control, data protection, resilience against attacks, secure configuration, and so on. Annex I tells you what outcomes the regulator expects but not how to get there. That is where threat modeling earns its keep: each Annex I requirement maps to one or more threat categories from STRIDE (or whatever framework you use), and each threat in your register maps back to one or more Annex I requirements. The result is a two-way audit trail.

A few practical mappings illustrate the pattern. Annex I requires products to protect the confidentiality and integrity of stored, transmitted, and processed data. STRIDE’s Information Disclosure and Tampering categories address that directly – any data flow in your DFD that crosses a trust boundary triggers both threat categories and forces the team to specify encryption-in-transit, encryption-at-rest, and integrity-check controls. Annex I requires products to be designed to limit attack surfaces. STRIDE’s Spoofing and Elevation of Privilege categories surface every authentication and authorization decision in the architecture – the threat model documents which user roles can reach which components and forces the team to justify any over-privileged path. Annex I requires products to protect availability through resilience and mitigation against denial of service. STRIDE’s Denial of Service category, combined with the threat model’s evaluation of whether a sophisticated DoS attack is realistic for your specific product, gives you the risk-based justification for whatever DoS protection level you implement.

The practical workflow is to attach an Annex I reference (e.g. ‘Annex I (2)(a)’) to every threat in your register, and an Annex I reference to every mitigation. When an auditor asks ‘how does this product meet Annex I requirement X?’, you can answer with the threat model entry that drove the implementation. No separate compliance worksheet, no after-the-fact reverse-engineering.

Documenting Threat Models = Documentation for CRA Compliance

One often overlooked benefit of threat modeling is how it simplifies the paperwork of compliance. The CRA mandates extensive technical documentation to prove your product meets the essential requirements (per Article 31 and Annex VII). This isn’t just bureaucratic busywork – it’s evidence that you built your product with security in mind. A well-executed threat model produces exactly the kind of evidence the CRA expects to see. Your threat modeling artifacts – diagrams of data flows, lists of identified threats and mitigations, risk ratings, and decisions on security controls – collectively form the “cybersecurity risk assessment” that Article 13(3) and (4) demand to be included in technical documentation. In fact, the CRA’s wording implies that the risk assessment should explicitly link to the essential requirements (e.g., noting which Annex I points are addressed, which are not applicable, and why). A threat model naturally provides this linkage: each threat maps to mitigations, which in turn map to security requirements. By maintaining this documentation throughout the product lifecycle (updating it as the design changes or new threats emerge), you also fulfill the CRA’s expectation that risk assessments be living documents, updated as appropriate.

When it comes time to declare conformity (and potentially face a market surveillance audit), you won’t be scrambling to assemble evidence – it’s already there, baked into your development artifacts. Additionally, threat modeling documentation can feed into user-facing documentation the CRA requires (such as secure configuration guides or known residual risks in instructions), demonstrating transparency and due diligence. In short, threat modeling doesn’t just bolster security – it generates the compliance artifacts you need for CRA on the fly. This integration kills two birds with one stone, giving you regulatory peace of mind without separate, duplicative work. As a bonus, having this thorough security documentation internally means your teams and leadership have clearer visibility into the security posture of each product, aiding informed decision-making beyond compliance.

Business Benefits: Lower Costs, Clear Compliance, Stronger Culture, Self-Sufficiency

For security professionals, the value of threat modeling extends beyond passing an audit – it fundamentally improves how your organization operates. Let’s break down the business case:

Reduced Costs Through Early Risk Mitigation: As mentioned, fixing design issues early prevents exponentially higher costs later. By cutting down late-stage security fixes, threat modeling saves engineering time and money. A single severe vulnerability caught in design could avoid a costly patch or incident down the line (one estimate put the cost of a single late-stage fix at over $50,000 (The High Costs of Delaying a Security by Design Program – Security Compass)). Multiply that by dozens of potential issues across products, and the savings are significant. Furthermore, avoiding breaches or incidents (with their associated downtime, damage, and fines) has an incalculable benefit. Threat modeling is essentially preventive medicine for products – a small up-front investment that averts huge remediation bills.
Regulatory Clarity and Focus: The CRA and other regulations can be daunting, but threat modeling provides a roadmap through them. It forces cross-functional conversations about which regulations and controls apply to a given project. By tying concrete threats to specific compliance requirements, you demystify what needs to be done for CRA compliance in each context. Teams get clarity on why certain security controls are necessary, which increases buy-in. And leadership gains confidence that compliance isn’t being achieved haphazardly, but through a risk-driven plan. This clarity can also prevent over-spending on “just in case” measures that regulations mention but your risk assessment deems low priority. In essence, you achieve CRA compliance with surgical precision, focusing resources on the areas regulators (and your own risk criteria) deem most critical.
Stronger Security Culture: Threat modeling, when scaled as a program, becomes a training ground for your entire development organization to think about security. It’s a collaborative practice – developers, architects, and security experts work together to brainstorm threats and defenses. Over time, this builds a security-first mindset across teams. Instead of relying solely on periodic audits or one security champion, everyone starts to internalize how to build secure systems. This cultural shift is invaluable: security moves from being “the security team’s job” to “everyone’s job.” An inclusive threat modeling practice can make security a shared responsibility and even a point of pride among engineering teams. (It’s telling that many security leaders view threat modeling proficiency as integral to building a strong, sustainable security culture. A mature security culture not only reduces the number of issues that slip through, but it also makes hiring and retention easier – top engineering talent increasingly want to work in environments where security is taken seriously and built in by design.
Internal Self-Sufficiency and Skill Growth: Investing in threat modeling capability – through training and tooling – pays off in greater independence. If you currently rely on expensive external consultants or penetration tests late in the cycle, building an internal threat modeling program can cut that dependency. Your teams become capable of assessing designs and systems on their own, catching issues without always needing a third-party review. This is a pain point for CISOs, who noted the “high recurring costs and dependency on external consultants” for threat assessments. By empowering in-house staff with threat modeling know-how, you reduce these external costs. Moreover, the skills developed (systematic risk analysis, creative adversarial thinking, knowledge of attack patterns) benefit other areas of security and IT. Over time, your organization grows a cohort of security-savvy engineers and architects. This not only supports the scalability of your threat modeling program (more trained people to lead sessions as your product portfolio grows), but also contributes to overall self-sufficiency. Threat modeling training “empowers internal staff, improving self-sufficiency and reducing external dependency”. In a world of scarce cybersecurity talent, growing your own internal expertise through practices like threat modeling is a smart long-term strategy.

When you combine these benefits – cost reduction, clarity in compliance, cultural transformation, and skill development – the case for scaling up a threat modeling program becomes compelling. It’s not a buzzword or a trend; it’s a sustainable practice that aligns security, compliance, and business objectives. As you plan budgets and initiatives for the coming year, consider that threat modeling isn’t just an extra task for your teams, but a force multiplier that can make all your other security and development efforts more effective.

Conclusion: Take Action on Threat Modeling for CRA Success

The EU Cyber Resilience Act raises the bar for product security and accountability – but with threat modeling as part of your strategy, you can not only meet these requirements, but exceed them in a way that adds value to your business. By embedding threat modeling into your development lifecycle, you achieve true security by design, document your compliance as you go, and foster a proactive security culture within your organization. As a senior leader, championing a threat modeling program is a savvy move to scale security without scaling cost. It turns compliance from a headache into a driver of innovation and quality.

Next Steps

Ready to elevate your security program? Start by educating and empowering your teams. Sign up for Toreon’s Threat Modeling Insider newsletter for regular insights on scaling a threat modeling program, CRA compliance tips, and real-world case studies. And to accelerate your journey, check out our threat modeling training – a hands-on way to build in-house expertise and confidently meet CRA obligations. Don’t wait for the next regulatory deadline or security incident to force your hand; take action now to make threat modeling your strategic advantage in 2025 and beyond.

About the Author

Seba Deleersnyder is the editor of the Threat Modeling Insider newsletter and a passionate advocate for practical security solutions. With years of experience in the field, he continues to curate insights and build communities that make threat modeling more accessible to everyone.