Why identity, not the network, has to be the perimeter

COMMENTARY: For years, Zero Trust meant tighter network segmentation: smarter firewalls, more granular VLANs, "never trust, always verify" applied as a network access control story. That model is hitting a hard limit in cloud-native environments, and most teams building on Kubernetes and multi-cloud infrastructure haven't fully reckoned with why. [ SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.] The limit is simple: in a Kubernetes cluster, the network isn't stable enough to build a perimeter around. Pods scale up and down in seconds. IP addresses are ephemeral and get reassigned constantly. A workload that existed a minute ago may not exist now, and whatever's running in its place has a different identity entirely, even serving the same function. Zero Trust built on network location and IP-based trust rules is trying to secure a perimeter that won't hold still long enough to secure. The organizations getting this right have stopped asking "what network segment is this traffic coming from" and started asking "what is this workload, cryptographically, and can it prove it." That's an architectural shift, not a policy update, and it rests on three legs: identity-centric microsegmentation, workload attestation, and continuous risk assessment across the multi-cloud estate. Microsegmentation has to follow the workload, not the subnet Traditional microsegmentation draws boundaries around network zones. Cloud-native microsegmentation has to draw boundaries around workload identity instead, because the zone itself is transient. Every service-to-service call gets evaluated on the cryptographic identity of the calling workload, not on which subnet it happens to occupy at that moment. Related reading: This matters more than it sounds, because the default alternative is worse than it looks: a static Kubernetes service account token with broader permissions than intended, or an IP-based allow rule left over from an architecture that no longer exists. Neither gets revisited when the workload behind it changes. It just keeps granting trust to whatever occupies that identity now. Workload attestation closes the "secret zero" problem This is where SPIFFE and SPIRE have become the standard worth knowing. NIST SP 800-207A now names SPIFFE explicitly as application identity infrastructure for Zero Trust in cloud-native, multi-cloud environments. The idea: instead of distributing a static secret and trusting whoever holds it, SPIRE issues short-lived cryptographic identities through a chain of attestation. A node proves what it is using platform evidence, cloud instance metadata, a TPM, a Kubernetes service account token. A workload then proves what it is using process-level evidence: its namespace, its service account, its container image digest. Only if both checks pass does the workload receive a SPIFFE identity document, typically valid for about an hour before it rotates automatically. The practical effect: a stolen workload credential is worthless within the hour, not valid for months the way a leaked API key sitting in an environment variable usually is. That's what "secret zero" actually means, and why rotating credentials more often doesn't solve it alone. If the first credential still has to be distributed and trusted somehow, you haven't removed the weak point, you've moved it. Attestation-based identity removes it by deriving trust from what the workload verifiably is, not from what it's holding. Continuous risk assessment is the piece most programs still get wrong Identity and attestation solve authentication. They don't solve governance: across a real multi-cloud estate spanning multiple clusters and providers, how do you know your posture right now, rather than at the last time someone ran a scan? This is where Zero Trust initiatives quietly regress into point-in-time compliance exercises. A quarterly cloud security posture review isn't continuous risk assessment; it's a snapshot with a three-month blind spot on either side. In an environment where identities rotate automatically and infrastructure changes by the hour, a risk posture reassessed quarterly describes an environment that no longer exists by the time anyone reads the report. Genuine continuous risk assessment means treating posture data the way you'd treat a security event: streamed and correlated in near-real-time, not batched. That means feeding workload attestation logs, Kubernetes audit trails, and cloud configuration state into the same risk-scoring pipeline as your threat detection telemetry, rather than running cloud posture management as a disconnected workstream. Getting this right doesn't require starting over None of this requires ripping out existing infrastructure. SPIFFE and SPIRE are already production-proven at scale, and Kubernetes-native tooling can wire cryptographic identity directly into network policy enforcement without application code changes or a full service mesh migration. The heavier lift is organizational: getting security, platform engineering, and cloud governance teams to agree that identity, not network topology, is now the control plane worth building around. That's the real Zero Trust maturity signal in cloud-native environments. Not whether an organization uses the term, but whether its architecture still makes sense with the network diagram deleted and only the identity graph left. For most organizations, that's still an uncomfortable question. It's also the right one to be asking.