CyberArk, Idira and the Future of Privileged Access

Palo Alto Networks' introduction of Idira, built on CyberArk's privileged access heritage, is more than a brand update. It reflects a broader shift in how the market is talking about identity security, privilege and risk.

For many years, Privileged Access Management (PAM) has been associated with a relatively narrow set of controls: vaulting administrator credentials, rotating passwords, monitoring sessions and reducing standing access for high-risk users. Those controls still matter, and in many organisations they remain the foundation of a strong PAM programme.

What is changing is the scope of the problem. As organisations adopt more cloud services, automation, APIs, third-party integrations and AI-enabled workflows, privileged access is no longer limited to a small group of IT administrators. Machine and AI identities now outnumber human identities by 109 to 1, and 90% of organisations experienced an identity-related breach in the past twelve months (Palo Alto Networks 2026 Identity Security Landscape Report).

The most useful question for security leaders is not "what is Idira?" It is whether their privileged access controls are still keeping pace with how the organisation actually works.

Idira was introduced by Palo Alto Networks on 12 May 2026, following its completion of the CyberArk acquisition in February 2026. It builds on CyberArk’s privileged access heritage while expanding the conversation into broader identity security. The platform reflects a broader market shift: privilege controls increasingly need to apply across human, machine and AI agent identities. The point is not to treat every account like a domain administrator, but to understand where privileged access exists and how it is controlled. It introduces expanded capabilities including discovery across the full identity estate, zero standing privilege enforcement, AI-driven governance, and browser-based session access.

At the platform launch, Palo Alto Networks CEO Nikesh Arora described the problem as the "IAM fallacy": the long-held assumption that maintaining a firm divide between a small number of powerful administrators and a much larger number of ordinary users is sufficient protection. That assumption, he argued, no longer holds. With adversaries now logging in rather than breaking in, every identity has become a target.

Why Are Machine and AI Identities Now a Privileged Access Risk?

The keynote framing of "securing machine identities in the agentic enterprise" reflects a shift that is already under way in most organisations, not a future concern.

91% of organisations already run autonomous AI agents in production. Those agents authenticate, call APIs, access sensitive data, and in some cases can escalate their own privileges to complete a task. No traditional PAM or identity platform was designed to see any of that, let alone control it in real time.

This creates a blind spot that is growing faster than most security teams realise. Machine and AI identities do not go through a provisioning workflow. They do not appear in an HR system. They may be created by developers, by third-party tools, or by other agents acting autonomously. By the time a security team discovers an agent has standing access to a production environment, that access may have been in place for months.

Palo Alto positions Idira as a single control plane across human, machine and agentic identity types, continuously scanning cloud, SaaS and developer environments to surface every active identity and enrich it with context: who owns it, what it can access, and which permissions are actually in use. Rather than granting static access tokens, it applies dynamic privilege controls by elevating access when an agent needs to execute a task and revoking it immediately afterwards.

For many organisations, the immediate priority is not agentic identity. It is getting the fundamentals right for human and service account identities first. But where this is heading is clear, and the organisations that build good PAM hygiene today will be better placed to extend those controls when they need to.

Why Does the Idira Launch Matter Beyond CyberArk Customers?

The Idira announcement matters even if an organisation is not a CyberArk customer. It shows how the wider market is reframing privileged access: not as a narrow administrator account problem, but as a broader identity security challenge.

This does not mean the basics have become less important. Vaulting, credential rotation, least privilege, just-in-time access, session monitoring and endpoint privilege controls all continue to play an important role.

But the scope of privileged access has widened considerably. Security teams increasingly need to understand privileged access across administrator accounts, service accounts, cloud roles and SaaS privileges, developers and DevOps workflows, third-party users, business-critical application access, automation and integration accounts, machine identities, and web application access.

This shift is already visible in how compliance and audit frameworks are evolving. The NCSC's Cyber Assessment Framework 4 (CAF4), for example, sets clear expectations around privileged user management. Contributing Outcome B2.c, privileged user management, points to the importance of dedicated privileged accounts, appropriate separation of roles, strong authentication, time-bound access where appropriate, and routine review and recording of privileged activity. These are the types of controls a mature PAM programme can help organisations operationalise and evidence.

CAF4's B2.a outcome on identity verification also points to regular access review and the use of multi-factor authentication across systems supporting essential functions. B2.d, covering Identity and Access Management (IdAM), reinforces the need for user, device and system access to be logged, monitored and reviewed. PAM is not the whole answer to these requirements, but it can provide important evidence and control over the highest-risk forms of access.

Sarbanes-Oxley (SOX), similarly, places pressure on organisations to protect the integrity of financial data and demonstrate appropriate control over how people access and change relevant systems. These expectations extend well beyond the administrator password vault.

