Zero Trust Architecture in ArchiMate: Viewpoints and Modeling Patterns

ArchiMate modeling example in Sparx Enterprise Architect

Introduction

Zero Trust Architecture (ZTA) is often described with slogans—“never trust, always verify”—and vendor diagrams full of boxes called “Zscaler” or “Conditional Access.” That language is useful for awareness, but it’s not architecture. Enterprise Architecture teams need a way to represent Zero Trust as a system of capabilities, services, controls, and deployment patterns that can be reviewed, governed, and improved over time.

This is where ArchiMate is uniquely strong. ArchiMate was designed to connect strategy, business capabilities, application services, technology services, and implementation concerns into a single coherent language. Zero Trust is inherently cross-layer: it spans business governance, identity and access management, application-level enforcement, network segmentation, data protection, and continuous monitoring. A single-layer diagram is never enough; you need viewpoints that match stakeholder questions.

This post is a practitioner’s guide to modeling Zero Trust with ArchiMate in 2026. You’ll get:

A clear mapping of Zero Trust concepts into ArchiMate elements and relationships
Seven stakeholder-ready viewpoints (executive to engineer)
Four reusable modeling patterns that scale across initiatives
Practical modeling conventions: properties, naming, and governance checks
Common anti-patterns that make Zero Trust models useless

The goal is not to replace security frameworks (NIST, vendor reference architectures, internal controls). The goal is to make them architecturally visible: so business and IT leaders can understand what is being built, where enforcement happens, how trust boundaries work, and what is still missing.

1) Zero Trust in 2026: what architects should model

In most organizations, Zero Trust is adopted for the same underlying reasons:

Hybrid reality: users work from everywhere, applications run across cloud and data center, and partners integrate through APIs.
Identity is constantly attacked: credential theft and session hijacking are routine; perimeter defenses are no longer enough.
Lateral movement is the real breach amplifier: once an attacker gets a foothold, internal trust relationships allow rapid expansion.
Regulatory pressure: data access, auditability, and control evidence must be demonstrable.

Architecturally, Zero Trust is a set of design commitments:

No implicit trust: being “inside” does not grant access.
Explicit verification: access decisions use identity + context + policy.
Least privilege: minimum permissions, time-bound, scope-bound.
Assume breach: design for containment, detection, and response.
Continuous evaluation: authorization is not a one-time event.

What should you model as an Enterprise Architect? Not vendor products. Model the functions and control points:

Policy Decision Point (PDP): evaluates policy and returns allow/deny/obligations.
Policy Enforcement Point (PEP): enforces the decision at runtime (gateway, proxy, sidecar).
Policy Information Point (PIP): provides context (device posture, risk score, HR attributes, data classification).
Identity Provider (IdP): authenticates and issues tokens/claims.
Telemetry pipeline: logs, signals, detections, and response actions.
Trust boundaries and segmentation: where movement is constrained.

Once these are modeled as components/services, you can reason about completeness: Do we have enforcement everywhere? Is the PDP centralized or duplicated? What context is actually used? Where do we have gaps? Which controls apply to which business services?

2) Mapping Zero Trust concepts into ArchiMate

A good ArchiMate model makes it easy to keep “concept drift” under control. Zero Trust terms mean different things across teams. The best way to stabilize them is to map them to a consistent ArchiMate vocabulary.

2.1 Business layer mapping: Zero Trust as governance and capability

At business level, Zero Trust is not technology—it’s a capability to reduce risk while enabling modern ways of working. The most common business-layer elements are:

Capability: Zero Trust Security, Identity Governance, Security Monitoring, Data Governance
Requirement: “All access requests must be explicitly authorized”
Constraint: “Least privilege by default” / “No shared accounts” / “No direct DB access”
Outcome: reduced breach impact, improved auditability, faster secure onboarding
Business Service: Secure Access Service, Secure API Consumption, Secure Data Access

Recommended relationships:

