Over the past two years, we’ve watched a steady wave of acquisitions reshape the privileged access market. For many security leaders, that wave has now hit home. Your PAM vendor has been acquired, absorbed into a larger platform, and suddenly the roadmap you once relied on feels less certain.

This moment is easy to dismiss as “business as usual.” It is also one of the rare points where it actually makes sense to step back and reassess your PAM strategy with fresh eyes.

Vendor acquisitions are not inherently bad. In many cases, they validate the importance of the problem being solved. But they also change incentives, priorities, and pace. For organizations that already feel friction around access management, cloud scale, or AI readiness, this can be a practical opportunity to decide whether staying put still makes sense, or whether it’s time to look at alternatives built for where access is headed next.

Why PAM Consolidation Is Accelerating

The recent acquisition activity reflects a growing recognition that identity, and particularly privileged access, has become foundational to security in the cloud and increasingly to AI-driven environments.

In the past two years alone, we’ve seen:

• 2024
  • CyberArk acquires Venafi to expand coverage for non-human identities for $1.5 billion
  • BeyondTrust acquires Entitle for roughly $150M
• 2025
  • Palo Alto Networks acquire CyberArk for $25B
  • Okta acquires Axiom for approximately $100M
• 2026
  • CrowdStrike acquires SGNL for $740M
  • Delinea acquires StrongDM for undisclosed amount 

There are two clear signals here.

First, large security platforms understand that controlling privileged access is essential as organizations move toward AI-driven operations. They are buying capabilities to ensure they are not caught flat-footed, the way many were during the initial cloud transition.

Second, identity-focused vendors recognize that legacy PAM architectures built for on-prem environments are no longer sufficient. The shift to cloud infrastructure, API-driven services, and autonomous systems demands a different approach to access control.

For customers, however, these acquisitions raise an important question. Does the new parent company’s vision align with what you actually need from PAM going forward?

How Can an Acquisition Impact Your PAM Strategy Right Now?

When a startup is acquired by a large platform, the technology does not disappear overnight. But the dynamics around it often change.

Product direction may shift toward platform alignment rather than customer-driven innovation. Roadmaps slow as teams integrate codebases and processes. Support models change. Features that were once core can become secondary to broader platform goals.

This does not automatically make the solution worse. But it does change the calculus for customers who were relying on that vendor to solve specific access challenges at cloud scale.

More importantly, it creates a natural pause point. A chance to ask whether your current PAM approach is positioned to handle what comes next, not just what worked yesterday.

Identity, Cloud Scale, and Why Static Models Fell Behind

Privileged access management worked reasonably well in the on-prem era because the environment was stable.

Infrastructure changed infrequently. Permissions were coarse-grained. Identities were almost entirely human. Static roles and periodic access reviews, while inefficient, were manageable.

That world no longer exists.

The move to the cloud fundamentally changed the problem:

• Infrastructure adoption accelerated faster than most security programs anticipated
• Resources multiplied and permissions became increasingly granular
• Change shifted from quarterly to daily

Even when identity management was limited to humans, static roles and periodic reviews struggled to keep up.

Then came the explosion of non-human identities.

Service accounts, workload identities, API tokens, CI/CD pipelines, and automation are now embedded everywhere. These identities are predictable in function, but they exist at massive scale. Estimates now place the ratio of non-human identities to humans at roughly 150:1.

Most of these identities sit outside traditional IdPs like Okta or Entra ID. Visibility is fragmented. Lifecycle management is weak. Permissions are often left overly broad because teams are understandably afraid of breaking production workflows.

Now we are entering the Agentic AI era, where earlier cracks widen further.

AI agents combine human-like autonomy with machine speed and scale. They decide what to access, when to act, and how to proceed, often without direct human oversight. If non-human identities were already a scaling challenge, AI is a multiplier.

This is why identity has become the limiting factor for both cloud security and AI adoption.

Why “Modern PAM” Still Fell Short

Some newer PAM solutions attempted to address cloud access challenges, but many carried forward assumptions that no longer hold.

Tools like StrongDM and Teleport were built around proxies and local network concepts. They change how engineers connect, introduce operational overhead, and require agents and pre-created roles. That model can work in certain environments, but it still slows teams and shifts complexity onto admins.

Other tools, like Entitle, introduced API-based connectivity but continued to rely on static, pre-defined roles. That reduces some friction, but it does not eliminate role sprawl, privilege accumulation, or manual maintenance.

The common thread is static management. Roles are still defined ahead of time, permissions accumulate over time, and reviews happen after the fact.

That model struggles under continuous change.

Legacy PAM vs Modern PAM vs Cloud PAM

Below is a high-level comparison of how these approaches differ. This table is meant to frame the discussion, not replace deeper evaluation.

Why Platformization Is Not Always the Best Answer

There is a natural pull toward platforms. A single vendor, a single contract, fewer integrations. In theory, this simplifies life.

In practice, platformization comes with trade-offs that are worth considering, especially after an acquisition:

• Best-of-breed capabilities are often diluted in favor of broad coverage
• Innovation slows as features compete for platform priority
• Customer feedback loops lengthen
• Product responsiveness can suffer

Ironically, these are often the same reasons the startup was attractive in the first place.

For security leaders, the question is not whether platforms are good or bad. It is whether a platform-centric roadmap aligns with the access challenges you are actively facing.

What to Look for When Re-Evaluating Your PAM Strategy

As organizations reassess their PAM approach, a few themes consistently surface:

• Can access decisions adapt continuously as context changes?
• Are privileges scoped dynamically per task, not per role?
• Is access enforced directly through cloud APIs?
• Does the model reduce operational overhead instead of shifting it?
• Can the same approach govern humans, non-humans, and AI?

These are not theoretical questions. They determine whether access becomes an enabler or a bottleneck as environments continue to evolve.

How Apono Approaches Cloud Privileged Access

At Apono, we start from a simple premise. Access decisions cannot be static in environments that change constantly.

Rather than managing large catalogs of pre-defined roles, we generate tightly scoped permissions on demand and remove them automatically when the task is complete. Access policies are driven by risk and real-time context, not assumptions made weeks or months earlier.

Our approach focuses on:

• Continuous, context-aware access enforcement
• Dynamic role creation that eliminates standing privileges
• Automated policy adaptation as resources and usage change
• Consistent governance across humans, non-human identities, and AI

Because the model is built around risk rather than identity type, it extends naturally to Agentic AI without introducing separate control frameworks or manual processes.

Turning Consolidation Into a Strategic Advantage

Vendor acquisitions are a reality of the security market. They can bring stability, scale, and resources. They can also create moments where customers pause and reassess.

If your PAM vendor has been acquired, this isn’t a crisis. It’s an opportunity to step back and ask whether your access strategy is aligned with where your organization is going — not just where it’s been.

Identity security today isn’t about quarterly reviews or static roles. It’s about continuous enforcement that can keep up with cloud infrastructure, non-human identities, and increasingly automated access patterns.

Before committing to a new roadmap or long-term contract, it’s worth pressure-testing your requirements against how access actually behaves in modern environments — and what recent consolidation signals about where the market is heading.

Our PAM Buyer Guide was created for security and engineering leaders navigating this exact moment.

It outlines what to evaluate when reviewing PAM strategy today, including cloud access models, non-human identities, and AI-driven access — and where legacy assumptions often break down.

Download the PAM Buyer Guide to ground your decision in the right criteria, or book a demo if you want to see how cloud-native privileged access works in practice.

Nobody breaks into AWS by logging in as root and announcing themselves. They start with something small, such as a leaked key. IAM:PassRole is the kind of permission that creates a clean privilege-escalation path if you’re not watching it closely.

The problem is that IAM:PassRole slips through because it’s not obviously “admin.” It’s a capability that allows an identity to borrow someone else’s privileges, especially when teams scale, and machine identities are granted standing permissions to keep things moving. 

These non-human identities (NHIs) often hold persistent PassRole permissions that manual audits cannot track. When you misconfigure PassRole, you are essentially building an invisible attack path for privilege escalation. But, with credential abuse appearing in 22% of analyzed breaches as the top initial attack vector, you can’t afford to cut corners. 

What is IAM:PassRole? A Quick Overview for AWS Users

IAM:PassRole allows a principal to “pass” an IAM role to an AWS service, such as EC2, Lambda, or ECS.

AWS services don’t automatically get permission to touch your resources. So, you have to give them a role to work with. If you launch an EC2 instance that needs to write to an S3 bucket, you don’t give the EC2 service those permissions directly. You attach an IAM role with S3 access and pass that role to the instance at launch.

It’s vital to distinguish PassRole from AssumeRole:

• AssumeRole is when an identity takes on a role to inherit its permissions directly. 
• PassRole is when an identity assigns a role to a service, allowing the service to perform tasks.

