<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1563986768494-4dee2763ff3f?w=1200">“Zero Trust” entered the security lexicon around 2010 with John Kindervag’s research at Forrester, became a NIST standard in 2020, and a government mandate in 2021. By 2023 it was so over-hyped that saying “we’re implementing Zero Trust” communicated approximately nothing about what you were actually doing.In 2026, the hype has cleared and the discipline has sharpened. Teams that have been implementing Zero Trust for three or four years have learned what works, what’s expensive theater, and what the unsolved problems are. This post documents those lessons.<hr><h2 id="what-zero-trust-actually-means-stripped-of-marketing">What Zero Trust Actually Means (Stripped of Marketing)</h2>Zero Trust is a security philosophy built on one principle: never assume network location equals trust. The corollary: every access decision should be made based on verified identity, device health, and context — not on whether the request originates from “inside” the network.The original “trust nothing, verify everything” framing is too absolute to be useful in practice. The operational version is:<ol><li>Identity-centric access: Authenticate every user and service, every time, with strong credentials</li><li>Least privilege: Grant only the access needed for the specific task</li><li>Assume breach: Design systems as if attackers are already inside your perimeter</li><li>Continuous verification: Don’t grant access once and forget; re-evaluate continuously</li></ol>None of these are new ideas. Zero Trust is the systematic application of all four, simultaneously, across your entire environment.<hr><h2 id="the-three-pillars-that-actually-matter">The Three Pillars That Actually Matter</h2>After stripping away the vendor narratives, Zero Trust implementations that work focus on three concrete areas:<h3 id="pillar-1-identity">Pillar 1: Identity</h3>Strong identity is non-negotiable. In 2026, “strong identity” means:<ul><li>Passkeys or hardware tokens for human authentication — passwords are not acceptable for any internal system</li><li>SPIFFE/SPIRE (or equivalent) for workload identity — services authenticate with cryptographic certificates, not static API keys</li><li>Continuous session validation — authentication isn’t a one-time check; sessions are invalidated based on context changes (location, device health, time elapsed)</li></ul><div><pre><code>// Example: SPIFFE workload identity in a service-to-service call
import (
 "github.com/spiffe/go-spiffe/v2/spiffeid"
 "github.com/spiffe/go-spiffe/v2/spiffetls/tlsconfig"
 "github.com/spiffe/go-spiffe/v2/workloadapi"
)

func newSecureClient(ctx context.Context, targetServiceID string) (*http.Client, error) {
 // Fetch our own SVID (SPIFFE Verifiable Identity Document)
 source, err := workloadapi.NewX509Source(ctx)
 if err != nil {
 return nil, fmt.Errorf("failed to create SVID source: %w", err)
 }

 // Configure TLS to use our SVID and only trust the target service's identity
 targetID := spiffeid.RequireIDFromString(targetServiceID)
 tlsConfig := tlsconfig.MTLSClientConfig(source, source,
 tlsconfig.AuthorizeID(targetID))

 return &amp;http.Client{
 Transport: &amp;http.Transport{TLSClientConfig: tlsConfig},
 }, nil
}
</code></pre></div>SPIFFE/SPIRE is now the CNCF-graduated standard for workload identity. If you’re still using long-lived API keys for service-to-service authentication, replacing them with SPIRE is the highest-leverage security investment available.<h3 id="pillar-2-policy-as-code">Pillar 2: Policy-as-Code</h3>Access policies that live in wikis or people’s heads don’t scale and can’t be audited. Zero Trust requires machine-readable, version-controlled policy.<img src="https://images.unsplash.com/photo-1614064641938-3bbee52942c7?w=800" alt="Security policy as code in a modern engineering workflow"> Photo by Towfiqu barbhuiya on UnsplashOpen Policy Agent (OPA) has become the standard for general-purpose policy evaluation. It’s embedded in Kubernetes admission controllers, API gateways, and custom authorization middleware.<div><pre><code># OPA policy: authorize service-to-service API access
package api.authorization

default allow = false