Requirement influences Capability (or is realized by business processes)
Capability realizes Business Service
Outcome is influenced by Capability improvements (use Motivation elements if your metamodel includes them)

Practical tip: Don’t over-model “business process” unless you truly have a security operating process that stakeholders care about (e.g., access request + approval + recertification). Many teams get better value by focusing on capabilities and services first, then adding process only where it matters for audit and governance.

2.2 Application layer mapping: where decisions and enforcement happen

The application layer is where Zero Trust becomes concrete. Here, you model:

Application Component: Identity Provider, MFA Service, Policy Engine (PDP), API Gateway (PEP), Service Mesh Policy Controller, Token Service
Application Service: Authentication Service, Authorization Service, Policy Decision Service, Token Issuance, Risk Scoring
Application Interface: OAuth/OIDC endpoints, token introspection endpoint, policy decision API
Data Object: Access Token, Claims, Device Posture, Risk Score, Policy Bundle

Recommended modeling pattern:

Represent PEP and PDP as Application Components and expose decision/enforcement APIs as Application Services.
Represent context sources as Application Services producing Data Objects (risk score, posture).
Represent policies as a Data Object or Artifact (depending on whether you treat them as data or deployment deliverables).

Why application layer matters: Many organizations claim “Zero Trust,” but enforcement happens only at the perimeter (VPN replacement). A correct model makes the enforcement points visible: API gateways, service mesh sidecars, identity-aware proxies, and data access layers. It becomes obvious where enforcement is missing (e.g., internal service-to-service traffic without policy).

2.3 Technology layer mapping: segmentation, secure connectivity, and telemetry

The technology layer expresses the infrastructure reality: networks, clusters, endpoints, and the technology services that implement segmentation and secure communication. Typical elements include:

Node: Kubernetes Cluster, Secure Zone, Workload Node, Zero Trust Gateway, Bastion Host
System Software: Service Mesh, Endpoint Protection Platform (EPP/EDR), Log Collector, Policy Agent
Technology Service: mTLS Transport, Secure Network Access, Device Compliance, Secure DNS, Encrypted Storage
Artifact: policy agent deployment, sidecar configuration, certificate bundle

Recommended relationships:

Application Components are deployed on Nodes (Deployment relationship) or realized by System Software.
Technology Services are serving Application Components (e.g., mTLS serving service mesh enforcement).
Telemetry services access logs/metrics events as Data Objects; they can also influence security capabilities in the business layer if you model feedback loops.

3) The viewpoints: seven diagrams that make Zero Trust understandable

Zero Trust stakeholders ask different questions. Your job is to provide viewpoints that answer them clearly, without mixing everything into one unreadable mega-diagram. Below are seven viewpoints that work well in practice. Use them as a “minimum publication set” for a Zero Trust program.

Viewpoint VP1 — Zero Trust Capability Map (Executive)

Audience: CIO, CISO, executives, transformation leads.

Question answered: “What are we investing in, and what is the scope of Zero Trust?”

This viewpoint expresses Zero Trust as a set of capabilities that are understandable without security jargon. A robust capability map usually includes:

Identity & Access Governance (IGA)
Authentication & Conditional Access
Authorization & Policy Management
Secure Application Access (SSO, token-based access)
Secure Network Access (ZTNA, segmentation)
Workload Identity & Service-to-Service Trust
Data Protection & Data Access Control
Continuous Monitoring & Incident Response

Modeling tip: Don’t mix product names here. Keep it stable across years. This becomes your architecture “map” for strategy and roadmaps. If a capability is missing, you have a clear gap. If multiple tools overlap, you have a rationalization conversation.

Viewpoint VP2 — Secure Access Service (Business-to-Application)

Audience: business stakeholders, product owners, security governance, solution architects.

Question answered: “How do business users and partners access business services securely?”

This is the “translation” diagram. It connects business services (what people want) to application services (how it is provided), and shows which security capabilities are involved. Good contents include:

Business Actor: Employee, Partner, Customer, Administrator
Business Service: “Access Customer Data”, “Submit Orders”, “Approve Payments”
Application Service: Authentication, Authorization, Token Issuance
Requirements/Constraints: MFA, device compliance, least privilege

Key pattern: show the access flow as a service, not as “network.” Business people care about what they can do and what must be true for access. This viewpoint prevents Zero Trust from being perceived as an IT-only barrier.

Viewpoint VP3 — Identity-Centric Access Flow

Audience: security architects, IAM teams, solution architects.

Question answered: “What actually happens when a user requests access?”

This viewpoint should tell a clear story:

User/device attempts to access an application or API.
Identity Provider authenticates (MFA, device signals, risk evaluation).
Tokens/claims are issued (OIDC/OAuth style) with attributes.
Policy engine evaluates context (PDP) and returns a decision.
Enforcement point (PEP) allows/denies, and logs the decision.

ArchiMate modeling guidance:

Represent token/claims as Data Objects.
Represent identity provider and policy engine as Application Components.
Represent the runtime decision as an Application Service with a Serving relationship to enforcement.
Represent context sources (device posture, HR attributes) as Application Services or external systems.

Practical value: This diagram prevents the most common Zero Trust confusion: teams think identity is only login, not continuous authorization. When you show the policy engine and context evaluation explicitly, the “continuous” nature becomes visible.

Viewpoint VP4 — Policy Enforcement Architecture

Audience: platform teams, API teams, security engineering.

Question answered: “Where are we enforcing policies, and is coverage complete?”

This viewpoint is the most operationally important for a Zero Trust rollout. Many programs define policies but fail to place enforcement at the correct points. A mature model typically shows multiple PEP types:

API Gateway enforcement for north-south traffic
Service Mesh sidecar enforcement for east-west traffic
Identity-aware proxy for legacy apps
Data access layer enforcement for sensitive datasets

Also show the shared services:

Policy Decision Service (PDP)
Policy Administration (where rules are authored and deployed)
Telemetry/logging service and SIEM pipeline

Modeling tip: Use separate relationships for “decision request” vs “telemetry export.” Otherwise your diagram becomes ambiguous. If you want to be precise, you can add Application Interfaces for the PDP API and for telemetry export.

Viewpoint VP5 — Micro-Segmentation (Technology)

Audience: infrastructure/network/cloud teams, security architects.

Question answered: “How do we prevent lateral movement and constrain blast radius?”

Micro-segmentation is often misunderstood as “more firewall rules.” In Zero Trust, segmentation is an architectural concept: services are grouped, traffic is explicitly allowed, and identity-based policies can apply inside the infrastructure. This viewpoint should show:

Zones (or domains) as Nodes or Groupings
Connectivity services (mTLS, secure tunnels, service mesh)
Gateways or policy enforcement nodes between zones
Key workloads and where they are deployed

Practical pattern: Use this viewpoint to show your “trust boundary map.” If a system sits in a zone, it inherits constraints. If it needs cross-zone access, you model the explicit path (and where enforcement occurs).

Viewpoint VP6 — Data Protection & Access Control

Audience: data owners, data architects, security governance, auditors.

Question answered: “How is sensitive data protected and accessed in a Zero Trust model?”

Zero Trust is ultimately about data. If you secure identity and networks but allow uncontrolled data access, you’re still exposed. This viewpoint should model:

Data Objects: Customer Data, Payment Data, HR Data (and classifications)
Application Services: Data Access API, Data Masking, Encryption, Tokenization
Policy evaluation (PDP) connected to data access decisions
Constraints: “No direct DB access,” “mask PII unless privileged,” “log all reads”

Modeling tip: Avoid drawing databases as the thing people access. Model “data access” as an application service that mediates access, because that’s where policy enforcement can realistically be implemented. Databases can remain as Technology/System Software, but the control point should be explicit.

