Try Free →
Framework · Lite Edition · 2026

Asset-Driven Secure Design Framework

A practical methodology for security design review and threat modeling — built for every stakeholder in an SDLC, not just security engineers.

Original IP · A-SDF v1.0
The Problem

Most threat modeling frameworks are built for security engineers — not for teams.

STRIDE requires data flow diagrams. PASTA requires attack simulation. OWASP TM requires technical notation. All start with threats — which means reviews never get done unless a specialist runs them.

The gap: Any product team can describe what their system owns in five minutes. They cannot draw a DFD or enumerate trust boundaries. A-SDF asks a different first question — "what does this system own?" — before asking what can go wrong. That one change makes security design reviews accessible to every stakeholder in an SDLC.


Who It Is For

Built for every role in a modern SDLC.

A-SDF does not require a security background to run. If you can describe what your system does, you can run a review.

🔐
Security Practitioners
Run structured reviews faster. Produce outputs your stakeholders can read and act on.
🏗️
Architects and Engineers
Identify security gaps at design time — before they become vulnerabilities in production.
📋
Product Managers
Understand security implications of product decisions without needing a specialist in every meeting.
💼
Security Consultants
Deliver threat models to clients faster. Output is business-readable and directly backlog-ready.
🎓
Learners
Learn threat modeling through structured practice on real systems — not abstract theory.
🚀
Founders and CTOs
Get a structured security review of your product without hiring a specialist for every sprint.

When to Use It

Run a review when any of these happen.

A-SDF is designed for real SDLC cadences — not once-a-year compliance exercises.

New product feature being designed or scoped
New third-party integration being added
New data type introduced — especially PII, PCI, or PHI
Cloud infrastructure change or migration
GenAI capability being added to an existing product
Pre-compliance audit or penetration test preparation
Any security incident — even minor — on a live system
Minimum annually — regardless of whether anything has changed

Solution Coverage

Works across every modern solution type.

The same methodology regardless of technology stack. The asset domains adapt to the solution — the method never changes.

🌐
Web App
SPA · MPA · API-first
☁️
SaaS
Multi-tenant · B2B · B2C
📱
Mobile
iOS · Android · Hybrid
🏗️
Cloud
AWS · Azure · GCP
🤖
GenAI
LLM · RAG · Agents
🔌
APIs
REST · SOAP · GraphQL
🏢
Enterprise
ERP · ITSM · Internal tools
📞
IVR
Voice · OTP · Reset flows

The Core Model

One reasoning model. Every solution type.

Every abuse case — across Web Apps, SaaS, Cloud, and GenAI — derives from a single pattern.

A-SDF Threat Derivation Model
Actor → Unwanted Action → Asset → Impact
Internal reasoning engine — output is always plain language.

Asset Taxonomy

Five asset domains. Every review starts here.

Every system can be decomposed into five domains. Identifying assets before threats is what makes A-SDF different from every existing methodology.

1
👤 User
2
🖥️ System
3
🗄️ Data
4
🔗 Integration
5
⚡ Actions
+
🔑 Identity Cloud
+
🧠 Intelligence AI / GenAI
Every review starts with User. Identifying all five asset domains before asking what can go wrong is what makes A-SDF produce controls that are specific and actionable — not generic threat lists.

Output — What You Get

A threat model table. Directly actionable.

The output of every A-SDF review is a four-column table — Asset, Abuse Case, Preventive Control, Detective Control. One row per abuse case. No risk scores. No gap columns.

Sample Output — Single Asset Row
Illustrative extract
AssetAbuse CasePreventive ControlDetective Control
User Unauthenticated · AccessAn unauthenticated caller requests a one-time code without identity verification, gaining access to another user's password reset flow. Verify caller identity via registered phone number before any OTP is issued. Unverified callers receive nothing. Log all OTP generation events with caller identity and timestamp. Alert on repeated requests for the same account within a 10-minute window.

* A full review covers all five asset domains — typically 12–18 rows. Downloadable as PDF or Word.


Framework Comparison

How A-SDF compares to existing approaches.

A-SDF is an independent methodology. It does not extend or layer on existing frameworks.

Dimension A-SDF STRIDE OWASP TM
Starting point Assets the system owns Data flow diagrams Application attack surfaces
First question "What does this system own?" "Where are our trust boundaries?" "What are our attack surfaces?"
Controls in output Yes — preventive and detective per abuse case No — threat list only Partial — via external cheat sheets
Diagrams required None DFD mandatory Architecture diagram required
Who can run it Any SDLC stakeholder Security engineers only Security engineers only
GenAI support Native — Intelligence asset domain Not designed for LLM scope Limited — separate LLM Top 10 track

FAQ

Common questions.

What does A-SDF stand for?
A-SDF stands for Asset-Driven Secure Design Framework — an original threat modeling methodology that starts with asset identification before asking what can go wrong.
How is A-SDF different from STRIDE?
STRIDE starts with threat categories and data flow diagrams. A-SDF starts with assets. No diagrams, no taxonomy, no security expertise required. Any SDLC stakeholder can run a review.
Does it work for GenAI and Cloud?
Yes. A-SDF extends with Identity and Intelligence asset domains for Cloud and GenAI solutions. The core reasoning model works identically across all solution types.
Where can I run a review?
At threatmodeling.in — four reviews per month are free with no credit card required. Output downloads as PDF or Word.

Run your first review — free.

4 threat models per month. No credit card required.

Start at threatmodeling.in → © 2026 Lokesh Ranjan · A-SDF is original intellectual property · All rights reserved