Zero Trust Architecture v1

The one-sentence definition

Zero Trust means no user, device, workload, or network location receives implicit trust. Every access request must be authenticated, authorized for its specific resource and action, and evaluated using relevant context and risk. Access is limited, observable, and revocable.

Architect interview mindset

Don’t start by naming products. Start with assets, trust boundaries, identities, policies, enforcement points, failure modes, and rollout. Then choose technologies that implement those controls.

1. Head First: why Zero Trust exists

Imagine a company with a public API, internal microservices, a database, Kafka, and an admin portal. Everything sits inside a private VPC.

An engineer says: “It’s inside our network, so it’s trusted.”

Now imagine an attacker steals a developer’s credentials, compromises one container, or exploits a vulnerable service. If the network is treated as trusted, the attacker may move laterally from that first foothold to databases, queues, and administrative endpoints.

Zero Trust changes the question from:

“Is this request coming from the right network?”

to:

“What is the identity making this request, what resource and action are requested, what evidence supports trust, which policy applies, and where will that decision be enforced?”

A private network, firewall, VPN, or WAF can still be useful. Zero Trust does not mean removing every perimeter control. It means the perimeter alone is not sufficient authorization.

The core principles

1. Verify explicitly: authenticate the user/workload and evaluate relevant context.
2. Use least privilege: grant only the permissions needed, for the required resource, action, and duration.
3. Assume breach: design to contain compromise, detect abuse, and revoke access quickly.
4. Protect resources, not just network segments: data, applications, services, identities, and workflows are the focus.
5. Make access decisions observable and revisitable: record decisions and reevaluate access when important risk signals change.

2. The architecture at a glance

flowchart TB
    U[User / Device] --> EDGE[Edge: WAF, DDoS, API Gateway]
    EDGE --> PEP1[Policy Enforcement Point]
    PEP1 --> APP[Protected Application / API]

    APP --> PEP2[Service-to-service Enforcement]
    PEP2 --> SVC[Order / Payment / Customer Service]

    SVC --> PEP3[Data Access Enforcement]
    PEP3 --> DB[(Database)]
    SVC --> PEP4[Messaging Enforcement]
    PEP4 --> K[Kafka]

    IDP[Identity Provider / MFA] --> PDP
    DEVICE[Device posture / endpoint signals] --> PIP
    THREAT[Threat intelligence / risk signals] --> PIP
    INVENTORY[Asset inventory / workload identity] --> PIP

    PDP[Policy Decision Point] --> PE[Policy Engine]
    PE --> PA[Policy Administrator]
    PA --> PEP1
    PA --> PEP2
    PA --> PEP3
    PA --> PEP4
    PIP[Policy Information Points] --> PE

    PEP1 --> AUDIT[Security telemetry / SIEM]
    PEP2 --> AUDIT
    PEP3 --> AUDIT
    PEP4 --> AUDIT

This is a logical diagram, not a requirement to build one giant central service. The policy decision function can be centralized, federated, or partly distributed. Enforcement should happen close enough to each protected resource that a missed gateway or lateral network path does not bypass authorization.

3. The four core components: PE, PA, PDP, PEP, PIP

These names come from the NIST Zero Trust Architecture model.

Component	Meaning	Job
Policy Engine (PE)	Decision logic	Evaluates policy and context to permit, deny, or revoke access
Policy Administrator (PA)	Decision executor	Carries out the decision, such as establishing or terminating an access path or issuing session credentials
Policy Decision Point (PDP)	PE + PA functions	Logical decision-making side of the architecture
Policy Enforcement Point (PEP)	Enforcement at the resource boundary	Intercepts access, enforces allow/deny, monitors, and may terminate access
Policy Information Point (PIP)	Context source	Supplies identity, device posture, asset, threat, and other policy inputs

A useful analogy

• The PE is the person deciding whether you may enter.
• The PA communicates and implements that decision.
• The PEP is the guard at the actual door.
• The PIP provides the guard with current evidence: badge status, access list, device health, and risk alerts.

A policy decision without enforcement is just advice. An enforcement point without a good policy can block the wrong traffic or allow too much.