Viewpoint VP7 — Continuous Verification & Monitoring

Audience: SOC, security engineers, compliance, operations.

Question answered: “How do we detect, respond, and adapt policies as risk changes?”

One of the most important differences between “traditional IAM” and Zero Trust is continuous evaluation. This viewpoint should show:

Telemetry sources (PEP logs, endpoint signals, cloud audit logs)
Aggregation and analysis (SIEM, detection engines)
Risk scoring and posture services (PIP)
Feedback into policy decisions (PDP) or policy updates (administration)
Response actions (session revocation, step-up authentication, access removal)

Practical value: This diagram is powerful for auditors. It shows not only controls, but also the evidence chain: how access decisions are logged and how detections can change access in near-real time.

4) Reusable modeling patterns for Zero Trust

Patterns are what make architecture scalable. If each initiative creates its own “unique” security model, your organization will end up with incompatible implementations. The patterns below are reusable templates. In ArchiMate, represent the template as a combination of elements, relationships, and viewpoint rules (what must be included).

Pattern A — Identity Gateway Pattern

Use when: you have web apps, SaaS, or portals where centralized identity and conditional access is the primary control.

Key elements: Identity Provider, MFA, Risk/Device posture service, Token service, PEP (proxy/gateway), Target application.

Modeling guidance: Use an Application Component for IdP and PEP, Application Services for auth/token, Data Objects for tokens/claims. If you want to show step-up authentication, model it as a Triggering relationship from risk evaluation to MFA service.

Pattern B — API Zero Trust Pattern

Use when: you expose APIs to internal teams or partners, and you need strong policy control and auditability.

Key idea: The API gateway is the PEP. It validates token claims, calls PDP for fine-grained decisions, and produces telemetry. This pattern is where least privilege becomes concrete through scopes, claims, and contextual decisions.

What to model: The API itself as an Application Service and Interface; the gateway as an Application Component; policies and scopes as Data Objects; telemetry export as a flow to monitoring.

Pattern C — Service Mesh Enforcement Pattern

Use when: you run microservices (especially Kubernetes) and want Zero Trust inside the cluster. Without this, attackers who compromise one service can pivot laterally.

Modeling guidance: Show the sidecar proxy (System Software) and the mesh control plane; show mTLS as Technology Service; show policy decisions coming from PDP; show telemetry flowing to monitoring.

Practical note: Many organizations implement mesh mTLS but not authorization policies. Your model should separate “encrypted transport” from “authorized access.” Encryption reduces eavesdropping; authorization reduces lateral movement. Both are needed for Zero Trust.

Pattern D — Data Access Control Pattern

Use when: you have sensitive data domains and want to enforce policy at the data access layer, not by trusting applications.

Modeling guidance: Data Access Service as an Application Service; masking/tokenization as application services; policies and classifications as Data Objects; audit logging as flows to monitoring.

Why it matters: This pattern is essential for regulated data (PII, payment, health). It turns “data governance” from a policy statement into a runtime control design.

5) Modeling conventions that make Zero Trust models maintainable

Zero Trust models often fail because they look good once but cannot be maintained. Here are conventions that help models stay alive.

5.1 Use a consistent element taxonomy

Capabilities for business/security outcomes (stable vocabulary)
Services for what is delivered (auth service, authorization service, secure access)
Components for the “things” that implement services (IdP, gateway, policy engine)
Data Objects for tokens, claims, risk scores, policies, logs
Nodes/System Software for deployment and runtime enforcement (clusters, proxies, mesh)

5.2 Add properties that enable governance

Add a minimal property set to key elements. For example:

Owner (team accountable)
Control Type (Prevent / Detect / Respond)
Assurance Level (Low/Medium/High)
Data Classification (Public/Internal/Confidential/Restricted)
Enforcement Coverage (Planned/Partial/Complete)

These properties unlock portfolio views, heatmaps, and compliance evidence. They also make it possible to build dashboards from exports.

