Business application security gaps are widening in enterprise IAM

At a glance

What this is: This is Delinea's analysis of the “security doughnut” problem, where business applications remain less controlled than the surrounding enterprise security stack.

Why it matters: It matters because IAM, IGA, and PAM teams need to govern application access, segregation of duties, and elevated privileges across finance, HR, CRM, and ERP systems, not assume those risks are covered elsewhere.

By the numbers:

• Organizations lose 5% of their revenue to fraud each year, and the average fraud loss per case is $1.7M, according to the Association of Certified Fraud Examiners.

👉 Read Delinea's analysis of the business application security gap and control model

Context

Business application security is the control gap that appears when organisations protect infrastructure and data centrally but leave finance, HR, CRM, and ERP systems to departmental ownership. The result is a governance hole in the middle of the programme, where sensitive transactions, elevated privileges, and high-value records are often less tightly controlled than the surrounding environment.

The primary IAM issue is not whether these applications are important. It is whether access governance, segregation of duties, administrative review, and change control are applied consistently across all business systems. When ownership is split between business units and IT, the security model often becomes assumed rather than enforced.

Key questions

Q: How should security teams govern access in business applications with different owners?

A: Treat business applications as governed systems, not departmental exceptions. Central teams should define access standards, SoD rules, and review cadence, while application owners approve business justification. The control goal is consistency across ERP, HCM, CRM, and finance applications so no system becomes a blind spot for fraud or audit risk.

Q: Why do business applications create hidden identity risk even when perimeter security is strong?

A: Because the highest-risk actions often happen inside the application, not at the perimeter. Over-provisioned users, excessive admin rights, and weak workflow separation can all convert valid access into fraud or unauthorised change. Perimeter controls do not stop misuse once an authorised identity is inside the business process.

Q: How do organisations know whether application access governance is working?

A: Look for fewer unresolved SoD conflicts, lower volumes of over-provisioned access, complete review coverage for privileged accounts, and a clear audit trail for sensitive data changes. If access reviews keep finding the same exceptions, the governance process exists on paper but is not changing behaviour.

Q: Who should be accountable for business application security findings?

A: Accountability should sit with both the business owner and the identity governance function. The business owner defines acceptable access and approval risk, while IAM or IGA teams enforce the control model, maintain evidence, and escalate unresolved conflicts. Without shared accountability, application risk is pushed between teams and left unowned.

Technical breakdown

Application access governance across business systems

Application access governance is the discipline of deciding who can do what inside business applications, then proving those decisions stay aligned with job function and risk. In ERP, HCM, CRM, and procurement systems, the control challenge is not logon alone but entitlements, workflow permissions, privileged functions, and data-level access. When these are managed inconsistently, the organisation loses sight of who can create, approve, modify, or pay. That is where fraud, audit failure, and unauthorised change usually start.

Practical implication: map application entitlements to business-critical functions and review them at the permission level, not just the user level.

Segregation of duties and elevated privilege

Segregation of duties, or SoD, prevents one identity from completing conflicting actions that create financial or operational abuse paths. In business applications, that usually means separating create, approve, and pay workflows, and treating administrative access as a distinct risk tier. Elevated privileges matter because a small number of users can alter system settings, security roles, or sensitive data without the normal business controls that govern standard users.

Practical implication: define SoD conflicts for each critical application and review all administrative accounts on a fixed governance cadence.

Automated reviews for privilege creep and data change

Manual review processes struggle in application estates with frequent role changes, mergers, and system upgrades. Over time, users accumulate access that no longer matches their duties, which creates privilege creep and increases the chance of hidden conflicts. Logging critical data changes adds the second control layer, because governance is not only about who has access but about whether sensitive records are being altered unexpectedly and whether those changes can be traced.

Practical implication: automate user access reviews and critical-change logging so drift is detected before it becomes an audit finding or fraud path.

NHI Mgmt Group analysis

Business application security is where IAM governance meets financial control. The article correctly exposes a common enterprise blind spot: applications that hold financial, employee, and customer data are often governed by business ownership assumptions rather than by consistent identity controls. That model breaks down when entitlement risk, administrative access, and approval workflows sit outside central review. Practitioners should treat application access governance as a core control surface, not a local system issue.

Segregation of duties failure is the most concrete risk in the security doughnut. Once one identity can create, approve, and execute a transaction path, the organisation has a control design problem, not just a user access problem. That is why application governance must be measured at the lowest securable object and permission level. The practitioner conclusion is simple: SoD is only real when conflicting actions are structurally impossible or independently approved.

