Threat Modeling Guide

1. Introduction

The capabilities defined in W3C specifications are developed in the context of the W3C Ethical Web Principles [ethical-web-principles]: the Web should work for people, by supporting accessibility, internationalization, privacy, and security as part of platform design. Once defined, any capability can be used, misused, or abused, and it can also become part of an attack surface.

Threat modeling helps a Group build and record a useful model of that capability: what is being specified, who or what is involved, what can go wrong, what the specification does about it, and what assumptions or responsibilities remain elsewhere. The goal is not to produce an exhaustive list of every possible problem. The goal is to make the security, privacy, and socio-technical reasoning behind the specification visible while the design can still be changed.

The W3C Self-Review Questionnaire: Security and Privacy [SECURITY-PRIVACY-QUESTIONNAIRE] explains that specifications should include Security Considerations and Privacy Considerations sections so that implementers and web developers can understand the risks a capability may present and potential mitigations. A threat model is the analysis that helps those sections communicate more than conclusions: it records the model, the important threats, the selected responses, the relevant assumptions, and any remaining threats.

Some concerns are security threats, privacy threats, or socio-technical threats. Security threats concern security properties of the system under analysis. Privacy threats concern privacy properties and expectations. Socio-technical threats start from the system under analysis and reach users, non-users, or other affected stakeholders. In this Guide, harms are the adverse impacts that may result from those threats. These categories are prompts for analysis, not mutually exclusive classifications. A single issue may involve security threats, privacy threats, and socio-technical threats at the same time.

Because W3C specifications are implemented in different products and deployed in different environments, a threat model should make visible the assumptions and responsibilities that remain outside the specification itself. Some threats arise from implementation choices, deployment choices, ecosystem behavior, or dependencies on other technologies. A specification might not be able to address those threats directly, but it can identify them, explain the assumptions being made, and help implementers and reviewers understand which issues are addressed (mitigated, transferred, accepted), and what is left as remaining threats. Threat modeling helps tell that story.

This Guide is primarily for specification developers, Groups, chairs, and editors. It also helps implementers understand the threats and assumptions they need to account for, helps reviewers evaluate a specification with more context, and helps the wider community understand what was considered, what was addressed, and what remains out of scope.

In that sense, threat modeling helps a group answer a small set of questions adapted from Shostack’s Four Question Framework [SHOSTACK2014] and the Threat Modeling Manifesto for W3C specifications. The second question makes affected stakeholders explicit; the fifth keeps the analysis stage-appropriate:

1. What is being specified?

2. Who may use or be affected by it?

3. What can go wrong, and what harms may result?

4. How are those threats and resulting harms addressed, and where is the response documented?

5. Is the analysis good enough for the current stage of the specification?

A useful threat model usually records:

• the system under analysis, including relevant actors, components, flows, trust boundaries, and assumptions;

• the scope of the analysis, with rationale for anything explicitly deemed out of scope;

• relevant stakeholders, including people or groups who may be indirectly affected, and relevant assets where asset-based analysis helps;

• important threats and resulting harms, identified from use cases, user journeys, diagrams, or another documented analysis framework;

• the selected responses, including where each response appears in the specification or supporting document;

• responsibilities left to implementers, deployers, user agents, users, operating systems, regulators, or other parts of the ecosystem;

• relevant remaining threats, including the basis for any acceptance or transfer of responsibility.

A security threat model should inform the Security Considerations section of a specification. The same approach can also support Privacy Considerations, where a Group develops a privacy threat model or other privacy analysis. The analysis may be included directly in the specification, or published separately when it is large, or when several related specifications share common assumptions and threats.

One side benefit of the threat modeling approach is that it simplifies other types of review, notably the wide review (including horizontal review) that is core to the W3C Process. Reviewers need enough information to understand the system under analysis, the relevant threats, and how the specification responds to them, without having to reconstruct that reasoning from scratch. A threat model helps reviewers find the relevant threats, assumptions, responses, limitations, and remaining threats.

The goal of this Guide is to help W3C identify, capture, and communicate the security, privacy, and socio-technical threats associated with its technologies, and to develop reusable, shareable, and extensible threat models for specifications. Over time, these threat models can form a coherent set of related documents that help describe threats to the Web as deployed, making assumptions, responses, responsibilities, and remaining threats easier to understand across specifications.

Note: This Guide does not require a specific threat modeling framework; what matters is that the group can explain the system under analysis, the relevant threats, and the responses. Nevertheless, the framework and process used must be specified in the threat model. For example, a Group might specify whether it analyzed the system under analysis by component, by interaction, by threat category, using a particular framework, or through another documented process.

1.1. What a Threat Model Should Capture

A threat model for a specification should help readers understand the reasoning behind the specification. In practice, this means answering the five questions introduced above. These questions do not need to appear as separate sections in the final threat model. In practice, they are usually captured through three kinds of information: the system under analysis, the relevant threats, and the responses to those threats.

1.1.1. What is being specified?

For a W3C specification, the system under analysis is the relevant thing being specified: a capability, API, protocol, behavior, data flow, ecosystem interaction, or deployment pattern introduced, enabled, constrained, or assumed by the specification.

The description of what is being specified will usually include one or more diagrams or other visual representations, together with enough prose to explain the relevant actors, components, boundaries, data flows, and assumptions.

A threat model does not need to model every detail. It needs to describe enough of the system under analysis so that the relevant security and privacy reasoning can be followed. A diagram does not need to be complete to be useful: it needs to be useful for the analysis the group is trying to perform. It is also important to make clear what is in scope, what is out of scope, and why.

Note: A useful way to start is to draw the high-level flow first, and only then add trust boundaries. Trust boundaries help show where different actors, principals, privileges, or responsibilities meet. They are especially useful because threats often appear where something crosses those boundaries. If no boundary is visible, the group should ask whether everything in the model really has the same level of privilege, access, and responsibility, or whether the diagram is missing an element, a boundary, or both.

1.1.2. Who may use or be affected by it?

A threat model should make clear who may be affected by the capability being specified. This includes the obvious stakeholders, such as users, implementers, deployers, websites, and user agents. It may also include less visible stakeholders, including non-users or other parts of the Web ecosystem that are affected indirectly.

This question is important because not all relevant threats are only threats to technical components. Some threats affect confidentiality, integrity, availability, or accountability. Others affect people, groups, or institutions through misuse, abuse, harmful incentives, or unexpected ecosystem behavior.

In other words, the analysis should not only ask what can go wrong inside the system under analysis. It should also ask who pays the cost when something goes wrong.

Note: Other W3C work gives useful examples of how to think about stakeholders: the Web Content Accessibility Guidelines (WCAG) 2.2 specification [WCAG22] starts from the needs of people with disabilities, but also speaks to a wider ecosystem of designers, developers, policy makers, purchasing agents, teachers, and students; the W3C Internationalization Glossary [i18n-glossary] reminds us that people may be affected differently depending on language, region, or culture; the Web Sustainability Guidelines [web-sustainability-guidelines] include the wider frame of planet, people, and prosperity; and the Self-Review Questionnaire: Societal Impact [SOCIETAL-IMPACT-QUESTIONNAIRE] reminds us to consider broader consequences, diverse use cases, exclusion, power dynamics, surveillance, psychological well-being, and environmental impact.

