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.

Run a Free Review → Read the framework ↓
Lokesh RanjanOriginal IP · A-SDF v1.0
© 2026All rights reserved
IndependentNot an extension of STRIDE or OWASP

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

STRIDE requires data flow diagrams. PASTA requires attack simulation. All start with threats — which means reviews never get done unless a specialist runs them. A-SDF asks a different first question.

The old way
Draw a DFD first
STRIDE the data flows
Hand a 30-page PDF to a developer
Watch nothing get fixed
With A-SDF
Ask "what does this system own?"
Derive abuse cases per asset
Define preventive + detective controls
Developers can act on it today

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 & 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 & CTOs
Get a structured security review without hiring a specialist for every sprint.

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 changed

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

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
Who
Actor
Does what
Unwanted Action
To what
Asset
Result
Impact
Internal reasoning engine — output is always plain language.

Six asset domains. Every review starts here.

Every system can be decomposed into these domains. Identifying assets before threats is what makes A-SDF different from every existing methodology. Asset names adapt to solution context — a Component in a web app becomes "Payment workflow" or "Resume upload interface".

01
👤
User
Every human actor interacting with the system — authenticated or unauthenticated.
Authentication Authorisation Access provisioning Activity logging
Updated
02
🧩
Component
Frontend, backend logic, workflows, and sessions. Named after what it actually is in context — e.g. "Payment workflow", "Resume upload interface", "Admin dashboard".
Business logic integrity Input handling & validation Client-side security Session security Error handling Logging
03
🗄️
Data
Every piece of information the system stores, processes, or transmits — especially PII, PCI, PHI.
Encryption at rest Encryption in transit Data in use — masking Retention & disposal Classification
04
🔗
Integration
APIs, webhooks, third-party services, background jobs, and any system-to-system interface.
Auth between services Authorisation & permissions Data minimisation Input validation API logging
05
Actions
Privileged, irreversible, or bulk operations performed through the system — e.g. bulk export, financial transaction, delete.
Non-repudiation Privilege control Approval workflows Rate limiting Audit trail
Cloud / GenAI
+
🔑
Identity & Intelligence
IAM, federated identity, LLM, RAG, and agentic systems. Extended domains for Cloud and GenAI reviews.
IAM least privilege Federated identity Model access control Output monitoring Training data integrity

* Every review starts with User. Component replaces the generic System domain for application-layer reviews. Infra is a separate review scope.

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 — Employee SaaS Portal (personal profile, resume upload, salary slip download)

Asset Abuse Case Preventive Control Detective Control
Component

Resume upload interface
Attacker uploads malware disguised as a PDF resume, compromising the document processing pipeline. Validate file type server-side. Scan on upload with AV. Store files outside webroot. Reject unsupported formats silently. Alert on AV scan failures, unexpected file extensions, or upload volume spikes per user session.
Component

Business profile form
Employee manipulates their own designation or cost centre via direct API call to gain elevated privileges in downstream systems. Business fields read-only to employees — HR role only. Enforce server-side. Never trust client-submitted role or department values. Alert on any API call attempting to modify designation, department, or cost centre fields outside HR role session.
Actions

Salary slip download
Authenticated employee downloads a colleague's salary slip by manipulating the document ID parameter in the download request. Enforce server-side ownership check on every download request — authenticated user ID must match the salary slip owner ID. Reject and log mismatches. Alert on any salary slip access where requesting user ID ≠ document owner ID. Flag off-hours bulk download attempts.
Data

Personal profile — PII
Insider or compromised HR account exports bulk employee personal data without a legitimate business reason. Enforce least-privilege on HR data access. No bulk export without manager approval workflow. Mask sensitive fields in UI by default. Alert on bulk export exceeding 50 records. Log all PII field access with identity, timestamp, and action type. Weekly access review.

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

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 pointAssets the system ownsData flow diagramsApplication attack surfaces
First question"What does this system own?""Where are our trust boundaries?""What are our attack surfaces?"
Controls in outputYes — preventive and detective per abuse caseNo — threat list onlyPartial — via external cheat sheets
Diagrams requiredNoneDFD mandatoryArchitecture diagram required
Who can run itAny SDLC stakeholderSecurity engineers onlySecurity engineers only
GenAI supportNative — Intelligence asset domainNot designed for LLM scopeLimited — separate LLM Top 10 track
Asset namingContext-specific — named after what it actually isGeneric component typesGeneric attack surface labels

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 in minutes.
What is the Component asset domain? +
Component covers frontend, backend logic, workflows, and session management for application-layer reviews. Unlike the generic "System" label, Component assets are named after what they actually are in your application — "Payment workflow", "Resume upload interface", "Admin dashboard" — so every abuse case lands with the developer who owns it.
How long does a review take? +
A focused review of a single feature or flow takes 5–15 minutes. A full application review covering all asset domains typically takes 30–45 minutes. Compare that to 2–3 days for a traditional threat model with DFDs.
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 CSV.

Run your first review — free.

4 threat models per month. No credit card required. Output in minutes.

Start at threatmodeling.in →