Resources

Zero Trust Security Architecture Pattern

Pattern Name: Zero Trust Security Architecture Category: Security Architecture / Technology Architecture Complexity: High Stability: High: increasingly the mandated standard for government and regulated industries


Context

Traditional network security architecture operated on a perimeter model: “trust everything inside the network, trust nothing outside it.” The perimeter was defended by firewalls, VPNs, and DMZs. Once an entity was inside the perimeter: whether a user, application, or device: it was assumed to be trustworthy and granted broad access.

Cloud computing, remote working, BYOD, and increasingly sophisticated threat actors have made the perimeter model obsolete. Workloads sit in multiple clouds, users work from anywhere, and adversaries who breach the perimeter (or who operate as trusted insiders) have wide lateral movement capability. The 2020 SolarWinds compromise, where attackers moved freely inside trusted networks for months, exemplified the failure mode at scale.


Problem

How do you design a security architecture that protects resources against internal threats, lateral movement, and credential-based attacks, in an environment where the network perimeter no longer provides a meaningful security boundary?

The core failure of perimeter-based security is the implicit trust granted to everything inside the boundary. Once an attacker obtains valid credentials or compromises an internal system, they can move laterally across the network with minimal resistance. Modern threat actors exploit this routinely. The problem intensifies in hybrid cloud environments where “inside” and “outside” are no longer meaningful concepts.


Solution

Zero Trust is a security model based on one principle: never trust, always verify. Every access request: regardless of network location, user identity, device, or time of day: is treated as potentially hostile and must be authenticated, authorized, and validated before access is granted. Access is granted on a least-privilege basis: the minimum permissions required for the specific task, for the minimum time required.

Core Zero Trust tenets:

Verify explicitly: Always authenticate and authorize based on all available data points: identity, location, device health, service or workload, data classification, and anomalies. Multi-factor authentication (MFA) is the minimum; continuous authentication (risk-based, adaptive) is the target.

Use least-privilege access: Limit user and service access with just-in-time (JIT) and just-enough-access (JEA) policies. Privileged access should require explicit justification and should be time-limited. Service-to-service communications should use scoped, short-lived credentials.

Assume breach: Design as though the network is already compromised. Segment the network so that a breach in one segment cannot spread to others. Encrypt all communications, including internal. Collect and monitor telemetry to detect anomalies. Have incident response plans for containment.

Key architectural components:


Sparx EA Implementation Notes

Element types to use:

Diagram types: ArchiMate Technology Architecture diagram showing the Zero Trust control plane topology; UML Sequence diagram showing the authentication and authorisation flow for a specific access scenario; network segmentation diagram showing microsegment boundaries and permitted traffic flows; ArchiMate Information Structure diagram showing data classification

MDG considerations: Security architecture models require especially rigorous MDG governance: the elements and relationships must consistently represent the actual control environment, not an aspirational state. Define «ZeroTrustComponent» stereotypes for each component type (IdP, PDP, PEP) with mandatory implementation and compliance tagged values. Create a custom «DataClassification» tagged value set applied to Data Object and Application Interface elements. Build a model search that surfaces all interfaces where Confidential or Restricted data crosses a segment boundary: this is a standard compliance audit query that becomes trivially easy via EA GraphLink.

Package structure: A Security Architecture package containing: Identity & Access Management (IdP, MFA, PAM), Policy Infrastructure (PDP, PEP configurations), Network Security (microsegment topology), Endpoint Security, Monitoring & Analytics (SIEM, telemetry), and Data Classification. Maintain a Compliance Mapping sub-package linking security controls to regulatory requirements (ISO 27001, NIST, SOC 2, etc.).

EA GraphLink and AI integration: Security architecture governance generates a steady stream of compliance and risk questions that AI tools can answer from the model. “Which applications are accessible without MFA?”, “What data flows cross the boundary between Confidential and Restricted segments?”, “Which services have direct access to the production database without going through the PEP?”. These are audit questions. With EA GraphLink and an AI interface, security teams can run these queries continuously rather than waiting for quarterly audits. For compliance teams, the ability to ask natural-language questions about the security architecture model: and receive answers grounded in the live repository: dramatically reduces the effort of preparing for audits or responding to security incidents.


When to Use

When Not to Use


Related Patterns

Ready to make your EA investment work harder?

Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.