allow {
 # Identity must be valid
 is_valid_workload_identity(input.source_id)

 # Source service has permission for this operation
 has_permission(input.source_id, input.resource, input.action)

 # Request comes with valid, non-expired credentials
 not is_expired(input.credential)

 # Scope check: staging services can't access production resources
 compatible_environments(input.source_id, input.resource)
}

is_valid_workload_identity(id) {
 # SPIFFE ID format validation
 startswith(id, "spiffe://company.com/")
 valid_service_names[_] == split(id, "/")[3]
}

has_permission(source, resource, action) {
 data.permissions[source][resource][_] == action
}

compatible_environments(source, resource) {
 env_of(source) == env_of(resource)
}

env_of(id) = env {
 parts := split(id, "/")
 env := parts[4] # e.g., spiffe://company.com/ns/prod/sa/payment-service
}
</code></pre></div>The key insight: policies stored in Git, reviewed via PR, and deployed via CI/CD are auditable, testable, and reversible. A policy change that breaks something gets reverted like any other code change.<h3 id="pillar-3-encrypted-inspectable-data-paths">Pillar 3: Encrypted, Inspectable Data Paths</h3>Zero Trust requires that all traffic is encrypted and that you have enough visibility to detect anomalies. In practice:<ul><li>mTLS everywhere: Mutual TLS for all service-to-service communication. Service meshes (Istio, Linkerd, Cilium) handle the certificate lifecycle automatically.</li><li>Centralized logging: Every access decision logged with full context (who, what, when, from where, device health, outcome).</li><li>Behavioral baselines: Alerting based on deviation from normal, not just known-bad signatures.</li></ul><hr><h2 id="the-access-proxy-pattern">The Access Proxy Pattern</h2>The practical implementation of Zero Trust for application access (not just service-to-service) typically uses an access proxy:<div><pre><code>User → Identity Provider (SSO) → Access Proxy → Application
 ↑ ↑
 Authentication Authorization
 (Are you who you (Are you
 claim to be?) allowed?)
