Rising in Cyber 2026 signals where identity security is heading

At a glance

What this is: This is Orca Security's readout on Rising in Cyber 2026, a CISO-voted industry signal showing that identity security, AI agents, and cloud defence are converging in buyer priorities.

Why it matters: It matters because IAM, NHI, and autonomous AI governance are increasingly being judged together, which changes how security leaders prioritise controls, partnerships, and roadmap decisions.

By the numbers:

• The 2026 honorees were selected by 150 active CISOs and senior security executives.

Context

Identity security now sits at the intersection of cloud operations, AI adoption, and access governance. Rising in Cyber 2026 matters because it reflects what senior security buyers are treating as urgent: not just who can log in, but how software, services, and AI-driven systems are authorised to act inside the enterprise.

The article frames AI agents, application defence, security operations, and identity and access management as one decision space. That is the right lens for current programmes because the same access decisions now affect human users, service identities, and agentic systems, even when the controls are managed by different teams.

For practitioners, the useful signal is not the ranking itself but the shift it implies in buying and governance behaviour. If CISOs are voting identity and AI security into the same conversation, programme owners need to align IAM, cloud security, and AI governance more tightly than most organisations do today.

Key questions

Q: What does Rising in Cyber 2026 signal about identity security priorities?

A: It signals that identity security is no longer being treated as a narrow access management problem. Senior security leaders are elevating IAM, cloud defence, and AI security together because the same identities now govern human users, workloads, and emerging agentic systems across the enterprise.

Q: Why do AI agents change the way organisations think about runtime authorisation?

A: Because the decision to act now happens inside the session, not only at provisioning time. Runtime authorisation gives teams a way to constrain tool use, API calls, and data access to the current task, which is essential when the agent can initiate actions independently and cross trust boundaries without a human approval gate.

Q: What breaks when access reviews are built around static identity categories?

A: Reviews become blind to overlapping states, temporary affiliations, and delegated access that outlive the reason they were granted. The result is stale entitlements, unclear ownership, and inconsistent remediation. A review process that ignores relationship state will certify accounts that no longer match the person’s current role or authority.

Q: How should security teams organise controls across cloud, IAM, and AI security?

A: They should organise controls around actor type and reachable impact, not around team silos. Human accounts, service identities, and AI-driven execution paths need different lifecycle rules, but they should be assessed through one shared view of blast radius, containment, and accountability.

Technical breakdown

Why identity security is becoming a control plane

Identity has moved from an access administration function to the control plane for cloud and AI operations. When software, workloads, and agents are all authorised through identities, the real security question becomes whether those identities are scoped, observed, and retired correctly across the whole environment. That changes governance from periodic review to lifecycle control across issuance, privilege, and offboarding. In practice, the same identity model must now cover human access, workload trust, and machine-driven execution paths without assuming those subjects behave the same way.

Practical implication: treat identity governance as an operating model that spans human, workload, and agent access rather than a single IAM workstream.

What agentic AI changes in access governance

Agentic AI adds runtime decision-making to a problem that traditional IAM was built around static subjects and predictable request patterns. A human or service account typically requests access for a known task, but an autonomous agent can select tools, sequence actions, and change scope during execution. That breaks assumptions behind least privilege, certification timing, and approval workflows, because the privileged act may happen before any review can occur. The governance challenge is not just controlling credentials, but controlling what an agent is allowed to decide and invoke.

Practical implication: define authorisation boundaries for agent behaviour, not just for the credentials an agent uses.

Why cloud and application defence now overlap with IAM

Cloud security and application defence increasingly depend on identity context because most meaningful risk now flows through authenticated access paths, not perimeter entry points. A cloud control that lacks identity visibility cannot distinguish normal workload activity from abused access, and an application defence model that ignores identity provenance misses how sessions, tokens, and service accounts carry trust across components. That is why security teams are connecting cloud posture, runtime protection, and identity governance into one control conversation rather than treating them as separate domains.