Avoid a single central bottleneck

Central policy is useful for consistency, but a remote policy call on every packet can add latency and create an availability dependency. Many designs distribute policy decisions or cache short-lived, bounded decisions at enforcement points. Define cache expiry, revocation behavior, and what happens when policy services are unavailable.

4. Define the subjects, resources, actions, and context

Before designing controls, enumerate what can request access and what is being protected.

Subjects (who or what is asking?)

• Human users: employee, customer, administrator, contractor.
• Devices: managed laptop, mobile device, server.
• Workloads: order-service, batch job, CI/CD runner, Kafka consumer.
• Third parties: payment processor, partner API, SaaS integration.

Resources (what is being protected?)

• APIs and business operations.
• Individual records, tenants, files, and object-storage keys.
• Databases, Kafka topics and consumer groups.
• Secrets, encryption keys, deployment pipelines, admin consoles.
• Production environments and operational controls.

Actions (what does the subject want to do?)

read, create, update, delete, approve-payment, publish-event, consume-topic, rotate-key, deploy-production.

Context (what evidence influences the decision?)

• Identity and authentication strength.
• Roles, scopes, tenant, ownership, and delegated permissions.
• Device compliance and endpoint security posture.
• Workload identity, environment, and expected caller.
• Requested resource, action, data classification, and time.
• Network location as one signal—not as proof of trust.
• Risk signals such as unusual behavior, leaked credentials, or active incident.
• Freshness of credentials and policy.

5. The request decision flow

Flowchart :

flowchart TD
    A["Subject requests a resource/action"]
    B["PEP intercepts the request"]
    C["Validate identity and credentials"]
    D["Evaluate policy and context"]
    E{"Access permitted?"}
    F["PEP allows the operation"]
    G["PEP denies the operation"]
    H["Record decision safely"]
    I["Monitor for risk changes"]
    J["Reevaluate or revoke access"]

    A --> B
    B --> C
    C --> D
    D --> E
    E -- Yes --> F
    E -- No --> G
    F --> H
    G --> H
    H --> I
    I --> J

Sequence Diagram :

sequenceDiagram
    participant S as Subject
    participant PEP as Enforcement Point
    participant ID as Identity Provider
    participant PDP as Policy Decision Point
    participant PIP as Context Sources
    participant R as Resource

    S->>PEP: Request resource + action + credential
    PEP->>ID: Validate identity / token / certificate
    ID-->>PEP: Identity claims
    PEP->>PDP: Subject, action, resource, context
    PDP->>PIP: Obtain policy attributes / risk signals
    PIP-->>PDP: Context data
    PDP->>PDP: Evaluate policy (default deny)
    PDP-->>PEP: Decision + constraints
    alt Permit
        PEP->>R: Forward authorized request
        R-->>PEP: Response
        PEP-->>S: Response
    else Deny
        PEP-->>S: Denied
    end

Not every request needs a synchronous round trip to a central policy service. The invariant is that the resource is protected by an enforcement point applying a current, bounded authorization decision.

Example policy

Allow order-service to read only the order records belonging to the authenticated tenant. Allow it to publish to orders.created but not to read payments.*. Require a valid workload identity and TLS. Deny by default. Log policy decisions without logging sensitive payloads.

This is much stronger than “allow anything from subnet 10.0.0.0/16.”

6. Identity: users, devices, and workloads

Human identity

Use a trusted identity provider (IdP), strong authentication, MFA or passkeys where appropriate, lifecycle management, and role/group/attribute-based access. Privileged actions may require stronger authentication or approval.

Device identity and posture

For enterprise endpoints, evaluate device identity and posture where appropriate: managed status, supported OS, patch state, disk encryption, endpoint protection, and compliance. A valid user on a compromised or noncompliant device may require denial, restricted access, or step-up authentication.

For customer-facing public apps, enterprise device management may not be feasible. Use risk-appropriate controls instead; do not assume every customer has a corporate-managed device.

Workload identity

Every service or job needs a distinct identity. Avoid a single shared credential used by every microservice.

