Security Architecture Views are the single piece of a submission a reviewer can take in at a glance. Done well, they earn trust before a single sentence is read. Done poorly, they create a credibility gap the rest of the file can't close.
Most teams over-engineer the diagrams and under-engineer the boundaries.
A defensible Security Architecture View has four things:
A clear system boundary. What's the device. What's not. Where the device meets the network, the cloud, the EHR, the user, the clinician, the manufacturer. If the boundary is fuzzy, every threat downstream is contestable.
Honest trust zones. Group components by the trust level they actually require, not by where they sit on the network diagram. The device firmware, the mobile app, the cloud backend, and the manufacturer's update service are almost never in the same trust zone, even when the marketing slide makes them look unified.
Named data flows. Every line between components should answer three questions: what data, in what direction, over what channel. "HTTPS" is not a channel. "Mutually-authenticated TLS 1.3 with device-attested client certificates" is.
Entry points called out. Every interface that accepts input from outside its trust zone is an attack surface. Mark them. The threat model later in the submission should map back to these exact entry points.
The diagram you submit isn't art. It's a contract between you and the reviewer about what the device is and how it's defended.
Here's the version of this we see most often: a single rounded rectangle labeled "Cloud Platform" with one arrow labeled "HTTPS" going to a box labeled "Device." That diagram has zero trust zones, one unnamed data flow, and no entry points. The rewrite that passes splits the cloud into ingestion API, analytics service, and clinician portal — three trust zones — names the channel as mTLS 1.3 with device-attested certs, and marks the ingestion API as the only externally reachable entry point. Same system. Completely different conversation with the reviewer.
The teams that get this right ship submissions where the rest of the file flows from a single source of truth. The teams that don't end up explaining the same system three different ways across the package, and the reviewer notices.