TL;DR: Idira is Palo Alto Networks’ rebranded CyberArk portfolio, combining PAM, secrets management, certificate management, and an early AI agent identity layer into one control plane, according to Infisical. For practitioners, the important question is not the brand change but whether the architecture, operating model, and cost profile fit the identity problem you actually need to solve.
At a glance
What this is: Idira is CyberArk’s rebranded platform under Palo Alto Networks, with a broader identity scope that now spans human, machine, and AI agent control.
Why it matters: It matters because IAM and security teams must separate branding noise from governance reality, especially where NHI lifecycle, privileged access, and emerging agentic controls overlap.
By the numbers:
- Palo Alto Networks completed its acquisition of CyberArk, a deal widely reported at around $25 billion, and in May 2026 folded the CyberArk portfolio into a single brand called Idira.
- CyberArk's technology (which powers Idira) is almost 30 years old, which has led it mature, but also means it has accumulated complexity, which is the biggest complaint.
👉 Read Infisical's analysis of the Idira rebrand and CyberArk transition
Context
Idira is best understood as a rebrand of CyberArk’s identity security stack under Palo Alto Networks, not as a clean break in product substance. The primary issue for practitioners is the mismatch between the marketing story and the operational reality of PAM, secrets management, and machine identity governance.
For IAM, PAM, and NHI programmes, the important question is whether the new platform reduces governance complexity or simply repackages an already complex estate. That matters most where teams already manage lifecycle, audit, rotation, and access review processes across multiple identity types.
Key questions
Q: How should security teams evaluate a rebranded identity platform after an acquisition?
A: Start with the operating model, not the brand. Confirm what changes in architecture, support, pricing, roadmap, and migration effort, then map those changes to the identity problems you actually have. A rebrand can preserve technology while changing governance, vendor dependency, and product direction, so the decision should be based on lifecycle and control impact rather than name recognition.
Q: When does an all-in-one identity platform create more risk than it removes?
A: It creates more risk when the platform centralises too many identity domains but still requires specialised operators, opaque pricing, or complex migrations. In that case, centralisation can increase blast radius and make offboarding harder, especially if the organisation cannot independently validate how each control domain is governed.
Q: What do IAM and NHI teams get wrong about secrets management and PAM?
A: They often treat them as interchangeable because both deal with credentials, but they solve different problems. Secrets management governs non-human credentials and rotation, while PAM governs elevated human access and session control. Combining them in one procurement does not remove the need to design separate policies, owners, and audit evidence.
Q: Who is accountable when a platform vendor changes ownership or branding?
A: The customer remains accountable for access, rotation, offboarding, and audit continuity. Vendor ownership changes may affect roadmap and support, but they do not transfer governance responsibility. Teams need documented exit paths, entitlement inventories, and control ownership so that a product change does not become an access-control blind spot.
Technical breakdown
One control plane for human, machine, and agent identities
Idira combines human privileged access controls, secrets management, certificate lifecycle, and AI agent security under one umbrella. In practice, that means one governance surface can cover session isolation, short-lived credentials, workload secrets, and early agent discovery features. The technical trade-off is breadth: the same platform that centralises reporting also expands the configuration and operational footprint. For large enterprises, that can simplify oversight. For smaller teams, it can make the control plane harder to run than the problem it was meant to solve.
Practical implication: Treat platform breadth as an operating burden as well as a governance benefit, and validate whether one team can realistically run the full stack.
Why secrets management and PAM behave differently
Secrets management protects credentials such as API keys, tokens, certificates, and workload secrets, while PAM governs elevated human access and session-level privilege. They overlap in identity security, but they fail differently. Secrets sprawl is usually a discovery and rotation problem. PAM failure is usually a standing-privilege and audit problem. Folding both into one product does not remove the need to design each control domain separately. The architecture still has to answer who gets access, for how long, and how revocation is enforced.
Practical implication: Do not assume a shared vendor platform means a shared control model; map secrets and PAM to separate lifecycle and audit requirements.
AI agent identity is still an immature governance layer
Idira’s AI agent positioning points to the next frontier in identity security, but the control model is still early. Agent identity is not just another secrets problem because autonomous systems can select tools, time actions, and chain execution paths in ways static IAM policies were not built to govern. That means the platform has to do more than issue credentials. It has to encode task scope, delegation boundaries, and revocation logic that works at runtime. Most teams are not there yet.
Practical implication: Evaluate agent controls as emerging governance, not mature entitlement management, and avoid assuming human IAM patterns will transfer cleanly.
Threat narrative
Attacker objective: The practical objective is not immediate compromise but sustained access and weak governance boundaries across human, machine, and emerging agent identities.
- Entry begins with broad identity consolidation, where a platform inherits legacy CyberArk customers, secrets stores, and PAM deployments across multiple environments.
- Escalation follows when complexity, closed architecture, and operational friction create workarounds that leave sensitive credentials, audit paths, or privileged workflows harder to govern consistently.
- Impact is governance drift: teams lose clarity over which controls apply to which identity type, making migration, review, and accountability more difficult at scale.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Brand consolidation does not resolve identity architecture risk. Idira may unify the customer story, but it does not unify the underlying governance problems of PAM, secrets, certificate lifecycle, and agent access. The field should read this as a platform-level packaging decision, not a control-model breakthrough. Practitioners should evaluate whether the consolidation clarifies accountability or merely centralises complexity.
The biggest issue is operational complexity, not feature breadth. CyberArk’s long product history and acquisition trail created a stack that many teams can use only with specialist knowledge and dedicated staff. That pattern matters because identity control that depends on scarce operators is fragile at the programme level. Practitioners should measure whether their own operating model can sustain the platform, not just whether the feature list is complete.
Agent identity governance is still an assumption-testing exercise. The assumption that access is assigned to stable, reviewable actors was designed for human and workload identities with predictable lifecycles. That assumption fails when the actor is an autonomous agent because task scope, tool use, and timing can shift at runtime. The implication is that identity governance has to distinguish between credential issuance and decision authority.
Identity blast radius is the more useful concept than brand coverage. One platform can reduce tool sprawl, but it can also create a larger failure domain when governance slips. That is especially true when the same control plane spans human privilege, machine secrets, and early agentic features. Practitioners should judge whether centralisation lowers blast radius or just concentrates it.
Closed platforms force a higher trust threshold. When a secrets or PAM platform is proprietary, teams lose transparency into implementation details, self-hosting flexibility, and the ability to validate operational assumptions independently. That does not automatically make the product unfit, but it does raise the assurance bar. Practitioners should demand stronger exit planning, migration clarity, and lifecycle ownership.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- For the broader control model, Ultimate Guide to NHIs is the next step when teams need to connect rotation, offboarding, and governance.
What this signals
Identity blast radius is now a procurement issue, not just an architecture concern. As platforms consolidate PAM, secrets, certificates, and emerging agent controls, the governance question shifts from feature coverage to recoverability and operating ownership. Teams that cannot describe who owns each identity domain will struggle to defend the platform during audit, incident response, or vendor transition.
The practical test for programmes like this is whether control boundaries survive branding changes. If a rebrand forces policy rewrites, support ambiguity, or new operational dependencies, then the platform has not simplified governance. It has redistributed it, which means lifecycle clarity and exit planning should sit alongside capability evaluation.
Secrets lifecycle discipline remains the anchor point. With 27 days to remediate a leaked secret in one NHIMG research set, teams should assume that operational delay is structural unless rotation, discovery, and offboarding are tightly linked. That is why lifecycle governance, not vendor consolidation, remains the practical control objective.
For practitioners
- Map identity domains separately before platform selection. Split human PAM, machine secrets, certificate lifecycle, and agent governance into separate control requirements before comparing products. A single vendor can cover all four, but the operating model still needs distinct ownership, review cadence, and recovery paths for each domain.
- Test the migration and offboarding path first. Validate how credentials, policies, audit logs, and service integrations move out of the platform before committing to expansion. Exit planning matters as much as deployment planning when a security stack becomes central to access control.
- Measure operator dependence as a risk indicator. Track how many specialised engineers are required to run onboarding, policy updates, rotation, and incident response. If the tool needs a permanent expert team to stay safe, the control is carrying hidden governance debt.
- Set explicit boundaries for agentic features. If you evaluate AI agent controls, define what the platform may do autonomously, what still requires approval, and which delegation paths remain prohibited. Do not let an emerging feature set inherit human IAM assumptions by default.
Key takeaways
- Idira is best read as CyberArk under a new umbrella, with broader positioning but the same core governance questions.
- The material risk is operational complexity, especially where one platform spans PAM, secrets, certificates, and early agent controls.
- Practitioners should judge the stack by lifecycle ownership, migration pain, and exit readiness, not by the rebrand narrative.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secrets rotation and lifecycle governance are central to the platform discussion. |
| NIST CSF 2.0 | PR.AC-4 | Privilege control and access management drive the PAM and audit discussion. |
| NIST Zero Trust (SP 800-207) | PR.AC | The platform’s broad control plane intersects with zero trust access decisions. |
Tie privileged access processes to PR.AC-4 and confirm least privilege across all identity domains.
Key terms
- Identity Blast Radius: The amount of access, control, and operational dependency concentrated in one identity platform or control plane. A larger blast radius does not mean a worse product by default, but it does mean a failure, migration issue, or governance gap can affect more identity domains at once.
- Secrets Lifecycle: The end-to-end management of non-human credentials from creation through use, rotation, review, and removal. In practice, it is the discipline that determines whether API keys, tokens, certificates, and workload secrets can be governed without relying on manual cleanup or scattered ownership.
- Privilege Governance: The policy and operational control of elevated access across users, admins, service accounts, and related identity workflows. It focuses on who can act, for how long, under what approval model, and how evidence is preserved for audit and incident response.
- Agentic Identity: An identity model for software that can decide actions at runtime, choose tools, and execute without needing a human to approve each step. That makes governance harder than with ordinary workload identities because the access boundary can shift during execution, not just at provisioning time.
What's in the full article
Infisical's full blog post covers the operational detail this analysis intentionally leaves for the source:
- A side-by-side breakdown of Idira, CyberArk, and the renamed product components for practitioners comparing packaging and capabilities.
- Detailed discussion of which existing CyberArk products continue, which are renamed, and how the portfolio is being positioned under Palo Alto Networks.
- Pricing, deployment, and operational complexity notes that help teams estimate whether the platform fits a small, mid-market, or large-enterprise operating model.
- Practical buying guidance for teams deciding whether to stay with CyberArk lineage tooling or evaluate simpler alternatives.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme governance, it is worth exploring.
Published by the NHIMG editorial team on 2026-06-29.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org