Possible approaches include:

• short-lived workload credentials from the cloud platform;
• service-account identities;
• certificate identities with managed issuance and rotation;
• SPIFFE/SPIRE-style workload identity in suitable environments;
• OAuth client credentials or token exchange where appropriate.

A service identity says which workload is calling. It does not automatically grant permission to every API or topic.

Least privilege examples

• order-service can write orders.created, but cannot read payment card data.
• invoice-worker can read invoice.requested and write invoice.completed.
• a CI runner can deploy to staging, but production deployment requires a separate identity and approval.
• a support user can view limited customer metadata, but cannot export all records by default.

7. Authentication is not authorization

Authentication establishes identity. Authorization evaluates whether that identity may perform this action on this resource.

A valid JWT, mTLS certificate, VPN session, or login does not imply universal access.

Use the smallest meaningful permission:

• resource: orders/123;
• action: read;
• subject: customer-456;
• tenant: tenant-A;
• relationship: order belongs to customer-456;
• context: account is active, token not expired, risk policy passes.

Enforce object-level authorization in the application or a trusted policy layer. Random identifiers are not authorization; a user may still guess, obtain, or leak another valid identifier.

8. Where enforcement belongs

A mature design uses multiple enforcement points because each layer protects a different boundary.

Boundary	Enforcement examples	What it protects
Internet → edge	WAF, DDoS controls, gateway authentication/rate limits	Public entry points and abuse
User → application	OIDC/session validation, device/context policy, application authorization	User actions and records
Service → service	mTLS/workload identity, service authorization, mesh/API policy	Lateral movement and spoofed workloads
Service → database	Database identity, least-privilege grants, tenant/data access checks	Stored records
Producer/consumer → Kafka	TLS, SASL/mTLS/OAuth, topic/group ACLs and quotas	Event streams and consumer groups
Workload → secrets/KMS	Workload identity, resource policy, narrowly scoped key/secret access	Credentials and cryptographic keys
Admin → production	Strong MFA, privileged access workflow, just-in-time grants, audit	High-impact operations

A gateway alone is insufficient if services can be reached directly or if internal service calls bypass authorization. A service mesh alone is insufficient if business authorization and tenant ownership are not enforced.

9. Service-to-service Zero Trust and mTLS

For synchronous microservice calls, use authenticated workload identity plus authorization.

A common pattern is:

1. a workload receives a short-lived identity credential;
2. the client and server establish TLS, often mTLS for workload-to-workload identity;
3. the receiving service validates the peer identity;
4. the receiving service or enforcement proxy evaluates whether that identity may invoke the operation;
5. authorization is scoped to service/action/resource and logged;
6. certificates/credentials rotate automatically.

sequenceDiagram
    participant O as order-service
    participant CA as Workload identity / CA
    participant P as Proxy or payment-service
    O->>CA: Obtain short-lived workload identity
    CA-->>O: Certificate / credential
    O->>P: HTTPS request with mTLS
    P->>P: Validate certificate, identity, and trust chain
    P->>P: Authorize order-service for this operation
    alt Allowed
        P-->>O: Response
    else Denied
        P-->>O: Reject and audit
    end

mTLS gives transport encryption and peer authentication. It does not automatically define business permissions, prevent a compromised authorized service from abusing its own rights, or secure data stored on disk.

Service mesh: when is it useful?

A service mesh can standardize mTLS, workload identity, service-level policy, telemetry, and certificate rotation across many services. It also adds proxies, configuration, resource usage, operational complexity, and another failure/debugging surface.

Use it when the number and variety of workloads justify the platform cost. For a small system, managed platform identities and carefully configured TLS/authentication may be simpler.

10. Data security and cryptography inside Zero Trust

Zero Trust is not a replacement for cryptography; it determines who can access what, while cryptography protects data and establishes trust.

