If Your Reviewer Can't See the System, You Don't Have an Architecture

Security Architecture Views are the only thing I can take in at a glance. When they're done well, I trust them before I read a single sentence. When they're done poorly, they create a credibility gap that the rest of the file can't close.

Most teams over-engineer the diagrams and under-engineer the boundaries of the system. I see it all the time.

The Four Things A Defensible View Has

I need 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.

The Rewrite That Earns Trust

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 reason the second version works is not that it has more boxes. It is that every box, line, and label answers a question the reviewer was already going to ask. Where does external input enter the system? Which components share a failure domain? Which channels are authenticated, and how? Which interfaces are the threat model going to have to address?

The first diagram leaves all of those questions open. The second one closes them on the page.

Three Views, Not One

A common mistake is trying to make a single diagram carry every job. It cannot.

The package that lands cleanest uses three layered views, each doing one thing.

A context view. The device sits in the middle. Every external actor and external system that touches it is on the perimeter; clinicians, patients, network infrastructure, cloud services, third-party integrations, the manufacturer's own services. The point of this diagram is to make the world the device lives in unambiguous before any internal detail is shown.

A trust-zone view. Internal components grouped by trust level, with explicit boundaries between zones. This is where the architectural decisions become visible; what is in the secure enclave, what is in the application processor, what is in the cloud control plane, what is in the cloud data plane. A reviewer should be able to point at any zone and ask "what protects this boundary?" and find the answer in the threat model.

A data-flow view. Every flow between zones, with channel, direction, authentication, and the sensitivity of the data being moved. This is the view the threat model lives on top of. STRIDE applies cleanly here because every flow is a candidate for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

Three views, ten minutes to read, and the reviewer now has a mental model of the device that survives the rest of the submission.

Common Failure Modes

The marketing diagram. A logo-heavy slide that shows partner integrations and value flow. It is not an architecture view, and submitting it as one tells the reviewer the team does not know the difference.

The network diagram pretending to be an architecture view. Subnets and firewalls are not trust zones. A device and a hospital workstation can sit on the same VLAN and live in completely different trust zones. Reviewers are looking at trust, not topology.

The single-arrow cloud. "HTTPS" arrows from device to cloud, with no decomposition of what is in the cloud, are the single most common pattern we see, and the single most common source of follow-up questions.

Diagrams that disagree with the threat model. If the architecture view shows three trust zones and the threat model only addresses two, the package is internally inconsistent. The reviewer will find it. It is one of the cheapest deficiencies to avoid and one of the most damaging to land.

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.