Ask a systems team where their cybersecurity analysis lives and you'll usually get pointed at a spreadsheet. It's a threat register: rows for assets, columns for attack paths, a risk rating, a mitigation. It was probably built in a workshop three months ago and hasn't been touched since. Meanwhile the architecture it describes has moved on. An interface got renamed, a component got split in two, a data flow that used to be internal now crosses a network boundary. The security analysis and the system it's supposed to protect have quietly drifted apart, and nobody notices until an auditor or an attacker finds the gap. Model-based security engineering is the attempt to stop that drift by moving the threat analysis into the same model as the design.
Why the spreadsheet fails
The problem isn't that threat registers are wrong. It's that they're disconnected. A cybersecurity risk assessment is a set of claims about a specific architecture: this asset, reachable through that interface, exposed to this threat. Every one of those claims depends on the system actually being structured the way the assessment assumed. When the architecture is a living model and the assessment is a static document, there's no mechanism to tell you when an assumption breaks.
Standards have made this worse in a productive way, by demanding evidence. ISO/SAE 21434 for road vehicles requires a documented Threat Analysis and Risk Assessment, or TARA, that traces from item definition through assets, threat scenarios, attack paths, and risk treatment. DO-326A does something similar for airborne systems. These frameworks want traceability, and traceability across two disconnected artifacts is manual, error-prone work that has to be redone every time either side changes. That redo cost is exactly what model-based approaches are built to eliminate.
What moving security into the model looks like
The core idea of model-based security engineering is that the things a TARA talks about are already objects in your system model, or should be. An asset is a block. An interface is a port. A data flow is an item flow. So instead of retyping all of that into a separate register, you extend the model with the security-specific elements and link them to what's already there.
The most developed version of this is MBSEsec, an academic method that gives security a place in the SysML modeling flow rather than bolting it on afterward. It builds on familiar constructs: extended use case diagrams to capture misuse cases, activity diagrams to model attack scenarios, and a threat-and-risk structure that links risks, threats, vulnerabilities, and treatments back to the assets they concern. A misuse case is just a use case seen from the adversary's side: an actor deliberately provoking a feared situation that compromises the mission. Modeling it next to the legitimate use cases forces the two views to share vocabulary and stay consistent.
Threat taxonomies plug in cleanly. STRIDE, the spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege checklist, becomes a way to systematically walk each asset and interface and ask which categories apply. Because the assets and interfaces are model elements, that walk can be partly driven from the model instead of from memory.
Traceability is the real payoff
The reason to endure the extra modeling is what it buys you downstream. When a misuse case links to the asset it targets, and that asset links to the interface that exposes it, and the mitigation links back to a cybersecurity requirement, you get a traceable chain from threat to countermeasure that lives inside the same digital thread as the rest of your engineering data.
That chain is what makes change tolerable. Move a component across a trust boundary in the architecture and the model can show you every misuse case and mitigation now affected, instead of leaving you to remember which spreadsheet rows to revisit. It's also what makes compliance defensible. When an assessor asks how a given security control traces to an identified threat and back to a requirement, the answer is a query against the model rather than an afternoon of cross-referencing.
Tooling for this varies in maturity. Some teams extend general-purpose SysML environments such as Dassault's Cameo Systems Modeler or Eclipse Capella with a security profile and custom stereotypes, while platforms like Dalus work natively in SysML v2, whose textual notation and API make it easier to attach and query the kind of cross-cutting security links a TARA depends on. In every case the security layer is only as trustworthy as the model it sits on, so the discipline of keeping the base architecture current matters more than the specific tool.
What it won't solve
Modeling threats is not the same as finding them. A model-based TARA is a structured way to record and trace the threats your team identifies. It does not conjure the threats. If your analysts don't know that a particular protocol has a replay weakness, no diagram will surface it. The creativity of thinking like an attacker still lives in people, and model-based methods can even give false comfort by making an incomplete analysis look rigorous.
It also adds real cost. Extending a model with a security profile, training people to use misuse cases correctly, and keeping the security links in sync with a changing architecture is ongoing effort, not a one-time setup. For a small system with a narrow attack surface, a well-maintained register may genuinely be enough, and forcing everything into the model can be overkill.
And it doesn't replace testing. Penetration testing, fuzzing, and code-level analysis find the concrete flaws that architectural threat modeling can only point toward. The model tells you where to look and why it matters. It doesn't tell you whether the mitigation you specified was actually implemented correctly. That gap between the modeled control and the built control is where a lot of real breaches live, and only verification closes it.
The bottom line
Model-based security engineering is worth the effort when your cybersecurity analysis has to survive a changing design and stand up to an auditor. Pulling assets, misuse cases, threats, and mitigations into the system model, and linking them into the same digital thread as your requirements and architecture, turns a stale spreadsheet into a queryable, traceable part of the design. It won't invent threats for you, it won't verify your code, and it adds maintenance overhead you have to be honest about. But for systems where a missed attack path is a safety or certification problem, keeping the security analysis attached to the thing it protects is a better bet than hoping two documents stay in sync on their own.