1.1.3. What can go wrong, and what harms may result?

Where useful, a group should distinguish threats to the capability or system from threats that may occur through the capability or system. Security threats explain how security properties can be violated. Privacy threats explain how privacy properties or expectations can be violated. Socio-technical threats explain how a specified capability, implementation choice, deployment pattern, incentive, governance decision, or user interaction can create the conditions for adverse impacts on stakeholders. In this Guide, those adverse impacts are harms.

These categories are prompts for analysis. A single threat may involve security threats, privacy threats, and socio-technical threats at the same time. The point is not to classify perfectly, as they are not mutually exclusive classifications.

Some frameworks use "harm" broadly to describe both the adverse impact and the pathway that enables it [MICROSOFT-HARMS-MODELING] [SOLOVE-PRIVACY]. Shostack describes a related distinction between threats to the system and threats via the system [SHOSTACK-C2PA] [SHOSTACK2014]. This Guide separates those ideas: a harm is the adverse impact, while a socio-technical threat describes how the system under analysis, implementation choice, deployment pattern, incentive, governance decision, user interaction, or ecosystem behavior can create the conditions for that impact.

Threats and resulting harms often come from examining use cases and user journeys. Each step in the flow is an opportunity to ask what can go wrong, who may be affected, what harm may result, and which actor is responsible for preventing or responding to it. A specification may not be able to address all of these threats or harms directly. But even when the response is outside the specification, the threat model can still document the issue, the relevant assumptions, the expected responsibilities, and the remaining threat.

Assumptions should also be checked as potential sources of threats. If a threat model assumes that an implementation, deployment, user agent, relying party, regulator, or another part of the ecosystem behaves in a particular way, the group should ask what threat appears if that assumption is violated.

Note: One practical way to make this step systematic is to iterate through the relevant elements of the diagram. For each element, such as a process, a data flow, a data store, or a trust boundary, ask which property is expected to hold, what stakeholder interest is at stake, and what could threaten it. Identity can be spoofed, data can be modified, information can be disclosed, authority can be exceeded, a privacy expectation can be broken, or a capability can create conditions for adverse impacts on stakeholders. The table can then record the element, the property or stakeholder interest at stake, the threat, and the harm that may result.

This gives the group a concrete way to move from the diagram to the list of threats. As support, groups can also use lists or threat analysis frameworks.

1.1.4. How are those threats and resulting harms addressed, and where is the response documented?

A useful threat model connects important threats, resulting harms, and responses to the places where the specification addresses them. The documented outcome might be a normative requirement, a Security Considerations section, a Privacy Considerations section, an implementation note, an assumption, a transfer of responsibility, an acceptance rationale. Issues that are outside the current scope should be recorded as scoping decisions, not as responses.

When a threat is reduced rather than eliminated, or when responsibility is transferred outside the specification, relevant remaining threats should be documented. The mapping shows that the group not only identifies a threat, but also reasons about what to do with it. It also helps reviewers and implementers find the relevant text in the specification.

Note: When documenting how a threat is addressed, it is useful to record the exact place where the response appears in the specification. For example, if the threat is a network attacker modifying a request before it reaches the user agent, the response might be to expose the API only in a SecureContext. The threat model and Security Considerations section should therefore link that threat to the corresponding requirement in the specification, rather than only saying that the threat is “mitigated”.

1.1.5. Is the analysis good enough for the current stage of the specification?

A threat model does not need to be exhaustive to be useful. In practice, trying to enumerate every possible threat can make the analysis harder to write, review, and maintain. The goal is to capture enough of the important threats to explain the security and privacy reasoning that shaped the specification.

Diagram: This starts from the diagram. A useful diagram is detailed enough to let the group tell the story of the system under analysis, identify the relevant stakeholders, data flows, trust boundaries, and security or privacy decisions, and walk through the model to ask what can go wrong. If the group needs to explain important behavior that is not visible in the diagram, the diagram is probably missing something. If the group cannot traverse the diagram because it contains too much detail, the diagram is probably trying to do too much and should be split into a high-level diagram and focused sub-diagrams. The diagram should identify what is out of scope.

Threats: Groups should therefore focus on the main threats that affect the design: the threats that led to normative requirements, mitigations, Security Considerations or Privacy Considerations, implementation requirements, or assumptions. A manageable set of high-quality threats is more useful than a very large list of highly detailed threats that cannot be worked through or maintained. This does not mean that other threats are irrelevant. Rather, the threat model provides a framework for evaluation. It makes the Group’s reasoning visible, and gives reviewers a concrete basis for asking whether important threats are missing, whether responses are adequate, or whether additional text is needed in the specification.

Responses: Groups should map each threat to one or more documented outcomes: a normative requirement in the specification, a Security Considerations section, a Privacy Considerations section, an implementation requirement, an assumption, a transfer of responsibility, an acceptance rationale, or a documented remaining threat.

Note: A threat model can inform risk assessment and risk management, but it is not itself a risk-scoring exercise. The threat model first helps the Group understand what can go wrong and what responses are available, then the remaining threats can be used as an input for risk assessment or risk management, in particular using it in the Risk Identification phase. This can be useful when a threat creates a difficult trade-off, or cannot be handled through ordinary engineering changes. Groups should first identify the relevant threats and resulting harms, then decide how to address them and document them. Scoring is optional, and should be used only where it helps that decision [SHOSTACK-RISK-TM].

1.2. When to Threat Model

Threat modeling can be performed throughout the entire lifecycle of a specification, but the sooner you start, the better, because the sooner you understand what can go wrong, the more cost-effective it is to implement mitigations and make adjustments. Just like a specification, a threat model is an iterative, incremental process, and its maturity and level of detail are directly related to the specification.

Threat models should be developed collaboratively by the Group, with support from the W3C Team and horizontal groups, and iteratively at different times during the lifecycle of a Group and specification:

• Charter: Significant threats known at the time of chartering should be captured in the charter when they help clarify the scope of the work. For example, a group working on digital credentials may already know that tampering, spoofing, and information disclosure are important concerns, even before a complete threat model has been developed.

• Explainer: at this stage, use cases and user journeys are identified, so it is possible to understand which features or capabilities are being developed, what can go wrong at a high level, such as the potential for abuse, and which assumptions are being made.

• Working Draft and before Candidate Recommendation: at this stage, the threat model should be aligned with the specification, with the mapping between threats and responses to the text of the specification. A sufficiently complete version should be available for horizontal review.

Note: During horizontal review, the threat model is the artifact that helps reviewers answer the review version of the fourth threat modeling question: has the Group done a good enough job for this stage of the specification? Horizontal groups should not need to reconstruct the model from scratch. They should be able to read the threat model, understand what was considered, what was addressed, what assumptions remain, and then respond to the Group with any missing threats, unclear responsibilities, the need for more responses, or remaining threats that need to be documented or addressed.

• Recommendation and later updates: at this stage, the threat model should be kept updated. Implementation experience can signal new threats or evolution of existing threats.