Practical implication: map cloud and application controls to the identities that exercise them, then close the visibility gaps between those control owners.

NHI Mgmt Group analysis

Identity governance is becoming the organising layer for cloud and AI security. Rising in Cyber 2026 is another signal that buyers no longer treat IAM as a back-office control. The same entitlement decisions now shape access for people, workloads, and AI systems, which makes lifecycle governance central to enterprise risk management. Practitioners should treat identity as the connective tissue across cloud, security operations, and AI adoption.

Agentic AI breaks the old assumption that access is static enough to be reviewed after the fact. That assumption was designed for human-paced or workload-paced access decisions. It fails when an autonomous system can choose tools, execute actions, and alter scope during runtime. The implication is that governance programmes must rethink what is being governed: not only identity objects, but decision authority itself.

“Identity blast radius” is now a more useful metric than isolated control ownership. The market is moving toward integrated views of who or what can act, where that authority propagates, and how quickly it can be contained. That shift matters because cloud security, AI security, and IAM teams often assess risk in different languages. Practitioners should unify those views around reachable impact, not team boundaries.

Vendor consolidation is likely to accelerate around identity-rich control points. The report's market framing suggests that investors and security leaders are rewarding platforms that can connect identity, AI activity, and response workflows in one operational model. That does not eliminate best-of-breed demand, but it does raise the bar for point tools that cannot explain their identity governance role. Practitioners should expect tighter pressure to justify fragmented control ownership.

The most durable security programmes will govern actors, not product categories. Human users, service identities, and AI agents are converging in the same access paths, even though they need different policy and lifecycle treatment. That makes actor-type clarity the prerequisite for any credible IAM or AI security strategy. Security leaders should design controls around the subject that acts, not the tool that happens to expose it.

What this signals

Identity and AI governance are converging into one operating problem. Security teams should expect more programmes to collapse the separation between IAM, cloud runtime protection, and AI controls. The practical shift is from asking whether a tool authenticates correctly to asking whether the acting identity can be scoped, observed, and contained across the full execution chain.

Actor-type clarity will become a prerequisite for control design. Human users, workload identities, and autonomous systems cannot be governed as interchangeable subjects. Programme owners should map each identity type to its own lifecycle, authorisation, and offboarding rules before their environments accumulate more AI-driven access paths.

Identity blast radius will be a useful planning lens for cloud and AI security roadmaps. Instead of measuring maturity only by policy coverage, teams should track how far any single trusted subject can move if compromised or over-scoped. That gives a more realistic view of where investment reduces enterprise exposure fastest.

For practitioners

• Align IAM and AI governance ownership Create one decision map for who owns human access, workload identity, and AI agent authorisation so review, revocation, and escalation paths do not fragment across teams.
• Inventory identities by actor type Separate human accounts, service accounts, tokens, and AI-driven execution identities in your inventory, then define which controls apply to each lifecycle.
• Bound agent authority before production use Require explicit scope limits, tool access boundaries, and approval rules for any autonomous system that can select actions at runtime.
• Measure identity blast radius Assess how far a compromised or over-scoped identity can move across cloud, application, and AI systems, then prioritise the largest reachable impact paths.
• Rehearse cross-domain containment Test how quickly security teams can revoke access, disable tokens, and isolate workloads when the same identity spans cloud infrastructure and AI activity.

Key takeaways

• Rising in Cyber 2026 reflects a broader market shift: identity, cloud, and AI security are being evaluated together, not as separate buying categories.
• The article points to a governance problem, not a product problem, because access decisions now affect people, workloads, and AI systems through the same enterprise trust paths.
• Security leaders should reframe programme design around actor type and identity blast radius if they want controls that match how modern environments actually operate.

Key terms

• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Actor Type: Actor type is the governance classification of the identity subject, such as human, non-human, or autonomous. The distinction matters because different actor types create different trust assumptions, lifecycle requirements, and access risks, even when they use similar credentials or access the same systems.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.