An example of PASTA Threat Modelling is assessing a customer login service by first defining business objectives, then mapping attack paths such as credential stuffing, token theft and session abuse. The team scores impact and likelihood, identifies weak controls, and uses the result to prioritise rate limiting, MFA, logging and fraud checks.
How PASTA Becomes a Working Threat Model
PASTA is most useful when it stays tied to a real business service, not an abstract diagram. In practice, the team starts with the business objective, then defines what success and loss look like for that service, so the threat model can be anchored to outcomes rather than generic technical worries.
The next step is to map the attack surface and likely attack paths. For a customer login flow, that usually means tracing how an attacker could abuse password reuse, stolen tokens, session hijacking, weak rate limits, or account recovery steps, then translating those paths into concrete controls and testable assumptions.
This is where a good Threat Modelling Guide helps teams keep the method disciplined: define the system, draw trust boundaries, identify abuse cases, and turn the discussion into fixes the engineering team can actually implement.
What the Login-Service Example Is Really Scoring
The practical value of PASTA is not the diagram itself, but the scoring that follows. Teams estimate likelihood and impact for each attack path, then compare weak points such as missing MFA, weak session handling, poor observability, or excessive account recovery privilege. That makes the output decision-oriented rather than purely descriptive.
In the login-service example, credential stuffing and token theft matter because they are high-probability paths with direct business consequences: account takeover, fraud, support cost, and trust loss. Session abuse often deserves the same attention because it can bypass strong passwords entirely once a session is compromised.
For teams building broader application security programmes, this is the same logic used in Application Security Guide material, where threat modelling is used to decide which controls, testing, and remediation work should happen first.
From Findings to Controls That Reduce Real Exposure
PASTA works best when each identified path turns into a specific control decision. For login abuse, that often means adding rate limiting, stronger authentication, improved logging, anomaly detection, and fraud checks, then deciding which of those controls should block, step up, or merely observe suspicious behaviour.
The method also works well when teams are explicit about what they will not fix immediately. If a control cannot be implemented before release, the model should still record the compensating measure, the residual risk, and the condition that would trigger escalation. That keeps the threat model alive as an operational artifact instead of a one-time workshop note.
Risk and Threat Considerations
Authentication services attract abuse because they sit at the front door of the application and often provide high-value entry paths. If the model stops at password risk and ignores token or session abuse, it can miss the more dangerous route, where an attacker bypasses the login screen entirely after initial compromise.
Failure mechanism: Weak rate limiting, reusable tokens, poor session invalidation, or weak recovery flows let attackers automate guessing, replay credentials, hijack sessions, or persist after a password reset.
Impact: The result can be account takeover at scale, fraudulent activity, lateral movement into connected services, and a false sense of safety if only the password control was evaluated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Login-service abuse depends on authentication strength and step-up handling. |
| V7 — Session Management | Session theft and reuse are central attack paths in the example. | |
| Recommendation — Validate authentication flows, token handling, and recovery paths before release. Harden session creation, invalidation, and fixation resistance. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The example includes token theft and login abuse patterns that mirror API authentication failures. |
| Recommendation — Test authentication assumptions and reject weak or replayable auth flows. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The example prioritises logging and detection for suspicious login behaviour. |
| IA-2 — Identification and Authentication (Organizational Users) | The scenario centres on controlling access through user authentication strength. | |
| Recommendation — Record authentication and abuse events so suspicious patterns can be investigated. Enforce strong user authentication for privileged and customer access paths. | ||
Practitioner Guidance
What to prioritise: Start with the highest-value and highest-volume abuse paths, usually the ones that can be automated or reused across many accounts. If a path can be exercised with commodity tooling, it deserves more attention than a low-probability edge case.
What to verify: Make sure the model ends with an owner, a decision, and a testable control change. If the workshop produces risks but no backlog items, no detection rules, and no review of the exception path, the exercise has not yet become a usable threat model.
Practitioner takeaway: A good PASTA example is not a generic list of threats, it is a traced attack path that leads directly to ranked controls and an explicit decision about what risk remains acceptable.