Application access governance is becoming harder to ignore

At a glance

What this is: This is Saviynt’s argument that application access governance has become a core identity control because application sprawl, third-party access, and cross-environment complexity are making access review and segregation of duties harder to sustain.

Why it matters: It matters because IAM, IGA, and PAM teams now need to govern access across many applications and identity types, not just within isolated systems or legacy GRC workflows.

By the numbers:

• Enterprise organisations utilize anywhere between 600 and 1,000 plus applications, which makes access governance materially harder across the stack.
• 15X according to some estimates

👉 Read Saviynt's analysis of application access governance and enterprise access sprawl

Context

Application access governance is the discipline that keeps access decisions, entitlement reviews, and segregation of duties under control across business applications. In this post, the central problem is not whether access exists, but whether organisations can still govern it consistently once application counts, identity types, and deployment models multiply.

That governance burden grows quickly when applications span SaaS, on-premises, and hybrid environments, because the access model is no longer uniform. The article frames application access governance as a practical extension of IGA, not a separate niche, and that is the right lens for teams responsible for both human and non-human access paths.

The article's starting position is typical rather than exceptional: most enterprises already have enough application variety and enough third-party participation to make manual, app-by-app governance brittle. The real issue is whether existing review and control processes can still produce a single answer to who has access to what, and for how long.

Key questions

Q: How should security teams govern access changes across hybrid identity environments?

A: They should treat provisioning, review, and revocation as one lifecycle control loop rather than separate tasks. The practical goal is to keep permissions aligned with current business need across cloud, SaaS, and on-premise systems. If identity state cannot be updated quickly enough, stale access becomes the real control gap.

Q: Why does application sprawl make access governance harder?

A: Because each additional application adds another entitlement model, another review queue, and another source of audit evidence that must be reconciled. When organisations reach hundreds of applications, manual governance becomes too fragmented to reliably show who has access to what and for how long.

Q: What breaks when third-party access is not included in identity governance?

A: Auditability breaks first, followed by containment. Supplier accounts can remain active across multiple systems without clear ownership, which makes it difficult to prove who authorised access, whether it was still needed, and whether privileged activity was monitored throughout the relationship.

Q: How should security teams implement segregation of duties across multiple business applications?

A: Start by mapping the business actions that must never sit in the same identity across ERP, finance, HR, CRM, and workflow systems. Then translate those actions into conflict rules that are checked whenever access changes, not only during audit season. The goal is to catch toxic combinations before they become operationally usable.

Technical breakdown

Why application access governance breaks down across hybrid estates

Application access governance becomes difficult when entitlement models differ across SaaS, on-premises, and hybrid systems. A single access review process must reconcile distinct role structures, object models, and audit expectations, which is why manual reconciliation becomes slow and error-prone. Once organisations rely on separate governance processes per application, segregation of duties analysis and cross-app access visibility degrade quickly. The technical issue is not just scale, but inconsistency in how access is represented and validated across platforms.

Practical implication: centralise entitlement collection and normalisation before access review cycles begin.

How third-party access changes the governance problem

The article points to a broader identity population that now includes supply chain partners, outsourced functions, contractors, and temporary workers. In practice, that means joiner-mover-leaver controls must extend beyond employees, because external identities often retain access in systems that were designed for internal users only. AAG becomes a control layer for access scope and duration, especially where auditors expect evidence that access was both approved and removed on time. Without lifecycle discipline, third-party access becomes a persistent governance blind spot.

Practical implication: include third-party identities in lifecycle review and offboarding workflows.

Why cross-application SoD needs standardised entitlement data

Segregation of duties only works reliably when entitlement data can be compared across applications. If each platform stores roles and permissions differently, SoD checks remain trapped inside individual systems and miss toxic combinations that span multiple applications. The article describes the value of standardising control requirements so security teams can identify actual versus potential violations across the estate. That is the architectural difference between local compliance checks and enterprise-wide access governance.

Practical implication: build SoD logic on normalised entitlement data, not on isolated application reports.

Threat narrative

Attacker objective: The objective is to turn fragmented application governance into durable access that enables misuse, persistence, or privilege expansion across business systems.

1. Entry occurs through expanding access surfaces across many applications, third parties, and hybrid environments where entitlement governance is inconsistent.
2. Escalation happens when over-broad roles, stale access, or cross-application inconsistency let an identity accumulate more privilege than intended.
3. Impact follows when toxic access combinations, delayed revocation, or weak monitoring allow lateral movement, audit findings, or policy violations to persist.

