← Cloud projects

Cloud · Architecture Concept

Zero Trust Architecture Principles

Design access around explicit verification, least privilege, segmentation, strong identity, context, and continuous telemetry instead of trusting network location.

PlatformCloud
DomainSecurity
LevelFoundation
Last reviewed2026-09-19
Use whenCreate a security model that does not automatically trust users, devices, networks, or workloads because of location.
Key decisionIdentity is a primary control plane
Key conceptsVerify explicitly · Least privilege · Assume breach · Strong identity
Cost focusidentity licensing
On this page

Building blocks

Verify explicitlyLeast privilegeAssume breachStrong identitySegmentationDevice/workload contextContinuous monitoring

Design goal

Reduce blast radius and implicit trust by making every access path prove identity, authorization, context, and policy—even inside the network perimeter.

Architecture

Access decisions use identity, context, policy, segmentation, telemetry, and continuous evaluation rather than a trusted network perimeter alone.

Architecture decisions

Decision

Identity is a primary control plane

Why

Strong authentication and authorization should protect access regardless of network location.

Trade-off

Identity-centric access reduces reliance on network location, but makes identity availability, device posture, and authentication policy critical dependencies.

Decision

Assume breach

Why

Limit blast radius through segmentation, least privilege, monitoring, and rapid response.

Trade-off

Segmentation and least privilege reduce blast radius, but increase policy, exception, telemetry, and operational management overhead.

Security

Protect the control and data paths deliberately. Apply MFA or strong authentication, least privilege, segmentation, secure secrets, continuous telemetry, and policy-driven access.

Availability

Design for the failure domain that must be survived. Resilience should include identity, authorization, logging, and security controls so emergency recovery does not require bypassing the security model.

Disaster recovery

Treat regional recovery as a separate operating state. Ensure break-glass access is controlled, tested, monitored, and separated from normal credentials.

Cost drivers

  • identity licensing
  • security telemetry
  • network controls
  • endpoint/workload security

Design assumptions

  • Business and technical identities can be inventoried

Implementation plan

  1. Inventory workforce, workload, device, and service identities together with the resources and data they are allowed to access.
  2. Require strong authentication and least privilege, then reduce standing administrative access with time-bound elevation where practical.
  3. Define trust boundaries and segment access paths so network location alone never grants broad authorization.
  4. Protect secrets and sensitive data with managed identity, vaulting, encryption, and explicit service-to-service authorization where supported.
  5. Centralize identity, access, endpoint, and workload telemetry and continuously test whether policies still enforce the intended trust model.

Validate the design

  • Attempt representative privileged actions and confirm strong authentication and time-bound/least-privilege controls are enforced.
  • Test segmentation by attempting access across trust boundaries that should be denied.
  • Run an identity-compromise scenario and verify detection, containment, credential revocation, and investigation paths.
  • Review telemetry coverage to confirm critical identity, device, network, and workload decisions can be reconstructed after an incident.

Architecture basis

Continue a learning path