Need	Typical control	What it does not solve by itself
Protect data in transit	TLS 1.2/1.3, mTLS where appropriate	Application authorization
Protect stored data	Database/storage encryption, KMS, envelope encryption	A compromised authorized app reading plaintext
Store passwords	Adaptive password hashing (e.g. Argon2id) with unique salt	Phishing or stolen sessions
Verify message integrity with shared secret	HMAC	Confidentiality
Verify signer	Digital signature and trusted public key	Trust if public key identity is unverified
Authenticate a server	Validated certificate chain and hostname	Permission to call every endpoint
Limit access to encryption keys	KMS/HSM policy and audit	Incorrect application-level data access

Zero Trust does not mean “encrypt everything with RSA.” Use modern TLS for transport, authenticated symmetric encryption for bulk data, password-specific hashing for passwords, and managed key lifecycle controls.

11. REST/API design under Zero Trust

Every request should be treated as a candidate for evaluation, not trusted merely because it came from an internal frontend or subnet.

Checklist:

• use HTTPS and validate certificates;
• validate session/token signature, issuer, audience, expiry, and permitted algorithm;
• check authorization for every action and object;
• validate inputs and enforce business invariants server-side;
• rate-limit sensitive endpoints and cap body size/timeouts;
• protect browser sessions against CSRF and XSS as applicable;
• use parameterized queries and safe output handling;
• prevent SSRF, path traversal, mass assignment, and unsafe deserialization;
• avoid credentials and sensitive payloads in URLs/logs/traces;
• log actor, action, target, result, and correlation ID with safe redaction;
• make revocation and permission changes propagate within a defined time.

Token guidance

A signed JWT is generally readable; its signature does not encrypt its claims. Validate tokens against a trusted issuer and audience, and don’t use possession of a valid token as the only authorization check. Use short-lived credentials where appropriate and plan how compromised credentials are revoked or invalidated.

12. Kafka under Zero Trust

Kafka brokers should not trust a producer simply because it is in a private subnet.

Apply separate controls:

• TLS: protects traffic in transit and validates peers.
• Authentication: mTLS, SASL/SCRAM, OAuth-based authentication, or another supported mechanism.
• Authorization: ACLs or the configured authorizer for topics, consumer groups, and administrative operations.
• Quotas: limit resource use and reduce abuse.
• Data governance: minimize sensitive event payloads, restrict retention, protect broker disks and backups, and consider application-level encryption for especially sensitive fields.
• Secrets lifecycle: store credentials securely, rotate them, and monitor access.

Example:

• order-service may produce to orders.created.
• fulfillment-worker may consume orders.created with a specific consumer group.
• neither gets cluster-admin privileges.
• payment-service cannot read all customer topics just because it can authenticate.

Kafka ACLs secure broker operations. They do not replace application authorization for business actions or data minimization in message payloads.

13. Database, storage, and cloud access

• Give each workload its own identity and minimum database permissions.
• Separate read/write privileges where useful; avoid shared admin credentials.
• Enforce tenant and record access in the application/data access layer.
• Encrypt databases, snapshots, backups, and object storage with managed keys.
• Use short-lived cloud credentials or workload roles instead of long-lived access keys where possible.
• Restrict KMS key use independently from ordinary storage access.
• Keep buckets and databases private by default.
• Audit exports, permission changes, key use, and privileged access.
• Establish retention, deletion, and restore procedures.

A database being “private” and “encrypted” does not mean every authenticated application user should be able to query every row.

14. Policy design: RBAC, ABAC, ReBAC

• RBAC (Role-Based Access Control): permissions associated with roles, e.g. support-agent.
• ABAC (Attribute-Based Access Control): policy uses attributes such as department, device posture, sensitivity, environment, time, and requested action.
• ReBAC (Relationship-Based Access Control): access follows relationships, e.g. “this customer owns this order” or “this clinician is assigned to this patient.”

They can coexist. RBAC is easy to understand but can become coarse or create too many roles. ABAC is expressive but policies can become complex and hard to audit. ReBAC fits ownership and sharing relationships but requires accurate relationship data.

A practical policy should be:

• default deny;
• narrow in scope;
• understandable and testable;
• version-controlled and reviewed;
• evaluated consistently at relevant enforcement points;
• accompanied by a safe failure mode.

15. Continuous evaluation and revocation

