Back

Identity Attack Surface Analysis: Securing the New Perimeter 

The traditional network perimeter has effectively dissolved in today’s cloud-centric and data-driven technology landscape. Firewalls and VPNs are no longer enough to protect organizations from sophisticated cyber threats. Instead, identity is the new perimeter.

With employees, contractors, and partners accessing cloud applications and internal resources from anywhere, a compromised identity, often through a phishing attack, can open the door to impactful incidents and devastating breaches.

According to the Veza State of Access Report, organizations now average 1.75 identity platforms, with 34% of identities existing as unmanaged local accounts—often outside the reach of traditional tools like Active Directory, Azure AD, or Okta. That fragmentation increases your risk surface.

This article explores how to perform an identity perimeter analysis, a critical exercise so you can identify exposure, shrink the blast radius, and build resilience around your most targeted assets: your identities.

Why Identity is the New Perimeter 

The shift to cloud services, remote work, and decentralized technology platforms has made identities the frontline of cybersecurity. Assume an employee falls victim to a phishing attack—a safe assumption given that phishing remains the top attack vector. In the 4th quarter of 2024, over 989,000 unique phishing attacks were detected worldwide.

Identity isn’t just part of the attack surface; it is the attack surface. From compromised credentials to token theft and over-permissioned service accounts, identity-based attacks now top the charts across reports from Verizon, Cisco, CrowdStrike, and Expel – all published within the last six months.

It’s no longer about breaking in through technical vulnerabilities. It’s about logging in through the front door, with legitimate credentials and just enough access to move quietly through your environment.

Nicole Perlroth put it best on a recent episode of the Identity Radicals podcast:
“They’re not hacking in anymore,” she says. “They’re logging in.”

Once an attacker gains access to an employee’s credentials, they typically move laterally, seeking other systems, applications, or privileged accounts to escalate their access. This lateral movement succeeds where identity protections are weak or access controls are loosely defined.

An identity perimeter analysis treats end users as the perimeter, focusing on what an attacker could access with a compromised identity. By mapping out lateral access paths, identifying privileged accounts, and evaluating protections like multi-factor authentication (MFA), organizations can proactively reduce their attack surface and strengthen their security posture. 

Identity Visibility Is the New Control Plane

Security teams can’t protect what they can’t see. As identity becomes the perimeter, having a clear view into who has access to what, and how that access is used, is foundational.

This goes far beyond tracking logins. It means mapping relationships between identities and resources across cloud, SaaS, and on-prem environments. Service accounts, policy inheritance, misconfigurations, and stale entitlements all contribute to hidden risk.

To address this complexity, Gartner recently introduced a new framework called Identity-First Visibility and Intelligence Platforms (IVIPs). These platforms provide a unified, contextual view of access across fragmented identity systems. Rather than replacing identity providers or governance tools, IVIPs enhance them by surfacing shadow access, monitoring privilege drift, and helping teams reduce the blast radius of a compromise.

Identity visibility is no longer optional. It is the foundation for enforcing least privilege, validating Zero Trust, and responding effectively to identity-based threats.

Steps for Performing Identity Perimeter Analysis 

Here’s a practical framework for conducting an identity perimeter analysis, designed to uncover risks and prioritize mitigations.  

Step 1 –  Inventory and Map Identities

Start by inventorying every identity—employees, contractors, service accounts, keys, and non-human identities (NHIs). This step is foundational.
The Veza State of Access Report reveals a 17:1 ratio of NHIs to humans in cloud environments. And 34% of identities exist as unmanaged local accounts, often outside standard governance tools.

Use tools like Veza Graph to answer:

  • What identities – human or non-human – exist in your cloud environments (e.g., AWS, Azure, GCP, SaaS)? Front-door access tools like Okta and Entra handle login, but Veza shows you what’s actually inside: every account, including local and unmanaged ones. 
  • What types of accounts are in play – employees, contractors, service accounts, ephemeral compute, or legacy integrations?
  • Are there dormant or unused accounts still holding permissions that could be exploited? 
  • Are long-lived tokens or static credentials still in use, especially in service accounts or automation scripts?
  • What’s unmanaged—and what’s invisible to your current IGA tools?

Pro Tip: Leverage Veza Access Graph to discover and tag high risk accounts. Catalog this inventory to validate other controls such as MFA, password rotation.  Flag risky accounts, such as those with overly broad permissions. 

Step 2 – Identify Accessible Applications and Systems and Privileged Entitlements

