The challenge behind the engagement.
Threat modeling finds the flaws a penetration test can only confirm later: a missing authorization check between services, or a tenant boundary that lives in the screen but not the code. We run workshops that ask what you are building, what can go wrong, and what you will do about it. We draw or correct the diagrams of how data moves, where it is stored, where it enters, and where trust changes hands, then walk each part for how it could be attacked. We add privacy risks where personal data is handled and build attack scenarios for goals such as reading another tenant’s records. Each weakness becomes a testable requirement your developers can put on the backlog. You receive annotated diagrams, a threat register with owners, and the reusable model, which is design evidence, not proof of exploitability.
For architects, lead developers, and product owners about to build a new service, change authentication or tenancy, or add an AI or third-party integration. Also for teams that need design-stage evidence of secure development for a customer security review or an audit.
What we do.
What you can use.
Gather the system truth
You provide whatever exists: architecture and sequence diagrams, data classifications, the identity provider and authorization model, and the list of third-party integrations. Where diagrams are stale we take read access to infrastructure as code or the cloud console to confirm topology. We agree the systems and features in scope and book two to four hours of engineer time per workshop.
Run the modeling workshops
With your architect, lead developers, and product owner present, we draw how data moves through the system, then work through each part for how it could be abused. We add privacy risks where personal data is handled and build attack scenarios for goals that matter. Each threat is ranked by likelihood and impact and given a response: fix, accept, transfer, or design out.
Hand over a model you can keep
You receive the threat register in your tracker’s format, with an owner and target release for each fix, plus written security requirements your team can build to. You also get an abuse-case list for your testers and the reusable model file itself. In a closing session we show your developers how to extend the model; open threats feed into code review or pipeline gates.
Who it’s for.
When you need it.
- Product and platform teams designing a new service or a significant feature before code exists
- Architects reworking authentication, multi-tenancy, or how systems trust one another
- Teams adding an AI capability or a third-party integration that widens the attack surface
- Organizations needing design-stage evidence of secure development for a customer security review or audit
- A new service or feature is entering design while the architecture is still changeable
- A change to authentication, tenancy, or system-to-system trust is planned this quarter
- A customer or auditor has asked how security is considered during design
- Penetration tests keep surfacing flaws that should have been caught at design time
What the scope can include.
- 01
Diagrams of how data moves drawn or corrected: the parts, where data is stored, who connects, and where trust changes hands
- 02
A structured walk of every part and connection for how it could be attacked, with privacy risks added where personal data is processed
- 03
Attack scenarios for two or three high-value goals, such as reading another tenant’s records or shipping a release without review
- 04
Each weakness turned into a written, testable security requirement your team can put on the backlog
- 05
Response decision recorded per threat: mitigate, accept, transfer, or eliminate, each with an owner and a target release
- 06
Third-party, AI, and identity integrations reviewed for where trust changes hands and what is assumed about the other side
What it typically costs.
One rate: $150/hour.
Every engagement is priced by the hours it takes at one flat rate, with scoping, the work, and the final deliverables included. Find the size closest to yours.
One new feature or small application, one or two workshops
About 16–32 hoursOne complete system with several connected services
About 40–80 hoursA multi-customer platform or a set of three to five systems
About 100–180 hours- Number of components, data flows, and trust boundaries
- Number of workshops and teams that must attend
- Quality of existing design documentation
- Whether personal data and privacy risks are in scope
1–2 weeks for a single feature; 2–3 weeks for a full system; 4–8 weeks for a platform
Get a fixed quote for your scopeRanges are planning estimates at $150/hour, not a quote. Your price is confirmed in writing after a scoping call, before any work begins.
What you take forward.
- Annotated diagrams of how data moves, with boundaries, entry points, and assets labeled
- Threat register listing each risk with its category, likelihood, impact, planned fix, owner, and status
- Written, testable security requirements, plus an abuse-case list your testers can work from
- The reusable model file and an executive summary written for leadership
Final coverage, deliverables, timing, and any retesting or implementation work are confirmed before the engagement begins.
Before we get started.
Do we need finished architecture documents before we start?
No. A slide or two and a stale diagram is a normal starting point; we draw the rest in the first workshop. What we do need is the people who know how the system is deployed, the identity provider and authorization model, the data classifications, and the list of integrations. If nobody is sure how a component actually talks to another, read access to infrastructure as code or the cloud console settles it. A single feature is usually one workshop plus a few days of write-up; a platform with several services runs one to two weeks.
How is this different from a penetration test, and do we still need one?
A threat model works from the design and never touches a running system. It finds missing controls, misplaced trust, and abuse cases before code is written, and it produces requirements a developer can build to. A penetration test confirms exploitability in the built system. Both are worth doing, and they feed each other: the abuse-case list becomes the test plan, and open threats point the code review at the paths that matter. The model can serve as evidence of secure design for a SOC 2 or ISO/IEC 27001 control; whether an auditor accepts it is the auditor’s call.
- Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities
- Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines
- SLSA specification
- 2026 Minimum Elements for a Software Bill of Materials (SBOM)
- OWASP Top 10 CI/CD Security Risks
- Threat Modeling - OWASP Cheat Sheet Series
- 2025 CWE Top 25 Most Dangerous Software Weaknesses