Category: Vulnerability and Software Security

Threat Modeling

Also known as: threat model

Simply put

Threat modeling is a structured way to think through what could go wrong in a system before attackers find out for you. Teams identify potential threats and weaknesses, then decide what protections to put in place to reduce or mitigate the risks. It is intended to help prioritize security work, not to guarantee that every threat is eliminated.

Formal definition

Threat modeling is a form of risk assessment that systematically models the attack and defense aspects of a logical entity, such as a piece of data, an application, a host, or a system. It comprises a family of activities that identify and prioritize potential threats and structural vulnerabilities, including the absence of appropriate safeguards, and then define countermeasures intended to prevent or mitigate their effects. As a process it typically pairs threat and vulnerability identification with risk assessment and recommended corrective actions; its effectiveness depends on scope, the accuracy of the model, and the assumptions made, and it does not by itself validate implemented controls.

Why it matters

In payment environments, weaknesses are often introduced during design and architecture decisions rather than at the moment of a breach. Threat modeling helps teams reason about what could go wrong in a system before an attacker does, so that limited security resources can be directed toward the threats and structural vulnerabilities that matter most. By identifying potential threats and the absence of appropriate safeguards early, teams can define countermeasures intended to prevent or mitigate their effects rather than reacting after an incident.

For organizations handling cardholder data or sensitive authentication data, threat modeling supports the broader risk assessment activities that inform how systems are scoped and protected. It is a way to make assumptions explicit: where cardholder data flows, where it is stored or transmitted, and which entities could be attacked. This structured view helps prioritize security work, but it is important to recognize what it is not. Threat modeling identifies and prioritizes risks and recommends corrective action; it does not by itself validate that implemented controls actually work as intended, and its output is only as accurate as the model and the assumptions behind it.

Who it's relevant to

Security Engineers

Security engineers use threat modeling to systematically examine applications, hosts, and data flows, identifying structural vulnerabilities and missing safeguards during design and architecture. It helps them prioritize which countermeasures to build, though the results depend on the scope and accuracy of the model rather than serving as validation that controls work.

Compliance Officers

Compliance officers can use threat modeling as part of broader risk assessment activities that inform how systems handling cardholder data are scoped and protected. It supports prioritization and corrective-action planning, but should be treated as an analysis that complements, not replaces, control validation and testing.

Fraud Analysts and Merchant Risk Teams

Fraud and risk teams can apply threat modeling to reason about how different parts of a payment system could be attacked and where safeguards may be absent. This structured view helps prioritize where to focus detection and mitigation efforts, while recognizing that identifying a threat is distinct from confirming that a control against it is effective.

Acquirers and Payment Processors

Acquirers and processors operate complex systems where data, applications, and hosts present multiple potential attack surfaces. Threat modeling helps them identify and prioritize threats across these entities and recommend corrective actions, with effectiveness tied to the completeness of the model and the assumptions made.

Inside Threat Modeling

Asset Identification

Cataloging what needs protection within the environment, such as cardholder data (PAN, cardholder name, expiration date, service code), sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks), systems, and trust boundaries. Note that sensitive authentication data must not be stored after authorization, even when encrypted, so its handling during processing is a key modeling focus.

Trust Boundaries and Data Flows

Mapping how data moves between components, users, and external systems, and where control of that data changes hands. Data-flow diagrams help identify where cardholder data enters, is processed, transmitted, or stored, which also informs PCI DSS scope determination.

Threat Enumeration

Systematically identifying potential adversarial actions against each asset and boundary, such as interception of data in transit, unauthorized access to stored data, tampering, or abuse of authentication flows. This may include distinguishing card-present versus card-not-present attack surfaces where relevant.

Vulnerability and Weakness Analysis

Assessing where existing controls may fail or be absent, and how a threat could exploit that gap. This is intended to be qualitative and prioritized rather than a guarantee of completeness.

Countermeasures and Mitigations

Identifying controls intended to reduce identified risks, such as tokenization, encryption, truncation, masking, or hashing for data protection, and multi-factor authentication, EMV chip authentication, 3-D Secure, or strong customer authentication for their respective points in a transaction. Each addresses different risks and none should be treated as eliminating fraud.

Risk Prioritization

Ranking identified threats by likelihood and potential impact to guide where mitigation effort is applied first. Prioritization reflects judgment and available information, not fixed figures.

