• Home
  • BVSSH
  • Engineering Enablement
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Practice : Zero Trust Architecture

Purpose and Strategic Importance

Zero Trust Architecture (ZTA) is a security framework that assumes no user, device, or network is inherently trusted. Instead, it continuously verifies identity, enforces least privilege, and validates access based on context - regardless of whether access originates from inside or outside the perimeter.

ZTA significantly reduces attack surfaces, limits blast radius, and improves visibility and control in modern, distributed, cloud-native environments.


Description of the Practice

  • Zero Trust replaces implicit trust (e.g. IP ranges, network zones) with explicit verification.
  • Key principles include: verify explicitly, use least-privileged access, and assume breach.
  • Enablers include identity-aware proxies, policy engines, microsegmentation, continuous authentication, and secure service-to-service communication.
  • Tools and frameworks include BeyondCorp, Istio, SPIFFE/SPIRE, Open Policy Agent, Azure AD Conditional Access, and AWS IAM.

How to Practise It (Playbook)

1. Getting Started

  • Map your current trust boundaries and identify areas of implicit trust.
  • Start by enforcing strong identity for users, devices, and services.
  • Apply least privilege access controls to internal and external systems.
  • Introduce identity-aware access proxies or gateways for sensitive workloads.

2. Scaling and Maturing

  • Adopt context-aware access policies (e.g. device health, geolocation, time of day).
  • Implement mutual TLS (mTLS) between services for authenticated service communication.
  • Replace VPN access with fine-grained, role-based, and per-resource authentication.
  • Integrate Zero Trust controls into CI/CD and deployment pipelines.
  • Audit and continuously evaluate access patterns, policies, and exceptions.

3. Team Behaviours to Encourage

  • Question assumptions - “what are we trusting here and why?”
  • Treat identity and access as core to architecture, not bolt-ons.
  • Regularly review roles, policies, and trust relationships.
  • Collaborate across dev, ops, and security teams to define enforceable policies.

4. Watch Out For…

  • Blind spots in legacy environments or multi-cloud infrastructure.
  • Trust assumptions hardcoded into apps or infrastructure.
  • User frustration from overzealous enforcement - balance security with usability.
  • Lack of visibility into enforcement outcomes and policy violations.

5. Signals of Success

  • All access decisions are logged, traceable, and evaluated against policy.
  • Trust decisions are based on identity and context, not location or network.
  • Lateral movement during breaches is constrained or prevented.
  • Services authenticate and authorise one another explicitly.
  • Security posture improves without reducing delivery velocity.
Associated Standards
  • Access is continuously verified and contextual
  • Credentials are short-lived and auditable
  • Security is considered from the start
  • Sensitive data and credentials are managed securely
  • Teams understand the threat models relevant to their domain
  • Technical debt is actively reduced over time

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering