--- title: "Threat Modeling Is the Work. Everything Else Is the Receipt." description: "Learn how to create effective threat models that genuinely secure systems by shaping architecture and driving requirements from the project's start." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Person", "@id": "https://christianespinosa.com/#person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "image": "https://christianespinosa.com/__l5e/assets-v1/de07e44b-a8e0-4bcc-bcb0-13aec15421f1/headshot-front.jpg", "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ], "jobTitle": "Bestselling Author, Keynote Speaker, Entrepreneur", "worksFor": { "@type": "Organization", "name": "Blue Goat Cyber", "url": "https://bluegoatcyber.com/" } }, { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://christianespinosa.com/#website", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "publisher": { "@id": "https://christianespinosa.com/#organization" }, "inLanguage": "en-US" }, { "@context": "https://schema.org", "@type": "Organization", "@id": "https://christianespinosa.com/#organization", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" }, "founder": { "@id": "https://christianespinosa.com/#person" }, "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ] }, { "@context": "https://schema.org", "@type": "Article", "headline": "Threat Modeling Is the Work. Everything Else Is the Receipt. | Christian Espinosa", "description": "Learn how to create effective threat models that genuinely secure systems by shaping architecture and driving requirements from the project's start.", "image": "https://christianespinosa.com/__l5e/assets-v1/7af5e217-88f0-42f6-8238-26e5fdc08d99/threat-modeling-is-the-work-everything-else-is-the-receipt-card.png", "datePublished": "2025-11-18T13:00:00Z", "dateModified": "2025-11-18T13:00:00Z", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://christianespinosa.com/blog/threat-modeling-is-the-work-everything-else-is-the-receipt" }, "author": { "@type": "Person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/about" }, "publisher": { "@type": "Organization", "name": "Christian Espinosa", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" } } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is the core idea behind \"Threat Modeling Is the Work. Everything Else Is the Receipt\"?", "acceptedAnswer": { "@type": "Answer", "text": "You don't have a threat model if you write it after the design is done. You have a justification" } }, { "@type": "Question", "name": "Who is this post for?", "acceptedAnswer": { "@type": "Answer", "text": "Honestly, security leaders, medical device teams, and technical operators who want the honest version, not the vendor version. If you want a listicle, this is not that. If you want the honest version of what I have actually lived and worked through, keep reading." } }, { "@type": "Question", "name": "How do I actually apply this, not just nod along?", "acceptedAnswer": { "@type": "Answer", "text": "Pick the single line in the post that made you flinch or look away, and change one thing in your week because of it. One choice this week beats a whole framework you never touch." } }, { "@type": "Question", "name": "How does this connect to From the upcoming book?", "acceptedAnswer": { "@type": "Answer", "text": "Medical Device Cybersecurity: An In-Depth Guide; a chapter-by-chapter walkthrough of premarket submissions and postmarket surveillance, written for engineers, regulatory teams, and founders who'd rather not learn this the hard way. If the post landed, that is the natural next step; the preview the book link at the bottom of the page goes straight there." } } ] } ] --- [Skip to content](#main) [](/) [About](/about)[Speaking](/speaking)[Cybersecurity](/cybersecurity)[Programs](/programs)[Books](/books)[Media](/media) Writing Search Ctrl K[Connect](/connect) [Cybersecurity](/blog/category/cybersecurity) # Threat Modeling Is the Work. Everything Else Is the Receipt November 18, 2025 4 min read 824 words You don't have a threat model if you write it after the design is done. You have a justification ![](/__l5e/assets-v1/295fd150-115e-4a0d-904f-1353bc456684/threat-modeling-is-the-work-everything-else-is-the-receipt-hero.webp) Published November 18, 2025 Read time 4 min In this essay 1. [01 The Order That Actually Produces A Defensible System ](#the-order-that-actually-produces-a-defensible-system) 2. [02 What "Letting It Rewrite The Design" Looks Like ](#what-letting-it-rewrite-the-design-looks-like) 3. [03 Where Most Threat Models Quietly Fail ](#where-most-threat-models-quietly-fail) 4. [04 The Payoff ](#the-payoff) Jump to 1. [01 The Order That Actually Produces A Defensible System ](#the-order-that-actually-produces-a-defensible-system) 2. [02 What "Letting It Rewrite The Design" Looks Like ](#what-letting-it-rewrite-the-design-looks-like) 3. [03 Where Most Threat Models Quietly Fail ](#where-most-threat-models-quietly-fail) 4. [04 The Payoff ](#the-payoff) The takeaways 1. 01 Instead of justifying existing systems, a real threat model helps shape architecture and drive requirements from the outset. What to do next Open your current threat plan today and identify the one gap you would not want an auditor to find. 2. 02 Threat modeling should begin by defining the system thoroughly, including boundaries, data flows, and trust zones, ideally representable on a single page. What to do next Add threat to the next leadership review as a standing item, not a one-time slide. 3. 03 Identify threats using methods like STRIDE or attack trees before considering controls to avoid creating a control catalog disguised as a threat model. What to do next Run a 20-minute tabletop with your team this month using threats as the scenario. 4. 04 Actively challenge trust boundaries, entry points, interfaces, and assumptions to rigorously test the system's security posture. What to do next Open your current trust plan today and identify the one gap you would not want an auditor to find. 5. 05 Allow the threat model to iterate and modify the system's design; if it doesn't change the architecture, it's mere paperwork, not true threat modeling. What to do next Run a 20-minute tabletop with your team this month using threat as the scenario. Editor's note Adapted from Chapter 7 of Medical Device Cybersecurity: An In-Depth Guide. Threat modeling is the single highest-use practice I see across the 250+ submissions Blue Goat Cyber has supported; and the one most teams treat as the lowest-priority deliverable. The book walks through STRIDE, trust boundary analysis, entry-point analysis, and threat scenario development with worked examples from real device classes. I've reviewed hundreds of medical device threat models. The bad ones all look the same to me. They describe the system as it was already built. They list a few generic threats. They map those threats to controls that were already in place. They close with a residual risk table that says "acceptable." FDA reviewers can tell. Attackers can tell, too. A real threat model is the work; the part that shapes architecture, drives requirements, and decides what gets built. The document is the receipt. ## The Order That Actually Produces A Defensible System 1. **Define the system before you describe it.** Boundaries, data flows, trust zones, assumptions. If you can't draw it on one page, you don't know what you're securing. 2. **Find the threats before the controls.** STRIDE, attack trees, kill chains; pick a method and use it consistently. Threats first, mitigations second. Most teams reverse this and end up with a control catalog dressed as a threat model. 3. **Argue with yourself.** A trust boundary you don't push on is a trust boundary you're hoping holds. Walk every entry point. Walk every interface. Walk every assumption. 4. **Let the threat model rewrite the design.** This is the part teams skip. If threat modeling never changes the architecture, you're not doing threat modeling. You're doing paperwork. 5. **Then write the document.** Concise, traceable, every threat tied to a mitigation and a residual risk. The reviewer should be able to follow the logic in one pass. The teams that ship cleanly aren't smarter. They start earlier and they let the model change their minds. ## What "Letting It Rewrite The Design" Looks Like The single biggest tell of a real threat model is that something in the system actually changed because of it. A connected infusion pump team we worked with started threat modeling six weeks before their submission was due. The first pass uncovered three things they had not been carrying as risks: the maintenance USB port had no authentication, the mobile companion app trusted any pairing response from a nearby BLE device with the right service UUID, and the cloud telemetry channel reused a single device certificate across an entire production lot. None of those were going to show up on a checklist. All three would have showed up to an attacker, and to a reviewer who walked the architecture carefully. The right response is not to write three more mitigations into the residual risk table and call it acceptable. The right response is to change the device. Disable the port. Require attested pairing on the app. Provision per-device keys at manufacture. Then the threat model documents a system that is actually defended, not a system someone hopes is defended. That is the difference between threat modeling as engineering and threat modeling as compliance theater. ## Where Most Threat Models Quietly Fail A few patterns show up in almost every weak threat model we review. **The data flow diagram and the architecture diagram disagree.** Two artifacts, one system, different stories. The reviewer notices immediately and the rest of the model loses credibility. **Trust boundaries that wrap the whole system.** If your only trust boundary is "the device" or "the cloud," you have not done the work. The interesting boundaries are inside; between firmware and bootloader, between the mobile app and its dependencies, between the ingestion service and the analytics service. **Generic STRIDE entries copy-pasted from a template.** "Spoofing of user identity" with no specifics is not a threat. "An attacker on the hospital network impersonates the device's update server because the device does not pin the update server's certificate" is a threat. The first is theater; the second tells you exactly what to build. **Residual risk tables full of mediums.** Almost no real residual risk is medium. Medium usually means the team did not want to commit to high (which would force a mitigation) or low (which would force a justification). Pick. **Mitigations with no owner and no verification.** A mitigation that does not map to a security requirement and a verification activity is a wish, not a control. ## The Payoff Do this and the SBOM, the security requirements, the architecture views, the test plan, and the risk file all line up; because they were derived from the same source, not assembled from different ones. Reviewers can feel that coherence. So can the team six months later when something changes and they need to know what is affected. So can the postmarket function when a CVE drops and somebody has to decide in 24 hours whether it touches the device. A submission built on a real threat model is faster to write, easier to defend, and cheaper to maintain. A submission built on a justification looks fine until the first deficiency letter and then collapses under follow-up. That's the whole game. > “If threat modeling never changes the architecture, you're not threat modeling. You're doing paperwork.” Frequently asked ### What is the core idea behind "Threat Modeling Is the Work. Everything Else Is the Receipt"? ### Who is this post for? ### How do I actually apply this, not just nod along? ### How does this connect to From the upcoming book? ### From the upcoming book Medical Device Cybersecurity: An In-Depth Guide; a chapter-by-chapter walkthrough of premarket submissions and postmarket surveillance, written for engineers, regulatory teams, and founders who'd rather not learn this the hard way. [Preview the book](/books/medical-device-cybersecurity) Share this essay [X ](https://twitter.com/intent/tweet?url=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fthreat-modeling-is-the-work-everything-else-is-the-receipt&text=Threat%20Modeling%20Is%20the%20Work.%20Everything%20Else%20Is%20the%20Receipt) [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fthreat-modeling-is-the-work-everything-else-is-the-receipt) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fthreat-modeling-is-the-work-everything-else-is-the-receipt) [Email](mailto:?subject=Threat%20Modeling%20Is%20the%20Work.%20Everything%20Else%20Is%20the%20Receipt&body=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fthreat-modeling-is-the-work-everything-else-is-the-receipt)Copy link ![Christian Espinosa, headshot](/__l5e/assets-v1/de07e44b-a8e0-4bcc-bcb0-13aec15421f1/headshot-front.jpg) About the author [Christian Espinosa](/about) · Founder & CEO, Blue Goat Cyber I'm the founder and CEO of Blue Goat Cyber, a medical device cybersecurity firm where my team has supported 250+ FDA submissions with zero failing to clear on cybersecurity. I previously founded and sold Alpine Security. I host The Med Device Cyber Podcast and wrote The Smartest Person in the Room and The In-Between: Life in the Micro, with Medical Device Cybersecurity: An In-Depth Guide out in 2026. Air Force Academy grad, 24x Ironman, climber of two of the Seven Summits. Keep reading - [ ### FDA Premarket Cybersecurity: What the 2026 Guidance Actually Requires What the FDA actually wants to see in the threat model section of a premarket submission, and the most common deficiencies. Read essay → ](/blog/fda-premarket-cybersecurity-what-the-2026-guidance-actually-requires) - [ ### Why Postmarket Cybersecurity Is Where MedTech Actually Fails A weak threat model becomes a brittle postmarket program. The two failures are connected. Read essay → ](/blog/why-postmarket-cybersecurity-is-where-medtech-actually-fails) [← Previous essay What Is Threat Intelligence, and Why Is It Important in Supporting Your Cyber Team? - Christian Espinosa ](/blog/what-is-threat-intelligence-and-why-is-it-important-in-supporting-your-cyber-team)[Next essay → Total Product Lifecycle: The Framing That Fixes Most MedTech Submissions | Christian Espinosa ](/blog/total-product-lifecycle-the-framing-that-fixes-most-submissions) Related, Cybersecurity ### Need medical-device or offensive security expertise? Blue Goat Cyber, Christian's firm, runs FDA-aligned premarket submissions, penetration testing, and SBOM/SOUP analysis for medtech and high-stakes industries. [Explore Blue Goat Cyber](/cybersecurity) Christian Espinosa Bestselling author, keynote speaker, and Founding CEO of [Blue Goat Cyber](https://bluegoatcyber.com/). Helping technical leaders develop the soft skills that turn brilliance into impact. [](https://www.linkedin.com/in/christianespinosa/)[](https://x.com/Ironracer)[](https://www.instagram.com/christian.espinosa.official/)[](https://www.youtube.com/@ChristianEspinosaOfficial)[](https://www.facebook.com/christian.espinosa.official) Explore - [About](/about) - [Timeline](/timeline) - [Speaking](/speaking) - [Cybersecurity](/cybersecurity) - [Programs](/programs) Read - [Books](/books) - [Guides](/guides) - [Blog](/blog) - [Media](/media) - [Podcast Interviews](/podcasts) - [Success Stories](/success-stories) Connect - [Contact Christian](/connect) - [LinkedIn ↗](https://www.linkedin.com/in/christianespinosa/) - [Blue Goat Cyber ↗](https://bluegoatcyber.com/) - [Resources](/resources) © 2026 Christian Espinosa. All rights reserved. [Privacy](/privacy-policy)[Terms](/terms-of-use)