It is a core part of identity and access governance in AWS because you’re defining who can delegate privileges to workloads. Everyday use cases of IAM:PassRole include assigning execution roles to ECS tasks, allowing Lambda functions to access backend resources, or enabling CI/CD pipelines to launch new workloads.

Why are IAM:PassRole misconfigurations a common attack vector?

Misconfigured PassRole permissions are a target because they determine which roles can be used by which workloads. If you don’t scope this correctly, you can unintentionally grant escalated privileges to developers, pipelines, or compromised NHIs.

Most attackers don’t go straight for your most valuable server. They go for the easy win through a low-privilege identity that has both pass roles and launch compute. With IAM:PassRole, plus something like ec2:RunInstances, attackers can create a new instance, attach an admin-level role, and pull the credentials from the instance metadata service.

Machine identities make this easier because they’re often always-on and rarely watched as closely as human users. Furthermore, even a well-scoped PassRole permission can be undermined if the trust policy on the target role is too permissive, allowing unauthorized services to assume it.

PassRole abuse is so difficult to prevent with periodic reviews or static guardrails alone. By the time a risky delegation is discovered, the permission has often already been exercised by a bot or compromised token long before a human ever notices.  At scale, you need automated access control systems that can spot PassRole use outside normal deployment patterns and shrink the window for misuse.

7 Pitfalls to Consider When Configuring IAM:PassRole

1. Granting PassRole Permissions Too Broadly

Broad permissions involve using “Resource”: “*” in a policy instead of naming specific Role ARNs. It is common in “Developer” managed policies designed for speed, where engineers are given a blank check to attach any existing role to a new resource. By failing to specify resources, you allow the user to utilize every identity in the account as a potential stepping stone.

Implications:

• A principal can pass any role in the entire account to a service.
• If the user can launch compute, they can grant themselves AdministratorAccess by passing the most powerful role to a resource they control.
• It removes the primary guardrail meant to stop a single compromised credential from taking over the account.

2. Allowing Roles That Can Escalate to Admin Privileges

Sometimes the problem is that the user can pass a role that has too many permissions. If they can pass roles with AdministratorAccess or PowerUserAccess, they don’t need admin permissions directly. Even with a locked-down user policy, they can still hand an admin role to a service.

Implications:

• The user effectively becomes an administrator because they can create a resource with those powers.
• It creates a bypass for restrictive identity policies that were intended to limit access for that specific user.
• It expands the blast radius of a compromised account to include the entire cloud environment.

3. Misconfigured Trust Policies That Open the Door to Abuse

Misconfigurations occur when a target role has a trust policy (the AssumeRolePolicyDocument) that is too wide, such as trusting an entire account ID or using a wildcard Principal. This stage is where traditional IAM reviews and static policies often fail, especially when most of the identities involved are non-human.

While your PassRole policy may appear secure on the surface, a loose trust policy on the role itself means the receiving end of the delegation remains unprotected. When this architectural gap exists, your security logic effectively stops halfway. You might have restricted the delegation process, but the role’s entry point remains dangerously exposed.

Implications:

• Restricting who can pass the role becomes irrelevant if a weak trust policy allows any authorized service in the account to assume it.
• It invites “confused deputy” scenarios where a legitimate service is tricked into acting on behalf of an unauthorized user.
• The essential security handshake between the delegator and the role is broken, leaving the delegation open to exploitation.

4. Overlooking NHIs Using PassRole

Pipelines and bots often have PassRole access to ensure automation continues smoothly. Because these are not people, they usually miss out on regular security audits and identity lifecycle reviews. These automation accounts often reside in the shadows, holding permanent, high-impact permissions that are vulnerable to exploitation if a secret is ever leaked from a code repository or build environment. 

From an attacker’s perspective, NHIs are the most reliable access brokers in the environment. If your CI/CD secrets aren’t tightly controlled, secret management becomes central to your IAM strategy. 

Implications:

• NHIs lack MFA protection, making them a path of least resistance for attackers.
• A leaked CI/CD token provides a persistent “access broker” for horizontal movement.
• Attackers can use these identities to pass admin roles without triggering standard “new user” alerts.

5. Relying on Long-Lived Credentials With PassRole Permissions

IAM:PassRole shows up in real life in the worst places. It looks like old scripts nobody maintains or credentials on a developer’s laptop. Once PassRole is tied to long-lived credentials, it becomes a permanent privilege. The attacker can return tomorrow, next week, or at any time, and continue passing roles until you shut it down. And, if the key was exposed through a compromised dev tool or dependency, you’re dealing with supply chain risk plus standing privilege. 

Implications:

• Leaked keys provide an indefinite window for an attacker to escalate privileges.
• Unlike session-based access, these keys don’t expire and require manual revocation.
• It increases the presence of “dormant” privileged access on forgotten servers.

6. Not Restricting Which Roles Can Be Passed to Which Services

Failing to restrict roles happens when a policy lacks the iam:PassedToService condition key. It allows a role to be passed to any service principal in the account rather than just the one it was built for. Without this constraint, a role designed with specific guardrails for a Lambda function could be repurposed by an attacker for an EC2 instance, where they have much more interactive control.

Implications:

• A role meant for a restricted Lambda function could be passed to an EC2 instance instead.
• Attackers can move ephemeral permissions into an interactive environment where they have shell access.
• It bypasses the governance of short-lived environments, allowing roles to be used on unauthorized resource types.

Source

7. Lack of Monitoring for Role Use, Abuse, or Drift

As headcount and automation increase, your original access model rarely survives unchanged. If you want to close the gap created by IAM drift, you need detection that flags any PassRole activity that doesn’t match your usual deployment behavior. Otherwise, an attacker can blend in and use PassRole to move laterally without much resistance. Monitoring is one of those areas where teams have to automate processes, as manual reviews won’t catch off-hours role passing reliably.

Implications:

• Leaving permissions “always on” turns a functional tool into a permanent vulnerability.
• Attackers often wait for off-hours to pass roles, knowing detection is less likely when the team is offline.
• You lose the ability to enforce strict deployment windows, which are vital for limiting when role passage can actually occur.

Table 1: PassRole Pitfalls at a Glance

Pitfall	What goes wrong	Why it’s dangerous
1. PassRole is too broad	“Resource”: “*” lets a principal pass any role.	A compromised identity can attach high-privilege roles and escalate fast.
2. Passable roles include admin power	Admin/PowerUser roles are in the “passable” set.	Users/pipelines can indirectly gain admin via a service they control.
3. Trust policy is too permissive	The role trusts wide principals/accounts/services.	PassRole controls are bypassed if the role can be assumed too freely.
4. NHIs aren’t governed	Pipelines/bots keep PassRole with little review.	Stolen tokens become reliable, low-noise escalation paths.
5. Long-lived creds have PassRole	Static access keys retain PassRole indefinitely.	Leaked keys enable persistent privilege escalation until revoked.
6. No iam:PassedToService restriction	Roles can be passed to unintended services.	Attackers can move roles into EC2 for interactive control.
7. No monitoring for PassRole use	PassRole events aren’t tracked or alerted on.	Abuse can happen off-hours or outside deploy windows undetected.

How to Configure IAM:PassRole Safely

Anywhere you see “Resource”: “*”,  assume attackers will eventually abuse it and replace it with specific Role ARNs. Then, you can ensure that staging environments can’t pass or assume production roles, even if someone mis-clicks. 

Keeping an inventory of which humans and NHIs truly need PassRole is a crucial step in getting stricter about trust policies. Of course, you’ll need to delete anything stale. Once you’ve verified that PassRole is time-bound and monitored, it should appear during known workflows, such as break-glass events. The more you can standardize those workflows with clear owners, approvals, and workflow integrations, the harder it is for risky role passing to hide in the noise. If it appears outside of these patterns, especially from NHIs, hit the alarms.  

It’s important to note that Zero Trust isn’t a one-and-done configuration. You can build all these controls with IAM, but enforcing them consistently (especially for NHIs) becomes operationally heavy without automated access control systems.

From IAM Hygiene to Identity-First Control

IAM:PassRole creeps because it’s used for a quick fix, then becomes too convenient. Eventually, it’s a default dependency, especially for automation use cases. Over time, these privilege escalation paths become increasingly difficult to distinguish until attackers target them. 

Apono takes always-on delegation off the table and replaces it with Just-In-Time access. With Apono, access comes hand-in-hand with context and is approved in the workflow and time-bound by default. You’ll get the control and auditability you need for production environments without turning engineering into a ticket queue.

Not sure how much standing privilege still exists in your environment? Start with the Zero Standing Privilege (ZSP) Checklist for a quick self-assessment.Then, when you’re ready to go deeper, download the Apono Privilege Discovery & Remediation Datasheet to see how teams identify and eliminate risky access across both human and non-human identities.

