Saviynt’s KuppingerCole recognition highlights identity governance scope

At a glance

What this is: Saviynt’s press release says KuppingerCole recognized it across four identity-security evaluations, reinforcing the push toward unified governance across human, machine, privileged, non-human, and AI identities.

Why it matters: For IAM teams, the practical issue is whether governance, privileged access, and application-risk controls are still operated as separate programmes when the identity surface is converging.

👉 Read Saviynt’s press release on KuppingerCole recognition across identity security evaluations

Context

Saviynt’s announcement is about identity governance scope, not just analyst recognition. The central question is how far an identity programme can extend when the same governance model is expected to cover workforce, machine, privileged, non-human, and AI identities across hybrid and cloud environments.

That matters because identity teams are already being asked to unify policy, review, access control, and compliance across systems that were historically managed separately. The underlying governance challenge is familiar to readers of the Ultimate Guide to NHIs, but the operational pressure is now broader and more cross-domain.

Key questions

Q: How should IAM teams govern human, non-human, and AI identities together?

A: Start by separating the identity types in policy, ownership, and review cadence, then define where controls can be shared and where they must remain distinct. Human users, service identities, and AI systems do not fail in the same way, so the governance model has to preserve that difference while still producing one audit trail.

Q: Why do PAM and IGA need to be aligned in enterprise identity programmes?

A: Privileged access is only defensible when it is visible to governance and recertification. If PAM runs as a separate control plane, teams can approve elevated access without the same ownership, policy, and evidence used in access reviews, which weakens auditability and increases privilege drift.

Q: How do organisations know if identity governance is too fragmented?

A: Look for duplicated reviews, inconsistent owners, and exception handling that differs by platform rather than by policy. If the same entitlement is governed differently in IGA, PAM, and application-risk workflows, the programme is fragmented even if each team believes it is compliant.

Q: What should teams do when access control spans SAP and other business applications?

A: Treat business application entitlements as governance evidence, not just application administration. Teams should map segregation-of-duties risks, certification triggers, and remediation ownership into the same review process used for core identity controls, so business-process access is governed with the same discipline as technical privilege.

Technical breakdown

Why unified identity governance becomes harder across human and non-human access

Identity governance and administration works best when the subject, entitlement, and review cadence are stable. Once the programme spans humans, service identities, privileged accounts, and AI-driven access, the control model has to handle different lifecycle triggers, different ownership patterns, and different evidence expectations. That is where fragmentation becomes a governance issue rather than a tooling issue. The architectural question is not whether a platform can list identities, but whether policy, certification, and exception handling still remain coherent when the identity types behave differently.

Practical implication: map governance controls to identity type before you consolidate programmes.

How privileged access management changes when governance is identity-centric

PAM is no longer just about vaulting credentials or brokering admin sessions. In a converged identity model, privileged access becomes one expression of a broader entitlement system that also includes approvals, recertification, context, and audit evidence. That shifts PAM from a standalone control tower to a component of identity governance. The technical risk is overlap without consistency, where one team grants privilege and another team certifies it without the same policy basis or lifecycle visibility.

Practical implication: align PAM policy, review, and exception handling with the same identity record used for governance.

What SAP access control and business application risk management add to the identity stack

SAP and business application governance introduce a different layer of complexity because access often reflects business process, not just technical privilege. Effective control depends on understanding transactional risk, segregation of duties, and application-specific entitlement logic. That is why identity security vendors increasingly talk about governance across applications, not only directories. The mechanism is straightforward: the farther entitlements drift from a single source of truth, the harder it is to prove who can do what, where, and under which policy.

Practical implication: treat application risk data as part of identity governance evidence, not as a separate audit exercise.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unified identity governance is now a structural requirement, not a programme preference. Saviynt’s recognition across IGA, PAM, SAP access control, and business application risk management reflects a market that is converging around one problem: the identity estate no longer fits into separate human, non-human, and privileged silos. That convergence matters because identity decisions made in one domain now affect the others, especially in hybrid and cloud environments. Practitioners should read this as a signal that governance scope is expanding faster than most operating models.

Identity governance loses precision when it is organised around control families instead of actor types. The article repeatedly frames governance across workforce, machine, privileged, non-human, and AI identities. That is the right direction, but it also exposes a common enterprise weakness: teams often design controls by tool category, then discover that the review, ownership, and evidence model does not line up across identity classes. The implication is that governance architecture has to start with the subject being governed, not with the product stack.