Note: If the group begins working on the threat model at an advanced stage of the specification, it is advisable to start by reverse-engineering the security-related decisions contained in the specification itself.

1.3. Where to Publish the Threat Model

The threat model serves as the foundation for the Security Considerations section of a specification. If the threat model is small, it can be included directly in the Security Considerations section. Otherwise, it can be published separately, for example, as a Group Note, and referenced from the Security Considerations or Privacy Considerations section.

Even when the threat model is published separately, each specification should still include Security Considerations and Privacy Considerations sections that summarize the relevant threats, explain where the responses are documented, and link to the threat model.

When publishing externally groups are encouraged to list the threats by name and ID, without further description, as an index in the appropriate considerations section, making it easy for readers to see at a glance any threats they might care about.

When publishing separately, groups are encouraged to list the threats by name and identifier, without further description, as an index in the relevant considerations section. This makes it easier for readers to see at a glance which threats may matter to them, and where the full analysis can be found.

If a threat model covers a family of related specifications and becomes too broad, it can be split by specification or layer, provided that the related threat models and the relevant Security Considerations and Privacy Considerations sections are clearly cross-linked.

Note: From an open-standards perspective, the threat model should be developed and published openly unless there is a clear reason not to, as it is an important tool for both implementers and users.

1.4. Core Terminology

The following terms provide the core vocabulary needed to read this Guide. They are listed alphabetically for lookup. Longer discussion of analysis frameworks, modeling choices, and response strategies appears in the body of the Guide and in the appendices.

This Guide uses the terms below in a practical way. The intent is not to create a new taxonomy, or to replace existing security terminology. Where possible, the definitions are aligned with NIST risk assessment guidance [NIST-SP800-30R1]. Where the W3C context requires it, the terms are adapted to specifications, implementers, users, and the wider Web ecosystem.

analysis framework

A structured way to analyze a model, in particular to understand what can go wrong from a specific point of view.

asset

Something of value to one or more stakeholders. Assets may include data, credentials, keys, capabilities, services, infrastructure, availability, integrity, confidentiality, privacy, user agency, safety, reputation, or other properties that stakeholders value.

assumption

A condition believed to be true for the threat model to hold. Assumptions should be explicit, especially when responsibility is left to implementers, deployers, users, operating systems, browsers, infrastructure providers, or other parts of the ecosystem.

attack

The concrete way in which a threat is realized or attempted [NIST-SP800-30R1]. It describes how the threat can happen in practice, for example by exploiting a vulnerability, abusing a legitimate capability, or misusing intended functionality. In this Guide, “attack” is used in this practical sense, not only for intentional adversarial behavior.

authority

The entity that controls, operates, authorizes, or is responsible for a trust domain, element, data object, security decision, or capability.

data store

A data store is an element that retains information.

diagram / visual representation

A simplified visual model of the system under analysis, used to identify and discuss system elements, flows, boundaries, stakeholders, threats, and responses.

element

Any item represented in a threat model diagram or otherwise referenced by the threat model. Elements may include external entities, processes, flows, data stores, data objects, boundaries, trust domains, or containers.

flow / data flow

The path, mechanism, or interaction by which data moves between elements. A flow may be uni-directional or bi-directional, and may connect external entities, processes, data stores, data objects, or other elements.

harm

A negative or adverse impact generated by a threat.

impact

The consequence produced by a threat, risk, event, design choice, implementation choice, deployment condition, or use of the system under analysis. In this Guide, when considering threats, we focus on adverse, or negative, impacts [NIST-SP800-30R1].

out of scope

A documented scoping decision that an actor, component, data flow, dependency, deployment condition, use case, misuse case, scenario, threat, harm, or risk is outside the system, context, or stage of work being modeled. An out-of-scope decision is not a response strategy.

Privacy Considerations

The section, or related analysis, that documents privacy-relevant issues associated with a specification. In this Guide, the Privacy Considerations section may be informed by the same threat model, or by a related privacy analysis, and should describe relevant privacy threats, assumptions, impacts, harms, responses, and remaining threats [SECURITY-PRIVACY-QUESTIONNAIRE] [RFC6973].

privacy threat

A threat to a privacy property, privacy expectation, or privacy-relevant stakeholder interest.

process

In the context of a threat model diagram, an active element that receives, transforms, stores, sends, validates, authorizes, or otherwise acts on data.

remaining threat

A threat that remains possible after responses have been applied, after responsibility has been transferred, or after the Group has decided that no further response is appropriate within the current scope. A remaining threat should be documented when it is relevant to implementers, deployers, reviewers, users, or other stakeholders [NIST-SP800-30R1].

response

What the specification is expected to do about a threat, an impact, a harm, or a risk.

response strategy

A classification of responses to a threat, impact, harm, or risk. This Guide uses four common response strategies with the ERTA mnemonic: Eliminate, Reduce, Transfer, and Accept.

risk

Something uncertain that may happen and that, if it happens, has an impact. A threat model can use risk-based language, but it does not need to score every threat quantitatively [NIST-SP800-30R1] [PRINCE2-RISK].

scope

The part of the system, ecosystem, or specification behavior considered by the threat model. Scope should make clear what is included, what is excluded, and which assumptions are being made.

Security Considerations

The section of a specification that documents security-relevant issues that implementers, deployers, reviewers, and other stakeholders should consider. In this Guide, the Security Considerations section should be informed by the threat model, including the relevant threats, assumptions, responses, limitations, and remaining threats [SECURITY-PRIVACY-QUESTIONNAIRE] [RFC3552].

security threat

A threat to a security property of the system under analysis, or of the actors, data, processes, or flows represented in the threat model.

socio-technical threat

A threat that starts from the system under analysis and reaches stakeholders, including users, non-users, groups, communities, institutions, society, the Web ecosystem, or the environment.

stakeholder

A person, group, organization, implementer, deployer, user, user agent, service provider, reviewer, or other party that can affect or be affected by the system under analysis.

system under analysis

The specification feature, protocol, API, behavior, data flow, ecosystem interaction, or deployment pattern being analyzed.

threat

Something that may happen and that, if it happens, can produce an adverse impact. In this Guide, threats are the things that can go wrong for the system under analysis, its stakeholders, or the broader Web ecosystem [NIST-SP800-30R1].

threat model

The artifact produced by threat modeling. A threat model describes the system under analysis, scope, stakeholders, threats, assumptions, impacts, harms, and responses.

threat modeling

A structured and repeatable activity used to identify, discuss, and document what can go wrong in a system, and to support decisions about how to respond.

trust boundary

The place where different authorities, trust domains, privilege levels, operational responsibilities, or assumptions meet.

vulnerability

A security-relevant issue in a specification design, implementation, configuration, control, procedure, assumption, or dependency that can make a threat possible [NIST-SP800-30R1] [ONOFRI-ONOFRI2023].

2. How to Threat Model

This section is a work in progress.

1. Paint a picture

2. Capture threats

3. Describe responses

The simplest threat model involves three key components.