MongoDB powers some of the world’s most modern applications .Everything from self-managed deployments to fully managed cloud environments run with MongoDB Atlas. But as teams scale across environments and projects, managing secure access becomes increasingly complex.

Apono brings Just-in-Time, least-privilege access to MongoDB services across MongoDB, MongoDB Atlas, and MongoDB Atlas Portal.

One Access Layer for Every MongoDB Deployment

Whether you’re running MongoDB in the cloud or using fully managed MongoDB Atlas, Apono provides a single access governance model with automatic resource discovery and just-in-time (JIT) access across all MongoDB deployments.

Across MongoDB, MongoDB Atlas, and the MongoDB Atlas Portal, Apono delivers a unified access governance layer that automatically discovers clusters, databases, collections, and roles, and enforces secure, just-in-time, least-privilege access at scale. By centralizing discovery and policy-driven access workflows across self-managed and cloud-managed MongoDB environments – including multiple Atlas organizations and projects – Apono enables teams to manage access consistently, whether connecting to a single cluster or operating across many.

Instead of managing permissions statically and separately across environments, Apono unifies MongoDB access under a single, policy-driven control plane. This enables security teams to define access policies once and apply them consistently across all MongoDB resources, no matter how many projects, databases, or clusters exist.

Just-in-Time Access with Zero Standing Privileges

The integration of Apono and MongoDB eliminates permanent MongoDB permissions by enforcing:

• Just-in-Time (JIT) access.
  
• Just-Enough-access (JEA) permissions.
  
• Automatic revocation when access expires.
  

Users only have access when they need it,dramatically reducing blast radius and credential sprawl.

Self-Service Access with Centralized Control

With Apono and MongoDB  integrations, engineers, DevOps, and data teams can request access to MongoDB resources through Slack, Teams, CLI, Backstage, MCP servers, or the Apono portal. Access is granted automatically based on company policy, approvals, and context – eliminating tickets while preserving security and oversight.

Auditability Built In

Every access request is fully logged, including who accessed which MongoDB or Atlas resource, for how long, and under what approval. This provides clear audit trails for compliance frameworks such as SOC 2 and ISO 27001.

Better, More Secure MongoDB Access Starts Here

Together, MongoDB, MongoDB Atlas, and MongoDB Atlas Portal deliver the scale and performance modern applications demand. Apono supports your scale and velocity by ensuring that access is  secure and governed at every layer.

Better security. Faster access. One unified access model. Better together.

Contact our team for a demo and see how you can start implementing Zero Standing Privileges (ZSP) across the MongoDB ecosystem today.

Security powerhouse CrowdStrike made headlines this week with a major acquisition in the identity space with their purchase of SGNL for a reported $740 million. If you’re wondering why did CrowdStrike buy SGNL, you’re asking the right question. And you’re probably not alone.

Over the past year, we’ve watched some of the largest security platforms in the world spend real money acquiring identity security companies. 

From the outside, it might look like platforms buying solutions in a standard consolidation story. From the inside, it looks more like preparation. Specifically, preparation for a future in which identity becomes the most critical control plane for securing cloud environments and the AI systems now operating within them.

At Apono, we see this acquisition as something to celebrate. Not because a competitor was acquired, but because it validates a reality we’ve been living in for years. Identity security has reached a scale and complexity that legacy approaches simply cannot handle. And with AI entering the picture, that gap is becoming impossible to ignore.

Consolidation of Privileged Access Is a Sign of Challenges to Come

CrowdStrike’s acquisition of SGNL is part of a much broader pattern. Over the last 18 months, security vendors have been moving aggressively to close gaps in identity, access, and cloud authorization.

A few examples stand out:

• Palo Alto Networks acquiring CyberArk $25B
• Okta acquiring Axiom for roughly $100M
• BeyondTrust acquiring Entitle for around $150M

Just to name a few.

Now the latest news to break was today’s announcement of Delinea’s acquisition of StrongDM, doubling down on the fact that the big players in the security industry are working hard to ensure that they’re not left flat-footed on identity for Agentic like they were with the advent of the cloud. 

And that’s the backdrop for why did CrowdStrike buy SGNL? It’s a recognition that Identity isn’t a feature anymore. Managing privileged access is simply foundational. But how did we get here?

Why Identity Has Become the Limiting Factor for AI

The pressure around identity and access did not appear overnight. It built up in layers as environments changed faster than access models could adapt.

Before the cloud, access management lived in a very different world:

• Infrastructure was static and long-lived, changing infrequently and predictably
  
• Identities were almost entirely human and relatively easy to enumerate
  
• Permissions were coarse-grained, often all-or-nothing access to a system
  
• Roles were created once and reused for years with minimal adjustment
  
• Access reviews happened periodically and were simply approved, causing access creep.
  
• Manual approvals and standing access were inefficient but manageable
  

In that environment, static roles and slow processes were imperfect, but they mostly worked. The problem is that the world they were built for no longer exists.

It started with the move to the cloud:

• Infrastructure adoption accelerated faster than most security programs anticipated
  
• Resources multiplied, permissions became far more granular, and change shifted from quarterly to daily
  
• Even with only human identities, static roles and periodic access reviews quickly stopped scaling
  

Then came the explosion of non-human identities:

• Service accounts, workload identities, API tokens, CI/CD pipelines, and automation spread everywhere
  
• These identities are predictable in function but exist at a massive scale
  
• The ratio of non-human identities to humans is now estimated at roughly 150:1
  
• Most sit outside traditional IdPs, with fragmented visibility, weak lifecycle controls, and permissions left overly broad to avoid breaking production
  

Now we are entering the Agentic AI era, and earlier cracks are widening:

• Agentic AI combines human-like autonomy with machine speed and scale
  
• These systems decide what to access, when to act, and how to proceed, often without direct human oversight
  
• They ingest untrusted inputs, interact across systems, and operate continuously
  

If non-human identities were already a scaling problem, Agentic AI is a multiplier.

As it stands, AI vendors will manage their models, just as cloud providers manage infrastructure. But organizations still own access. They remain responsible for what identities can reach, what actions they can perform, and where guardrails exist when things go wrong.

And this is where many organizations are running into a hard truth: they do not yet have their identities under control, human or otherwise. AI does not introduce new access failures. It accelerates the ones that already exist.

As Den Jones of 909Cyber put it in a recent Forbes article by Tony Bradley, “Most companies don’t struggle with AI because the models are bad. They struggle because their systems, identities, and data aren’t ready for it.”

This realization that they need to get their privileged access in order has led both customer organizations and big security vendors to seek out Privileged Access Management tools to reduce their access risk.

Why Dynamic Authorization Is the Real Shift

What SGNL got right, and what we have been building toward at Apono, is that access decisions cannot be static. They need to be continuous, contextual, and risk-driven. That applies equally to human users, non-human identities, and now AI-driven ones.

This is exactly what CrowdStrike’s President Michael Sentonas pointed to in his announcement blog. Managing access across all identity types requires decisions that adapt in real time, not policies that are frozen at creation and cleaned up later.

What we see from Sentonas’ post is that the real value of managing access in the cloud is not in turning access on and off. It is about continuously aligning access decisions with risk as identities, resources, and usage patterns change.

That is what dynamic authorization actually means, and why we believe that Apono is well placed to lead the identity security industry into the Agentic AI age. 

How We Think About This at Apono

At Apono, we start from a simple position: access decisions cannot be static in constantly changing environments. In the cloud, defining access once and reviewing it later is disconnected from how work actually happens.

Resources change, teams shift, and usage patterns evolve continuously. Access controls have to keep pace with that reality.

Our approach is built around a few core principles:

• Access decisions should be driven by risk and real-time context, not pre-defined roles
  
• Privileges should exist only for the duration and scope of a specific task
  
• The same governance model must apply across humans, non-human identities, and AI
  

Instead of managing large catalogs of static roles, we provide tightly scoped permissions on demand and remove them automatically when the task is complete. This eliminates standing access, reduces privilege sprawl, and keeps least privilege aligned with how systems are actually used.

Because our Just-in-Time model is based on context and risk rather than identity type, it extends naturally to Agentic AI without introducing a separate control framework.

Why This Acquisition Validates the Direction

If you don’t have human and machine identities under control today, you won’t be ready for AI tomorrow. Period.

The SGNL acquisition, followed closely by StrongDM’s announcement, reinforces the same message. Security platforms are racing to catch up to the reality that identity is now the control plane for everything else.

And they are racing to catch up.

What Comes Next

Our prediction is simple. We will continue to see consolidation in the privileged access sector, heating up alongside the general AI space. 

For security leaders, the takeaway is not about vendors. It’s about readiness. Identity security is no longer about quarterly reviews or static roles. It’s about continuous enforcement at scale.

And that’s why this moment matters.If you’re interested in how this looks in practice, you can explore Apono’s approach to Just-in-Time, Just-Enough access and see how identity can become an enabler rather than a blocker as AI becomes part of everyday operations.

As cloud environments sprawl and engineering teams scale, the number of identities you manage has exploded. It’s no longer just employees and contractors; CI/CD pipelines, service accounts, API tokens, and AI-powered agents are all asking for access to production systems and sensitive data. 

It’s no shock that identity has become a top-line priority for security and platform leaders. 78% of organizations plan to ramp up spending on identity and access management tools to ease concerns over identity-based attacks that lead to phishing and lateral movement. The challenge in choosing an IAM tool is finding one with the capability to scale with your cloud footprint. 

What are identity and access management tools?

Identity and access management (IAM) tools help you answer two core questions: Who is this?” and “What are they allowed to do?”

IAM tools verify identities through authentication methods such as SSO and MFA, then enforce fine-grained permissions across your cloud providers, infrastructure, and SaaS applications. Rather than letting each system manage its own users and permissions, IAM tools centralize all identity data and access workflows, allowing DevOps and security teams to apply consistent, least-privilege controls.

When people say “identity and access management tools,” they’re usually talking about a whole stack. Not just classic IAM platforms, but also privileged access management (PAM), Just-in-Time (JIT) access orchestration, and secret scanning tools. JIT in particular has become a critical extension of modern IAM strategies.

Cloud-native environments are flooded with non-human identities (NHIs) like service accounts, workloads, and bots, each tied to secrets such as API keys and certificates.

This proliferation means IAM tools now need to govern both human and non-human access with the same rigor to avoid silent, large-scale over-permissioning. A recent State of Secrets Sprawl analysis highlighted that as NHIs multiply, so do the secrets tied to them. Traditional, reactive secrets management simply isn’t enough in automated, cloud-native environments.

Types of Identity and Access Management Tools

Modern IAM spans several categories, and many solutions overlap. Here are the core types engineering and security teams rely on:

• Cloud-native IAM (AWS, Azure, GCP): The built-in controls you use to manage roles, policies, and permissions directly in your cloud accounts.
• JIT and time-bound access platforms: Hand out temporary, scoped access only when it’s needed, so you can actually enforce least privilege across infra and SaaS.
• Machine identity & secrets management: Systems that keep API keys, tokens, certificates, and other credentials for human and non-human identities safe.
• PAM: Platforms that control and log elevated access, increasingly leaning on JIT so admins don’t carry standing privileges.
• Authentication tools (SSO, MFA, passwordless): Services that prove who someone is but don’t decide what that identity can do after they’re signed in.
• Access governance & authorization platforms: Tools that give you visibility and control over entitlements so you can right-size permissions and reduce continuous threat exposure.

Benefits of Identity and Access Management Tools

Reduced Risk Through Least Privilege

By centralizing roles, policies, and entitlements, IAM tools eliminate excessive permissions, especially among NHIs that accumulate broad access over time. This approach turns Zero Trust from a slideware concept into something your engineers feel day-to-day.

Stronger Protection Against Identity-Based Attacks

When attackers compromise a human or machine identity, they typically exploit misconfigured roles and standing privileges. IAM platforms strengthen defenses with features like real-time access controls that make identity-based intrusions significantly harder to execute.

Improved Operational Efficiency for Engineering Teams

Instead of relying on ad hoc approvals or ticket queues, teams can automate access flows, freeing up DevOps and platform engineers to focus on higher-impact work.

Better Compliance and Audit Readiness

IAM tools offer automated logging and entitlement reviews to reduce audit fatigue and eliminate spreadsheet-driven processes, similar to how efficient laboratory management practices emphasize traceable, well-documented workflows and data integrity.

Scalable Access Management for Cloud-Native Environments

IAM solutions scale policy enforcement and support dynamic access models, such as JIT, ensuring security remains consistent even as you adopt multi-account cloud structures and AI-driven automation. 

Key Features to Look For in an Identity and Access Management Tool

• Least-privilege automation: Look for IAM platforms that automate dynamic roles and fine-grained policies, rather than relying on one-off cleanup projects. 
• JIT and time-bound access control:  Prioritize tools that support time-bound, scoped access and auto-expiring permissions so engineers don’t keep privileges “just in case.”
• NHI security: Features that can discover, right-size, and continuously govern NHIs and their secrets are essential. 
• Compliance and audit readiness: Strong options provide centralized logs, reporting features, and access review workflows for repeatable auditing.
• Cloud-native integrations: API-driven, cloud-native solutions embed access control directly into developer workflows (e.g., Slack, Teams, CLI) and manage policies as code as your environment scales.

10 Top Identity and Access Management Tools

1. Omada Identity Cloud 

Omada Identity Cloud is a SaaS-delivered Identity Governance and Administration (IGA) platform focused on lifecycle management and access governance. It delivers policy-based controls and offers no-code configuration.

Main Features:

• Risk analytics and AI-driven recommendations to identify anomalous access
• SaaS delivery with standardized implementation program 
• Access governance with policy- and role-based controls

Price: By inquiry.

Best for: Deep identity governance and lifecycle management. 

Review: “I love the clean interface, simplicity of features and controls, and how quick it is to edit user permissions.”

2. Apono

Apono is a cloud-native access management and privileged access platform that automates JIT and Just-Enough-Privilege (JEP) access across your entire stack. Instead of managing static roles or manual tickets, DevOps and platform teams define dynamic access flows that grant granular, time-bound permissions only when needed, then revoke them automatically. Apono is designed to eliminate risky standing permissions for both human and non-human identities without slowing down engineers.

Main Features:

• Enforces automated JIT access policies across cloud providers, databases, and internal tools, drastically reducing standing privileges
• Engineers request granular access directly from Slack, Microsoft Teams, or CLI, with policy-driven approvals
• Pre-configured emergency and on-call access patterns speed up incident response
• Centralized view of who can access what (including NHIs), with automated reports to support compliance audits

Price: Contact the Apono team for a tailored quote.

Best for: Cloud-native engineering and DevOps organizations that need to eliminate standing permissions and automate JIT and JEP access.

Review: “Quick and easy config to integrate access control with a myriad of service providers and data stores. For the admin, it’s pretty straightforward to define and implement access flows. For the requester, all they have to do is ask for it via slack and they get what they need within seconds.”

3. Securden Unified PAM

Securden Unified PAM focuses on securing high-risk accounts and keys across servers, databases, network devices, and SaaS. The platform supports on-prem and cloud deployments, making it flexible for hybrid environments.

Main Features:

• Centralized vault for privileged account passwords and application credentials
• Session management with monitoring and recording 
• Integrations with common IdPs (e.g., Entra ID, Okta)

Price: Quote-based pricing depending on your deployment option.

Best for: Traditional Privileged Access Management. 

Review: “PAM got our own passwords safe and gave us a single, centralized way to manage customers’ passwords and remote access through a single interface.”

4. Segura

Next up is Segura, an identity security platform that evolved from a PAM solution into a broader identity and access management stack. It provides centralized control over privileged accounts, session recording, and access workflows while also covering general identity and access use cases.

Main Features:

• Built-in integrations to record all privileged sessions for forensic analysis
• Governance over both privileged and non-privileged identities through a unified platform
• JIT elevation and detailed session recording for admins and service accounts

Price: By inquiry.

Best for: All-in-one PAM and identity security platform.

Review: “I would especially highlight the simplicity and speed of use combined with the breadth of functionalities in a single, highly integrated platform.”

5. Doppler

As a secrets and configuration management platform, Doppler centralizes API keys and environment variables for engineering teams. Instead of scattering secrets across CI/CD pipelines and cloud services, Doppler syncs them automatically to apps and infrastructure. 

Main Features:

• Audit logs, secret health analytics, and alerts via Slack and Teams
• Dynamic secrets and automatic rotation capabilities 
• Centralized secrets store with automatic syncing into CI/CD and runtime environments

Price: Free Developer plan for up to 3 users; Team plan starting around $21/user/month; Enterprise tier is quote-based.

Best for: Centralized secrets and configuration management.

Review: “I really appreciate both the command-line interface and the user interface for managing secrets and keeping them in sync.”

6. Seamfix iAM

Seamfix iAM is a workforce and citizen identity platform focused on centralized identity lifecycle management and MFA. It provides a unified console to manage user accounts, roles, and application access, helping teams replace manual access management with policy-based automation.

Main Features:

• Strong authentication with MFA and support for biometric login
• Role-based access control and centralized policy management 
• Pre-built integrations with common enterprise and SaaS applications 

Price: By inquiry.

