Simplifying Identity Security: Why We Don’t Need Another Tool to Protect the Tool That Protects the Tool

Identity Security: Beyond Logins and Credentials 

For years, identity security has been approached through the lens of credentials and logins. 

If attackers steal passwords or privileged credentials, the assumption has been that security can be restored by: 

• Vaulting the credentials 
• Rotating secrets frequently 
• Enforcing MFA 
• Brokering privileged sessions 

This is why Privileged Access Management (PAM) became a foundational control in many security programs. 

Yet identity-driven breaches continue to dominate real-world incidents. 

Not because PAM failed, but because modern identity risk no longer lives where PAM was designed to operate. 

Identity Is the New Perimeter – and It’s Full of Blind Spots 

Today’s enterprise identity landscape is fragmented: 

• Active Directory and Entra ID 
• Human admins, service accounts, and non-human identities 
• Legacy systems, file shares, databases, ESXi, and network devices 
• Command-line tools, scripts, automation, and scheduled jobs 

Attackers don’t try to defeat identity controls directly - they operate around them. This is where traditional PAM quietly stops helping. 

Where PAM Falls Short (Even When Deployed Correctly) 

PAM does a good job inside its narrow lane: 

• Vaulting and brokering privileged credentials 
• Controlling interactive admin sessions 
• Enforcing MFA where possible 

But it struggles with how identity actually works inside real environments: 

1. PAM Doesn’t See Most Authentication Paths 

PAM rarely sits in the authentication path for: 

• Service-to-service authentication 
• LDAP binds from Linux, ESXi, firewalls 
• NTLM/Kerberos used by legacy systems 
• Scripts, scheduled tasks, background processes 

According to Gartner, comprehensive discovery is a well-known PAM pain point as no single tool discovers 100% of privileged accounts. 

That’s where your real risk lives. 

2. PAM Doesn’t Stop Lateral Movement 

In many environments, credential rotation does not automatically terminate access. 

Here’s why. 

In Active Directory–based environments, authentication commonly relies on Kerberos tickets. Once a user or service account has a valid Ticket Granting Ticket (TGT) or service ticket, that ticket can remain valid independently of the underlying password. 

In practice, this means: 

• An attacker holding a valid ticket may not need the password again 
• Access can continue until the ticket expires or is explicitly invalidated 
• Password hygiene improves future security, but does not always revoke current access 

This is why attackers can reuse stolen tickets, perform pass-the-ticket attacks, and move laterally without triggering fresh authentication. The 2026 Unit 42 Global Incident Response Report found that more than 99% of identities had excessive permissions, some unused for 60 days or more, creating a threat landscape where post-authentication lateral movement is easier than it should be simply because so many identities carry excessive privileges.  

Credential management alone cannot reliably stop this class of attack. 

3. PAM Creates Operational Overhead 

Service account protection in PAM tools often requires: 

• Large, manually maintained allow-lists 
• Hundreds of destinations per account 
• Humans being asked to make impossible decisions 

In addition to policy complexity, PAM deployments often introduce significant operational overhead. Organizations must deploy and maintain dedicated PAM infrastructure, including vault servers, connectors, databases, session proxies, html gateways and high-availability components. These systems require ongoing patching, upgrades and integrations. 

Operationally, this can also introduce friction for administrators and users, who may need to work through credential checkout processes, session brokers or additional authentication workflows. As environments scale and privileged accounts multiply, maintaining these systems and workflows becomes increasingly difficult. 

The result? Broad exceptions, over-permissive access, and controls being bypassed just to keep systems running.  

At scale, the operational burden becomes a security risk of its own. 

A Real-World Lesson: Identity-Based Attack Example  

In a recent widely reported breach, the organisation involved had: 

• Privileged Access Management (PAM) deployed 
• Multi-factor authentication enforced 
• A mature identity and security program 

Attackers gained initial access using previously compromised credentials associated with a third-party account. Those credentials were used to generate repeated MFA push notifications and access was ultimately granted - a pattern commonly referred to as MFA fatigue. 

After gaining internal access, the attacker performed internal discovery, scanning intranet resources and shared locations. During this phase, they identified PowerShell scripts stored on a network drive that contained hard-coded privileged secrets. 

Those secrets were powerful enough to authenticate directly to the PAM service. 

Using that access, the attacker was able to: 

• Retrieve additional privileged credentials 
• Escalate privileges 
• Spread access across multiple systems and administrative domains 

The key takeaway wasn’t that MFA or PAM failed. 

PAM was present, but it did not govern how identity was being exercised. 

Source: UpGuard analysis of the Uber breach

When Security Becomes a Chain of Dependencies 

After incidents like this, the industry response follows a familiar pattern: 

“We need another layer.” 

So, organisations introduce: 

