Many organizations invest heavily in firewalls, endpoint protection and threat detection. That's the right instinct. But while the perimeter gets locked down, the door is left wide open to fraud risk within your own business applications.
Enterprise Resource Planning (ERP) and financial applications sit at the center of operations and hold your most sensitive data, control your financial transactions and determine who can create, approve or change critical records. And yet, security in these critical line of business systems is consistently underprioritized, misunderstood or misconfigured.
These aren’t theoretical risks. The Association of Certified Fraud Examiners (ACFE) estimates that organizations lose 5% of revenue to fraud each year, and more than half of occupational fraud cases trace back to missing or overridden internal controls. The damage isn’t always malicious; sometimes it’s a click on the wrong button by someone who had more access than they should have. Either way, the loss is tangible.
Addressing that risk calls for strong Application Access Governance (AAG): the framework and IT General Controls (ITGCs) that ensure the right people have the right access in these business applications, at the right time, and that their access is continually reviewed and enforced.
Below are ten common business application security “gotchas” and how to avoid them.
One of the most common errors is giving business application users more access than they need. It usually starts with a shortcut: Someone on the business side needs a problem solved fast, IT grants broad access and the admin role never gets removed. Multiply that across an organization, and you end up with bloated permissions, elevated risk and a system that’s nearly impossible to audit.
The fix is least privilege. Assign users only the bare minimum access required to perform their day-to-day functions, nothing more. Yes, it takes more time to implement correctly and requires collaboration with business application owners to get right, but there is recognizable ROI. Tightening access reduces fraud exposure, lowers segregation of duties (SoD) risk and saves on licensing costs in many ERP environments.
It’s easy to focus on whether a user can access the right screens and forget to check what that access actually enables or costs. In many ERP systems, security assignments are directly tied to licensing requirements. Over-assigning a user’s role can mean overpaying for that user’s license. I’ve seen organizations carry six- and even seven-figure licensing exposure because security was set up without anyone considering the downstream licensing impact.
My advice is to review every security design or change through two lenses: SoD risk and licensing impact. If your ERP system exposes telemetry data, use that to compare what users actually do against what they’re assigned and identify where you can scale back access and licenses.
For Microsoft D365 Finance & Supply Chain (F&SC) and D365 Business Central (BC), Delinea’s Fastpath Telemetry Data reporting surfaces exactly that. We also know that no employee ever raised their hand asking for access to be removed from their account. Right-sized access following a least privileged approach can also reduce these licensing costs.
Security should be treated like code. It needs to move through development, testing and production environments with proper review and sign-off at each stage. Instead, I see security being configured directly in production or inconsistently applied across environments because someone needed to move quickly, with limited or no testing of the security change.
The result is environments that don’t match, roles that exist in one place but not another and a provisioning drift that compounds over time. If you wouldn’t allow a developer to push code changes directly to production, don’t allow security changes to bypass the same controls.
Security isn’t static, and neither are your users. People change departments, employees leave the company and temporary contractors are brought on. Without scheduled user access reviews, temporary access becomes permanent, users accumulate roles they no longer need, and the security design created at go-live slowly erodes.
The fix is to build a cadence for user access reviews (UARs), whether quarterly, semi-annual or annual. Those reviews should answer three questions:
Who has access?
What access do they have?
Is that access still appropriate?
These reviews should not be done by IT alone. Business application owners and managers belong in the room because they’re the ones who can determine whether an access assignment is still needed. They should also have been the ones to approve the original access requests for these applications.
IT knows how to configure security. What IT often doesn’t know is what a given user in accounting, operations, or procurement should actually be able to do in their day-to-day job. When security design is treated as a purely technical exercise, business application owners are left out and you end up with roles that are technically valid but functionally wrong.
Application access governance is inherently cross-functional. Security provisioning and access design require a feedback loop between IT and the business. The business defines what access is needed, and IT implements and enforces it. When that communication breaks down, the result is over-provisioned users, access that doesn’t reflect real job functions and a security posture that nobody fully owns. Any of these can lead to control weaknesses and an increased risk of insider fraud.
Security often gets pushed to the end of an ERP implementation or upgrade because teams don’t want to slow functional testing. That delay creates expensive remediation later: role redesign, rework of the security architecture, even reconfigured business processes.
Start security work early and build it into every sprint cycle. It should be part of a required part of the implementation project plan, not a ‘nice to have.’ The payoff is a more coherent security model, fewer last-minute surprises and a team that’s practiced at the process before the go-live pressure is highest. Strong controls around security of your business applications lower fraud risk, which is a good thing to have in place.
If your QA team is running test scripts while logged in as a system administrator, you’re not testing security. You’re testing functionality with a blindfold on. If security isn’t tested properly, access issues only appear in production.
When you test an application, use the actual security roles users will have. Test security in phases:
Develop the security role
Assign it to a test user in isolation with no other roles
Validate functionality, then check SoD and licensing impact
Assign additional roles and revalidate
Additionally, the SoD risk picture often changes when roles are combined, and you need to catch that before it reaches production. Reviewing the SoD impact of proposed access changes before deploying them to production is another strong control for lowering fraud risk.
Your team is not the only one making changes to your system’s security model. ERP vendors and third-party ISVs push updates that add new features, modify existing permissions and introduce new security objects. I’ve seen ISV components that require elevated or even administrative access to function. Nobody questioned it because the assumption was that the vendor handled security responsibly.
In reality, usually those ISVs did not need elevated or admin access for their code changes to be introduced, but it was easier to just run wide open, but that introduces a new level of risk as well into your business application environments.
Don’t assume. Any update, whether from your ERP vendor or a third-party integration, should be assessed for its security impact. This includes SoD risk and licensing changes. Trust but verify applies here as much as anywhere.
Most enterprise business applications offer security capabilities well beyond basic role and permission assignments. Data-level security controls, entity permissions, and table-level frameworks exist to give administrators finer-grained control over who can see and do what. These features are frequently underused, either because organizations don’t know they exist, or because their implementation partner didn’t surface them during setup.
Before reaching for a custom workaround or accepting unnecessary access exposure, review what your ERP system already offers. There are often built-in tools that can solve the problem without additional cost or complexity.
However, this does not mean you should trust native roles that ship with business applications. Those roles were not designed with segregation of duties in mind. Most companies take the native roles and clone them, modifying them to meet their control needs, including SoD.
Picture a doughnut. Think of the outer ring as the cybersecurity perimeter: firewalls, endpoint detection, identity threat protection. Organizations invest heavily there, and rightly so, to mitigate those external threats. But the hole in the middle? Those are your business applications and the internal fraud risks. Too often, that hole in the security doughnut gets left to the line of business to manage, disconnected from the broader security strategy the CISO owns.
CISOs and CIOs who govern enterprise security need to own business application security too.
The internal threat is just as real as the external one
No firewall will stop the employee who accidentally initiates a purchase order for ten times the intended quantity, or the one who deliberately exploits overprovisioned access during a difficult stretch. True enterprise security means closing the hole in the doughnut, not just fortifying the perimeter.
Likely none of these mistakes will come as a big surprise, but I see them across industries, different business applications and organizations of every size. The common thread is the lack of a consistent approach to application access governance and the internal controls needed to mitigate fraud risks.
The good news is that none of these fixes require sophisticated tools or unlimited budget. They require process discipline, cross-functional communication and treating security as a first-class concern rather than a final checklist item. The solutions from Delinea Fastpath add easy-to-use application access governance controls that provide visibility and automation to streamline internal controls to support mitigating risks within operations. They also surface risk insights that guide informed access decisions.
Want to go deeper on any of these gotchas? I recently co-presented this topic in a live webinar for MS Dynamics World with my colleague, Alex Meyer, Microsoft MVP.
You can watch the full session on-demand here: Top D365 F&O Security Administration Gotchas and How to Avoid Them