5.3 Keep viewpoints small and publish on a rhythm

Use a limited viewpoint set (VP1–VP7) and publish updates monthly or quarterly. Stakeholders trust architecture that appears consistently. If you publish a large “perfect” model once per year, it won’t be used.

5.4 Separate principles from implementation choices

Model principles and control points first (PDP/PEP/PIP, segmentation, monitoring). Then map vendor products as realizations later if needed. This avoids vendor lock-in in your model and keeps it conceptually stable.

6) Common anti-patterns (and how to avoid them)

Anti-pattern 1: Vendor diagrams with ArchiMate symbols

If your model is just product boxes with ArchiMate shapes, you don’t have architecture—you have a procurement storyboard. Use vendor names only at realization level (implementation mapping), not as the primary conceptual model.

Anti-pattern 2: One “everything” diagram

Zero Trust touches everything. That’s why you need viewpoints. The overview (VP0) is allowed, but it should remain an overview. Use VP1–VP7 for stakeholder-specific depth.

Anti-pattern 3: No enforcement points

If you can’t point at the PEP on each access path, you don’t have Zero Trust. Make enforcement explicit: gateways, proxies, sidecars, and data access services.

Anti-pattern 4: Identity treated as “login only”

Zero Trust is continuous evaluation. Model risk scoring, device posture, session revocation, and policy feedback loops. If your model stops at authentication, it will mislead stakeholders about actual security posture.

7) A practical modeling roadmap for a Zero Trust program

Finally, here’s a pragmatic roadmap that matches how Zero Trust is typically delivered.

Phase 1 — Foundation (0–3 months)

Publish VP1 capability map and VP0 overview
Model identity platform (VP3) and initial access service (VP2)
Define policies and property conventions

Phase 2 — Enforcement coverage (3–9 months)

Establish API gateway enforcement pattern (VP4 + Pattern B)
Introduce segmentation and mesh patterns where relevant (VP5 + Pattern C)
Publish data protection pattern for sensitive domains (VP6 + Pattern D)

Phase 3 — Continuous verification (9–18 months)

Implement monitoring + risk feedback (VP7)
Define quality gates (validation checks) and publishing rhythm
Produce compliance evidence views and operational dashboards

Appendix A — Zero Trust “concept to ArchiMate” mapping table

The table below is intentionally practical: it is not a theoretical mapping of every possible term. It focuses on the terms you actually hear in Zero Trust programs and shows the most useful ArchiMate representation for each. Use it as a consistent vocabulary in your repository.

Zero Trust concept	ArchiMate element(s)	Notes for modeling
Policy Decision Point (PDP)	Application Component + Application Service	Model the engine as a component; expose “Policy Decision Service” as an application service.
Policy Enforcement Point (PEP)	Application Component (Gateway/Proxy) or System Software (Sidecar)	Choose based on where it lives: gateway is application-level; sidecar is system software on a node.
Policy Information Point (PIP)	Application Service + Data Object	Risk score, device posture, HR attributes—model as data produced by services.
Identity Provider (IdP)	Application Component + Application Service	Authentication and token issuance are services; IdP is the component providing them.
Conditional Access	Requirement/Constraint + Application Service	Model the rule as a requirement/constraint and show evaluation through a decision service.
Access Token / Claims	Data Object	Also useful as a “contract” between IdP and applications for authorization decisions.
mTLS between services	Technology Service	Represent secure transport as a service that serves application components.
Micro-segmentation	Nodes/Groupings + Technology Services	Use zones or domains as groupings; show explicit allowed connectivity paths.
Device compliance / posture	Application Service + Data Object	Produced by endpoint management or EDR; consumed by PDP or IdP.
SIEM / detection analytics	Application Component + Application Service	Show ingestion, correlation, and alerting; connect to response actions.
Session revocation / step-up auth	Application Service + Triggering relationship	Model as a response service triggered by risk events or policy violations.
Data masking / tokenization	Application Service + Data Object	Make it explicit in VP6; it’s often a missing control in real implementations.