First, a picture of the system with relevant parts enumerated. This picture, typically an architecture diagram, defines the scope of concern for the threat model. If your concerns include hardware-level considerations, make sure your picture includes the components that are involved. Keep this picture as simple as possible to make it easy to absorb, but don’t leave out components that are related to major threats. In short, it’s the detail in the diagram that lets you discuss the appropriate level of threats. It’s here that threat analysts anchor the model to actual systems either already built or to be build.

Second, given the elements of the diagram, capture threats to the integrity of system operation. As specification developers, you are the closest to both the problems address and problem solved by the specification. Use your own expertise to establish a list of threats that captures the concerns that arise from building consensus for your specification.

Third, for each threat, document options for responding. These responses may be baked into the specification or they may need further work by implementers. Some responses will simply be to accept the threat. Acceptance lets people who share that concern understand that the specification was developed with full knowledge of this threat--and implementers should consider it--but believe a solution is either unknown or unreasonable at this layer in the system.

We dive into each of these later in this guide.

2.1. Threat modeling specifications

The point of threat modeling specifications is to help implementers understand the security trade-offs inherent in the technology, enabling them to make informed security decisions when implementing the specification.

Downstream, we anticipate that both implementers and security professionals will extend the threat models created by working groups with their own evaluations based on implementation decisions. Such implementation-specific threat models are not expected to be standardized and may be published or not. However, they provide implementers with a coherent way to evaluate the security trade-offs of their applications when integrating the specified technologies.

2.2. Threat Modeling Process

1. Model the system

2. Identify & Evaluate Stakeholders

3. Identity & Evaluate Threats

4. Consider Responses

5. Publish for consideration

6. Iterate

2.2.1. Model the system

The first step in creating a threat model is asking the question "What are we working on?". Defining the primary use cases and create a diagram that illustrates the system realizing that use case—an "abstract representation of some process" [ONEIL2016]—and diagrams as graphical representations of the model [HOWARD-LIPNER2006] (p. 110).

Creating good diagrams is fundamental, as they are the heart of a good threat model [OSTERMAN2006]. Diagrams should list and describe the various elements that make up the system [OSTERMAN2007]. For computer systems, multiple diagrams are often used: a high-level diagram followed by a series of detailed diagrams that detail the various elements [HOWARD-LIPNER2006] (p. 112).

Include the computational and network contexts that matter to the threat analysis. Ultimately, information systems are realized by software running on hardware, communicating with other systems over networks and with users through interfaces. The model of the system should describe a typical deployment, showing how the specification fits into real-world systems. These system boundaries illustrate flows and elements from which threats might arise.

This is similar to geographical maps. Not only can it be useful to have various levels of zoom, it can be useful to have different information (e.g., satellite images, street map, topographic map) presented in different maps of the same. region. The principle that "the map is not the territory" [KORZYBSKI1933] also applies here [ONOFRI2024-INCLUSION]. We use the diagram, like a map, to understand the system with awareness that the diagram is not the system as it gets deployed. It is a simplification to present specific information about the system Another well-known aphorism, "all models are wrong, some models are useful" [BOX1976], is also used in modeling [FENSTERMACHER2004] to help modelers manage scope by selecting those elements that are most useful rather than chasing perfect correctness. The diagram can never perfectly represent every element of the system; use it to represent the elements of the system that illustrate the most salient security concerns.

Any visualization that clearly distinguishes the relevant elements of the specified system is acceptable.

However, all visual imagery needs to follow accessibility guidance, such as W3C Accessibility Guidelines (WCAG) 3.0, for example:

• use shapes rather than colors or shading to distinguish different types of elements, and

• make sure that sufficient context is provided for alternate renderings, e.g., by a screen reader, using ALT tags and ARIA properties.

This guide also recommends that

• diagrams enumerate all components with unique short IDs and names,

• diagrams are accompanied by a prose description of the architecture describing a common use case to give context and explanation for the diagram, and

• diagrams are accompanied by dictionaries that enumerate and describe the elements in the diagrams. These dictionaries also serve as references in subsequent discussions of threats and responses.

We provide an example in the Appendix 1: Minimalist Threat Model for the World Wide Web.

2.2.2. Identify and Describe the Stakeholders

When modeling the system, it is vital to include all affected stakeholders to answer the question "Who is affected?" or, equivalently, "Who is impacted?" Focus on identifying and analyzing the people, groups, and entities that interact with or are affected by the system modeled in the first step. This work aims to shift the paradigm from viewing the user as an asset to be protected to the "weakest link" of the security chain [SCHNEIER2015] (preface section). Systems that represent only technical components often miss critical threats related to human error and malfeasance. By including both human and legal persons in your threat model, you increase the likelihood of including threats related to both.

In addition to listing the human and legal persons involved in a system, describe each to illustrate how identified threats impact their use of the technology. Specifically, identify the primary goals for each stakeholder to illustrate their primary motivations for building and/or using the technology.

This step is inspired by the harms modeling process described in Microsoft [MICROSOFT-HARMS-MODELING] and is useful for integrating threat modeling with harms modeling.

Identifying stakeholders is particularly useful when analyzing high-level models and technologies that can have a societal impact. A thorough understanding of stakeholders ensures that the resulting systems are not only secure but also trustworthy, recognizing and respecting human rights as a fundamental design principle.

This includes understanding who the stakeholders are, what they value, how they might benefit from the technology, and how they could be harmed by it. Stakeholders typically include, but are not limited to:

• Customers: direct users or adopters of the technology.

• Non-customers: individuals, groups, or organisations indirectly affected by the technology’s operation or deployment.

• Developers and operators: those who design, implement, or maintain the system.

• Regulators and policymakers: entities establishing or enforcing rules that affect the system’s design and usage.

• Society at large: communities, environments, and ecosystems influenced by the system’s broader externalities.

To guide the analysis, a useful review asks the following questions for each stakeholder category:

1. Who are the end users for your technology?

   1. What components do they interact with?

   2. How should they benefit from your technology?

   3. How could your technology harm them?

2. Who are the non-user stakeholders?

   1. What components do they interact with?

   2. How should they benefit from your technology?

   3. How could your technology harm them?

Asking these questions provides a deeper understanding of what matters to stakeholders and how these values influence their relationship with the product or system. This understanding forms the basis for identifying not only technical threats but also social and cognitive harms, ensuring that threat modeling extends beyond the system’s components to include its human and societal dimensions.

2.2.3. Identify & Evaluate Threats

The second step in creating a threat model asks the question, "What can go wrong?" where threats are identified and assessed [SWIDERSKI-SNYDER2004] (p. 111). Threats can be identified in different ways, such as experimentally, by analyzing the chain of events leading up to an attack—i.e., a kill chain —or by using a list of threats [SHOSTACK2014] (pp. 9, 385, 388) [PENNEY2023]

Threat lists, like other types of lists used in threat modeling, are particularly useful for identifying issues on a diagram. This operation can be performed: "per element" of the diagram, where the analysis starts with the first element and evaluates all threats [OSTERMAN2007A]; "per interaction", where the analysis is focusing on the data flow of the diagram, focusing on the interactions between elements [FFRI2016] (slide 4-5), "per threat", taking one threat at a time and figuring out which element it applies [DISTRINET2024].