Breaches seen in the wild

• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
• Code Formatting Tools Credential Leaks — Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

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

NHI Mgmt Group analysis

Application access governance is now an enterprise identity control, not an application admin task. Once organisations operate hundreds of applications across multiple environments, access governance becomes the only practical way to unify entitlement review, SoD detection, and audit evidence. The discipline shifts from local control inside one application to enterprise control across many. Practitioners should treat AAG as part of the identity operating model, not as a reporting layer.

Cross-application visibility is the named governance gap this article exposes. The article's own logic depends on the fact that individual application reports do not tell the full access story. That gap is what breaks SoD assurance, emergency access oversight, and audit readiness when identity data stays siloed. The implication is that governance quality now depends on data normalisation as much as on policy design.

Third-party identities make application governance a lifecycle problem as much as an access problem. Contractors, outsourced staff, and supply chain partners change the shape of who needs access and for how long. When those identities are not folded into the same review and offboarding logic as employees, access outlives accountability. Practitioners should read AAG as a governance control for mixed identity populations, not a human-only review process.

Segregation of duties fails when entitlement models are not comparable across systems. The article highlights a real weakness in legacy GRC approaches, which often stop at the boundary of a single application. Once security teams must reconcile different models across multiple apps, the control assumption changes from static policy to continuous aggregation. The practical conclusion is that enterprise SoD depends on standardised entitlement evidence, not separate app-level attestations.

Cross-application governance is the right place to absorb the pressure from cloud migration and application sprawl. As more critical systems move into SaaS and hybrid estates, access risk moves with them and becomes harder to localise. AAG is therefore less about one product category and more about preserving control coherence across a fragmented application landscape. Teams that ignore this will keep finding gaps at audit time rather than at design time.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• For lifecycle governance context, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows how provisioning, rotation, and offboarding should be aligned.

What this signals

Application access governance will increasingly be judged by how well it spans identity types, not by how many application reports it can produce. As application estates fragment, teams need one evidence trail for employees, contractors, and machine-to-machine access paths. That is where cross-application entitlement normalisation becomes a programme design issue, not a reporting feature.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, access governance is now inseparable from privilege containment. If application review processes ignore machine identities, the control surface expands faster than the review cadence can absorb.

Cross-application governance will pull IAM, IGA, and PAM teams closer together. Access approval, SoD testing, and emergency access oversight now intersect in the same workflow, which means fragmented ownership will keep producing audit gaps and remediation delays.

For practitioners

• Normalise application entitlement data Pull roles, permissions, and access history from every business-critical application into a common control model before running reviews or SoD checks.
• Extend lifecycle governance to third parties Add contractors, outsourced workers, and temporary staff to joiner-mover-leaver processes so access approvals and removals are tracked with the same rigor as employee access.
• Prioritise cross-application SoD rules Define toxic combinations that span multiple applications, then test them continuously instead of relying on single-system compliance reports.
• Review audit evidence coverage Check whether your current access governance process can prove who had access, who approved it, and when it was removed across SaaS, on-premises, and hybrid systems.

Key takeaways

• Application access governance is becoming essential because enterprise application sprawl has outgrown app-by-app control models.
• Third-party identities and non-human identities make lifecycle oversight and entitlement normalisation the core governance problems.
• Teams that standardise cross-application evidence and SoD logic will be better positioned to survive audit scrutiny and reduce access risk.

Key terms

• Application-Aware Access Governance: Application-Aware Access Governance is identity governance that understands the rules, data, and workflows of a specific business system. It goes beyond generic provisioning by connecting entitlements to process context, transaction behaviour, and cross-system evidence needed for defensible decisions.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Cross-application Entitlement Data: Cross-application entitlement data is the normalised record of roles, permissions, and access assignments collected from multiple systems. It lets identity teams compare access consistently, detect toxic combinations, and produce audit evidence that remains valid even when the underlying applications are different.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.

What's in the full article

Saviynt's full article covers the operational detail this post intentionally leaves for the source:

• Vendor examples of application types included in its access governance model, including ERP, SaaS, and on-premises systems
• The specific ways the platform standardises control requirements across multiple application security models
• How its reporting and violation remediation workflows are positioned for audit and compliance teams
• The KuppingerCole review and webinar context behind the product discussion

👉 Saviynt's full post covers cross-application control models, SoD governance, and audit visibility in more detail.

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.