Business application access governance gaps are driving hidden fraud risk

At a glance

What this is: This is Delinea’s analysis of ten common ERP and financial application security mistakes, centered on how weak application access governance exposes organisations to fraud and control failure.

Why it matters: It matters because IAM, IGA, and PAM teams cannot treat business applications as a separate domain when excessive access, poor reviews, and inconsistent controls create financial and compliance risk across human and non-human identities.

By the numbers:

• ACFE estimates that organisations lose 5% of revenue to fraud each year.

👉 Read Delinea's analysis of the top 10 business application security mistakes

Context

Business application security fails when access decisions are made quickly, then left in place long after the original need has passed. ERP and financial systems sit inside the control plane of the enterprise, so overprovisioned roles, weak review cadences, and inconsistent security design can turn routine access into fraud exposure.

The governance issue is broader than one application class. Application access governance has to connect business ownership, IT enforcement, and lifecycle control across humans and machine-like access paths. When those pieces drift apart, the organisation loses the ability to prove that access is still appropriate, not just technically valid.

That pattern is typical, not exceptional, in large enterprise environments where application security is treated as a late-stage configuration task instead of a governed control domain.

Key questions

Q: How should teams reduce fraud risk in ERP and financial applications?

A: Start with role design, not monitoring. Remove excess privilege, enforce segregation of duties, and ensure business owners validate which users can create, approve, or change sensitive records. Then pair that model with access reviews and lifecycle checks so temporary access does not become standing access. The goal is to make inappropriate action difficult, not merely detectable.

Q: Why do overprovisioned business application roles create audit problems?

A: Because they blur the line between technical access and approved business authority. Once a user can perform conflicting actions in the same system, auditors cannot easily prove that controls are preventing self-approval, duplicate payment, or unauthorized changes. Overprovisioning also makes role recertification less reliable because the entitlement set no longer matches actual job need.

Q: How do security teams know if business application controls are working?

A: Look for three signals: fewer standing exceptions, cleaner SoD outcomes after role combination tests, and access review results that consistently remove unused permissions. If the same people keep receiving broad access across projects or system changes, the control model is drifting. Effective governance should narrow access over time, not accumulate it.

Q: Who should own application access governance in finance systems?

A: Ownership should be shared. IT enforces the configuration, but business application owners decide what access is functionally necessary and managers validate whether it is still appropriate. Security teams should own the governance model and escalation path, because finance systems create control, fraud, and compliance exposure that no single function can manage well alone.

Technical breakdown

Overprovisioned roles create hidden segregation of duties failures

ERP and financial applications often bundle broad privileges into roles that are convenient to assign but difficult to unwind. Once users receive access beyond what their job requires, the problem is not only excess permission. It is also segregation of duties collapse, because the same account may be able to create, approve, and alter records in ways that bypass financial controls. Native roles frequently assume functional convenience, not control design. That is why role cloning, exception handling, and business-owner review become central to application security architecture.

Practical implication: map each high-risk business role to explicit SoD conflicts and remove any entitlement that cannot be justified by job function.

Lifecycle drift makes temporary access permanent

Access in business applications changes as people move roles, join projects, or leave the organisation, but the entitlement model often does not keep pace. Without structured user access reviews, temporary access becomes standing access and production roles diverge from the original design. This is not a visibility problem alone. It is a lifecycle control problem, because the application keeps enforcing outdated grants while the business has already moved on.

Practical implication: tie user access reviews to role changes, contractor expiry, and manager attestation so access does not outlive business need.

Security testing must validate roles, not just functionality

Testing a business application while logged in as an administrator proves the application works, but says little about whether the security model works. Effective testing requires role-specific validation, SoD analysis, and checks for licensing impact when permissions are combined. That matters because permissions that look harmless in isolation can create control failure when a user accumulates multiple roles. Security therefore has to be tested as part of the application lifecycle, not after go-live.

Practical implication: test new or changed roles in isolation first, then retest role combinations before production release.

Threat narrative

Attacker objective: The attacker or insider aims to bypass internal financial controls and manipulate business records, transactions, or approvals for direct monetary gain.

1. Entry occurs when business users are granted broad application access to solve operational problems quickly, often before proper role design is complete.
2. Escalation follows when those permissions are never removed, additional roles accumulate, and users gain the ability to create, approve, or modify sensitive records beyond their job need.
3. Impact appears as fraud, control override, licensing waste, and audit failure inside the ERP or financial system, where internal controls were expected to stop the abuse.

Breaches seen in the wild

• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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 the missing control layer in many financial systems. Organisations often overinvest in perimeter controls while leaving ERP and line-of-business access to ad hoc administration. That creates a gap between who can technically log in and who should be allowed to create, approve, or change financial records. The practical conclusion is straightforward: governance has to extend into business applications, not stop at the network edge.

Standing excess privilege is the failure mode this post describes. The issue is not simply that users have access. It is that access persists after the business reason expires, which breaks least privilege and SoD at the same time. That pattern is especially dangerous in finance and procurement workflows where a single account can influence both initiation and approval. Practitioners should treat excess privilege as a control failure, not an admin inconvenience.

Security ownership must move from a technical function to a shared control model. The article shows that IT alone cannot define appropriate access in accounting, operations, or procurement. Business owners must validate entitlement intent, while security teams enforce consistency and reviewability. That is why application access governance belongs in the same oversight conversation as IAM, IGA, and PAM, especially where financial exposure is at stake.

Built-in application controls matter more than custom workaround culture. Many enterprise systems already provide finer-grained security capabilities, but they are underused because teams accept the path of least resistance. That creates unnecessary access exposure and audit debt. The field implication is that security teams should prefer controls that fit the native application model before inventing exceptions that are harder to govern later.

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.
• 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.
• That confidence gap is why practitioners should also read Ultimate Guide to NHIs , Key Challenges and Risks for the control patterns that fail when access is too broad or too opaque.

What this signals

Access governance is converging across human and machine identities. The same failure pattern that creates ERP fraud risk also appears in NHI programmes when access is granted for convenience and never fully revisited. Teams that already struggle to evidence least privilege in business applications will find the same control weakness amplified as machine identities, service accounts, and API access expand.

Standing privilege is becoming the common denominator across identity programmes. Whether the subject is a finance user, a contractor, or a workload credential, the risk rises when access outlives the business reason for it. Practitioners should treat lifecycle review as an operating discipline, not a quarterly compliance event. The control objective is simple: reduce the number of identities that can act without current justification.

The practical next step is to align application governance with lifecycle management and Zero Trust expectations, using NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0 as organising references for ownership, review, and enforcement.

For practitioners

• Rebuild high-risk roles around least privilege Review ERP and financial application roles for create, approve, and modify combinations that violate segregation of duties. Remove access that is convenient for administration but unjustified by job function, especially in procurement and finance workflows.
• Tie access reviews to business events Run periodic user access reviews after role changes, contractor exits, and major process changes so temporary access does not become permanent. Include business application owners in the certification step, not just IT administrators.
• Test security in the same way you test functionality Validate each role in isolation, then test combined roles for SoD conflicts and licensing impact before production deployment. Treat security changes as lifecycle-managed changes, not late-stage configuration tweaks.
• Use native controls before custom exceptions Inspect the application’s built-in data-level, entity-level, and table-level permissions before approving workarounds. Where native controls already exist, prefer them over bespoke access paths that are harder to review and audit.

Key takeaways

• ERP and financial applications are not back-office exceptions. They are control systems, and weak access governance turns them into fraud exposure.
• Overprovisioned roles, stale entitlements, and poor security testing are the recurring failure patterns that erode SoD and auditability.
• Security teams need shared ownership, lifecycle reviews, and native application controls if they want access governance to hold up in production.

Key terms

• Application Access Governance: Application access governance is the discipline of deciding who should have access to business applications, what that access allows, and when it should be removed. It combines business approval, technical enforcement, and periodic review so access remains aligned with current job need and control requirements.
• Segregation of Duties: Segregation of duties is a control principle that prevents one identity from completing conflicting actions in the same process, such as creating and approving a payment. In business applications, it reduces fraud risk by making it harder for a single user to bypass financial or operational checks.
• User Access Review: A user access review is a periodic certification process that checks whether each identity still has the right permissions for its role. In practice, it is only effective when business owners participate, because they can judge whether access is still functionally necessary, not just technically assigned.
• Standing Privilege: Standing privilege is access that remains active all the time instead of being granted only when needed. In enterprise applications, it increases fraud and audit risk because the identity can perform sensitive actions long after the original business need has passed.

What's in the full article

Delinea's full blog covers the operational detail this post intentionally leaves for the source:

• A breakdown of each of the ten application security mistakes and the specific control gap behind it
• Practical examples from ERP and financial application environments, including security design and review patterns
• Discussion of telemetry-driven access analysis and how role changes affect licensing exposure
• Guidance on where built-in application controls can replace custom workarounds

👉 The full Delinea post covers the ten mistakes, access review cadence, and application control examples.

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.