“Zero Trust” does not require asking a central server for permission on every network packet. It means access decisions are based on explicit identity and policy, with re-evaluation and revocation when relevant context changes.

Events that may trigger reevaluation:

• employee disabled or removed from a group;
• device becomes noncompliant;
• credential or certificate is compromised;
• token expires or is revoked;
• workload identity changes;
• abnormal access pattern or incident signal appears;
• access policy or resource classification changes.

Define revocation objectives. For example, how quickly should a compromised service lose access to Kafka? What happens to existing connections? Are short-lived certificates/tokens used? Can the enforcement point terminate sessions? What is the maximum stale policy-cache interval?

“Continuous” is not automatically instantaneous

Short-lived credentials, event-driven revocation, policy cache invalidation, and connection termination all have timing limits. State those limits and design for the risk of stale permissions.

16. Availability, latency, and failure modes

Zero Trust adds identity providers, policy evaluation, certificate issuance, proxies, logs, and policy distribution. These are security-critical dependencies.

Design explicitly for:

Failure	Safer design question
Identity provider unavailable	Can existing sessions continue briefly? Should new authentication fail closed?
Policy service unavailable	Can enforcement use a bounded cached decision? Which high-risk operations must deny?
Certificate expires	How are expiry monitored, renewal automated, and failures rolled back?
Revocation event delayed	What is the maximum stale-access window?
Logging pipeline unavailable	Can local buffers protect audit events without exhausting disks?
Mesh/proxy misconfiguration	How are changes staged, validated, rolled back, and audited?
Clock skew	Are token/certificate validity checks reliable and clocks synchronized?
Too many policy rules	Are policies tested for conflicts, performance, and unintended access?

A common default is fail closed for sensitive data and privileged actions, but availability requirements matter. Use bounded, explicit exceptions rather than a blanket fail-open setting. Separate emergency break-glass access, require strong approval, and audit it heavily.

17. Observability and incident response

Capture security-relevant metadata:

• subject/workload identity;
• requested resource and action;
• policy decision and reason code;
• authentication method and credential/key identifier where safe;
• device/risk context at an appropriate privacy level;
• timestamp, correlation/trace ID, source, and outcome.

Never log raw passwords, bearer tokens, private keys, secret values, or unnecessary sensitive payloads.

Use telemetry to detect:

• repeated denied requests;
• unusual data exports;
• one workload calling resources outside its normal profile;
• new admin permissions or service accounts;
• certificate/key rotation failures;
• unexpected Kafka topic/group access;
• abnormal authentication failures or token replay patterns.

Incident response should be able to disable identities, revoke credentials, change policy, terminate sessions/connections, restrict network paths, rotate keys, preserve evidence, and restore safely.

18. Implementation roadmap: migrate incrementally

Do not try to “turn on Zero Trust” everywhere in one weekend.

Phase 1 — Discover and classify

• Inventory users, devices, workloads, APIs, databases, topics, secrets, keys, and data flows.
• Identify sensitive data and critical business operations.
• Draw trust boundaries and build a threat model.
• Find shared credentials, public endpoints, overly broad IAM roles, and direct paths that bypass gateways.

Phase 2 — Establish identity

• Centralize human identity and MFA for privileged access.
• Give workloads unique identities.
• Remove shared credentials and replace long-lived keys where feasible.
• Automate certificate and secret issuance/rotation.

Phase 3 — Enforce least privilege

• Define roles/scopes and resource-level authorization.
• Add service-to-service identity and policy.
• Tighten database grants, cloud IAM, Kafka ACLs, and KMS policies.
• Start with audit/monitor mode where supported, then enforce after validating policy behavior.

Phase 4 — Protect communications and data

• Enforce modern TLS at external and internal boundaries as required.
• Encrypt storage, backups, and snapshots.
• Move secrets to managed storage.
• Classify and minimize sensitive data in events, logs, and APIs.

Phase 5 — Observe and respond

• Centralize decision logs and security events.
• Alert on anomalous access, privilege changes, and failed rotations.
• Test revocation, break-glass access, incident playbooks, and disaster recovery.

