Zero Trust Network Architecture Diagram Template

Many diagrams labeled "zero trust" are a perimeter diagram with a new title: a firewall at the edge, a DMZ, and a trusted inside. A useful zero trust architecture diagram answers three questions at a glance: where is each access decision made, which signals feed that decision, and where is it enforced? If the picture can't answer those, it describes network location, not trust.

Below: the logical model from NIST SP 800-207, drawing rules a reviewer can check, common mistakes, and a free template to copy into Archboard.

The NIST SP 800-207 model

NIST SP 800-207 defines zero trust architecture (ZTA) around one idea: no implicit trust based on network location or asset ownership. Access to each resource is granted per session, decided by dynamic policy, and enforced before the subject reaches the resource.

The three logical components

Together, the PE and PA form the Policy Decision Point (PDP). In real systems the PE may live inside an identity-aware proxy or a service mesh control plane, and PEPs are gateways, sidecars, agents or proxies. The diagram should still make each role visible, even if one product plays two of them.

The data sources behind the decision

SP 800-207 lists the inputs a PE can use. The ones that belong on almost every diagram:

• Identity provider / ID management: users, service identities, groups, authentication strength.
• Device posture (CDM): continuous diagnostics and mitigation data: is the device known, managed, patched?
• Threat intelligence: feeds about new attacks, compromised accounts and vulnerabilities.
• Activity logs and SIEM: network and system activity collected and analyzed; this is where the feedback loop starts.
• Enterprise PKI: certificates for users, devices and workloads.

The standard also names data access policies and compliance requirements; draw them if they shape real decisions.

How to draw a zero trust architecture diagram

1. Put a PEP in every access path

Trace every arrow from a subject (user, device, service) to a resource. Each one must pass through an enforcement point first. If an arrow skips the PEP, either the diagram is wrong or the architecture has a gap. Include admin, CI/CD and break-glass paths, not only the user path.

2. Show identity and device signals feeding the decision

Draw the identity provider, device posture, threat intel and SIEM as nodes with edges into the Policy Engine. Label the edges with what flows: "user + groups (OIDC)", "device compliance", "risk signals".

3. Make per-session authN and authZ explicit

NIST describes access as granted per session; many implementations re-evaluate on every request. Either way, show the sequence: the subject requests access, the PEP asks the PDP, the PE evaluates, the PA configures the PEP, and the PEP allows or blocks the session. Numbered edge labels are enough; add a small sequence diagram for more detail.

4. Separate the control plane from the data plane

Put the PE, PA and data sources in one region and subjects, PEPs and resources in another. The only lines that cross are the PA-to-PEP control channel, the signal feeds and the log flow.

5. Show micro-segmentation and east-west traffic

Zero trust is not only about users reaching apps. For service-to-service traffic, draw:

• workload identity (for example, certificates bound to a service account),
• mTLS between services, and the CA or PKI that issues those certificates,
• segmentation policy between workloads, such as Kubernetes NetworkPolicy.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orders-allow-from-checkout
  namespace: orders
spec:
  podSelector:
    matchLabels:
      app: orders
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: checkout
          podSelector:
            matchLabels:
              app: checkout
      ports:
        - protocol: TCP
          port: 8443

A NetworkPolicy works at layers 3 and 4 and only takes effect if your CNI plugin enforces it. It is segmentation, not authentication, so pair it with mTLS and authorization at a PEP in the diagram.

6. Draw secrets and certificates as first-class parts

Show the vault (secrets manager) and the PKI as separate nodes. Draw which workloads fetch which secrets, and with which identity. In NIST's model, session-specific credentials come from the PA, so connect them to the decision flow.

7. Keep the WAF and firewalls, in the right place

Zero trust does not remove the WAF or firewalls. They still filter at the edge and between segments, but they are not the trust decision. Draw them as filters in the path, not as the wall around a trusted zone.

8. Close the loop with logging