Common questions

Answers to the questions practitioners most commonly ask about Threat Modeling.

Is threat modeling the same as a vulnerability scan or penetration test?

No. Threat modeling is a structured analysis activity that identifies potential threats, attack paths, and weaknesses in a system's design before or alongside testing. Vulnerability scanning and penetration testing are testing activities that probe an implemented system for known or exploitable flaws. Threat modeling helps decide what to test and what controls to design; it does not replace scanning or penetration testing, and those testing activities do not substitute for the design-level reasoning that threat modeling provides.

Does completing a threat model prevent breaches or guarantee a system is secure?

No. Threat modeling is intended to help teams identify and prioritize risks so they can design and select mitigating controls, but it does not prevent breaches or guarantee security. Its value depends on the quality of the analysis, the accuracy of the assumptions and system understanding, and whether identified mitigations are actually implemented and validated. Threats missed during modeling, changes to the system after the exercise, and gaps in follow-through all limit its effectiveness.

When in the development lifecycle should threat modeling be performed?

Threat modeling is generally most useful early, during design, so identified risks can influence architecture and control selection before code is written. It is also commonly revisited when significant changes occur, such as new data flows, new integrations, or changes to how cardholder data or sensitive authentication data are handled. Treating it as an iterative activity rather than a one-time gate helps keep the model aligned with the current system.

How does threat modeling relate to defining PCI DSS scope?

Threat modeling can help teams reason about where account data flows, is processed, or is stored, which supports scoping decisions and the identification of connected systems. However, it is an analysis aid, not a formal scoping determination. Scope must be confirmed against the current published PCI DSS and validated through appropriate methods, and readers should verify requirement wording against the current standard rather than relying on a threat model alone.

Who should be involved in a threat modeling exercise?

Threat modeling typically benefits from a mix of perspectives, such as developers or architects who understand the system design, security engineers familiar with attack techniques, and stakeholders who understand the data being handled and applicable compliance obligations. Broader participation can help surface data flows and assumptions that a single role might miss, though the specific participants depend on the system, organization, and the assets being analyzed.

How should the output of threat modeling be tracked and acted upon?

Identified threats and proposed mitigations are commonly recorded so they can be prioritized, assigned, and tracked to resolution, and revisited as the system changes. Without follow-through, documented threats provide limited protective value. Teams often integrate outputs into their existing risk management, change management, or issue-tracking processes so that mitigations are implemented and later validated rather than left as unaddressed findings.

Common misconceptions

Threat modeling is a one-time activity completed during design.

Threat modeling is intended to be iterative and revisited as architecture, data flows, and threats change. A model produced once can become inaccurate as systems, integrations, and scope evolve.

Applying encryption or tokenization identified during threat modeling removes data from PCI DSS scope automatically.

Tokenization, encryption, truncation, masking, and hashing transform or reduce data differently, and their effect on PCI DSS scope depends on implementation and validation, not on the label alone. Threat modeling can highlight candidate controls, but scope reduction must be confirmed against how the control is actually deployed and validated.

Threat modeling is a formal PCI DSS standard with its own numbered requirements.

Threat modeling is a security practice, not a standalone PCI standard. Where PCI DSS references related activities, requirement numbering and wording differ between versions, so readers should confirm applicable expectations against the current published standard rather than assuming a fixed requirement number.

Best practices

Build and maintain data-flow diagrams that explicitly show where cardholder data and sensitive authentication data enter, are processed, transmitted, or stored, and confirm that sensitive authentication data is not retained after authorization.

Revisit the threat model when architecture, integrations, data flows, or the threat landscape change, treating it as an iterative practice rather than a one-time deliverable.

When a mitigation such as tokenization, encryption, truncation, masking, or hashing is proposed, verify its actual implementation and validation before relying on it for scope reduction or risk reduction claims.

Model authentication controls at the correct point in the transaction, distinguishing EMV chip authentication, 3-D Secure, strong customer authentication, and multi-factor authentication, and avoid assuming any single control eliminates fraud.

Prioritize identified threats by likelihood and impact using qualified, documented reasoning, and record known limitations and false-positive or false-negative trade-offs for any detection controls proposed.

Confirm applicable control expectations against the current published PCI DSS or the relevant separate standard (such as PCI P2PE, PCI PIN, or PCI 3DS) rather than assuming a fixed requirement number or standard applies.