TL;DR: Authorization, not authentication, determines breach blast radius because attackers usually exploit inherited permissions, according to Opal Security’s analysis of 23andMe, MOVEit, Snowflake, National Public Data, and M&S alongside the 2024 Verizon Data Breach Investigations Report. When access is fragmented across cloud IAM, SaaS, Terraform, and third-party identities, runtime control becomes the perimeter that matters.
NHIMG editorial — based on content published by Opal Security: Back Authorization has always been the real perimeter
By the numbers:
- Over 80% of breaches involved valid credentials.
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams reduce breach impact when valid credentials are compromised?
A: They should focus on limiting what a valid session can do after authentication.
Q: Why do over-scoped identities increase breach severity in cloud and SaaS environments?
A: Over-scoped identities turn a single compromise into broad reach because the attacker inherits more permissions than the job requires.
Q: What do IAM teams get wrong about authorization governance?
A: They often treat authorization as a review artifact instead of a live security control.
Practitioner guidance
- Map effective permissions, not just assigned roles. Trace what each high-risk identity can actually reach across cloud IAM, SaaS, Terraform, and internal tools.
- Move critical access to task-specific sessions. Use just-in-time access for privileged actions, vendor access, and sensitive data paths so the default state is no standing privilege.
- Version and test authorization policies before rollout. Treat policies as code with change control, regression testing, and reviewable diffs so access logic is explainable before it reaches production.
What's in the full article
Opal Security's full article covers the incident patterns and control breakdowns this post intentionally leaves at the analytical level:
- A walk-through of the specific breach cases and how authorization decisions shaped each outcome.
- The vendor's framing of how policy should be unified across cloud IAM, SaaS, Terraform, and internal tools.
- Operational examples of task-specific access and runtime enforcement in real environments.
- The article's discussion of where policy-as-code helps and where governance still needs cross-functional ownership.
👉 Read Opal Security's analysis of why authorization is the real perimeter →
Authorization as the real perimeter: what IAM teams miss?
Explore further
Authorization is the real perimeter because breach damage is determined by effective permissions, not successful login. Authentication has improved dramatically, but modern attackers still win by operating inside trusted sessions and inheriting whatever access the environment has already granted. That makes runtime authorization the control plane that actually constrains blast radius. Practitioners should treat effective access as the security boundary that matters.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite.
A question worth separating out:
Q: Who is accountable when a third-party identity causes data exposure?
A: Accountability sits with the organisation that trusted the identity without sufficient boundaries, not just with the vendor that used it. If a third-party account was over-scoped, persistently trusted, or insufficiently monitored, the governance failure is internal. Frameworks such as NIST CSF and zero trust both expect explicit control over external access.
👉 Read our full editorial: Authorization is the real perimeter for AI, cloud, and IAM