</code></pre></div>Pomerium, Teleport, and Cloudflare Access are the most common choices in 2026. The proxy sits in front of every internal application and enforces:<ol><li>Authentication via your IdP (Okta, Azure AD, etc.)</li><li>Authorization via policy (OPA, Pomerium’s policy language, etc.)</li><li>Device posture checking (is the device enrolled in MDM? updated? uncompromised?)</li><li>Session recording for sensitive applications</li></ol>The advantage over VPN: granular access control per application, full audit trail, no “you’re in the network, you can see everything” model.<hr><h2 id="what-organizations-are-getting-wrong">What Organizations Are Getting Wrong</h2>After consulting with several teams on Zero Trust initiatives, the common failure modes:Treating Zero Trust as a product purchase: Zero Trust is an architecture and a discipline, not a product you buy. Vendors that claim you can achieve Zero Trust by deploying a single product are selling you something. The tools matter, but the culture and processes matter more.Starting with the wrong layer: Many teams start with network segmentation (micro-segmentation, East-West traffic policies) because it’s familiar. But identity is the foundation. If your identity system is weak, better network controls just add complexity without improving security.Ignoring non-human identities: A surprising number of “Zero Trust” implementations have airtight controls on human access and leave service accounts with broad permissions and static credentials. The 2024 SolarWinds-class supply chain attacks mostly exploited non-human identities. SPIFFE/SPIRE or cloud-native workload identity (AWS IAM Roles for Service Accounts, GCP Workload Identity) is essential.Perfect being the enemy of good: I’ve seen teams spend 18 months designing the perfect Zero Trust architecture and never ship anything. Start with the highest-risk, highest-value area. Typically this is: replace VPN with an access proxy for your most sensitive internal tools.<img src="https://images.unsplash.com/photo-1522071820081-009f0129c71c?w=800" alt="Engineering team working on security architecture"> Photo by Annie Spratt on UnsplashForgetting about developer experience: Security controls that developers find unusable will be circumvented. The access proxy needs to be fast (&lt; 50ms latency overhead), the authentication flow needs to be smooth (no re-authentication every 5 minutes), and the error messages need to explain what went wrong. Bad developer experience is a security vulnerability.<hr><h2 id="practical-implementation-roadmap">Practical Implementation Roadmap</h2>If you’re starting a Zero Trust initiative or want to assess where you are:Month 1-3: Inventory and Identity Foundation<ul><li>Audit all service-to-service credentials — find all long-lived API keys and static secrets</li><li>Deploy SPIRE for workload identity (start with one cluster, expand)</li><li>Enforce MFA everywhere — no exceptions for “it’s annoying” reasons</li><li>Enable SSO for all internal tools</li></ul>Month 4-6: Access Proxy Deployment<ul><li>Deploy an access proxy (Pomerium/Teleport/Cloudflare Access) for highest-risk internal tools</li><li>Migrate away from VPN access for those tools</li><li>Implement device posture checking for privileged access</li></ul>Month 7-12: Policy-as-Code and Observability<ul><li>Define access policies in OPA</li><li>Implement centralized access logging</li><li>Build behavioral baseline dashboards</li><li>Run tabletop exercises to test your Zero Trust controls against real attack scenarios</li></ul>Year 2: Advanced Controls<ul><li>Micro-segmentation for lateral movement prevention</li><li>JIT (Just-In-Time) access for sensitive operations</li><li>Continuous authorization (re-evaluate access mid-session for sensitive actions)</li><li>Supply chain controls (SLSA, Sigstore for software provenance)</li></ul><hr><h2 id="measuring-zero-trust-maturity">Measuring Zero Trust Maturity</h2>CISA’s Zero Trust Maturity Model (ZTMM) is the reference framework. It defines five pillars (Identity, Devices, Networks, Applications, Data) and four maturity stages (Traditional, Initial, Advanced, Optimal).Most enterprise organizations are at Initial-to-Advanced across Identity and Applications, and Traditional-to-Initial for Data (which remains the hardest pillar). If you’re honest about where you are, you can be honest about what to prioritize.The honest metric: how long would it take an attacker with one set of stolen credentials to move laterally to your most sensitive data? That number — measured during red team exercises — is the clearest signal of whether your Zero Trust controls are working.<hr><h2 id="references">References</h2><ul><li><a href="https://doi.org/10.6028/NIST.SP.800-207">NIST SP 800-207: Zero Trust Architecture</a> — the authoritative definition</li><li><a href="https://www.cisa.gov/zero-trust-maturity-model">CISA Zero Trust Maturity Model</a> — the government’s maturity framework</li><li><a href="https://spiffe.io/">SPIFFE/SPIRE</a> — workload identity standard</li><li><a href="https://www.openpolicyagent.org/">Open Policy Agent</a> — policy-as-code engine</li><li><a href="https://www.pomerium.com/">Pomerium</a> — open source Zero Trust access proxy</li></ul> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