Best for: Centralized workforce or citizen identity management and MFA.

Review: Not available.

7. Akeyless

Akeyless is a cloud-native secrets management and modern PAM platform delivered as SaaS. Its “vaultless” architecture is designed to reduce traditional vault complexity while still providing enterprise-grade security and performance.

Main Features:

• Vaultless secrets management to centralize and secure all secret types
• Certificate lifecycle management and “bring your own vault” connectors
• SaaS delivery with high availability and integrations into CI/CD pipelines

Price: By inquiry.

Best for: Consolidating secrets management and modern PAM.

Review: “Akeyless is a one-stop shop for everything—storing secrets, identity services, connecting to third-party tools, encryption, and more.”

8. WSO2 Identity Server

As an open-source, API-driven IAM platform, WSO2 Identity Server supports SSO and MFA use cases. With its extensible architecture, WSO2 is well-suited to organizations that want to deeply customize identity flows. 

Main Features:

• High extensibility and API-first design, allowing custom authenticators and integrations
• Support for modern cryptographic standards, including emerging post-quantum-ready capabilities
• Standards-based SSO and identity federation 

Price: Free open-source version. Enterprise support is quote-based.

Best for: Customizable, open-source IAM/CIAM platform.

Review: “What I appreciate most about WSO2 Identity Server is its comprehensive support for identity federation and single sign-on (SSO).”

9. FusionAuth

FusionAuth is a developer-focused CIAM platform that can run self-hosted or as a managed cloud service. It provides authentication, SSO, MFA, social login, and user management for consumer-facing applications.

Main Features:

• Flexible deployment: self-host via Docker/Kubernetes or use FusionAuth Cloud
• Advanced features like WebAuthn/passkeys and breached password detection
• SDKs and integration options designed for developer control

Price: The Community option is free. Then, prices rise from $125/month for Starter to $3,300/month for Enterprise.

Best for: Customer-facing authentication and CIAM workflows.

Review: “Their documentation is professionally written and well organized; that, along with their “Ask AI” feature, has made it possible to accomplish some sophisticated configurations.”

10. Infisical

Infisical is an open-source secrets management platform that centralizes application configuration and secrets. It brings secrets, IAM-style access controls, and auditability into a single, Git-integrated workflow.

Main Features:

• Wide integration coverage: GitHub, GitLab, Kubernetes, Docker, major cloud secret managers, etc.
• Temporary access and automated secret rotation tied to expiration
• Enterprise-grade governance via audit logs.

Price: Free open-source version, and enterprise is quote-based.                                                                 

Best for: Modern, open-source secrets management platform with strong RBAC.

Review: “It is very easy to set up and use – even for some very complex infrastructure environments.”

Table 1: IAM Solution Summary

Tool	Category	Key Focus / Strengths	Deployment Model
Omada Identity Cloud	IGA / Enterprise IAM	Identity lifecycle, access governance, certification campaigns, compliance	SaaS (cloud IGA)
Apono	JIT Access / Modern PAM / Access Orchestration	Automated JIT & JEP, auto-expiring permissions, ChatOps-based access, cloud-native integrations	Cloud-native SaaS, API-driven
Securden Unified PAM	Privileged Access Management (PAM)	Password & key vaulting, credential rotation, privileged session monitoring	On-prem, private cloud, hybrid
Segura (senhasegura)	Identity Security / PAM + IAM	Privileged access, secrets management, identity governance, compliance reporting	SaaS and on-prem options
Doppler	Secrets & Config Management	Centralized secrets, CI/CD environment syncing, developer-first workflows	SaaS
Seamfix iAM	Workforce / Citizen IAM	Lifecycle management, MFA, RBAC, centralized policy-based access	Enterprise / government deployments
Akeyless	Secrets Management + Modern PAM	Vaultless secrets, remote access, certificate lifecycle automation, multi-cloud support	SaaS (cloud-native)
WSO2 Identity Server	Open-Source IAM / CIAM	Standards-based SSO, MFA, federation, extensible identity workflows	Open-source; self-hosted or managed
FusionAuth	CIAM / App Authentication	Developer-friendly auth, SSO, MFA, flexible hosting	Self-hosted or SaaS
Infisical	Open-Source Secrets Management	Encrypted secrets, Git-integrated workflows, RBAC, audit logs	Open-source + cloud SaaS

Turning IAM into an Identity-First Advantage

Taking an identity-first approach gives you tighter control over identity-related attacks and cleaner audit trails as you scale into more clouds, more SaaS, and exponentially more NHIs. With the right stack, you can leave standing privileges and one-size-fits-all roles in the past, moving towards dynamic, least-privilege access.

Apono is a cloud native orchestration layer that automates time-bound access, granular approvals, and just-enough access for both users and NHIs. It discovers over-permissioned identities and removes risky standing privileges with auto-expiring permissions. 

If you’re already investing in IAM, the next step is turning those policies into something your engineers actually feel less, not more. Apono helps teams operationalize Zero Trust in day-to-day workflows: approvals that are contextual instead of manual ticket ping-pong, and guardrails for NHIs that match the sensitivity of the systems they touch.

Ready to see how Apono can plug into your existing stack and eliminate standing privileges for good? For a deeper evaluation, grab the Privileged Access Buyer Guide + RFP Checklist and benchmark your current tools against a JIT-first, identity-driven future.

Just-in-Time access is widely accepted as a best practice for reducing standing privilege. The challenge for most organizations is not deciding to use JIT, but designing access policies that actually reduce risk without slowing engineers down. Security teams want tighter controls, stronger auditability, and less standing access. Engineering teams need fast, predictable access to do their work. When approval policies are too rigid, teams get blocked or work around controls. When policies are too loose, risk quietly accumulates.

This guide explains the core challenges of designing effective Just-in-Time access policies, outlines a practical policy framework, and shows how modern automation makes these policies enforceable at scale.

The Challenge of Balancing Security and Productivity

Access management usually breaks down because environments change faster than policies. Cloud environments are exceedingly dynamic and legacy PAM tools designed for the on-prem era simply cannot keep up with the needs of the business or the risks.

Common problems show up quickly:

• Temporary access becomes permanent because no one wants to disrupt workflows
• Manual approvals turn into bottlenecks, especially during incidents
• The same rules are applied to low-risk and high-risk systems
• Access reviews catch issues long after privileges have drifted.

The result is a model that satisfies neither security nor engineering. Just-in-Time access can solve this, but only when policies are intentionally designed around risk and duration.

Why Time-Bound Access Enables Effective Controls

Standing access creates risk because it exists even when it is not needed. Just-in-Time access reduces that risk by ensuring access is granted only for a defined window and removed automatically when the work is complete.

Effective JIT policies follow a few core principles:

• Privileged access expires by default
• Re-access requires a new request
• Duration is enforced automatically
• Approval requirements reflect risk

When duration is enforced consistently, approvals become a supporting control rather than the only line of defense.

Automatic, Self-Serve, and Manual Access Paths

Modern JIT policies should support different access paths based on risk, without forcing everything through the same approval model.

Automatic access
Used for low-risk environments like development and sandbox systems. Access is granted automatically when policy conditions are met, but still expires. This keeps engineers productive while preventing access from lingering.

Self-serve on-demand access
Used for moderately sensitive systems. Users request access when needed. Policies determine whether approval is automatic or conditional. Access is granted Just-in-Time and removed automatically.

Manual approval
Reserved for high-risk systems such as production infrastructure and sensitive data. Requests require explicit approval and are tightly time-bound. This adds friction where it matters most, without making it the default everywhere.

The goal is not to approve everything. The goal is to align access paths with the sensitivity of what is being accessed.

Recommended Just-in-Time Access Policy Framework

The table below summarizes recommended access durations and approval models, based on Apono best-practice guidance.

These limits ensure access is time-bound by design and cannot quietly turn into standing privilege.

Using Context to Secure Break-Glass Access

Emergency access presents a unique challenge. During incidents, speed matters, but so does control.

By using context from incident response tools such as PagerDuty, Splunk OnCall, Opsgenie, Grafana IRM, or others, organizations can allow break-glass access only when an active incident exists or when an engineer is on call. Elevated access is granted temporarily, tightly scoped, and removed automatically when the incident ends.

This approach enables fast response without relying on permanent admin access or broad emergency roles.

Enforcing JIT Policies Automatically With Apono

Policy design only works when enforcement is consistent and low effort.

Apono enforces JIT access policies directly in the access flow. Every request includes a required duration. Access expires automatically and must be re-requested if needed again.

Instead of relying on pre-created roles, Apono dynamically creates ephemeral roles on the fly based on the specific resource, and context. Permissions are assembled Just-in-Time, scoped Just-Enough, and removed when access expires.