• Centralised secrets vaults 
• Runtime secret injection mechanisms 
• Script and file-level access controls 
• CI/CD pipeline scanning for exposed credentials 

Then reality expands the scope. 

• We also have cloud identities → introduce additional identity governance and posture tooling 
• Now the cloud control plane needs protection → add privileged access controls for cloud management 
• Over time, the secrets infrastructure itself becomes critical to day-to-day operations 

At that point, the problem shifts – not to protection, but to dependency. 

Key protection systems are added. External key management follows. Formal root-key handling and recovery processes become necessary. 

Each step is rational. Each step solves a real problem. But each step adds another dependency in the trust chain. 

The Nesting Doll Problem in Security 

Over time, identity security tends to become layered on top of itself. Each new control is introduced to protect the previous one: credentials are protected by vaults, vaults depend on keys, keys depend on key-management processes, those processes depend on privileged identities, and those identities rely on the very systems they are meant to protect. 

At the same time, identity itself expands: 

• From on-prem to cloud 
• From humans to services and automation 
• From applications to control planes 
• From access to administration 

What emerges is not a single failure point, but a stack of nested dependencies – each one trusted implicitly by the next. 

This is the nesting doll problem. Every layer appears secure in isolation, but compromise one layer, and everything inside it becomes reachable – the blast radius grows with every additional dependency. 

The result is an identity architecture that is: 

• Harder to understand and manage as a whole 
• Fragile under real attack conditions 
• Dependent on perfect operation across multiple tightly coupled systems 

Risk hasn’t been eliminated – it has been spread across a growing chain of dependencies. 

Aligning Identity Security Strategy with Zero Trust  

Instead of asking, “How do we protect credentials better?” We should be asking, “Why is this identity allowed to authenticate here at all?” 

Because credentials - no matter how well managed - only prove identity, not the scope. 

Assume Credentials Will Be Exposed – and Make Them Useless 

Assuming credentials will be exposed isn’t a radical idea – it’s a Zero Trust principle. And it’s backed by real-world evidence, as credential abuse remains the #1 initial access vector for breaches.  

Rather than assuming credentials can be perfectly protected forever, Zero Networks assumes compromise will eventually happen – and designs controls accordingly. 

Zero Networks enforces identity policy at the point of authentication and at the asset being accessed, not just where credentials are stored. 

That means: 

• Restricting where an identity can authenticate 
• Enforcing allow, deny, or MFA - even for legacy protocols 
• Applying the same controls to human and non-human identities 
• Preventing lateral movement even when tickets or credentials are valid 

And critically, Zero Networks doesn’t just enforce identity – it also closes the network paths.  

Zero Networks operationalises this principle by shifting identity security from static protection to continuous enforcement. It continuously discovers how identities are actually used across the environment and automatically constrains that usage - enabling service accounts and administrative access only where explicitly required, while blocking all other paths by default. 

Policies are derived from observed login patterns rather than manual configuration, reducing human error and eliminating unnecessary privileges. As a result, common credential abuse techniques such as Pass-the-Ticket, Golden Ticket, and Kerberoasting are inherently mitigated, ensuring that even if credentials are exposed, they cannot be reused or leveraged for lateral movement. 

If an identity isn’t allowed: 

• Authentication is blocked 
• The port remains closed 
• The path simply doesn’t exist 

Identity enforcement and network segmentation work together – removing entire attack paths, not just monitoring them. 

Modern Identity Attacks Don’t Look Like Traditional Logins 

The most damaging identity attacks today don’t resemble classic login events. They look like: 

• Service-to-service authentication 
• Background processes 
• Scripts using valid credentials 
• Silent lateral movement using tickets, hashes, or tokens 

Controls that only activate during interactive sessions will never see this activity. To stop it, enforcement must occur: 

• At authentication and authorization time 
• On the destination asset 
• Regardless of how the credential or ticket was obtained 

That’s how attackers are stopped even when everything appears to be working. 

Identity Segmentation: the Control Plane Identity Security Has Been Missing 

PAM, secrets managers, cloud IAM tools, and HSMs all have their place. But they are supporting mechanisms, not the foundation. 

Identity segmentation changes the model: 

• Identities can authenticate only where explicitly permitted 
• Unexpected authentication paths are denied by default 
• Kerberos abuse and ticket replay lose their effectiveness 
• Network access disappears when policy says “no” 

Instead of trusting credentials and wrapping layers around them, trust is enforced at the point of access. 

We don’t need another tool to protect the tool that protects the tool – we need fewer assumptions about trust. 

By enforcing identity at the asset and network level, identity segmentation breaks the chain of dependencies instead of adding another layer inside it, eliminating identity risk rather than contributing more complexity. 

Learn how Zero Networks can help your organization strengthen and simplify comprehensive protection against identity-based threats – request a demo.