“Zero Trust” entered the security lexicon around 2010 with John Kindervag’s research at Forrester, became a NIST standard in 2020, and a government mandate in 2021. By 2023 it was so over-hyped that saying “we’re implementing Zero Trust” communicated approximately nothing about what you were actually doing.
In 2026, the hype has cleared and the discipline has sharpened. Teams that have been implementing Zero Trust for three or four years have learned what works, what’s expensive theater, and what the unsolved problems are. This post documents those lessons.
What Zero Trust Actually Means (Stripped of Marketing)
Zero Trust is a security philosophy built on one principle: never assume network location equals trust. The corollary: every access decision should be made based on verified identity, device health, and context — not on whether the request originates from “inside” the network.
The original “trust nothing, verify everything” framing is too absolute to be useful in practice. The operational version is:
Identity-centric access: Authenticate every user and service, every time, with strong credentials
Least privilege: Grant only the access needed for the specific task
Assume breach: Design systems as if attackers are already inside your perimeter
Continuous verification: Don’t grant access once and forget; re-evaluate continuously
None of these are new ideas. Zero Trust is the systematic application of all four, simultaneously, across your entire environment.
The Three Pillars That Actually Matter
After stripping away the vendor narratives, Zero Trust implementations that work focus on three concrete areas:
Pillar 1: Identity
Strong identity is non-negotiable. In 2026, “strong identity” means:
Passkeys or hardware tokens for human authentication — passwords are not acceptable for any internal system
SPIFFE/SPIRE (or equivalent) for workload identity — services authenticate with cryptographic certificates, not static API keys
Continuous session validation — authentication isn’t a one-time check; sessions are invalidated based on context changes (location, device health, time elapsed)
// Example: SPIFFE workload identity in a service-to-service call
import (
 "github.com/spiffe/go-spiffe/v2/spiffeid"
 "github.com/spiffe/go-spiffe/v2/spiffetls/tlsconfig"
 "github.com/spiffe/go-spiffe/v2/workloadapi"
)
func newSecureClient(ctx context.Context, targetServiceID string) (*http.Client, error) {
 // Fetch our own SVID (SPIFFE Verifiable Identity Document)
 source, err := workloadapi.NewX509Source(ctx)
 if err != nil {
 return nil, fmt.Errorf("failed to create SVID source: %w", err)
 }
 // Configure TLS to use our SVID and only trust the target service's identity
 targetID := spiffeid.RequireIDFromString(targetServiceID)
 tlsConfig := tlsconfig.MTLSClientConfig(source, source,
 tlsconfig.AuthorizeID(targetID))
 return &http.Client{
 Transport: &http.Transport{TLSClientConfig: tlsConfig},
 }, nil
}
SPIFFE/SPIRE is now the CNCF-graduated standard for workload identity. If you’re still using long-lived API keys for service-to-service authentication, replacing them with SPIRE is the highest-leverage security investment available.
Pillar 2: Policy-as-Code
Access policies that live in wikis or people’s heads don’t scale and can’t be audited. Zero Trust requires machine-readable, version-controlled policy.
Photo by Towfiqu barbhuiya on Unsplash
Open Policy Agent (OPA) has become the standard for general-purpose policy evaluation. It’s embedded in Kubernetes admission controllers, API gateways, and custom authorization middleware.
# OPA policy: authorize service-to-service API access
package api.authorization
default allow = false
allow {
 # Identity must be valid
 is_valid_workload_identity(input.source_id)
 # Source service has permission for this operation
 has_permission(input.source_id, input.resource, input.action)
 # Request comes with valid, non-expired credentials
 not is_expired(input.credential)
 # Scope check: staging services can't access production resources
 compatible_environments(input.source_id, input.resource)
}
is_valid_workload_identity(id) {
 # SPIFFE ID format validation
 startswith(id, "spiffe://company.com/")
 valid_service_names[_] == split(id, "/")[3]
}
has_permission(source, resource, action) {
 data.permissions[source][resource][_] == action
}
compatible_environments(source, resource) {
 env_of(source) == env_of(resource)
}
env_of(id) = env {
 parts := split(id, "/")
 env := parts[4] # e.g., spiffe://company.com/ns/prod/sa/payment-service
}
The key insight: policies stored in Git, reviewed via PR, and deployed via CI/CD are auditable, testable, and reversible. A policy change that breaks something gets reverted like any other code change.
Pillar 3: Encrypted, Inspectable Data Paths
Zero Trust requires that all traffic is encrypted and that you have enough visibility to detect anomalies. In practice:
mTLS everywhere: Mutual TLS for all service-to-service communication. Service meshes (Istio, Linkerd, Cilium) handle the certificate lifecycle automatically.
Centralized logging: Every access decision logged with full context (who, what, when, from where, device health, outcome).
Behavioral baselines: Alerting based on deviation from normal, not just known-bad signatures.
The Access Proxy Pattern
The practical implementation of Zero Trust for application access (not just service-to-service) typically uses an access proxy:
User → Identity Provider (SSO) → Access Proxy → Application
 ↑ ↑
 Authentication Authorization
 (Are you who you (Are you
 claim to be?) allowed?)