The practical issue is not whether every identity has the word "admin" attached to it. It is whether that identity can create meaningful harm if it is compromised, misused or over-permissioned. For some organisations, the biggest privileged access risks are still traditional administrator accounts. For others, they may sit in cloud platforms, developer pipelines, service accounts, business applications or third-party access paths. Either way, the starting point is visibility.

What Does "Every Identity Is Privileged" Really Mean?

"Every identity is privileged" should not be read literally. It does not mean every user is a domain administrator, and it does not mean every identity needs the same level of control.

A more useful interpretation is this: organisations should assess privilege based on what an identity can do, not what the account is called.

Privilege is about potential impact. A developer account, finance approver, cloud role, service account or third-party user may not look like a traditional administrator account. But if it can approve payments, access sensitive data, change infrastructure, deploy code, alter configurations or bypass normal controls, it may create privileged-level risk. An AI agent that can call APIs and escalate its own permissions is no different in principle.

That is why privileged access programmes need to move beyond static account labels. Security leaders need to ask: what can this identity access; what actions can it perform; could it move laterally; could it change systems, data or configurations; is the access standing or temporary; is the access monitored; and who owns the process for reviewing and reducing it.

The scope of what counts as privileged has also changed in a practical sense. Traditional PAM solutions were built around RDP, SSH and databases. That remains important. But organisations today also have cloud environments, web applications, SaaS platforms and DevOps pipelines. Each can carry privileged-level risk. A privileged access programme that only covers RDP, SSH and databases is not covering the problem.

Is Traditional PAM Still Relevant?

Traditional PAM is not dead. In fact, many organisations still need to strengthen the fundamentals before they can move into broader identity security maturity.

For many security teams, the priority remains to discover privileged accounts, reduce standing access, vault credentials, rotate passwords, monitor privileged sessions, apply least privilege, introduce just-in-time access where appropriate, control endpoint privilege, and improve ownership and review processes.

The shift is not that these controls are becoming irrelevant. The shift is that they need to sit within a more complete view of privileged access risk. A mature PAM programme should not only ask whether admin credentials are vaulted. It should also ask whether the organisation knows where high-impact access exists, whether standing privilege is being reduced, whether privileged sessions are monitored and auditable, whether service accounts and machine identities are understood, whether cloud and SaaS privileges are included in scope, and whether the operating model supports continuous improvement.

Traditional PAM remains foundational. The definition of the privileged access problem is expanding.

What's the Difference Between Installing and Adopting PAM?

Many organisations have deployed a PAM solution. Far fewer have truly adopted it. That difference matters for security outcomes and audit readiness.

Adoption means that the processes align with the technology. It means coverage is broad enough to matter. It means administrators use the system as intended, rather than routing around it. It also means there are no open backdoors, such as accounts being created and managed outside the PAM environment that undermine the controls in place.

When adoption falls short, the PAM solution becomes a partial control at best. The vault may be in place, but privileged access is still happening outside it. Accounts may be created without proper governance, and sessions may go unmonitored. CAF4 B2.c flags issues such as generic, shared or default accounts and a lack of logical separation between roles as signs of weaker control maturity. These are the kinds of gaps that surface during audit review.

This distinction, between installing a PAM product and genuinely operating a PAM programme, is where Intragen focuses its work. The technology is a tool. The value comes from implementing it correctly, driving adoption, and operating it in a way that reflects the organisation's actual risk.

What Does PAM Audit Readiness Look Like in Practice?

The gap between installation and adoption becomes most visible under audit pressure.

Audit readiness does not mean audit assurance. The outcome of any audit or regulatory review depends on the organisation's wider control environment, implementation, evidence, governance and the judgement of the relevant auditor or authority. Intragen helps organisations identify gaps, strengthen privileged access controls and prioritise remediation.

Consider a global financial institution that had built strong internal security disciplines without a dedicated PAM solution. The team was technically mature. They had implemented manual controls: policies requiring regular password rotation, makeshift just-in-time elevation using native cloud tools, and strong processes for governing access on paper. By most measures, they had done more than most organisations manage without dedicated tooling.

But when internal auditors assessed their Digital Operational Resilience Act (DORA) readiness, they ran into a problem that process documentation alone could not fully address: monitoring. They could rotate passwords, restrict access and create policies. But they struggled to evidence what their administrators had done, on which systems, and at which times. For RDP sessions in particular, it can be difficult to produce complete, attributable evidence of privileged activity without dedicated session monitoring or equivalent controls. Without session recording or comparable evidence, it is harder to demonstrate that the controls described on paper were followed in practice.