Depending on the model, a group may also distinguish target threats, implementation threats, deployment threats, external threats, and dependency threats. These labels help explain where a threat arises; they do not replace the analysis of what can go wrong.

We recommend indexing numbered threats in a short form list as a table of contents, with threat details provided in separate tables. You can see this approach in Appendix 1: Minimalist Threat Model for the World Wide Web.

In particular, we recommend against presenting threat lists as large two-dimensional spreadsheets, as this format is often hard to reason over. See the section on curatorial storytelling for additional presentation suggestions.

However, threat modelers are free to use any representation that presents the threats effectively.

2.2.4. Consider Responses

The next step in creating a threat model is to ask the question, "What are we going to do about it?". That is, how are we going to respond to the threats [HOWARD-LEBLANC2002] (p. 106).

In the literature, there are several categories of responses, some specific to threat modeling and others derived from risk management, aimed at reducing or eliminating the threat or its impact [HOWARD-LIPNER2006] (p. 124). For this Guide, those responses are summarized using the ERTA mnemonic: Eliminate, Reduce, Transfer, and Accept. See Appendix 3: ERTA Threat Response Framework for more detail.

2.2.5. Publish for consideration

Next, we ask "Did we do a good job?" by publishing the threat model for feedback. Threat models, by their nature, are living documents that require continuous updates [SWIDERSKI-SNYDER2004] (p. 26). Attacks continuously evolve, with new attacks emerging as technology, law, and social expectations change. Publication is vital to give others the opportunity to review and give feedback throughout the lifecycle of the specification and its use.

Some stakeholders worry that publishing a comprehensive set of threats does more to teach our adversaries than it does to protect the system. However, the chance of attackers reading your documentation and changing their behavior is modest at best. "Attackers simply ignore your threat model" [ONOFRI2024-INCLUSION].

In contrast, by socializing a public discussion of the threats inherent in the specifications, there is an opportunity to improve the security of the entire Web, as different components better integrate and support the concerns from other dependent elements to minimize threats.

This step serves as a reminder to pause, publish for others, evaluate the completed work, and determine what still needs to be done. For example, performing formal verification, additional cryptographic checks, and so on.

This consideration is useful throughout the lifecycle of the specification. The earlier you publish, the earlier you can get feedback about how the model works. It continues after "finishing" the specification, e.g., the publication of a W3C Recommendation, as real-world adoption and use teaches us about additional or more nuanced threats.

2.2.6. Iterate

Once you have a published version of the threat model, engage stakeholders and update the model. The specificity and curation of the most relevant threats will be improved by more parties contributing constructively. Through your working group and horizontal review, invite input and feedback, and integrate that feedback into a better threat model. Bring in external perspectives from expected users of the technology, including both end users and service providers.

The best threat models evolve over time as the threat landscape and our understanding of threats change. We learn new details about potential threats, and new threats emerge constantly.

When possible, update the threat model as the specification evolves, including after publication as recommendation. When revising a specification, whether in a minor editorial change or a major breaking change, consider updating the threat model to reflect new understandings.

3. Curatorial Storytelling

A good threat model tells a good story.

That’s the priority.

The most important factor in the success of threat models is whether or not implementers actually read, understand, and apply them in their implementations. The principles of good storytelling can help.

It’s vital that developers can quickly read and understand the threats they should consider when making engineering decisions. A threat model that is too verbose risks overwhelming readers before they capture the value of the model. Huge tables of hundreds of threats are simply hard to absorb. Instead, carefully chosen and well-ordered threats lead readers through a gradual introduction to the threats they should care about most.

Modelers should focus on the most relevant threats in their work, and order them by priority to enable readers to see the big picture even if they do not have the time and inclination to read the entire document in detail. Pick the most salient threats and present them in an order that makes sense to new readers.

This principle also applies to the diagrams that ground the threat modeling. Identify just those elements that matter to your particular threat model. This requires having an intention about the general scope of the system to be considered. Your diagrams define and illustrate that scope.

For example, web browser devices, like a smart phone, contain dozens of different chips. Modeling the threats of a proposed CSS standard is unlikely to benefit from highlighting the fact that any one of those chips could be compromised in some way at the factory. Developers concerned about hardware security would be better served by creating a dedicated threat model that focuses on how the hardware might be compromised.

Choose the elements that best represent the threats you care about. Ignore the rest.

Focus on threats that either have known responses or are deemed acceptable because it is understood there are no clear alternatives. Abstract threats and "areas of concern" must be further distilled into actionable threats. A threat without a response is not actionable.

Focus on threats that either have known responses or for which a response should be determined. Explicitly accept those threats that are out of scope, to communicate with implementers in case they have an opportunity to address it in their implementation even while the specification does not. Abstract threats and "areas of concern" are best addressed through further distillation into actionable threats for which a concrete response can be discussed.

Readers of threat models seek a coherent presentation of the threats and responses they should consider when implementing the modeled specification. As such, threat models are not exhaustive lists of everything that might go wrong in a system. They are tightly curated sets of threats and responses that illustrate the specification developers' best thinking about threats at the time the specification was written. Any reader of a threat model should walk away with a clear understanding of the real threats people and organizations might face during deployment, along with guidance on how to address them.

As a storytelling exercise, threat modellers should present the most salient threats clearly and compellingly, avoiding overwhelming the reader with extraneous details.

4. How to Write the Security Considerations Section

This section is incomplete.

The Security Considerations section should explain the security issues that implementers should consider when developing and deploying the specification.

This guide recommends that Security Considerations include a well structured and coherent threat model as described in this Guide. Specification developers may also include additional sections that explore related security issues. In some cases, a threat model, included directly in the specification, may be sufficient. In others, it may be more appropriate to publish a detailed threat model as a separate W3C Note, with the Security Considerations briefly summarizing and referring to that Note.

While it is not reasonable to expect that a standard be immune to all threats and attacks, it is invaluable for specification developers to consider as many legitimate threats as possible. One purpose of the Security Considerations section is to explain which attacks are known to be of concern and what countermeasures have been, or can be, applied to defend against them.

Appendix 1: Minimalist Threat Model for the World Wide Web

The World Wide Web ("the Web") is built on many different technologies, many of which are independently developed and maintained. This makes threat modeling for the Web a complex challenge (See The Web is Unversioned).

For this threat model, we think about the World Wide Web as just nine independent components: three human (user, website admin, and network operator), three in software (a browser, a DNS server, and a web server), and three legal persons (Website Application Providers, Internet Service Providers, and Public Sector Officials). This is an intentionally simplified view of the web so that we can focus on the threats inherent in a minimal instantiation of an TLS-secured World Wide Web as an illustration of how to threat model. It is our hope that this work catalyzes a broader, more extensive threat modeling effort that eventually can be used in earnest to improve the security of the web.

A1.1 Visual Language

We use an intentionally simplified Data Flow Diagram (DFD) inspired by Adam Shostack [SHOSTACK2014], which uses just six elements for clarity: external entities, processes, flows, data storage, data objects, and threat containers (which define threat boundaries). Shostack’s model did not include data objects, but with the rise of digital credentials, system designers now have means for security individual data objects, making them first class citizens that can travel across threat boundaries while retaining integrity.