Every PEP and firewall should send logs to the SIEM, and analysis should feed back into the Policy Engine. Without that edge, the "continuous" part of continuous verification is missing from the picture.

Common mistakes

• Castle-and-moat, relabeled. A thick outer firewall, a "trusted internal network" and no enforcement between internal services.
• No policy decision flow. The IdP and a gateway are on the canvas, but nothing shows where the decision is made or what it consumes.
• No feedback loop. Logs go nowhere, or the SIEM is a dead end with no edge back to policy.
• Only north-south. Users to apps is covered; service-to-service and admin-to-infrastructure paths are not.
• Zones drawn as trust. Frames for segments are fine, but name them as segments or enforcement domains, not "trusted".

Build it in Archboard

The built-in packs cover the pieces. The Security pack has nodes for the identity provider, WAF, firewall, zero trust gateway, vault and certificates. The Network pack has Internet, DNS, load balancer, and VPC and subnet frames. The Kubernetes pack adds Namespace (drawn as a frame), Service, Pod and NetworkPolicy. Nodes have ports, so each edge attaches to a specific side of a node instead of floating on a shape.

1. Lay out the planes with Frames. Add two Core Frames, "Control plane" and "Data plane". Inside the data plane, add a Frame per segment, for example "Edge", "App segment" and "Data segment". For Kubernetes workloads, use the Namespace node.
2. Add subjects and the edge. Place a Network pack Internet node for users, then a Security pack WAF node, then the zero trust gateway node as the PEP for user access.
3. Add the decision and its inputs. In the control plane frame, place the identity provider node and Core Box nodes labeled "Policy Engine", "Policy Administrator", "Device posture (CDM)", "Threat intel" and "SIEM".
4. Wire the decision flow. Connect the signal sources to the Policy Engine, the Policy Engine to the Policy Administrator, and the Policy Administrator to each PEP. Label the edges.
5. Add east-west paths. Inside each Namespace, add Service and Pod nodes and a NetworkPolicy node. Add a certificate node for the mTLS issuer and a vault node for secrets, with edges to the workloads that use them.
6. Put firewalls between segments. Use the Security pack firewall node where traffic crosses segment frames.
7. Close the loop. Draw edges from each PEP and firewall to the SIEM, and from the SIEM back to the Policy Engine.
8. Write down the assumptions on the canvas. Use a Markdown block for policy rules and session lifetimes, with a fenced YAML code block in it for the NetworkPolicy.

A complete diagram like this can go past the Free plan's 15 diagram nodes per diagram; notes and text count separately, up to 150. On Free, split it into an overview and a Kubernetes detail diagram; Pro removes the node limit. You can export SVG or PNG (watermarked on Free), share a public link, and export the structured JSON to keep next to your infrastructure code.

The free template

The Zero Trust Perimeter example shows users entering through an edge WAF, an IdP / SSO node connected over OIDC, a zero trust gateway, a segment firewall, a secrets vault and an mTLS PKI around a private app. Open it and copy it into your workspace with Use this example. Then extend it with the control plane frame, the signal sources and the logging loop from this post. For the network underneath, see the datacenter network example and the network diagrams use case.

Checklist and FAQ

Before you share the diagram, check that:

• every subject-to-resource path crosses a PEP,
• identity, device, threat and log signals feed the Policy Engine,
• control plane and data plane are visibly separate,
• east-west traffic shows mTLS and segmentation,
• secrets and PKI show who fetches what,
• PEP and firewall logs flow to the SIEM and back into policy.

Is a zero trust architecture diagram just a network diagram? No. A network diagram shows where packets go. A ZTA diagram adds where access is decided, on which signals, and where it is enforced.

Do I still need firewalls in a zero trust design? Yes. Firewalls and WAFs still reduce exposure; they just stop being the reason something is trusted.

Does Kubernetes NetworkPolicy give me zero trust? Not by itself. It gives you L3/L4 segmentation. You still need workload identity, mTLS and authorization at a PEP, plus logging.

Start free — one seat, no credit card.