Application access governance needs shared ownership, not just IT

At a glance

What this is: This article argues that application access governance fails when it is treated as an IT-only task, because business applications concentrate sensitive access risk across finance, HR and customer systems.

Why it matters: It matters because IAM and IGA teams need shared accountability for access reviews, segregation of duties and provisioning if they want business application governance to hold up under audit and fraud pressure.

Context

Application access governance is the discipline of controlling who can access sensitive business applications and whether that access still matches business need. In ERP, HCM and CRM environments, the governance problem is not simply provisioning, but deciding who owns policy, review and remediation.

The article’s core point is that manual access tracking across business applications has outgrown an IT-only model. When access decisions sit too far from the business process, organisations lose the context needed to spot overprovisioning, Segregation of Duties conflicts and stale permissions before they become audit or fraud issues.

Key questions

Q: What breaks when IT is treated as the sole owner of application access governance?

A: IT can provision access, but it cannot reliably judge whether a role is appropriate for the business process. When IT owns the whole model, organisations tend to grant excessive or insufficient access, miss toxic permission combinations, and weaken the audit trail. The result is control drift, not better governance.

Q: Why do excessive permissions increase fraud and lateral movement risk in enterprise systems?

A: Excess permissions widen what a compromised or careless identity can touch. That creates more ways to move between applications, databases, and admin functions, and it also increases the chance that one user can both initiate and approve sensitive actions. The result is larger blast radius and weaker segregation of duties.

Q: How do organisations know if access certification is actually working?

A: Look for shrinking numbers of standing privileges, faster revocation after review decisions, and fewer orphaned or overprivileged accounts over time. If campaigns finish but access sprawl remains unchanged, the programme is producing documentation rather than governance. Working certification changes the entitlement baseline, not just the audit record.

Q: What should organisations do when employees move roles inside critical business apps?

A: They should trigger a new access review whenever responsibilities change, because stale permissions often persist after internal moves. The review should compare current access to the new job function, identify SoD conflicts, and remove rights that no longer match the role.

Technical breakdown

Why business application access becomes a governance problem

ERP, HCM and CRM systems carry the data and workflows that make access decisions consequential. These platforms often span finance, HR, sales and customer operations, so a single entitlement can create both operational convenience and control exposure. Application access governance exists because manual review cannot reliably keep pace with changing roles, role-based reports and cross-application dependencies. The technical issue is not only who can log in, but which securable objects, roles and approval paths they can reach inside each application.

Practical implication: treat access governance as a lifecycle and controls problem across the application estate, not as a one-time provisioning task.

How segregation of duties controls work across business apps

Segregation of Duties, or SoD, is the rule that no single user should hold a combination of access rights that lets them create, approve and conceal the same transaction. In business applications, SoD conflicts can hide inside role design, composite privileges and exceptions that were never re-tested after role changes. The article also points to sensitive access, which is broader than SoD and covers high-risk access that may be legitimate but still inappropriate without oversight. The control challenge is to identify toxic combinations before they are normalised by workflow.

Practical implication: map access rules to business process conflicts, not just to user roles, and re-evaluate exceptions whenever roles change.

Why application owners matter more than IT alone

Application owners understand how the system is used, which permissions are routine, and which access patterns are abnormal for their domain. That context matters because IT can provision and report on access, but it cannot reliably judge whether access is business-appropriate without input from the people closest to the process. In governance terms, ownership has to be split between policy, assurance and technical execution. If application owners are absent, certification becomes a mechanical checklist and stale permissions survive role moves, reorganisations and process drift.

Practical implication: assign access certification to application owners and use IT to execute changes, not to define business appropriateness alone.

Threat narrative

Attacker objective: The attacker objective is to use inappropriate application access to manipulate business processes, hide unauthorised actions or evade audit and compliance controls.

1. Entry occurs through excessive or inappropriate access granted inside ERP, HCM or CRM systems, where a user receives permissions beyond what their role requires.
2. Credential or account abuse then lets the user act inside business workflows that should have been separated, obscuring who can approve, modify or conceal transactions.
3. Escalation follows when overprovisioned roles or stale permissions are reused after job changes, allowing sensitive actions to be carried out without fresh review.
4. Impact is fraud, privacy exposure or failed audit outcomes because control evidence no longer matches the actual access landscape.

Breaches seen in the wild

• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Application access governance fails when ownership is treated as an IT deployment question. The article shows that business applications sit at the point where finance, HR, sales and security controls intersect, so no single technical team has enough context to govern access well. That is a governance design problem, not a tooling problem. The implication is that access governance must be structured around business accountability, not delegated into the infrastructure team by default.

SoD is only effective when it is tied to real business process conflicts. In ERP and adjacent systems, toxic combinations do not show up as abstract permissions, but as the ability to create, approve and reconcile the same activity. That makes role review and exception handling a process-control exercise as much as an access-control exercise. The implication is that finance and audit must help define what separation actually means in each workflow.

Shared ownership is the control model, not a coordination courtesy. The article’s strongest signal is that application access governance only works when finance, internal audit, application owners, and IT each own a distinct part of the programme. That structure mirrors how effective governance works in practice: business context, assurance, and technical enforcement remain separate but linked. The implication is that organisations should measure whether each team has a defined decision right, not just whether a tool exists.

Continuous monitoring matters because access drift is the real failure mode. The article points to changing roles, overprovisioned access and stale permissions as the practical reasons governance breaks down. Once access reviews become periodic rituals without ownership, excess permissions survive long enough to create fraud and audit exposure. The implication is that application access governance should be treated as an ongoing control environment, not a periodic recertification event.

What this signals

Shared ownership is the decisive control design: application access governance only holds when business owners, audit and IT each carry a defined part of the control. When those roles blur, access review becomes an administrative ritual instead of a governance mechanism.

Business applications create the conditions for control drift because roles change faster than entitlement reviews. The operational signal to watch is not simply whether access exists, but whether stale permissions survive job changes and exception handling.

The practical shift for identity teams is to treat access governance as an ongoing assurance model across business apps, with ownership, evidence and enforcement separated but coordinated.

For practitioners

• Define business-owned access decisions Assign finance, audit and application owners explicit responsibility for defining which access is appropriate for each critical business process, while IT executes the technical changes.
• Map SoD conflicts to actual workflows Build segregation of duties rules from the transaction steps inside ERP, HCM and CRM systems, then review exceptions with the business owner of each process.
• Separate certification from provisioning Use application owners to certify access appropriateness and use IT or security teams to implement approved changes and evidence the outcome.
• Monitor stale access after role changes Trigger targeted access reviews when employees move roles, change responsibilities or transfer between functions, so obsolete permissions do not persist.
• Automate evidence for audit readiness Generate review, change and provisioning records from the governance process so internal audit can validate control design and operating effectiveness without reconstructing events manually.

Key takeaways

• Application access governance breaks down when one team is expected to own business decisions, control design and technical execution at the same time.
• The risk is not abstract: excessive access in ERP, HCM and CRM systems can lead to fraud, privacy violations and failed audits.
• The control that matters most is shared ownership, with finance, audit, application owners and IT each accountable for a distinct part of the process.

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.
• User Access Review: A user access review is a periodic check that confirms each account still needs the access it has. In identity programs, the control is used to reduce excess privilege, support compliance, and catch access that has outlived its business need.
• Sensitive Access: Sensitive access is permission that gives an identity elevated ability to view, change, approve, or export critical data or process steps. It may not always trigger a formal segregation-of-duties conflict, but it still increases blast radius and should be governed as high-risk access.

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.