External Entity (E)	An autonomous entity, external to the application, that interacts with, or drives, processes. Preferably a human user or legal person responsible for driving an interaction. Include all stakeholders, including the primary user as well as others who have designed roles in the system. Do not include attackers as they are treated as independent factors, exogenous to the model. In particular, be careful about over-characterizing attackers as it is impossible to cover all possible attacks and attackers. Assumptions about the limits of attacks and attackers can leave you open to unforeseen vulnerabilities. In contrast, we can completely characterize the system under attack in a visual diagram, no matter the nature or intention of any attacker.
Process (P)	A process within the system (e.g., feature in a component, component in an application, application in an operating system, operating system in a virtual machine).
Flow (F)	The mechanism by which data flows between elements. May be uni- or bi-directional. Data can flow between an external entity and a process, between one process and another, or between a process and a data store.
Data Store (S)	A medium for retaining information. This may be generic (e.g., local filesystem) or specific (e.g., configuration table in a database). It might be ephemeral, like a cache, or more permanent, like an archive.
Data Object (O)	A self-contained data object shared over data flow or stored in a data store. Transferrable between elements without losing integrity. Often secured by cryptographic signature.
Threat Boundary (B)	A boundary separating trust domains, where each trust domain is controlled by a single authority. When a threat boundary defines a closed loop, it defines a threat container.
Threat Container (C)	A collection of elements secured by a common authority. Elements within a container are taken to be operating within a threat boundary. Communications into or out of a threat container are recognized as crossing a threat boundary.

A1.2 Data Flow Diagram for Minimalist Web Threat Model

A1.3 Data Flow Description

For this diagram, consider the simplest realization of the world wide web including DNS and TLS.

In the intended use, a user (E1) interacts (F1) with a browser process (P1), which operates in its own container, the web browser (C1). This interaction directs the browser to display a specific URL as selected by the user. The browser process (P1) starts by resolving the domain name of that URL by requesting DNS resolution (F2) from a DNS resolver (P2), which returns an IP address for HTTPS requests to that domain. This information is tracked as session data (F3) and stored in browser data storage (S1). Then, the browser sends HTTPS requests (F4) to a server process (P3), which is running in its own container, the web server (C3). These requests (F4) are encrypted using TLS protocols. In response to requests (F4), the web server returns an TLS certificate (O1) and the resource requested, using its own server data storage (S2) to generate an appropriate response.

Supporting this operation are the Website Administrator (E2) and the (E3) Network Administrator, who keep the network-available services running.

Additional stakeholders include the legal entities running websites (E4 Website Application Providers) as well as those legal persons running Internet infrastructure (E5 Internet Service Providers). Finally, public servants of various kinds have both legitimate interests in making sure everything is running according to the law and public policy (E6 Public Sector Officials).

Note: We do NOT model potential attackers, as over-characterizing attackers can lead to analysis bias that is better avoided.

It is understood that the browser process (P1) is likely realized as multiple processes running as software in an operating system on a device. Threat modeling for such details would suggest breaking both the process and its container (C1) into its subcontainers and processes, identifying the flows between each. However, in this threat model, we treat the web browser as just two elements, the browser process and its data storage.

Similarly, the web server (C3) is often realized not only as multiple processes, but often with data flows that communicate with multiple back-end systems in response to user requests. However, it is possible to realize the web server as a single process in a single container with its own local storage, which contains its TLS certificate. For our analysis, we choose this minimalist realization.

The DNS resolver also depends on external data flows that are beyond the scope of this threat model.

We treat the DNS Server and the Web Server as essentially black box elements which provide information in response to requests, but whose internals are intentionally outside the threat model. We are not evaluating the threats of the DNS system. Nor are we evaluating the threats of any particular back-end system or web server. These are external systems which may be worth noting as sources of threats, but whose definitions are beyond this scope.

A1.4 Data Flow Dictionary

From this diagram and its dictionary, we can begin to model relevant threats.

A1.5 Stakeholders

A1.5.1 E1 User

The user of the Web. Designed for human users, this role can also be realized by automated software, including scripts and AI. However, we consider the user as a black box without regard to the type of user or the subprocesses and data that might be used internally. Users control a user-agent, aka a browser, for interacting with the World Wide Web.

Users include just about any human on the planet using web technology to realize their own goals. This includes your healthy, wealthy consumer with the latest technology as well as members of vulnerable populations in challenging situations where accessibility and connecting might be a challenge.

These users' shared goal is reliable access to web-based services. Those services should operate as intended and the information they receive through their browser should be as the website provider intended.

A1.5.2 E2 Website Administrator

The administrator of the website. Their goal is to keep the website running as intended by the website owner. It may be presumed that they have complete access to everything on the server and can monitor or manipulate all communications into and out of the website.

The goal of website administrators is for their website to deliver authentic services over the network without interference such that interactions with end-users are faithfully engaged in both directions, from the browser through the network to the server and back. They want confidence that the end-user is experiencing the application that they developed without interference during communication. Finally, they want the input from users to be unadulterated and timely.

This includes all parties with authority to affect the website, including developers and customer support.

A1.5.3 E3 Network Administrator

Any number of network administrators who keep the network running, including maintaining an operational DNS system. In practice, this party also has the ability to watch and manipulate activity on its services.

These individuals work for Internet Service Providers and enterprise network operations. They keep the network running. That includes defending the network against any attackers, including denial of service and person-in-the-middle attacks. As the guardian of the network, these individuals often need to view data that could be used maliciously by malicious parties.

The goal of network administrators is visibility and control over the parts of the network they control, and reliability and integrity for the parts of the network they don’t.

A1.5.4 E4 Website Application Providers

Web application providers fund and maintain websites that provide services to end-users. These include for-profit organizations, whose offering necessarily supports their money-making agenda, as well as mission-driven public-sector and non-profit organizations for whom the website may serve a social benefit other than profit generation.

The goal of website application providers is to be reliably available to their constituents and to realize their intended functional goals, such as selling products or managing conversations. Focused on just their own applications, these providers rely on the Web as a medium for interacting with their customers and stakeholders.

A1.5.5 E5 Internet Service Provider

Internet Service Providers (ISPs) deliver infrastructure services such as connectivity, hosting, and specific network components such as DNS hosting and registration, email services, as well as dynamic DNS and TLS certificates.

These parties need the network to keep running, resilient to attacks that would disrupt operations. While they are often considered “utility” providers whose offerings are best appreciated when they are most invisible.

The goal of Internet service providers is for users on both ends of the network (end-users and services) to be able to reach the other end, as designed and implemented by application providers. Hosting providers want their clients' websites to stay up and be available in a reliable way; connectivity providers want their clients to have reliable, uninterrupted, and unfettered access to the services (or users) they want to reach online.

A1.5.6 E6 Public Sector Officials

Public sector officials include law enforcement, elected officials, and regulators seeking to oversee public interests in our digital communities.