This approach reduces overprivilege, eliminates role sprawl, and significantly lowers the operational burden on admins. Security teams define policy once, and Apono handles provisioning, expiration, and cleanup automatically.

All requests, approvals, role creation, and expirations are logged by default, creating a clear audit trail without manual evidence collection.

How JIT Policies Support Compliance and Audits

Well-designed JIT access policies directly support common regulatory requirements by enforcing least privilege and accountability continuously.

For auditors, this provides clear evidence of who accessed what, why, and for how long. For security teams, it turns compliance into an ongoing control rather than an annual scramble.

Designing Policies That Scale

Strong JIT access policies are not about adding friction. They are about removing standing access while preserving productivity.

By combining enforced expiration, dynamic role creation, risk-aligned approvals, and contextual controls, organizations can reduce privilege exposure, simplify audits, and give engineers the access they need without overprovisioning.

This framework provides a practical starting point for designing JIT access policies that scale with modern cloud environments.

Turn JIT Policy Design Into Enforced Access

You’ve seen how effective Just-in-Time access policies are designed—time-bound access, risk-aligned approvals, and automatic expiration.

The next step is turning those policies into something that actually works in production.

Download The Security Leader’s Guide to Rolling Out Just-in-Time Access to see how security teams operationalize JIT policies across cloud, databases, Kubernetes, and CI/CD—without disrupting engineering workflows.

Or, if you’re ready to see how this works in practice, book a demo to explore how Apono enforces JIT access with dynamic permissions, automatic revocation, and full auditability.

Privileged access programs were designed for environments where access could be defined ahead of time. That assumption no longer holds in the cloud.

Legacy PAM emerged in a world of static infrastructure, long-lived systems, and a relatively small number of privileged users. Access patterns were predictable. Roles could be created in advance, assigned broadly, and reviewed periodically. That model was imperfect, but it worked well enough.

Cloud environments operate at a very different pace. Infrastructure is created and changed continuously. Identities appear and disappear through automation. Privileged access is no longer limited to administrators. It is used constantly by developers, CI pipelines, service accounts, and increasingly AI-driven systems operating across production environments.

For cloud security teams, this shift turns privileged access into a dynamic security problem. Static access models struggle to keep up.

This is why the move from legacy PAM to Cloud PAM is not incremental. It is architectural.

Why the Cloud Broke Static Privileged Access

The move to the cloud changed how access behaves, not just where systems run. Several shifts matter most for cloud security teams.

Identity sprawl across humans, machines, and AI
Human users are now outnumbered by service accounts, pipelines, automation, and third-party integrations. These identities are often overprivileged and difficult to monitor at cloud scale. AI agents add further risk by introducing access patterns that cannot be fully predicted upfront.

Granular permissions
Cloud platforms expose fine-grained permissions at the API and resource level. Least privilege is achievable, but only if access can be adjusted dynamically. Broad, static roles quickly become misaligned with real usage.

Ephemeral infrastructure
Cloud resources are created and changed continuously by automation. Access needs evolve just as quickly, leaving static roles and predefined permissions struggling to stay relevant.

Together, these shifts make one thing clear. Access needs are no longer stable. Any PAM model that assumes they are will fall behind.

Why Static PAM Fails in the Cloud

Legacy PAM struggles in the cloud not because it is slow or manual, but because it is static by design.

Static PAM assumes access needs can be modeled in advance. Roles are pre-created. Approval paths are fixed. Privileges are granted long before they are actually needed, then reviewed periodically to correct drift.

That approach worked when systems changed slowly. In cloud environments, it produces predictable problems.

• Privileged roles expand to cover new services and workflows
• Standing access becomes the default because removal feels operationally risky
• Reviews lag behind reality and turn into reactive cleanup
• Security teams spend more time maintaining access models than enforcing outcomes

At cloud speed, access needs change continuously. New services, permissions, and identities appear daily. Static models require teams to anticipate these changes and update roles and policies ahead of time. That work inevitably falls behind.

Standing privilege becomes a coping mechanism for change, even as it increases risk. This is a structural limitation of static access models in dynamic environments.

How Cloud PAM and Just-in-Time Access Change the Model

Cloud PAM refers to privileged access systems built specifically for cloud environments, integrating directly with cloud control planes and APIs rather than relying on vaults, jump hosts, or session proxies. But Cloud PAM alone is not enough. Many Cloud PAM solutions still rely on pre-created roles and static permission models, which reintroduce standing access even in cloud-native architectures.

The real shift comes from Just-in-Time privileged access. Just-in-Time access changes how privileged permissions are granted, used, and removed. Instead of existing permanently, privileged access is provisioned only at the moment it is needed. Zero Standing Privilege builds on this model by making Just-in-Time access the default. Privileged access does not exist unless it is explicitly requested, approved if required, and granted for a limited duration.

Rather than relying on long-lived roles, Just-in-Time access delivers permissions that are scoped to the specific task, enforced at request time, and automatically revoked when the task is complete. This approach aligns privileged access with how cloud environments actually operate and eliminates standing privilege as a byproduct of static design.

In practice, Cloud PAM aligned with Just-in-Time access means:

• Privileged access is temporary rather than permanent
• Access decisions are made at request time
• Context such as environment and resource sensitivity informs access
• Privilege expiration is enforced automatically

For cloud security teams, this turns privileged access into a continuous control rather than a corrective process.

Legacy PAM vs. Cloud PAM at a Glance

Legacy PAM was designed for static infrastructure. Cloud PAM is built for environments that change constantly. This comparison shows how those models diverge in practice.

How Apono Makes Zero Standing Privilege Work at Cloud Speed

Apono was built to implement Cloud PAM in a way that truly supports Zero Standing Privilege at cloud scale.

Rather than requiring teams to pre-create and maintain privileged roles, Apono dynamically creates ephemeral roles at request time. Permissions are assembled based on context and the specific task being performed. Access is granted Just-in-Time, scoped Just-Enough, and removed automatically when no longer needed. This allows organizations to eliminate standing privilege without constantly rebuilding role models as environments evolve.

Static Access Cannot Secure a Dynamic Cloud

Cloud environments are not slowing down. Neither is the risk created by static privileged access.

For cloud security teams reassessing how access is granted, reviewed, and revoked, the next step is understanding where standing privilege still exists and how Just-in-Time access can replace it.

If you’re exploring Cloud PAM options, our Privileged Access Buyer Guide + RFP Checklist can help. It walks through the capabilities that matter most for operationalizing Zero Standing Privilege and offers clear guidance for comparing cloud-native approaches with legacy PAM solutions.

In most organizations, standing privileges don’t show up all at once. They accumulate quietly. A role is added “temporarily.” A contractor needs broad access to finish a project. A service account gets oversized permissions because no one has time to fine-tune them. None of these choices seem harmful in the moment, but over time they build into a privilege surface that’s far too large and far too easy to misuse.

The challenge is that standing privileges often look harmless until something finally goes wrong. The indicators are visible long before the incident, but only if you know where to look. Here are five of the clearest signs that your environment is carrying more access risk than it should.

1. You Have More Admins Than Your Environment Actually Needs

Admin creep happens naturally. In fast-moving environments, the easiest way to unblock a task is to give someone full access. It works. It’s quick. And it’s rarely revisited. Multiply that across cloud accounts, SaaS tools, Kubernetes clusters, and databases and you end up with dozens or even hundreds of identities that hold far more privilege than they need.

The problem isn’t just security. Admin sprawl amplifies operational fragility. A single mistake or a single malicious action can ripple far beyond its intended scope. We’ve seen this play out in cases like the fired contractor who reset thousands of employee passwords, or internal misconfigurations that caused major outages. In both types of incidents, the blast radius existed because privileges were broader than they needed to be.

If you can’t articulate why every admin in your environment truly needs that level of access, that’s a strong indicator that standing privileges have taken root, and a good moment to benchmark your exposure with the Standing Privilege Risk Checklist.

2. Long-Lived Keys and Credentials Are Still Everywhere

API keys, service account tokens, SSH keys, and automation secrets are some of the easiest paths into a cloud environment. They’re also some of the least governed. Many teams still keep:

• Credentials that never expire
  
• Keys embedded in pipelines or code
  
• Secrets used across multiple systems
  
• Tokens with full read/write access to production resources
  

These aren’t bad people making bad decisions. They’re busy teams trying to keep the lights on.

The problem is that long-lived credentials become high-value targets. Attackers increasingly test stolen cloud keys the moment they get them, as we saw in the AWS credential abuse cases involving TruffleHog and SES misuse. Whether the threat is external or internal, a persistent key with broad permissions is often the fastest route to sensitive resources.

If a service account can do more than its exact task—and keep doing it indefinitely—that’s an indicator of standing privilege risk.