Once you’ve mapped accounts, the next step is to understand what they can reach – the applications, systems, and entitlements each identity can access. In a cloud environment, this includes SaaS platforms (e.g., Salesforce, GitHub, Google Workspace, Office 365), internal tools, and cloud infrastructure (e.g., EC2 instances, S3 buckets). 

The Veza State of Access Report shows just how complex this can get:

  • AWS environments average 4,650 IAM roles, each with 3,350 system permissions
  • Salesforce orgs average 4,504 roles
  • Snowflake environments average 2,188 roles

Use Veza Access Graph to compile a comprehensive inventory. For each identity, ask: 

  • Which identities have privileged entitlements across environments (AWS, Azure, Salesforce, etc.)?
  • Are privileged entitlements protected by MFA?
  • Are there active access keys associated with these identities? Are they rotated regularly?
  • What applications or systems can this user access directly? 
  • Can identities reach other systems through federation, misconfigurations, or shared access?
  • Are sensitive systems (databases, PII, CI/CD pipelines, finance apps) directly reachable?
  • Are long-lived tokens used for access?

Step 3 – Analyze Privileged Account Exposure & Discover Lateral Access Paths

Privileged accounts are the first stop for any serious attacker. Whether it’s an AWS IAM admin, an Azure subscription owner, or a GCP service account with storage access, these identities carry power. That makes them a prime target for escalation.

During your assessment, evaluate the exposure path to these accounts. Can a compromised user assume a high-privilege role via group membership or policy inheritance? Are credentials exposed in places they shouldn’t be – like config files or cloud-init scripts?

Here’s what to dig into:

  • Are privileged accounts truly protected with enforced MFA, or are they vulnerable to legacy protocols?
  • Are any systems caching long-lived credentials in the clear?
  • Can an attacker hop roles or elevate through weak IAM controls (e.g., role assumption without policy boundary constraints)?

One standout insight from the Veza State of Access Report: While just 0.1% of users are labeled “privileged,” 34% of effective permissions include destructive capabilities like delete access. Implicit privilege is everywhere.

For instance, an attacker with access to an employee’s AWS console might exploit a misconfigured IAM role to gain administrative privileges. Use tools like AWS Security Hub or Azure Sentinel to detect privilege escalation risks. 

Pro Tip: Leverage Veza Access Graph to discover and tag high risk accounts. Catalog this inventory to validate other controls such as MFA, password rotation.  Flag risky accounts, such as those with overly broad permissions. 

Step 4 – Evaluate MFA and Other Controls 

MFA is a critical defense against identity-based attacks, but its absence or inconsistent application can be a major vulnerability. Start by reviewing which accounts (especially admins and service accounts) are covered, and which aren’t.

Consider:

  • Are all cloud console and SaaS logins protected with MFA?
  • Are exceptions hiding behind legacy auth methods or “trusted device” loopholes?
  • Do your MFA policies scale to non-human identities, or are service accounts excluded entirely?

According to Veza’s report, 13% of users have no MFA configured—a concerning number in today’s credential-theft landscape.

MFA should be backed by conditional access policies, session timeouts, and token rotation, especially in platforms like Entra ID and Okta. These tools can enforce step-up auth based on risk, location, device posture, or behavioral anomalies. 

For example, Azure AD Conditional Access can enforce MFA based on location, device, or risk level. And don’t forget about non-human accounts: cloud environments average a 17:1 ratio of NHIs to users. Many of these accounts operate without interactive login protections, making MFA enforcement impossible, so governance, policy enforcement, and credential rotation become even more critical. 

Step 5 – Simulate Lateral Movement Scenarios 

Once an identity is compromised, the real question becomes: how far can it go?

Use tools like Veza Access Graph to model lateral movement paths—from SaaS to cloud infra and everything in between. Attackers rarely stop at the first system; they pivot, escalate, and dig deeper.

Run scenarios like:

  • Can the identity access a Snowflake or SQL database with customer PII?
  • Are cached credentials on that system exposing lateral hop opportunities?
  • Do SaaS platforms store access tokens or cookies (e.g., AWS console tokens in OneDrive)?
  • Is there an exposed path from Okta or Salesforce to AWS via misconfigured API keys?
  • What is the blast radius if a single privileged identity is hijacked?

Document the paths and systems an attacker could reach, prioritizing those with high-impact consequences (e.g., data exfiltration, ransomware deployment). By simulating movement, you uncover paths attackers would exploit before they’re real.

Step 6 – Prioritize and Mitigate Risks 

Once you’ve mapped the landscape—identities, access, privilege, and lateral paths—it’s time to triage. Rank risks based on blast radius and exposure windows. Focus mitigation efforts where they’ll have the biggest impact.