Appendix B — Modeling recipes (copy-paste patterns for your repository)

Below are “recipes” you can use when building your model. They are intentionally concrete. If you apply the same recipe across initiatives, your architecture becomes comparable and governable.

Recipe 1: Model a Secure Access Path to a business service

Create a Business Service (e.g., “Approve Payment”).
Create an Application Service that realizes it (e.g., “Payment Approval API”).
Add Identity Provider and Policy Engine as Application Components.
Add a PEP (API Gateway or Proxy) and connect it to the application service.
Represent tokens/claims as Data Objects flowing from IdP to PEP/app.
Add telemetry flows from PEP to monitoring services.

Recipe 2: Model micro-segmentation for a platform

Create Nodes for zones (e.g., “DMZ”, “Workload Zone”, “Data Zone”).
Deploy key Application Components to the correct zone nodes.
Add Technology Services for allowed connectivity (e.g., “mTLS service mesh transport”).
Show explicit gateway nodes or policy enforcement components between zones.
Add constraints: which zones are allowed to connect and under what conditions.

Recipe 3: Model continuous verification (risk feedback loop)

Create a Monitoring Component (SIEM) and a Risk Scoring Service.
Connect telemetry sources: PEP logs, endpoint events, cloud audit logs.
Represent detections as events/data objects that trigger policy changes or response actions.
Model response services: session revocation, step-up authentication, access removal.
Connect the response services back to IdP/PDP to show the closed loop.

Appendix C — Governance checks you can automate

Once your Zero Trust model exists, you can enforce quality with simple checks (manually or via automation). Here are checks that catch the most common issues:

Every “Critical Business Service” must have an explicit PEP. If a service is critical, access must be mediated.
Every PEP must log to monitoring. If enforcement is not logged, you cannot prove control or detect abuse.
Every sensitive Data Object must be accessed through a Data Access Service. No direct access paths.
Every cross-zone connection must pass through an enforcement component or an explicit allowed connectivity service.
PDP must consume at least one context source (PIP) for privileged access. Otherwise “Zero Trust” is just SSO.

Even if you do not automate these with scripts yet, documenting them as architectural rules changes behavior: teams start modeling with the checks in mind, and gaps become visible early.

Appendix D — Optional jArchi automation ideas for Zero Trust repositories

If you use Archi with jArchi, Zero Trust models become even more maintainable. Examples of useful automations include:

Generate VP2 secure access views for each business service tagged as “Critical.”
Create standard PEP/PDP/PIP scaffolding for new domain architectures, so teams start from the same baseline.
Validate enforcement coverage: flag business services without PEP relationships.
Export policy coverage matrices (JSON/CSV) for dashboards: capability ↔ control ↔ enforcement status.
Apply consistent styling so PEP/PDP/PIP are instantly recognizable in every view.

The key idea is the same as software engineering: encode the boring, repeatable parts so architects can focus on decisions and trade-offs.

Conclusion

Zero Trust becomes real when it becomes architecture: a set of capabilities, services, control points, and patterns that are visible and governable. ArchiMate is one of the best languages for this because it connects business intent to technical enforcement across layers.

If you publish the viewpoints in this post and reuse the patterns consistently, you’ll get a Zero Trust architecture that stakeholders can understand, engineers can implement, and auditors can verify. More importantly, you’ll have a living model that can evolve as your organization changes—without rewriting security strategy every year.

Tags: Zero Trust Architecture, ArchiMate, Security Architecture, Identity Governance, Policy Enforcement Point, Micro-segmentation, Service Mesh, API Security, Data Protection, Continuous Monitoring, NILUS TRAINING & CONSULTING

If you’d like hands-on training tailored to your team (Sparx Enterprise Architect, ArchiMate, TOGAF, BPMN, SysML, or the Archi tool), you can reach us via our contact page.