Privilege creep in business applications is a lifecycle failure, not a one-time misconfiguration. The article's emphasis on periodic access review is directionally correct, but the deeper issue is that role movement, mergers, and application growth constantly outpace manual governance. This is a classic lifecycle problem across human identity and application entitlement models. Practitioners should assume access will drift unless the review model is operationalised across the full application estate.

Identity blast radius: Business applications create concentrated impact zones where a small entitlement change can affect financial postings, employee records, or customer data. That makes access governance and change monitoring disproportionately valuable compared with generic perimeter controls. The implication for identity programmes is that blast-radius reduction should be measured by the systems most likely to convert access into loss.

Automated governance changes the economics of review, not the need for control. Manual checks are too slow when organisations run multiple applications with different owners and control models. Automation does not replace governance, it makes governance scalable enough to keep pace with organisational complexity. Practitioners should use automation to compress review cycles, reduce false positives, and surface conflicts before they become audit or fraud events.

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.
• In the same study, 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, which shows how quickly hidden access becomes operational risk.
• For a broader view of how identity risk compounds across machine and human programmes, see Ultimate Guide to NHIs , Why NHI Security Matters Now.

What this signals

Application governance will increasingly be judged as part of identity governance, not as a separate finance or operations concern. When entitlement review, SoD enforcement, and privileged access controls are fragmented across business units, the programme cannot produce a defensible access story. The next maturity step is to connect application controls to enterprise identity policy rather than treating them as local exceptions.

Identity teams should expect more audit pressure around access evidence in ERP and SaaS business systems. As application estates expand through mergers and best-of-breed adoption, the control gap moves from theory to reporting risk. Programmes that can show review coverage, conflict resolution, and traceable change history will absorb that pressure more effectively.

Identity blast radius: When a business application concentrates financial and operational authority, the safest programme is the one that can prove who can change what and why. That is why application access governance should be folded into broader IAM roadmaps alongside privileged access and lifecycle controls.

For practitioners

• Map access to business-critical functions Inventory entitlements in ERP, HCM, CRM, procurement, and finance systems, then map each permission to the business action it enables. Focus on create, approve, post, pay, and administrative functions because those are the control points most likely to create fraud or audit exposure.
• Build SoD rules at the lowest permission level Define segregation of duties conflicts at the lowest securable object or permission level to reduce false positives. Include workflow combinations such as vendor creation plus payment approval, or user administration plus role assignment, so the control reflects actual abuse paths.
• Separate administrative access from standard user review Review elevated privileges on a distinct cadence and require explicit business justification for each admin account. Do not let administrative access be inherited from standard role reviews, because privileged users can alter settings and data without ordinary workflow controls.
• Automate access review for privilege creep Use automated user access reviews to compare current entitlements with job responsibility and recent organisational changes. Trigger reviews after role changes, mergers, and system upgrades so over-provisioned access is identified before it becomes persistent.
• Log critical data changes continuously Track changes to sensitive or high-value records in finance and business applications, then preserve the audit trail for investigation and remediation. This gives you traceability when a transaction, approval, or master-data change needs to be explained later.

Key takeaways

• Business application security fails when access governance is split across departments and treated as someone else’s control problem.
• Segregation of duties and administrative privilege are the two controls that most directly prevent fraud and unauthorised change inside ERP, HCM, and CRM systems.
• Automation matters because access reviews, privilege creep detection, and change logging must keep pace with application growth and organisational change.

Key terms

• Application Access Governance: Application access governance is the process of deciding, approving, and reviewing who can do what inside business applications. It covers entitlements, workflow permissions, and privileged functions, with the goal of keeping access aligned to business responsibility and preventing misuse.
• Segregation of Duties: Segregation of duties is a control that prevents one identity from performing conflicting actions that could enable fraud, error, or unauthorised change. In business applications, it usually separates create, approve, and pay functions, or other combinations where one user should not complete the full transaction path.
• Privilege Creep: Privilege creep is the gradual accumulation of access that no longer matches a user’s current role. It happens when entitlements are not removed after job changes, reorganisations, or system growth, leaving users with more power than they need and increasing governance and fraud risk.
• Administrative Access: Administrative access is elevated permission that allows a user to alter system settings, security roles, or sensitive records beyond ordinary business workflows. Because it can bypass normal controls, it requires separate review, tighter justification, and stronger evidence than standard user 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Delinea: Closing the security doughnut, why CISOs need to prioritize business application security. Read the original.