AI-era identity security is pushing IGA toward cross-domain entitlement governance. The vendor’s language is less about a single capability and more about the expectation that identity security platforms should correlate policy, access, and risk across systems that were once managed independently. That shift is especially relevant for organizations trying to reconcile IGA, PAM, and application risk management under one governance model. The practical conclusion is that point controls will not be enough if entitlement decisions stay fragmented.

Access certification and privileged control are becoming inseparable in modern identity programmes. The press release ties privileged access to contextual access management and identity governance, which reflects a broader trend: recertification without privilege context produces weak evidence, while privilege without governance produces blind spots. This is not a vendor-specific issue. It is the operational reality of running identity controls across business processes, applications, and infrastructure at the same time. Practitioners should expect audit expectations to move in that direction.

Identity security platforms are being judged on breadth because enterprise risk is already cross-functional. When a single product evaluation spans governance, privileged access, SAP control, and application risk, the market is signaling that practitioners want fewer seams between programmes. That does not mean every control belongs in one console. It does mean governance teams should re-evaluate handoffs, duplicated reviews, and disconnected evidence chains. The field is moving toward integration because the identity surface is already integrated.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly one governance failure can become a repeat problem.
• That is why the NHI Lifecycle Management Guide remains the right next step for teams trying to connect governance, rotation, and offboarding across machine identities.

What this signals

Identity governance is being pulled toward cross-domain control planes, but programme maturity still depends on the quality of ownership data. The practical risk is not simply too many identity types. It is inconsistent records, unclear accountability, and review processes that do not survive contact with SAP, PAM, and AI-adjacent access paths. Teams that want a unified model should start with ownership clarity, not tool consolidation.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, per The State of Non-Human Identity Security, the market is signalling that identity governance can no longer treat machine access as a side concern. That shift will pressure IAM teams to make entitlements, certification, and remediation work across more actor types without losing audit fidelity.

As governance expands, the most useful control conversations will move from product category to lifecycle evidence. Practitioners should expect tighter scrutiny on who owns access, how exceptions are approved, and whether reviews actually reflect current privilege across applications and identities.

For practitioners

• Define identity scope by actor type Separate human, non-human, privileged, and AI identities in your governance model before you consolidate controls. Use that inventory to decide where certification, approval, and exception handling should differ.
• Align PAM and IGA evidence Require the same identity record, owner, and policy basis to support privileged access approvals and access recertification. This reduces audit gaps where access is granted in one process and certified in another.
• Map application risk into governance workflows Pull SAP and business application entitlement risk into routine access reviews so segregation-of-duties issues are evaluated alongside standard entitlement checks. That keeps application risk from becoming a separate audit afterthought.
• Review cross-domain handoffs Document where IGA, PAM, and application-risk teams hand off responsibility, then test whether each handoff preserves ownership, evidence, and remediation accountability.

Key takeaways

• Identity governance is expanding beyond human access and now has to cover machine, privileged, and AI-driven identities in one operating model.
• When governance is split across IGA, PAM, and application-risk workflows, entitlement evidence becomes harder to trust and audit outcomes become less consistent.
• Practitioners should redesign controls around identity type, ownership, and lifecycle evidence before they attempt broader platform consolidation.

Key terms

• Identity Governance and Administration: Identity governance and administration is the set of processes used to assign, review, certify, and remove access across an organisation. In modern programmes, it has to work across human, non-human, and AI identities while still preserving ownership, evidence, and auditability.
• Privileged Access Management: Privileged access management governs elevated access that can change systems, data, or business outcomes. It is no longer only a vaulting problem. In identity-centric programmes, PAM must align with governance, context, and lifecycle evidence so privileged entitlements remain defensible.
• Non-Human Identity: A non-human identity is any machine or software identity used by a service, workload, token, key, certificate, bot, or agent. These identities often outnumber human accounts and can create disproportionate risk when ownership, rotation, or review is unclear.
• Access Recertification: Access recertification is the periodic review of whether an identity should keep its current entitlements. For non-human and AI identities, the review must reflect lifecycle, ownership, and runtime behaviour, because static human-style review cadences can miss rapid privilege change.

What's in the full analysis

Saviynt's full press release covers the recognition details and conference context this post intentionally leaves for the source:

• The exact KuppingerCole report categories and ranking language behind the four evaluation mentions.
• Quoted statements from Saviynt executives on AI-era identity security and unified governance.
• Conference session titles and speaker names tied to the European Identity and Cloud Conference.
• The company description of how its platform coverage spans workforce, machine, privileged, non-human, and AI identities.

👉 Saviynt’s full press release includes the analyst quotes, conference sessions, and platform scope details.

Deepen your knowledge

Identity governance across human, non-human, and AI identities is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to align PAM, IGA, and application-risk processes in one programme, this is a useful place to start.