Unfortunately, the Web doesn’t have specific oversight roles for public sector officers. The protocols and specifications of the World Wide Web do not specifically give capabilities to different parties based on their status or role in society. Nevertheless, these entities have jobs to do, whether it is enforcing privacy regulations or investigating a murder.

While too much public oversight can constitute undesirable surveillance and abuse of power, specification developers and implementers should consider threats posed both *by* public sector entities and *to* public sector interests. For example, subpoenas and other legal mechanisms can force website providers to reveal information otherwise secured by technical means. In some use cases, this may be important for security and privacy considerations.

The goal of public sector officials is to ensure that rules and regulations are being followed in their jurisdiction so that legitimate services can be securely accessed by appropriate persons wherever and whenever that might be. This includes preventing fraud, illicit sales, and privacy harms.

A1.6 Threats

The following sections describe the identified threats and potential responses to them.

Threat Index

1. Target Threats
1. Imposter Websites (URL validation)
2. Network Surveillance (DH, Encryption)
3. Network Corruption (MAC signature)
4. Fraudulent Certificate (Signed Certificates)
5. Implementation Threats
5. Key Compromise
6. Library Compromise
7. External Threats
7. Quantum Cryptography Attacks
8. Harvest Attacks
9. Flawed Cryptosuite
10. Dependency Threats
10. The Internet protocol suite (TCP/IP)

A1.6.1 Target Threats

The TLS addition to the Web specifically addressed a handful of known problems.

1. Imposter Websites (URL validation)
2. Network Surveillance (DH, Encryption)
3. Network Corruption (MAC signature)
4. Fraudulent Certificate (Signed Certificates)

A1.6.2 Implementation Threats

5. Key Compromise
6. Library Compromise

A1.6.3 External Threats

7. Quantum Cryptography Attacks
8. Harvest Attacks
9. Flawed Cryptosuite

A1.6.4 Dependency Threats

Appendix 2: Analyzing Threats and Harms

Every threat is a result of thinking about the system in a particular way. Several different analytical frameworks have been developed to help think about software and software systems in terms of harms, threats, and risks. Each framework inevitably defines its own terms, which together provide a coherent way to think about threats, but which might introduce term confusion. For example, "repudiation" means different things in the STRIDE framework than in LINDDUN. To understand the vocabulary, it is helpful to anchor it to a particular framework.

At W3C, we consider all variations of "threats" to be suitable for inclusion in a threat model, even if the source framework calls threats by a different name, with different nuance. This opens the aperture for threat modeling to any domain of concern the work group wants to consider. In fact, working groups should use whatever analytic frameworks most coherently describe the threats they are most concerned about.

Security, privacy, and socio-technical categories are prompts for analysis, not mutually exclusive classifications. A single issue can involve more than one category, and a group can apply more than one framework to the same diagram element, flow, trust boundary, use case, or stakeholder.

Applying frameworks to model elements

Threat modeling starts from the model of the system under analysis. Frameworks are useful when they help a group ask concrete questions about that model. A group can apply a framework to a process, flow, data store, data object, trust boundary, use case, stakeholder, or deployment assumption.

Use the framework to ask what can go wrong, identify the affected property or stakeholder interest, and document the response or remaining threat.

Threat sources, actors, and threat kinds

Some analysis distinguishes threat sources, threat actors, and adversaries. This is useful when the distinction affects the model or the response.

A threat source is a person, group, organization, condition, circumstance, failure, dependency, or event that can cause, enable, or contribute to an attack, and therefore to the realization of a threat. A threat source may be adversarial, accidental, structural, environmental, organizational, or external to the system under analysis [NIST-SP800-30R1].

A threat actor is a threat source that is a person, group, or organization. A threat actor may be malicious, negligent, coerced, misinformed, or operating under incentives that conflict with the interests of other stakeholders [NIST-SP800-30R1].

An adversary is a threat actor that intentionally attempts to cause, exploit, or benefit from an attack. This Guide uses "adversary" only when intentional adversarial behavior is relevant.

Threats can also be described by where they arise:

• A target threat is a threat to the specific behavior, feature, API, protocol, or capability that the specification is designed to address.

• An implementation threat is a threat that arises from how the specification may be implemented, even if the specification text is correct.

• A deployment threat is a threat that arises from how an implementation is configured, operated, integrated, monitored, updated, or governed in a real deployment.

• An external threat is a threat that arises from actors, systems, incentives, legal obligations, operational practices, or ecosystem behavior outside the specification, but that remains relevant to understanding the consequences of the specification.

• A dependency threat is a threat that arises from reliance on another technology, service, component, standard, policy, or operational assumption.

Data stores and data objects

A data object and a data store are related. A data object is a self-contained unit of data that can move through a flow, be retained in a data store, or be acted on by a process. For threat analysis, a data object in transit can often be analyzed like a flow. A data object at rest can often be analyzed like a data store. If a data object carries evidence, logs, credentials, proofs, signatures, or other security-relevant state, then spoofing, tampering, repudiation, information disclosure, denial of service, and expansion of authority may be relevant, depending on the context in which the object is used.

Authority and trust boundaries

Authority is important because threats often appear where one actor, component, or process can cause effects across a boundary. On the Web, authority is often related to origins and origin-based security boundaries. For example, Same Origin Policy and CORS use origins to decide when one resource may read from, send to, or otherwise interact with another resource [RFC6454] [FETCH] [CORS-FOR-DEVELOPERS].

In this Guide, authority is used in the security sense, not merely as the syntactic URL authority component. A useful trust boundary identifies a change in control, privilege, operational responsibility, or assumption that matters to the analysis.

A trust domain is a set of elements that share a common authority, privilege model, operational responsibility, or set of security assumptions. A threat boundary is treated as closely related to a trust boundary. A threat container is a collection of elements treated as being within the same boundary because they are secured, controlled, operated, or trusted under a common authority or set of assumptions.

Diagrams may use trust boundaries, threat boundaries, or threat containers, depending on the notation. The useful distinction is whether the boundary marks a change in authority, privilege, responsibility, or assumption.

Security analysis frameworks

Security analysis frameworks help groups ask how security properties can be violated in the system under analysis.

STRIDE

STRIDE is a security threat analysis framework that helps groups ask what can go wrong for each relevant element, flow, data store, or trust boundary in the threat model [SHOSTACK2014].

The STRIDE prompts are:

• Spoofing, which threatens identity or authenticity;

• Tampering, which threatens integrity;

• Repudiation, which threatens accountability;

• Information Disclosure, which threatens confidentiality;

• Denial of Service, which threatens availability; and

• Elevation of Privilege, which threatens authorization.

"Elevation of Privilege" has also been refined as Expansion of Authority, to better explain that the concern is authorization and privilege separation [SHOSTACK2023-THREATS]. This Guide uses Expansion of Authority where that wording is clearer for W3C specifications, because it asks what an actor, component, or program is allowed to cause or do.

STRIDE is a set of prompts, not a completeness guarantee. Groups should use it to find concrete threats tied to the model, and should not force privacy or socio-technical concerns into security wording when another framework describes the issue more clearly.

RFC 3552

