At some point in recent years, someone coined the expression “Identity is the new perimeter.” It’s catchy—and widely repeated—but what does it really mean? Let’s examine that idea using the first principles we teach in SANS SEC502: Cloud Security Tactical Defense.
Identity and Access Control: Who Can Do What to What
On Day 1 of SEC502, we focus on Identity and Access Management (IAM) across AWS, Azure, and Google Cloud. Each cloud service provider implements IAM a bit differently, but they all rely on the same fundamental model.
-
AWS and Azure use the term Principal
-
Google Cloud uses Member
In each case, access control answers the question:
“Who can do what to what?”
It’s a bit like diagramming sentences back in grade school. The subject takes an action on an object. In access control terms, a principal performs an action on a resource.
The differences between the major cloud providers lie mostly in syntax and structure—how permissions are applied, inherited, or expressed—not in their underlying logic. Understanding these mechanics is essential for building defensible cloud architectures.
Trust Boundaries and Threat Modeling
Later in the course, we introduce threat modeling, which examines what happens when data or control crosses from one level of trust to another—for example, from a user’s browser to a web server, or from an internal system to a cloud service.
A trust boundary marks where assumptions about identity, integrity, or confidentiality change. Inside the boundary, entities are trusted; outside, they’re not—or they’re trusted to a lesser degree.
Zero Trust: Trust Boundaries Everywhere
In a Zero Trust environment, the idea of a single perimeter dissolves. Instead of one large, static boundary separating “inside” from “outside,” every interaction between users, devices, and workloads becomes a potential trust boundary crossing.
Traditional security models asked how to prevent untrusted entities from breaching the perimeter. Zero Trust flips that logic:
“Never trust, always verify.”
Every request, regardless of origin, is treated as potentially hostile until proven otherwise. Each trust boundary is now a micro–security perimeter. Instead of one big wall, Zero Trust creates many small gates, each enforcing authentication, authorization, and validation.
Why “Identity Is the New Perimeter” Misses the Point
When we conflate identity with the security perimeter, we risk overlooking two distinct but interdependent access control concepts.
-
Identity defines who or what is making a request.
-
The perimeter defines where verification and enforcement occur.
Saying “identity is the new perimeter” blurs that distinction. Identities are what cross security perimeters; they are not the perimeters themselves.
It is true that identity plays a far greater role in modern, Zero Trust–driven architectures—but its purpose remains to control access across perimeters, not to replace them. Each security perimeter still requires its own defensive posture, policy enforcement, and verification of identity, integrity, and intent.
Keeping Zero Trust Simple
While there are many principles in Zero Trust doctrine, I prefer to keep it simple:
-
If System A doesn’t need to talk to System B, don’t allow network connectivity.
-
If System A does need to talk to System B, require strong authentication.
These two rules encapsulate the essence of Zero Trust: minimize connectivity and verify everything that remains.
Defining Perimeters in the Cloud
Thinking about security perimeters in the cloud is a valuable design exercise. When we treat trust boundaries as security perimeters, we can reinforce them with network security controls.
A Virtual Private Cloud (VPC), for example, provides a natural perimeter. Using security group rules, we can specify which ports are accessible to which services and from which source IP addresses. That satisfies Concept 1—restricting unnecessary connectivity.
Notice I said “service,” not “services.” Give each service its own VPC whenever possible. This isolates workloads and enforces the principle of least privilege at the network layer.
And whether “System A” and “System B” are virtual machines, containers, or serverless functions, the same first principles apply: identify your trust boundaries, enforce authentication at every crossing, and assume breach by default.
