Threat Modeling in Theory vs. Reality

Threat modeling has been part of security engineering for decades. Most experienced engineers are familiar with approaches such as STRIDE-based threat classification, data-flow–driven analysis, attack trees, and risk-oriented frameworks like TARA. Despite differences in notation and emphasis, these methods share a common intent: to reason about security before a system is built, and to influence architectural decisions while change is still feasible.

In recent years, threat modeling has moved beyond traditional IT systems and become a formal requirement in safety- and regulation-driven industries. Automotive cybersecurity is a clear example. Under UN Regulation No. 155, vehicle manufacturers are required to establish and operate a Cyber Security Management System (CSMS), and threat analysis and risk assessment are explicitly mandated as part of that system. In theory, this elevates threat modeling from a “best practice” to a core engineering activity with real regulatory weight.

And yet, in practice, threat modeling often fails to deliver the security outcomes it promises.

Threat models are created. TARA documents are reviewed. CSMS audits are passed. Still, familiar architectural weaknesses resurface in production vehicles, backend platforms, and update infrastructures. The problem is not that threat modeling is misunderstood or ignored. It is that, in real engineering organizations, it is frequently misaligned with how systems are actually designed, built, and evolved.

This article explores why threat modeling breaks down in practice—not at the level of theory, but at the level where organizational structure, delivery pressure, and real system complexity collide.

1. Threat Modeling Becomes a Compliance Artifact

In regulated environments, threat modeling is often driven by external requirements. For automotive teams responding to UN R155, threat modeling is closely associated with producing TARA documentation, risk tables, attack scenarios, and mitigation lists that can be presented during assessments.

Once those artifacts are approved, the activity is considered complete.

At that point, threat modeling stops being a design tool and becomes evidence of compliance. It explains the system as it already exists rather than shaping what the system should become. Architectural decisions—network segmentation, trust boundaries, key management models—are rarely revisited as a result of the analysis. The threat model exists, but its influence on the system is minimal.

The presence of documentation is mistaken for the presence of active risk management.

2. Organizational Boundaries Fragment the Threat Model

Threat modeling assumes a system-level view. Real engineering organizations rarely operate that way.

In modern vehicle platforms, responsibility is split across multiple domains: in-vehicle ECUs, gateways, cloud backends, mobile applications, OTA infrastructure, and third-party services. Development is further divided across OEM teams, Tier-1 suppliers, and external partners. Each group owns a piece of the system, but no single team owns the full threat landscape.

As a result, threat modeling is typically performed within local boundaries. Each team models threats for what it controls. Cross-domain risks—such as trust relationships between vehicle and cloud, authorization propagation across gateways, or failure modes during OTA rollback—fall into the gaps between teams.

CSMS may exist at the organizational level, but ownership of systemic threats often does not.

3. The Threat Model Reflects the Intended Architecture, Not the Real One

Threat models are usually built on clean architectural diagrams. Production systems are rarely clean.

Over time, vehicle platforms accumulate legacy ECUs, supplier-specific implementations, conditional security features, and operational exceptions introduced to meet schedule or compatibility constraints. These realities are well understood by engineers, but they are uncomfortable to capture formally. Including them complicates the analysis and raises difficult questions about residual risk.

As a result, many threat models describe an idealized system—one where secure boot, secure communication, and key management are consistently applied—rather than the system that actually ships.

Attackers do not interact with idealized architectures. They interact with deployed ones. The gap between the two is where many critical vulnerabilities live.

4. Threat Modeling Loses Authority Under Delivery Pressure

Engineering teams are driven by deadlines. In automotive development, SOP dates are fixed, and late architectural changes are expensive and risky. Threat modeling, by contrast, often produces findings that imply structural change rather than simple fixes.

When security recommendations conflict with schedule or scope, they are frequently deferred:

• “We’ll address this in the next platform.”
• “We’ll mitigate operationally.”
• “This risk is acceptable for now.”

Over time, teams internalize an implicit rule: threat modeling raises concerns, but it rarely changes delivery decisions. Once that perception takes hold, the exercise loses credibility—even when engineers agree with the analysis in principle.

5. Threats Are Identified, but Decisions Are Avoided

Many threat models are thorough in enumeration. Assets are listed, threats are categorized, risk scores are calculated. What is often missing is the hard part: explicit decisions.

Effective threat modeling forces uncomfortable questions:

• Which risks are we consciously accepting?
• Which assumptions must remain true for this design to be safe?
• Who owns this risk if those assumptions fail?

In practice, risks are documented but not owned. Mitigations are suggested but not enforced. Without clear decisions and accountability, the threat model becomes an analytical report rather than an engineering input.

6. Threat Models Do Not Survive the System Lifecycle

UN R155 emphasizes cybersecurity across the entire vehicle lifecycle. Real systems, however, evolve rapidly after launch. OTA updates add functionality. Backend services change. New integrations are introduced. Attack techniques evolve.

Threat models rarely evolve at the same pace.

Once development ends and production begins, threat modeling often stops. Lessons learned from incidents, vulnerability reports, and field data are not systematically fed back into the original analysis. The threat model remains frozen in time, increasingly disconnected from the system it was meant to protect.

Reframing Threat Modeling as an Engineering Discipline

Threat modeling does not fail because STRIDE, TARA, or similar methods are flawed. It fails because it is too often treated as a procedural requirement rather than an engineering discipline.

For threat modeling to matter, it must:

• Influence architectural decisions, not just describe them
• Reflect the deployed system, including legacy and operational constraints
• Assign ownership for cross-domain and systemic risks
• Evolve continuously alongside the system itself

Threat modeling is not about producing better diagrams or more complete tables. It is about forcing difficult design decisions while there is still time to act.

Until organizations align threat modeling with how systems are actually built, delivered, and maintained, it will continue to fail quietly—performed correctly, documented thoroughly, and largely ineffective in practice.