3. Privileges Don’t Match What Identities Actually Use

Privilege sprawl is often a visibility problem. Teams don’t know what rights are being used, so they over-grant “just in case.” Over time, roles accumulate hundreds of permissions, most of which are never touched.

Common examples include:

• IAM roles with wildcard permissions
  
• CI/CD pipelines that can modify infrastructure far beyond their workload
  
• Databases where read/write permissions aren’t separated
  
• Kubernetes service accounts with full cluster-admin rights
  
• NHIs with cross-environment access because it was simpler than scoping
  

When permissions are broader than their real usage, the organization isn’t just exposed to attackers. It’s exposed to insider mistakes, misconfigurations, and accidental changes in sensitive systems. The Cloudflare outage is a well-known example of a change having far more impact than expected because of how permissions were structured.

If your team doesn’t regularly compare “granted” versus “used,” standing privileges are almost certainly accumulating.

4. Sensitive Actions Don’t Require Any Friction

Some operations should not be immediately available to any identity, no matter how trusted:

• Resetting large numbers of passwords
  
• Editing IAM policies
  
• Disabling security controls
  
• Modifying production data
  
• Spinning up new users or access keys
  
• Stopping backup or logging services
  

These actions should require either approvals, elevated Just-in-Time access, or automated guardrails that constrain when and how they can be performed.

In environments without friction, sensitive actions can be executed accidentally or misused maliciously. This is how attackers using valid RDP credentials can disable security tools instantly, or how insiders can execute destructive scripts without hitting any checkpoints.

If sensitive actions feel too easy, that’s an indicator that standing privileges are enabling more reach than intended.

5. You Can’t Easily Answer Who Has Access to What

Standing privileges thrive in environments where visibility is fragmented. Cloud, SaaS, identity providers, CI/CD, Kubernetes, and databases all have their own privilege models. Without unified visibility, organizations rely on:

• Spreadsheets for access reviews
  
• Outdated role definitions
  
• Tribal knowledge
  
• Manual investigations
  
• Multiple admin consoles
  

This fragmentation makes it nearly impossible to catch privilege drift or identify when service accounts, contractors, or AI agents have more access than expected.

And when an incident happens, delayed response often comes down to not knowing who had the ability to take a specific action. This is one of the biggest—and most overlooked—indicators that standing privileges have become ingrained.

How Zero Standing Privileges Addresses These Indicators

Zero Standing Privileges (ZSP) focuses on removing permanent access and replacing it with temporary, scoped, and auditable elevation. Under ZSP:

• Access is granted Just-in-Time
  
• Privileges match the specific task
  
• Access expires automatically
  
• Sensitive actions require deliberate elevation
  

ZSP reduces the opportunity for malicious insiders, limits the surface attackers can abuse with stolen credentials, and prevents accidental actions from impacting production systems.

It directly addresses all five indicators by keeping privilege surfaces small and access intentional.

How Apono Helps You Reduce Standing Privilege Risk

Apono makes Zero Standing Privileges practical across cloud, databases, SaaS, Kubernetes, and hybrid environments. It helps teams:

• Automate Just-in-Time elevation without slowing users down
  
• Quarantine risky privileges without breaking workflows
  
• Rightsize access based on real usage and risk data
  
• Remove standing access for human and non-human identities
  
• Log and audit all elevations and admin actions
  
• Detect unusual privilege behavior early
  

The goal isn’t to lock systems down. It’s to introduce the right guardrails so access becomes safer and more predictable.

Putting Better Guardrails Around Access

Standing privileges rarely feel dangerous until they’re misused. But the indicators show up long before the incident happens. If your environment has more admins than needed, long-lived keys, broad permissions, frictionless sensitive actions, or limited visibility, privilege sprawl is already creating risk.

If you want a fast way to understand where your gaps are, download the Zero Standing Privilege Risk Checklist — 

or reach out to see how Apono can help reduce privilege exposure without slowing your teams down.

New integration closes a long-standing Zero Trust gap by eliminating persistent permissions and enabling real-time, policy-driven access across cloud environments.

NEW YORK – January 6, 2026 – Apono today announced a new integration with Check Point Software Technologies that delivers an advanced SASE-based Zero Standing Privilege (ZSP) architecture designed to eliminate long-lived permissions and provide real-time access across modern cloud environments. This solution enables organizations to significantly reduce their attack surface while maintaining the agility required across engineering, distributed teams, and incident response operations.

Traditional SCIM-based identity synchronization can take 30–60 minutes, forcing organizations to rely on standing access to avoid operational delays. The new Apono–Check Point integration removes this dependency by enforcing temporary, event-driven access directly through Harmony SASE. Users receive only the permissions required for the specific task and time window, with access automatically revoked when the work is complete.

“Cloud environments are now operated not only by humans but by automated systems and AI-driven agents,” said Ofir Stein, Co-founder and CTO of Apono. “These systems react in milliseconds, and access must follow the same pace. Our integration with Check Point allows access to rise and fall dynamically alongside the infrastructure, ensuring real-time enforcement whether the actor is an engineer or an automated agent.”

Enterprises increasingly rely on SASE frameworks to secure distributed workforces. However, traditional provisioning approaches introduce friction and slow response times, particularly during high-urgency moments such as incident response.

The joint approach removes these bottlenecks by:

• Eliminating persistent permissions
• Replacing slow SCIM or identity provider syncs
• Enforcing temporary, real-time least-privilege access at the SASE enforcement layer

“Organizations are under increasing pressure to enforce Zero Trust without slowing down their teams,” said Amit Bareket, VP of Security Service Edge at Check Point Software. “With Harmony SASE, our collaboration with Apono extends Zero Trust from identity to Just-In-Time & Just-Enough network access enforcement in a single, cloud-delivered control plane. By unifying policy and real-time enforcement across users, devices, and apps, we eliminate unnecessary complexity and let teams stay productive without compromising security.” 

Key Capabilities

• Real-time identity provisioning: Instantly adds or removes users from Harmony SASE groups without waiting for SCIM or IdP cycles.
• Policy-driven Zero Standing Privilege (ZSP): All access is temporary, time-bound, and governed by policy. Permissions automatically expire when no longer needed.
• Context-aware access workflows: Access can be triggered by signals such as incident acknowledgement, change management events, or ITSM workflows.
• Access rightsizing enforcement: Automates detection of over-privileged users and adjusts permissions to ensure least-privilege access.

Apono and Check Point plan to further expand the integration with advanced automation capabilities, additional context triggers, and broader governance workflows. Both companies share a long-term vision for a unified, real-time Zero Trust architecture where access appears only when needed and disappears automatically.

“When we talk about deeper automation and richer context, we’re talking about an access model that can react on its own,” said Ben Avner, Head of Technology Partnerships at Apono. “Partnering with Check Point gives us the foundation to deliver an end-to-end, real-time system where privileges rise and fall automatically with the work itself.”

About Apono

Apono provides real-time, Just-in-Time, and Zero Standing Privilege access for cloud infrastructure, SaaS, and operational resources. By automating identity provisioning based on policy and operational context, Apono helps organizations enforce Zero Trust without slowing down engineering, operations, or incident response.

Contact Information:

Stephen Lowing
VP Marketing

[email protected]

apono.io 

Shai Hulud didn’t invent a new supply chain weakness. It took advantage of something most teams already struggle with: long-lived credentials sitting on developer laptops and CI runners. Once it landed in a workstation or pipeline, it went hunting for secrets, then moved into GitHub, npm, and cloud environments.

The damage is huge. More than 25,000 GitHub repositories showed signs of credential exposure tied to the operation, and hundreds of npm packages were altered and republished as “normal” updates. 

Teams that treated non-human identity (NHI) security as a secondary layer discovered that the worm viewed those identities as primary targets. NHIs had more rights and seldom expired. When credentials outlive their usefulness, the Shai Hulud npm worm is a perfect illustration of how quickly a local compromise turns into an ecosystem issue.

What is the Shai Hulud npm Worm?

Shai Hulud 2.0 spread through legitimate packages that contained malicious preinstall scripts. Those scripts ran before installation finished and inherited the environment in which they executed. The worm used this position to inspect local files, gather tokens, and transmit them externally. Equipped with the victim’s npm credentials, it automatically backdoored and republished other packages the maintainer controls.

The pattern wasn’t complicated, but it was frustratingly effective. It waited for a normal install, ran its preinstall script, and searched for credentials with real reach. Once it had one, it republished a backdoored version under the maintainer’s identity and propagated through standard npm channels. Everything looked routine because, operationally, it was.