Key actions:

  • Enforce MFA universally—no exceptions for admins or service accounts. Use Veza to tag privileged identities and verify MFA enforcement across them.
  • Shrink lateral access: Veza Access Lifecycle Management enables RBAC and policy-based least privilege enforcement across cloud and SaaS environments.
  • Cull the clutter: Deactivate dormant users, remove excessive entitlements, and eliminate standing access that’s never used. According to Veza, nearly all AWS and Snowflake users access less than 20% of what they’re granted. That’s the attack surface.
  • This isn’t about perfect security. It’s about reducing attacker options—so even if they get in, they don’t get far.

Real-World Example: Phishing to Privilege Escalation 

Consider this: a mid-sized org running Microsoft 365 and AWS. An employee clicks on a phishing email, handing over their credentials. The attacker logs in, lands in OneDrive, and finds a text file with an AWS API key. Perfect (for them). 

That key maps to an IAM role with admin privileges. Minutes later, crypto mining EC2 instances are spinning up in us-east-1.

What could have stopped it?

  • Identity visibility: Veza would’ve flagged the OneDrive-to-AWS link by mapping identity-to-data relationships.
  • Access intelligence: That IAM role had more privileges than it needed. Veza could’ve flagged it with a high OPAS score.
  • MFA enforcement: Had the attacker faced MFA during login to either system, the breach likely would’ve stopped cold.

This is why perimeter analysis matters: it’s the difference between an attempted phish and a full-blown breach.

Conclusion 

In a world where infrastructure is ephemeral and applications are everywhere, identity has become the most consistent—and most targeted—attack surface.

The old perimeter is gone. Firewalls don’t protect SaaS. VPNs don’t stop credential stuffing. The only thing standing between an attacker and your data is access—who has it, how they got it, and what they can do with it.

Identity Perimeter Analysis arms security teams with a framework to get ahead of the problem. Map identities. Inventory access. Uncover privilege. Simulate lateral movement. Validate controls like MFA and conditional access. Then act.

This isn’t a one-and-done exercise. It’s a continuous loop of visibility, validation, and enforcement.

If you’re not doing this yet, start now. If you are, double down. The adversaries aren’t slowing down.

For more on how attackers are targeting identity as the front door, CISA’s phishing awareness infographic is worth a quick review.

What’s Next: From Insight to Action

Security teams can’t afford to treat identity like an afterthought—not when the blast radius of a single compromised account spans SaaS, cloud, and custom apps. If you’re ready to take the next step, here’s where to start:

  • Broaden your perspective:
    Hear the full conversation with Nicole Perlroth on Identity Radicalswhere she and Veza’s Chief Security & Trust Officer unpack the evolving cyber threat landscape, the rise of identity-based attacks, and why resilience is the new north star for security leaders.
  • Build your foundation: If identity is the new perimeter, it’s time to rethink how it fits into your Zero Trust architecture. Start with Why Identity Is the Cornerstone of Zero Trust Architecture to understand why identity, not network, is the new control plane.
  • Dig deeper into lifecycle governance: Overprivileged access isn’t just a misconfiguration—it’s a standing invitation to attackers. Download the whitepaper, Transforming Access Lifecycle Management with Veza’s Access Profiles, to see how teams like yours are automating privilege enforcement and aligning policy with actual access.
  • Put the theory into practice: Want to visualize the blast radius of a compromised account in your own environment? Schedule a demo with our team to see how Veza maps identity-to-resource access across your hybrid ecosystem, from cloud to on-prem and everywhere in between.
  • Stay ahead with IVIP: Curious about the new Gartner Identity Visibility and Intelligence Platform (IVIP) category? Get the lowdown and see how Veza fits into this next-gen identity security framework in our blog on Identity Visibility and Intelligence Platforms (IVIP).

About the Authors

Nathan Casey leads security at Veza, bringing two decades of hands-on cybersecurity experience across critical infrastructure, cloud, and enterprise environments. He provided the technical direction and core outline for this piece. Matthew Romero, Veza’s Technical Product Marketing Manager with deep SecOps expertise, refined and shaped the content to focus on practical identity security challenges. Rob Rachwald, VP of Marketing, finalized the review and ensured the narrative aligned with the real-world priorities of modern security teams.

Together, they bring operational credibility, technical depth, and strategic clarity to the evolving identity security conversation.

Connect with them on LinkedIn:

Nathan Casey | Matthew Romero | Rob Rachwald

Table of Contents