RFC 3552 provides guidance for writing security considerations in Internet protocol specifications [RFC3552]. It is useful when a group needs to describe attacks, security assumptions, and security properties in a way that is familiar to reviewers and implementers.

OSSTMM

OSSTMM can help groups reason about security, privacy, and trust controls where operational or testing-oriented analysis is useful [OSSTMM3].

Privacy analysis frameworks

Privacy analysis frameworks help groups ask how a specification can affect privacy properties, expectations, or stakeholder interests.

LINDDUN

LINDDUN is a privacy threat modeling framework. It considers linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, and non-compliance [LINDDUN]. These prompts are useful when a capability processes, exposes, correlates, observes, or changes expectations around personal data or privacy-relevant behavior.

RFC 6973

RFC 6973 provides privacy considerations for Internet protocols [RFC6973]. It is useful when groups need to describe privacy properties, privacy threats, and privacy-relevant mitigations in a specification-oriented way.

Privacy analysis can also be informed by broader privacy principles when a group needs to describe expectations, stakeholder interests, or privacy properties that are not captured by a narrower security framing [PRIVACY-PRINCIPLES].

W3C Self-Review Questionnaire: Security and Privacy

The W3C Self-Review Questionnaire: Security and Privacy helps groups ask review-oriented questions about security and privacy issues in Web specifications [SECURITY-PRIVACY-QUESTIONNAIRE]. It can be used as an input to the threat model and to the Security Considerations and Privacy Considerations sections.

Socio-technical threats and harms analysis frameworks

Socio-technical threats and harms analysis frameworks help groups ask how a specified capability, implementation choice, deployment pattern, incentive, governance decision, user interaction, or ecosystem behavior can create conditions that lead to harm.

A harm is different from a threat. A harm describes the adverse impact. A socio-technical threat describes the pathway through which the system, implementation choice, deployment pattern, incentive, governance decision, user interaction, or ecosystem behavior can create conditions for adverse impact.

Web specifications often allow extensibility, optionality, and implementation choice. Those choices can affect security, privacy, or socio-technical outcomes even when an implementation conforms to the specification. When specification developers know about implementation-specific details that may create relevant challenges, the threat model should capture them as implementation threats, assumptions, transfers of responsibility, or remaining threats, as appropriate.

Identifying socio-technical threats from harms

A group can start from a possible adverse impact and work backward to the threat. The question is what harm could occur, and what path from the system under analysis could create, enable, or amplify it.

A practical order is:

1. identify the stakeholder, group, institution, ecosystem property, or environmental interest that could be affected;

2. describe the possible harm;

3. identify the system behavior, capability, deployment pattern, incentive, governance decision, user interaction, or assumption that could create the condition for that harm;

4. connect that pathway to a diagram element, flow, trust boundary, use case, stakeholder relationship, or responsibility boundary where possible; and

5. write the socio-technical threat as the pathway from the system to the harm, then record the response, transfer, acceptance, or remaining threat.

Starting from a harm does not make the harm itself a threat. For example, exclusion from a service is a harm. A socio-technical threat explains how a specified capability, implementation choice, deployment choice, or ecosystem practice can create the conditions for that exclusion.

Use harms modeling, RFC 9620, and the W3C Self-Review Questionnaire: Societal Impact to identify relevant harms. Then map backward from those harms to the threat pathways that may create, enable, or amplify them.

Harms modeling

Harms modeling helps groups reason from system behavior to adverse impacts on people, groups, institutions, the Web ecosystem, or the environment [MICROSOFT-HARMS-MODELING].

Relevant concerns can include surveillance, exclusion, minority-group impacts, power imbalances, centralization, psychological well-being, loss of meaningful user control, discrimination, environmental impact, denial of consequential services, and erosion of social or democratic structures [SOCIETAL-IMPACT-QUESTIONNAIRE] [RFC9620] [MICROSOFT-HARMS-MODELING].

RFC 9620

RFC 9620 provides guidance on human rights protocol considerations [RFC9620]. It is useful when protocol or specification choices may affect rights, participation, exclusion, surveillance, or power imbalances.

W3C Self-Review Questionnaire: Societal Impact

The W3C Self-Review Questionnaire: Societal Impact helps groups consider broader consequences, diverse use cases, exclusion, power dynamics, surveillance, psychological well-being, environmental impact, and related concerns [SOCIETAL-IMPACT-QUESTIONNAIRE].

Appendix 3: ERTA Threat Response Framework

After identifying threats and possible harms, groups need to decide what to do about them. Response frameworks help make those decisions explicit and reviewable.

Mnemonic

For this Guide, threat responses are summarized with the ERTA mnemonic:

• Eliminate the threat or the condition that enables it.

• Reduce the threat by applying control, mitigation, or other design changes that lower likelihood, impact, exploitability, or exposure.

• Transfer responsibility to another actor, layer, dependency, deployment context, or the user.

• Accept the threat and document why no further response is appropriate within the current scope.

A control is a safeguard, requirement, mechanism, process, or practice that modifies risk by preventing, detecting, limiting, or recovering from an attack or its adverse consequences [NIST-SP800-30R1]. A mitigation is a response that reduces the likelihood or impact of a threat, risk, or harm.

These four map directly to the four risk responses embraced by the Project Management Institute’s Guide to the Project Management Body of Knowledge: avoid, mitigate, transfer, and accept. This Guide uses "Reduce" instead of "Mitigate" because risk responses are often called mitigations in common conversation, even when risk professionals use the term more narrowly.

Sometimes professionals use these terms with subtly different meanings. For example, Shostack [SHOSTACK2014] uses "mitigations" to discuss any response to a threat, while the PMI defines "mitigations" as one particular form of response. The ERTA set of threat responses avoids this problem. As this Guide uses both "threats" and "risks", it recommends ERTA for documenting threat responses.

When a threat is transferred, the threat model should say who is expected to handle it and what assumption makes that transfer reasonable. When a threat is reduced, the threat is not eliminated; any remaining threat should be documented and either accepted, transferred, or addressed by further work. When responsibility is transferred to the user, the relevant usability and accessibility safeguards should be considered.

Scoping decisions are not responses

An out of scope issue helps define what the current threat model is about. It does not, by itself, address a threat.

If an out-of-scope issue remains relevant to implementers, deployers, users, reviewers, or other stakeholders, the threat model should record the boundary being drawn and, where known, identify where the issue is expected to be analyzed or addressed. The issue may still be a remaining threat, or the specification may explicitly transfer or accept it.

Relationship between Threat Modeling and Risk Assessment

A threat model can inform risk assessment and risk management, but it is not itself a risk-scoring exercise. Risk language can be useful when a threat creates a difficult trade-off, or cannot be handled through ordinary engineering changes. Groups should first identify the relevant threats and resulting harms, then decide how to address them and document the response. Scoring is optional, and should be used only where it helps that decision [SHOSTACK-RISK-TM].

Appendix 4: Related Publications

• Threat Model for the Web

• Self-Review Questionnaire: Security and Privacy

• Fingerprinting Guidance

• Security Guidance on Cryptography

• File Format Threats Mnemonics