Security by Design

This chapter covers the foundational planning and architectural decisions that establish security throughout the product development lifecycle.

Security for a medical device gets decided long before anyone writes code. This chapter covers the planning and architecture work that determines whether security holds up later: writing a security management plan, understanding what patients, clinicians, hospital IT, and regulators each need from your device, and designing an architecture that meets FDA's five security objectives of authenticity, authorization, availability, confidentiality, and updatability.

The middle of the chapter walks through the four architecture views FDA expects in a premarket submission (global system, multi-patient harm, updatability and patchability, and security use cases), then moves into threat modeling with data flow diagrams and STRIDE, using the MITRE playbook's four questions as a frame. From there it connects threats to risk: scoring vulnerabilities with CVSS, deciding what's acceptable, and transferring security risks into your ISO 14971 safety risk process, since an authentication bypass or a denial of service attack on a clinical device can put patients at risk.

The last sections cover implementation patterns such as defense in depth, least privilege, and secure boot, plus documentation habits that make FDA review and audits less painful, and the five planning mistakes manufacturers keep making, like treating security as an add-on or a compliance checkbox.

After reading it, you should be able to draft a security management plan with clear roles and risk acceptability criteria, sketch the architecture views for your own device, run a basic threat modeling session, and score and prioritize the risks that come out of it. If you're early in development, this is the chapter to act on first. Decisions made here are cheap to change now and expensive to change after design freeze.