Pomerium, Teleport, and Cloudflare Access are the most common choices in 2026. The proxy sits in front of every internal application and enforces:
Authentication via your IdP (Okta, Azure AD, etc.)
Authorization via policy (OPA, Pomerium’s policy language, etc.)
Device posture checking (is the device enrolled in MDM? updated? uncompromised?)
Session recording for sensitive applications
The advantage over VPN: granular access control per application, full audit trail, no “you’re in the network, you can see everything” model.
What Organizations Are Getting Wrong
After consulting with several teams on Zero Trust initiatives, the common failure modes:
Treating Zero Trust as a product purchase: Zero Trust is an architecture and a discipline, not a product you buy. Vendors that claim you can achieve Zero Trust by deploying a single product are selling you something. The tools matter, but the culture and processes matter more.
Starting with the wrong layer: Many teams start with network segmentation (micro-segmentation, East-West traffic policies) because it’s familiar. But identity is the foundation. If your identity system is weak, better network controls just add complexity without improving security.
Ignoring non-human identities: A surprising number of “Zero Trust” implementations have airtight controls on human access and leave service accounts with broad permissions and static credentials. The 2024 SolarWinds-class supply chain attacks mostly exploited non-human identities. SPIFFE/SPIRE or cloud-native workload identity (AWS IAM Roles for Service Accounts, GCP Workload Identity) is essential.
Perfect being the enemy of good: I’ve seen teams spend 18 months designing the perfect Zero Trust architecture and never ship anything. Start with the highest-risk, highest-value area. Typically this is: replace VPN with an access proxy for your most sensitive internal tools.
Photo by Annie Spratt on Unsplash
Forgetting about developer experience: Security controls that developers find unusable will be circumvented. The access proxy needs to be fast (< 50ms latency overhead), the authentication flow needs to be smooth (no re-authentication every 5 minutes), and the error messages need to explain what went wrong. Bad developer experience is a security vulnerability.
Practical Implementation Roadmap
If you’re starting a Zero Trust initiative or want to assess where you are:
Month 1-3: Inventory and Identity Foundation
Audit all service-to-service credentials — find all long-lived API keys and static secrets
Deploy SPIRE for workload identity (start with one cluster, expand)
Enforce MFA everywhere — no exceptions for “it’s annoying” reasons
Enable SSO for all internal tools
Month 4-6: Access Proxy Deployment
Deploy an access proxy (Pomerium/Teleport/Cloudflare Access) for highest-risk internal tools
Migrate away from VPN access for those tools
Implement device posture checking for privileged access
Month 7-12: Policy-as-Code and Observability
Define access policies in OPA
Implement centralized access logging
Build behavioral baseline dashboards
Run tabletop exercises to test your Zero Trust controls against real attack scenarios
Year 2: Advanced Controls
Micro-segmentation for lateral movement prevention
JIT (Just-In-Time) access for sensitive operations
Continuous authorization (re-evaluate access mid-session for sensitive actions)
Supply chain controls (SLSA, Sigstore for software provenance)
Measuring Zero Trust Maturity
CISA’s Zero Trust Maturity Model (ZTMM) is the reference framework. It defines five pillars (Identity, Devices, Networks, Applications, Data) and four maturity stages (Traditional, Initial, Advanced, Optimal).
Most enterprise organizations are at Initial-to-Advanced across Identity and Applications, and Traditional-to-Initial for Data (which remains the hardest pillar). If you’re honest about where you are, you can be honest about what to prioritize.
The honest metric: how long would it take an attacker with one set of stolen credentials to move laterally to your most sensitive data? That number — measured during red team exercises — is the clearest signal of whether your Zero Trust controls are working.
References
NIST SP 800-207: Zero Trust Architecture — the authoritative definition
CISA Zero Trust Maturity Model — the government’s maturity framework
SPIFFE/SPIRE — workload identity standard
Open Policy Agent — policy-as-code engine
Pomerium — open source Zero Trust access proxy

Zero Trust Security in 2026: From Buzzword to Engineering Discipline

댓글