Application access governance needs shared ownership, not just IT

At a glance

What this is: This piece argues that application access governance is a shared business and security responsibility, not an IT-only function.

Why it matters: For IAM and NHI practitioners, the lesson is that access decisions fail when business context, control testing, and technical enforcement are split across disconnected teams.

By the numbers:

• Today, most organizations rely on 10 to 15 different business applications to manage critical functions like financial transactions, HR operations, and customer data.
• Organizations lose 5% of annual revenue to fraud, with the average case costing $1.7 million.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Delinea's guidance on who owns application access governance

Context

Application access governance is the discipline of deciding who should have access to business applications, what level of access is appropriate, and how exceptions are reviewed over time. In ERP, HCM, and CRM environments, the governance problem is not just scale but context, because access can create fraud, privacy, and segregation-of-duties risk when no one owns the full control loop.

The article frames a familiar enterprise pattern: IT can provision and automate, but business teams know what access should mean in practice. That division matters for IAM because application access decisions are part of a wider identity governance model, including reviews, evidence, and remediation. For NHI programs, the same ownership problem appears when service accounts and automation identities move across systems without a clear control owner.

Key questions

Q: How should organisations assign ownership for application access governance?

A: Organisations should treat application access governance as a shared program, not an IT ticket queue. Finance should own SoD policy, application owners should certify access based on business need, internal audit should test control effectiveness, and IT should implement provisioning and monitoring. That separation keeps decisions grounded in business reality while still allowing technical enforcement and evidence collection.

Q: When does user access review become ineffective?

A: User access review becomes ineffective when reviewers do not understand the business purpose of the access they are approving. If certifications are reduced to checking boxes, stale and excessive permissions stay in place. Reviews work best when they are tied to clear role definitions, exception handling, and remediation workflows that remove access, not just record it.

Q: What is the difference between SoD and sensitive access controls?

A: SoD prevents one identity from holding conflicting privileges that could enable abuse of a process, such as creating and approving the same transaction. Sensitive access controls flag high-risk permissions that may not create a formal conflict but still widen blast radius. Teams need both because one addresses process integrity and the other addresses privilege concentration.

Q: Why should security teams care about application access governance?

A: Security teams should care because excessive application access creates fraud, privacy, and audit exposure that IAM controls are expected to prevent. The technical side of the program lives with security and IT, but the business meaning of access lives elsewhere. Without that split, access decisions become inconsistent, and risky permissions persist far longer than they should.

Technical breakdown

Why application access governance breaks at application scale

Application access governance fails when entitlement review, policy definition, and remediation sit in different operating models. ERP and CRM systems often expose object-level permissions, roles, and exceptions that are hard to reason about from tickets alone. The technical challenge is not simply visibility. It is mapping business function to effective access, then keeping that mapping accurate as roles change, integrations expand, and exceptions accumulate. Continuous review is harder than periodic certification because business context changes faster than manual control cycles.

Practical implication: Practitioners should map each critical application to a control owner, a business approver, and a technical operator before automation is introduced.

How segregation of duties and sensitive access are enforced

Segregation of Duties, or SoD, is a control pattern that prevents one identity from completing conflicting steps in a sensitive process. In business applications, SoD rules compare combinations of entitlements against toxic access scenarios such as creating vendors and approving payments. Sensitive access adds another layer by flagging high-risk privileges that may not violate SoD directly but still increase blast radius. Automation can detect these conflicts, but policy quality depends on whether the rules reflect the real business process and not just the role catalogue.

Practical implication: Teams should validate SoD rules against actual workflows and revisit them whenever application roles or approval paths change.

Why continuous user access reviews need more than workflow automation

User access reviews, or UARs, are only effective when reviewers can see both the entitlement and the business reason for it. Workflow automation speeds collection and attestation, but it does not create judgment. If application owners, finance, and audit are not aligned, certifications become box-ticking exercises that preserve outdated access. The stronger model is continuous monitoring with exception handling, so review findings feed back into provisioning, deprovisioning, and evidence generation instead of becoming isolated audit artifacts.

Practical implication: Security teams should connect access review outcomes directly to remediation tickets and time-bound exception tracking.

Threat narrative

Attacker objective: The attacker objective is to use legitimate application access paths to manipulate financial or employee data without immediate detection.

