•
“Identity is the new perimeter” has been a useful shorthand in security for the past decade, especially as the traditional network perimeter gave way to SaaS, cloud-native infrastructure, remote users, and autonomous agents. But the notion that identity is somehow a new perimeter misses the point.
What protects critical systems isn’t whether someone can log in. It’s what that identity is allowed to do once inside. That’s authorization. And that’s not a recent innovation – it’s the oldest and most fundamental control in security.
Authorization has always been the real perimeter. We just stopped treating it like one, because fundamentally it’s both more complex and user-specific than authentication.
We've matured authentication, but authorization remains fragmented
Over the last 10 years, authentication has seen enormous investment and innovation. MFA, passwordless auth, behavioral biometrics, and adaptive signals have all made verifying identity more secure.
But the same can’t be said for authorization: the rules and systems that govern access after identity is verified.
In most organizations, authorization policies are still:
Hardcoded in application logic
Defined separately in Terraform, cloud IAM, and SaaS admin panels
Audited infrequently and inconsistently
Largely static
Siloed across IT, GRC, infrastructure, engineering, and security teams
These aren’t all flaws in the tools themselves – IaC and policy-as-code have brought real discipline to parts of the stack. But in the absence of shared ownership and centralized policy reasoning, authorization is still fragmented. And fragmentation is what attackers exploit.
Breaches don't escalate because an attacker gets in – they escalate because of what that attacker can do
Whether the attacker uses malware, credential stuffing, phishing, or a zero-day to gain access, the real question is always: what permissions did they inherit, and how far did that take them?
Let’s look at several major incidents from the past few years through that lens:
1. 23andMe, 2023: Access chaining through opt-in features
Attackers accessed real user accounts via credential stuffing. The breach became much larger when they leveraged a family-sharing feature that allowed visibility into relatives’ genetic data.
What failed: Authorization at the feature level. The system permitted large-scale data exposure through behavior that, while technically “opted into,” lacked usage monitoring or abuse detection.
2. MOVEit Transfer, 2023: Zero-day with implicit privilege
A zero-day SQL injection flaw allowed attackers to bypass authentication and query backend systems. But the reason data was exfiltrated so broadly had little to do with the exploit itself—it was because the exploited process had direct, unsegmented access to sensitive data.
What failed: Granular authorization and runtime controls. The application layer lacked safeguards that could have limited the scope of backend access once code execution occurred.
3. Snowflake, 2024: Credential compromise meets session sprawl
Attackers used malware to steal valid user credentials. Some lacked MFA, but the critical factor was that those accounts had persistent, high-privilege roles with broad access across data environments.
What failed: Session scoping, just-in-time access, and visibility into privilege inheritance across accounts.
4. National Public Data, 2024: No authentication required
Billions of records were exposed via unauthenticated or poorly scoped API endpoints. There was no breach in the traditional sense – just access control misconfiguration at massive scale.
What failed: Data-layer authorization and governance. No centralized enforcement or auditing of what systems and users should be allowed to access which datasets.
5. M&S, 2025: Third-party access without privilege separation
A vendor integration was compromised, exposing customer records. The identity was legitimate, but the access it carried was over-scoped and persistently trusted.
What failed: Authorization policy for third-party identities. There were no strong boundaries between internal and external systems, and no layered controls on what external actors could reach.
The data backs it up
According to the 2024 Verizon Data Breach Investigations Report:
Over 80% of breaches involved valid credentials
Nearly 70% involved human error or misuse of access
Most breach impact stemmed from lateral movement and privilege escalation, not initial access
In other words, the aforementioned incidents aren’t edge cases; they’re the norm. Attackers rarely need to “break in” today – they use what’s already trusted. And what determines the damage isn’t how they got in – it’s what the environment allowed them to do next.
What defending the real perimeter looks like
Modern authorization strategy means more than role definitions. It requires treating authorization as a real system with clear ownership, enforcement, and monitoring. That includes:
Short-lived, task-specific access by default
Contextual enforcement based on identity type, risk posture, workload, and environment
Policy unification across cloud IAM, Terraform, internal tools, and SaaS
Decoupled logic, where policies are versioned, testable, and explainable
Cross-functional ownership, spanning security, infrastructure, and platform teams
IaC and policy-as-code are critical enablers here. Tools like Terraform give us repeatability and structure – but enforcement still requires runtime evaluation, observability, and governance.
Final thoughts
The idea that “identity is the new perimeter” helped shift security thinking away from IP ranges and firewalls. But it was never a new concept – just a reframing of what’s always been true.
Authorization has always been the perimeter. The difference now is that the complexity of our environments makes managing it harder (and getting it wrong more dangerous).
Breaches don’t unfold at login. They unfold at the junction between trust and action. That’s where authorization lives. And it’s time we protect it accordingly.
Come visit us today and tomorrow at Identiverse, Booth 608, for a live demo.