The worm targeted a predictable set of secrets, including npm tokens, GitHub credentials (e.g., PATs/SSH creds), and cloud API credentials (AWS/GCP/Azure), plus CI environment secrets where available. These secrets already existed because they enabled faster local development and pipeline automation. Because these tokens were long-lived, the worm could reuse them across systems, moving from a single machine into source control, registries, and cloud environments. This is why secret management can’t be treated as a side project, as these tokens are the worm’s fuel. 

This combination of availability, scope, and longevity created the conditions for rapid propagation. The worm did not need to be sophisticated. It only needed access to credentials that could reach beyond the machine it first compromised.

Why the Shai Hulud Worm Is Malicious

Shai Hulud is dangerous because it moves through trusted identity relationships that were never designed to defend against compromise. It does not rely on a single exploit. It relies on normal development workflows and the credentials those workflows expose.

The worm embeds itself in preinstall scripts that run automatically during dependency installation. From there, it focuses on harvesting credentials rather than disrupting systems. Access is the objective. Tokens that can touch source control, publishing, and cloud are worth more than the laptop or runner they were stolen from. 

With the right token, an attacker can change code and reach production-like systems without ever needing to “own” the original machine. The Shai Hulud worm spread by acting like a normal maintainer. It reused real npm tokens to republish packages, so the poisoned versions looked legitimate, and they flowed downstream the same way any routine update would.

Several factors make this behavior particularly damaging:

• Preinstall scripts run by default during dependency installation, often before most security controls or CI guardrails can run.
• Stolen credentials enable unauthorized publishing and changes to repositories.
• NHIs often hold broad, persistent permissions.
• Each new installation exposes additional environments and secrets.

The main issue Shai Hulud exploits is a growing web of interconnected identities that link development systems, such as CI pipelines and cloud resources, together. This factor gives attackers clear paths across environments with little resistance. 

Impact of the Shai Hulud Worm

The operational impact of Shai Hulud extended across development, CI, and production environments. What began as a dependency issue quickly exposed structural weaknesses that exist in many engineering organizations, particularly around credential handling and trust in automation.

At the supply chain level, the worm modified hundreds of npm packages. Teams had to audit both transitive and direct dependencies, frequently without knowing which builds had pulled compromised versions. Integrity verification became sluggish and insufficient as a result. That scramble is exactly what effective supply chain risk management is meant to prevent: clear containment boundaries and fast credential rotation.

After credentials were stolen, the compromise became more serious. Attackers were able to alter repositories, publish unapproved package versions, and initiate continuous integration workflows under false identities. The risk extended beyond source control into cloud environments. Several areas felt the impact most acutely:

• Pipeline instability: Malicious scripts were introduced into build systems and altered execution paths, leading to compromised artifact generation, test behavior, and deployment reliability.
• Maintainer impersonation: Actual npm publishing keys were used to distribute modified packages, thereby undermining ecosystem trust and raising concerns over the accuracy of updates.
• NHI compromise: Service accounts and automation identities became the easiest pivot points. Their permissions were broad, their activity rarely scrutinized, and the worm moved through them without triggering the alerts teams rely on for user abuse.

Once the stolen secrets surfaced in public repositories, containment became significantly harder. Those credentials no longer had a defined boundary, which forced organizations to rapidly revoke, replace, and reassess every access path tied to the affected identities.

How to Know if You Are Affected by the Shai Hulud npm Worm

You can detect potential compromise by focusing on deviations in dependency structure, identity behavior, and repository activity. Look for:

• Packages that include unexpected preinstall scripts, such as setup_bun.js
• New versions of your packages were published without approval.
• Publishing activity by unknown identities or service accounts.
• Unapproved changes to GitHub workflows or repository settings appear without a corresponding change record.
• Sudden creation of GitHub tokens tied to users or automation that do not normally mint credentials.
• Cloud activity that originates from unfamiliar locations or involves sudden increases in privilege.
• CI jobs that run commands or scripts outside the planned sequence.
• Public GitHub repos referencing Shai Hulud that contain your secrets.
• Any shift in NHI patterns is unlikely to be benign because their behavior is normally consistent.

Most early signals appear in automation layers. NHIs do not deviate from routine unless something external influences them. Monitoring that layer provides the strongest detection point.

7 Ways to Protect Against the Shai Hulud Worm and Similar Attacks

Catching the next malicious script is not the goal of defending against Shai Hulud, as most of that is reactive. Removing the access conditions that allow a single compromised dependency to become a multi-system incident is the real work. Here’s how.

1. Remove Standing Credentials Through Just In Time Access

Shai Hulud was effective because the credentials it discovered were already valid and already powerful, some that were never meant to be permanent. That persistence gave the worm time to reuse them across repositories, registries, and cloud environments. 

Just-in-Time (JIT) access changes that dynamic. Using a cloud-native access management platform like Apono, you can apply this model consistently across both human users and non-human identities. The result is that access is available only for the duration of a task. 

2. Enforce Least Privilege Across Developers, Pipelines, and NHIs

Over-permissioning is rarely intentional. It is usually the result of pressure, such as a pipeline failure and blocked release. So someone broadens access to get things moving again, and the permission is never revisited. Over time, identities accumulate rights they no longer need.

When one of those identities is compromised, every attached permission becomes available to the attacker. Limiting privilege to a specific action, environment, and time window prevents that cascade. 

3. Secure CI and CD Systems by Removing Embedded Secrets

Because CI pipelines are situated between source code and production systems, they are appealing targets. That bridge is exactly why CI hardening is inseparable from cloud data security; pipeline credentials often have direct paths to production cloud resources. The pipeline configuration contains static secrets that make that access reusable and long-lasting. Once uncovered, those secrets are perpetually replayable. A more resilient approach removes secrets from pipelines entirely. 

4. Restrict and Monitor Publishing Rights

Package publishing rarely gets much attention once it is working. Tokens are created to keep releases moving and then left in place because changing them is more likely to cause trouble than praise. Over time, no one is quite sure who owns those credentials or how often they should be reviewed.

Shai Hulud exploited that drift. It reused valid maintainer credentials and pushed altered packages through standard release mechanisms. Nothing about the process looked unusual, which is why the updates traveled as far as they did before anyone noticed.

Constraining publishing access changes that outcome. Limiting who can publish, what they can publish, and how long that access exists reduces the window for abuse. 

5. Apply Zero Trust Controls Across Development Tooling

In many environments and for teams, Zero Trust initially applies, but not much beyond. Credentials are accepted once and then reused by developer tools without reassessing context, and access persists until it is explicitly revoked, even when the surrounding conditions no longer exist. This is the gap that Shai Hulud exploits, as stolen credentials remain usable even when the original context no longer exists.

In practice, that persistence shows up in a few predictable ways:

• Credentials remain valid across sessions. Access continues from different machines.
• Changes in device state go unnoticed.

Let’s look at a real-world example. Apono takes a different approach, where access is treated as a continuous decision rather than a one-time event. Each request is evaluated using the current identity attributes and the state of the requesting device. When those conditions no longer meet policy requirements, access is denied instead of preserved. 

Source

6. Track NHI Behavior Continuously

Non-human identities operate on schedules, repeating the same actions and creating useful predictability. When something goes wrong, the signal usually appears as a deviation rather than a spike in activity. That might look like:

• access to resources that the identity has never touched before
• activity outside its normal execution window
• permissions being exercised in a new context

Changes in behavior, scope, and timing are often the first indication that an automation identity has been compromised. Deviations from established patterns tend to surface upstream, before activity becomes overtly malicious, which is exactly where worms like Shai Hulud gain their footing.

7. Strengthen Developer Workstations

Developer machines remain a common entry point because access accumulates quietly over time as tokens get cached, among other bad habits, to reduce workflow friction. Tooling continues to assume a high level of trust long after the original context has changed.

Removing stored tokens, requiring hardware-backed authentication, and using secrets scanning tools to catch exposed tokens before they land in commits or logs. More importantly, local access should never grant durable privileges into production systems. When access is temporary and tightly scoped, a compromised workstation no longer serves as a gateway to the rest of the environment.

Why Containing Worms Requires Containing Privilege

When access outlives intent, compromise stops being local. The Shai Hulud infection was able to spread through repositories, pipelines, and cloud systems more quickly than most controls were designed to stop, thanks to those access paths.

Apono breaks the continuity attacks Shai Hulud relies on. Access is issued when needed, removed when it is no longer required, and never left standing by default across development, CI, and cloud systems. When credentials expire, and privilege is tied to intent, a compromised dependency stays local instead of rippling outward.

Supply chain attacks will continue. The organizations that hold up best are the ones that control privilege as aggressively as they control code. That starts with understanding where standing access still exists, how long it persists, and which access paths create unnecessary blast radius.

To help teams take that first step, we’ve put together a practical Zero Standing Privileges (ZSP) Checklist – a quick way to assess your current access posture and identify where privilege needs to be tightened before the next incident tests it.