1. Entry occurs through excessive or poorly reviewed access in ERP, HCM, or CRM systems, often after a role change or a weak certification cycle.
2. Escalation follows when a user or insider keeps conflicting privileges that allow abuse of sensitive transactions or data changes.
3. Impact appears as fraud, privacy exposure, or an audit failure that the organisation discovers too late to prevent material loss.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

Shared ownership is the only workable model for application access governance. IT can execute provisioning and automation, but it cannot define business-acceptable access on its own. Finance, audit, and application owners bring the process context that makes SoD and certification meaningful. Organisations that centralise ownership in the technical team usually create either overprovisioning or endless exception handling, so the program should be owned collaboratively from the start.

Application access governance is becoming an identity control plane problem. Business applications now hold the same kind of high-value entitlements that NHI programs manage in service accounts and automation identities. The governance lesson is that access review, entitlement modeling, and evidence collection need to operate continuously, not as annual checklists. Practitioners should treat application access as a living identity program, not an audit season activity.

Operational automation cannot replace control judgment, but it can make judgment scalable. The strongest access programs combine workflow, review, and remediation so people spend time on exceptions rather than clerical follow-up. That matters because stale access is usually a process failure before it becomes a technical one. The practical conclusion is that automation should compress cycle time while preserving business review authority.

The real failure mode is not missing tools, it is missing accountability. Many organisations already have review, provisioning, and reporting capabilities, yet still struggle with fraud and audit findings because no one is accountable for the end-to-end access decision. That is especially relevant as non-human identities spread through business applications and adjacent workflows. Practitioners should assign decision ownership before they try to optimise the tool stack.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: Read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the provisioning, rotation, and offboarding controls that underpin shared ownership models.

What this signals

Application access governance and NHI governance are converging. As business applications absorb more automation, the same ownership gaps that weaken user certification will also weaken service account and agent oversight. Teams that already struggle to assign accountability for ERP and CRM access will find NHI sprawl harder to contain unless they define control owners now. The forward move is to unify identity review, exception handling, and evidence collection across human and non-human access paths.

Ephemeral access will not fix poor decision ownership. Just-in-time patterns can reduce standing privilege, but they do not solve who is allowed to approve access or what business context justifies it. That is why access governance programmes need both policy and operating model changes, especially where automation identities can change data or trigger workflows. Practitioners should plan for controls that track decision authority, not only credential lifetime.

With 72% of organisations having experienced or suspect they have experienced a breach of non-human identities, according to our 2024 ESG report on managing non-human identities, control ownership is now a programme risk, not a process detail. Organisations that separate finance, audit, application, and security responsibilities without a clear governance loop will continue to miss risky access. The practical response is to establish one accountable review model across business applications and adjacent machine identities.

For practitioners

• Define a shared ownership model Assign finance to SoD policy, application owners to access certification, audit to control validation, and IT to provisioning and monitoring. Write the handoffs down so no team assumes another owns the decision.
• Map toxic access combinations Build a ruleset for conflicting entitlements in ERP, HCM, and CRM systems, then test it against real approval and transaction workflows rather than generic role names.
• Automate user access reviews with remediation Tie review findings to time-bound tickets, revoke exceptions when owners do not respond, and keep an evidence trail for control testing and audit.
• Use least privilege for business roles Compare each role to the actual tasks performed and remove inherited access that no longer supports the job function or process step.

Key takeaways

• Application access governance fails when control ownership is split without clear accountability.
• Fraud, privacy exposure, and failed audits are the predictable result when excessive access is not reviewed in business context.
• Teams should unify business approval, technical enforcement, and evidence collection before they automate access governance at scale.

Key terms

• Application Access Governance: Application access governance is the process of deciding who should have access to business applications and how that access is reviewed, approved, and remediated over time. It combines business ownership, control testing, and technical enforcement so access remains aligned to job function, risk tolerance, and compliance obligations.
• Segregation of Duties: Segregation of Duties is a control pattern that prevents one identity from performing conflicting actions in a sensitive process. In business applications, it helps stop a single user from combining steps that could enable fraud, concealment, or control failure, especially when access spans finance, HR, or customer systems.
• User Access Review: User Access Review is the periodic or continuous certification of whether a user still needs the permissions they hold. The control is only effective when reviewers have enough business context to identify stale, excessive, or inappropriate access and when review outcomes are tied directly to remediation.
• 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

Application access governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building shared ownership and review processes across business systems, it is worth exploring.

This post draws on content published by Delinea: Who owns application access governance in an organization? Read the original.