The internal audit concluded that their controls, however well-designed on paper, needed stronger supporting evidence. That finding became the driver for a more formal PAM programme. The CAF4 C1.a outcome is direct on this point: a "not achieved" rating applies where an organisation "is not able to audit the activities of users and systems." The C1.b outcome goes further, requiring that actions involving log data can be traced back to a unique user or system, and that log integrity is protected. DORA similarly increases the importance of being able to evidence how ICT risks are managed, including how access to critical systems is controlled, monitored and reviewed.

What Should Existing CyberArk Customers Do About Idira?

For existing CyberArk customers, the move to Idira may be a useful trigger to review whether the current PAM programme still reflects the organisation's risk profile, operating model and wider identity strategy.

That does not mean customers need to panic or rush into immediate change. For many SaaS customers, some Idira capabilities may be introduced through existing platform roadmaps or licensing arrangements. But it does mean this is a good moment to ask whether the original scope of the deployment is still sufficient. Useful questions include:

• Which CyberArk capabilities are in use today, and which are underused?
• Which privileged identities are currently outside the PAM scope?
• Is there too much standing access in the environment?
• Are service accounts, cloud roles and third-party access properly governed?
• Are privileged sessions consistently monitored and reviewed?
• Does the operating model support continuous improvement, or is it mainly maintaining the original deployment?
• Does the organisation have the internal skills and capacity to manage the next phase?

Budget pressures are real, and security leadership does not always win internal arguments for expanded investment. When PAM programmes stall, it is often not because the CISO lacks conviction. It is because the business case has not been made clearly enough to those who control the budget. Regulatory scrutiny and the cost of remediation after audit findings are increasingly important factors in building the case for PAM investment.

How Should You Prepare for PAM Platform Decisions?

The right response to Idira is not necessarily to buy more technology. For many organisations, the better first step is to understand current privileged access maturity: reviewing what is protected, what is exposed, what is over-privileged and what is not yet governed.

Before making platform decisions, security leaders should understand which identities have high-impact access, where standing privilege exists, which access paths create the most risk, whether privileged sessions are monitored, how service accounts and cloud roles are managed, who owns privileged access processes, and whether current tooling is being used effectively.

Platform expansion without clarity creates more complexity. Organisations may add tools, licences or integrations without first understanding the control gaps they are trying to close. Technology works best when the organisation has a clear view of the problem, the risk and the operating model needed to manage it. For many organisations, a PAM Quick Check assessment is a more useful starting point than a product-led conversation.

How Is AI Actually Changing Privileged Access Management?

There is one area where AI is genuinely changing what is possible in privileged access management, and it is worth addressing directly.

Privileged session monitoring has always faced a practical problem: sessions accumulate faster than anyone can watch them. The volume of recorded activity in a mature PAM environment is significant, and reviewing it manually is not realistic.

AI-enabled session analysis changes this. Rather than relying only on rule-based blocking, which can be circumvented by wrapping commands in scripts, modern PAM platforms can apply more context to session activity. The CAF4 C1.f outcome notes that effective detection depends on understanding normal user and system behaviour well enough that searching for abnormalities becomes meaningful. AI-driven analysis can help make this more practical at scale, correlating session data across systems and surfacing anomalies that static rules may miss.

Security leaders do not need to invest in AI-powered PAM because it is fashionable. They should consider it because manual review alone is increasingly difficult to sustain at scale, and organisations are under more pressure to provide clear, repeatable evidence of privileged activity.

How Can Intragen Help With PAM and Idira?

Intragen helps organisations understand privileged access risk and build practical PAM programmes that can be operated successfully over time. This support is designed to improve readiness, strengthen evidence and prioritise remediation. It does not guarantee the outcome of any audit, certification or regulatory review. That support can include:

• PAM discovery and maturity assessment
• Privileged access roadmap development
• CyberArk and Idira implementation and optimisation
• PAM operating model design
• Managed PAM support
• Review of current coverage, gaps and next steps

For existing CyberArk customers, Intragen can help assess whether the current deployment is aligned with today's risk profile and the Idira roadmap. For organisations newer to PAM, Intragen can help identify where to start, which controls to prioritise, and how to build a programme that is realistic, scalable and manageable. Where audit or compliance findings already exist, Intragen can help address the underlying privileged access recommendations and build a practical remediation path.

The Idira announcement is a useful reminder that privileged access is changing. The immediate priority for most organisations remains practical: understand where powerful access exists, reduce unnecessary risk, and build the right operating model to keep privileged access under control. If you are not sure whether your controls are keeping pace, our Managed Privileged Access service can review your current approach, highlight potential gaps and identify practical quick wins through a PAM Quick Check.