Replace trust based on network location with verified identity, encrypted service traffic and tested access policies, rolled out in phases and aligned to NIST SP 800-207.
Design targets · not measured results from past client work
Workloads receive short-lived credentials at runtime. Any static secret that has to remain is recorded with an owner and an expiry date.
Service-to-service traffic inside the mesh uses mutual TLS once the rollout reaches strict mode.
Every access-policy change passes automated tests in CI before it can be deployed.
Every access decision is logged with the identity, the resource and the outcome, and forwarded to your monitoring.
Zero trust is a security approach that stops treating network location as proof of trust. NIST SP 800-207, published in August 2020, describes it as a move from defending static network perimeters to protecting users, assets and resources: no implicit trust based on where something sits or who owns it, and authentication and authorization of both user and device before a session with a resource begins. It is an architecture and a program of change, not a single product.
Every request is authenticated and authorized using identity and context, for people, devices and workloads alike.
A policy engine decides, and an enforcement point (a proxy, a mesh sidecar, the application) applies the decision. Open Policy Agent is a common way to separate the two.
NIST SP 800-207A recommends a monitoring framework that tracks events such as access requests, and using that telemetry to tune access rights and require step-up authentication.
Identity, authenticated traffic and governed access, built to replace perimeter assumptions step by step.
Every user, service and device gets a verifiable identity, and workloads stop sharing long-lived secrets. SPIFFE gives each workload an ID and a short-lived certificate, rotated automatically through the Workload API.
Network location stops being proof of trust. Services authenticate each other with mutual TLS, introduced gradually: observe in permissive mode, fix the plaintext clients, then enforce strict mode.
Authorization decisions move out of scattered service code into policies that are written, reviewed and tested like software. A policy engine such as Open Policy Agent separates deciding from enforcing.
Zero trust is built in stages. The CISA Zero Trust Maturity Model (version 2.0) frames the journey across five pillars (identity, devices, networks, applications and workloads, and data) and four stages: traditional, initial, advanced and optimal. We use it as a common language for progress.
| Step | What happens | Deliverable | How you know it is done |
|---|---|---|---|
| 1. Map identities and resources | List every user type, workload and device, the resources they touch and the actions each needs. | Identity, resource and permitted-action table | Owners have reviewed it and it matches real access logs. |
| 2. Assess maturity | Score the current state against the five pillars and four stages. | Maturity assessment | Gaps are ranked by risk and effort, not just listed. |
| 3. Threat model critical systems | Walk through how an attacker with one stolen identity could move. | Threat model with attack paths | Each path has a control or an accepted-risk decision. |
| 4. Design the target architecture | Choose identity, traffic and policy controls for your platforms, cloud and on-premises. | Target architecture and decision record | Tool choices are tied to your stack, not to a vendor list. |
| 5. Pilot on one slice | Apply workload identity, mutual TLS and default-deny to a real set of services. | Working pilot and rollback plan | Pilot traffic runs in strict mode with no unplanned outages. |
| 6. Validate and roll out in phases | Test the controls, then extend phase by phase with measurable goals. | Phased roadmap and validation report | Independent testing confirms controls work, and each phase has agreed metrics. |
Zero trust maturity is a journey. Most organizations progress pillar by pillar, and the order should follow your risk.
No single tool delivers zero trust. This table maps common problems to the controls we most often use, and what to watch out for.
| Problem | Typical control | How it helps | Watch out for |
|---|---|---|---|
| Services trust anything inside the network | Mutual TLS with workload identity (service mesh) | Each workload proves its identity with a short-lived certificate, such as a SPIFFE X.509-SVID, and traffic is encrypted. | In Istio, permissive mode is the default and accepts plaintext. Migrate clients first, then enforce strict mode. |
| Static keys and passwords in config | Short-lived credentials from a secrets manager or cloud workload identity | Credentials expire quickly, so a leaked one has a small window of use. | Applications must renew credentials correctly. Test rotation before relying on it. |
| Roles are far broader than the job | Least-privilege IAM review with just-in-time elevation | Access is scoped per resource and elevated only when needed, with an approval and an expiry. | Tighten using usage logs, in steps. Keep a logged break-glass path. |
| Authorization logic copied across services | A policy engine (for example Open Policy Agent) with policies in Git | Decisions are made in one place, tested in CI and logged, while services enforce them. | Plan for policy-engine availability and latency, and test policies like code. |
| Staff reach internal apps through a VPN | Identity-aware access with device posture checks | Access depends on the user, the device state and the app, per request. | Posture signals are only as good as the device management behind them. Non-web apps need extra work. |
| Several clouds and on-premises sites | Separate trust domains with consistent policy | NIST SP 800-207A models policy at the network and identity tiers for cloud-native apps across locations. | More environments mean more policy to keep consistent. Start with one slice. |
Standards and products change. Check current documentation before you decide. References are listed below.
Core building blocks we include in a zero trust engagement.
Access to internal applications is decided per request from who the user is, the state of their device and the sensitivity of the app, rather than from being on the corporate network.
Authorization rules are written in a policy language, stored in Git and tested in CI. Services ask the policy engine for a decision and enforce the answer.
Access decisions, credential issuance and policy changes are logged in a consistent format and sent to your SIEM, so an investigation can answer who accessed what, and why it was allowed.
Scheduled checks compare live cloud configuration with the approved baseline and flag privilege escalation paths, open ingress and unmanaged security groups. Fixes go through review.
After a permissive-mode rollout and a check for plaintext clients, two small policies do most of the early work.
# 1. Require mutual TLS for workloads in the "shop" namespace
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: shop
spec:
mtls:
mode: STRICT
---
# 2. Only the checkout identity may call payments, and only this route
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: payments-allow-checkout
namespace: shop
spec:
selector:
matchLabels:
app: payments
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/shop/sa/checkout"]
to:
- operation:
methods: ["POST"]
paths: ["/v1/charges"]Istio’s default is permissive mode, which accepts both plaintext and mutual TLS. Its migration guide suggests finding clients still sending plaintext, injecting sidecars, applying strict mode to one namespace, verifying, then widening. Once an ALLOW policy applies to a workload, requests that match no rule are denied. Check the API version against your Istio release.
Six failure patterns we design against from the first week.
Zero trust is an architecture and an ongoing program, not a single product you can install. Tools help, but the work is in identities, policies and the processes behind them.
Switching straight to strict mode breaks every client that still sends plaintext. Start in permissive mode, find the stragglers, then enforce namespace by namespace.
Knowing which service is calling is only half the job. Without default-deny policies, every authenticated workload can still call every other one.
Removing roles without looking at real usage breaks production. Use access logs to find what is actually needed, then tighten in steps with a way back.
Short-lived credentials only work if applications can renew them. Test rotation under load before you depend on it, and keep a break-glass path that is logged.
If you cannot show which policy allowed which request, you cannot answer an auditor or an incident review. Log decisions and keep policy history in version control.
A mesh deployed in a dedicated environment with workload identities, mutual TLS and default-deny rules applied to one real slice of your services.
A dashboard for credential issuance, allow and deny decisions per service pair, and policy test results.
Terraform, mesh and policy configuration with automated tests in CI, ready for your engineers to run and extend.
Six questions to ask any firm, including us, and the evidence to request.
Ask how their approach maps to NIST SP 800-207 and the CISA Zero Trust Maturity Model. Evidence to request: a sample assessment showing pillar-by-pillar findings.
Ask exactly what you receive. Evidence to request: sample maturity assessment, target architecture, threat model and phased roadmap, with names redacted.
Ask how rollout is sequenced. Look for assessment, then a pilot on one slice, then independent validation, and phased expansion with rollback plans.
Ask how services will authenticate each other and how credentials rotate. Look for short-lived certificates, tested renewal and a plan for services outside the mesh.
Ask how controls are tested. Evidence to request: a sample test plan, policy tests in CI, and what independent validation covers.
Ask what you own at the end. Look for infrastructure as code, runbooks, policy repositories and training, with acceptance criteria agreed up front.
Zero trust architecture is a security design that gives no implicit trust based on network location or asset ownership. NIST SP 800-207 describes a shift from defending static network perimeters to protecting users, assets and resources, with authentication and authorization of both user and device before a session with a resource begins.
No. It is an architecture and a program of change that involves identity, devices, networks, applications and data. Products such as identity providers, service meshes and policy engines support it, but no single product delivers it.
It is a roadmap published by CISA. Version 2.0, released in April 2023, covers five pillars (identity, devices, networks, applications and workloads, and data) with three cross-cutting capabilities (visibility and analytics, automation and orchestration, governance) across four maturity stages: traditional, initial, advanced and optimal.
NIST SP 800-207A addresses cloud-native applications in multi-location environments. It recommends defining policies at the network and identity tiers, configuring components such as gateways and service identity infrastructure to enforce them, and monitoring events to tune access.
Workload identity gives each running service a verifiable identity instead of a shared secret. SPIFFE is a standard for this. A SPIFFE ID is a URI such as spiffe://acme.com/billing/payments, proven by an SVID, which is an X.509 certificate or a JWT. The Workload API delivers short-lived credentials that are rotated automatically.
Usually not. In Istio, permissive mode is the default and accepts both plaintext and mutual TLS. Strict mode accepts only mutual TLS, so clients that still send plaintext will fail. Istio recommends finding those clients, migrating them, then applying strict mode to a namespace before widening it.
It depends on how many systems, identities and environments are involved, and it is normally delivered in phases rather than once. A proof of concept on one slice of your services is the quickest way to get a realistic estimate, and we deliver that as a 14-day sandbox.
Last reviewed: October 2026
Work with our principal security architects to assess your current access model and plan a phased zero trust roadmap.