Phase 6 — Measure and improve

• Track percentage of workloads with unique identities.
• Track privileged accounts protected by strong authentication.
• Track critical resources with enforced least privilege.
• Track credential/certificate rotation success and stale-access duration.
• Measure unauthorized access tests blocked and mean time to revoke compromised identity.
• Review exceptions and remove them over time.

19. Example: design a Zero Trust e-commerce platform

flowchart TB
    USER[Customer / Admin] --> EDGE[CDN + WAF + DDoS]
    EDGE --> GW[API Gateway / Edge PEP]
    IDP[OIDC IdP + MFA / risk] --> GW
    GW --> ORDER[Order Service]
    ORDER --> AUTHZ[Resource policy / tenant ownership check]
    AUTHZ --> DB[(Orders DB)]
    ORDER --> KAFKA[Kafka: TLS + client auth + topic ACLs]
    KAFKA --> FUL[Fulfillment Worker]
    FUL --> INV[Inventory Service]
    ORDER --> KMS[KMS / Secrets Manager]
    INV --> DB2[(Inventory DB)]
    ORDER --> PAY[Payment Service]
    PAY --> PSP[Payment Provider]
    ORDER --> AUDIT[Audit / SIEM / alerts]
    KAFKA --> AUDIT
    DB --> AUDIT

Request: customer reads order 123

1. Client establishes HTTPS and validates the API certificate.
2. The API validates the session or access token against the trusted identity configuration.
3. The API checks the subject’s permission and confirms order 123 belongs to that subject/tenant.
4. The request is rate-limited and input is validated.
5. The service uses its own workload identity to access the database, not the customer’s token as a database credential.
6. The database identity has only the permissions needed.
7. Logs record the decision and target identifier safely, without tokens or sensitive order contents.

Request: order service publishes an event

1. The workload obtains its managed identity/credential.
2. It connects to Kafka over TLS and authenticates.
3. Kafka authorizes that identity to write only to the permitted topic.
4. The event contains only required fields; sensitive values are minimized or separately protected.
5. Consumers authenticate independently and receive only the topic/group permissions they need.
6. Access is audited and credentials can be rotated or revoked.

20. How to present this in a system design interview

Use this structure instead of listing security products:

1. Clarify scope: enterprise workforce, public customer app, internal microservices, hybrid cloud, or all of these?
2. Identify assets and threats: identities, data, APIs, service accounts, lateral movement, stolen credentials, privileged access.
3. Draw the architecture: identity provider, policy decision function, enforcement points, resources, telemetry.
4. Walk through one request: identity → context → policy → enforcement → resource → audit.
5. Cover each boundary: user/API, service/service, service/database, producer/Kafka, workload/KMS.
6. Discuss failure modes: IdP outage, stale policy, revocation, expired certificate, logging outage.
7. Roll out incrementally: inventory, identity, least privilege, encryption, monitoring, staged enforcement.
8. State trade-offs and metrics: latency, availability, complexity, false denies, stale-access window, mean time to revoke.

A strong architect answer is concrete about enforcement and failure behavior, not just slogans like “never trust, always verify.”

21. Further reading

• NIST SP 800-207: Zero Trust Architecture — foundational model and logical components.
• NIST SP 800-207A: Zero Trust for cloud-native, multi-cloud applications — application and workload identity, gateways, proxies, and identity-tier policy.
• CISA Zero Trust Maturity Model — maturity roadmap across identity, devices, networks, applications/workloads, and data.
• OWASP Microservices Security Cheat Sheet — service identity, mTLS, token-based approaches, and controls.
• OWASP Microservices Security Architecture Cheat Sheet — documenting services, data, and least privilege.
• OWASP REST Security Cheat Sheet — API-level controls.
• NIST SP 800-207A publication page — official publication and abstract.

Follow-up Questions

• Zero Trust — Interview Playbook > Core concepts
• Zero Trust — Interview Playbook > Architecture and request flow
• Zero Trust — Interview Playbook > Trade-offs and failure scenarios
• Zero Trust — Interview Playbook > Mock final-round answer