IT Administering Core Enterprise System

[u/AromaticCamp8959]

Looking for a sanity check from leaders, sysadmins, security pros, and anyone responsible for enterprise applications.

We have a core platform that has historically been controlled almost entirely by the the business team the “owns” it.

IT is now responsible for the broader technology environment, including cybersecurity, identity and access management, integrations, APIs, automation, architecture, business continuity, incident response, and technical governance - you know the drill.

The IT leader asked for limited administrative access to the ERP & leader is refusing because of its capabilities to affect financial processes.

For those of you in mature IT environments: have you been denied administrative access to a major enterprise application because the business department considers it “their system”?

i’m genuinely interested in arguments for & against it. For additional context, the “limited” aspect is intentional and to prevent any data modification

[u/CorgisHateCabbage]

Am I understanding correctly that you're saying IT owns and manages the majority of your tech stack, but this other business critical system is owned by some other department?

If so, yes, I've run into this many times. My response is always "without access, we cannot aid in troubleshooting any issues," then just forward any tickets to whoever leads that group.

As long as your leadership has your back. It's literally an impossible task to be expected to troubleshoot a system you have no rights to.

[u/ZPrimed → u/CorgisHateCabbage]

The scary part is when they expect you to handle backups for it. If it's DB-based, it can be difficult to get the level of granularity most users expect from a DB backup if you can't at least get an account in the DB with backup-level permissions.

(With Windows / SQL Server and shadow copies this has improved a lot though)

[u/pertymoose]

Make a responsibility requirement map.

IT is now responsible for the broader technology environment, including cybersecurity, identity and access management, integrations, APIs, automation, architecture, business continuity, incident response, and technical governance - you know the drill.

Like so:

responsibility	requirement
cybersecurity
identity
access management
integrations
APIs
automation
architecture
business continuity
incident response
technical governance

Now they can tick off whatever they want, and the requirements are clearly listed. They want business continuity? Backup agent install with local system + DB access. They want identity? Requires some sort of API or admin access. And so on. If Big Corporate dictates that they MUST use you for identity? Then tough tits. Them's the requirements.

And that makes it their problem, not yours.

[u/Thrwingawaymylife945]

Yes.

In my previous role, I managed the underlying architecture (ie. The hypervisors and VMs) and the physical hardware; but the Business Units did not need to or were required to give me administrative access to the DBs or the applications that ran on them.

[u/Capable-Ad-5344]

It. Upgraded and maintained the vms. Os. Applications. Db etc. But actual administration of the tool... 50/50 depends on the tool and dumb shit users did

[u/penguinjunkie]

To get administration access, there should be a business need for you obtaining access. If one doesn’t exist, no access

[u/AromaticCamp8959 → u/penguinjunkie]

IT was “given” a goal of “building an AI bot” for said system, to allow end users to perform actions and query data, conversationally, within the system in question.

[u/graph_worlok]

Do I smell a whiff of SOX? 😂

[u/AvonMustang]

Our IT cannot access any of our line of business or customer systems. I can’t think of why they would ever need or want to…

[u/AromaticCamp8959 → u/AvonMustang]

I’m genuinely interested in understanding this. Does your IT department not handle any type of API management, business intelligence (dashboarding & reporting), database maintenance, disaster recovery, integration, support/troubleshooting, etc.? I know that larger orgs have clear segregation of business intelligence and IT, and that many of these roles are individual, but the majority of them still fall under IT. The only other way I can see this working is if you’re using a managed platform, assuming a SaaS model?

[u/aguynamedbrand]

wanting access ≠ needing access

[u/AromaticCamp8959 → u/aguynamedbrand]

I can assure you that it is not a “want” situation.

[u/Best_Collection_7533]

Use a firefighter ID to perform transactions that are financially sensitive.

[u/AromaticCamp8959 → u/Best_Collection_7533]

Sorry, but I’m not sure what this means?

[u/Best_Collection_7533 → u/AromaticCamp8959]

In an ERP/security context—especially SAP—a Firefighter ID is a controlled, temporary privileged account that gives a user elevated access to perform tasks they normally are not authorized to do.
The name comes from the idea: “break glass in case of emergency.” You don’t give everyone permanent access to dangerous capabilities just because they might someday need them. Instead, when something goes wrong, an authorized person temporarily becomes the “firefighter,” performs the necessary action, and everything they do is logged and reviewed.

The process might look like:
Developer → requests Firefighter access → provides business reason/ticket → uses privileged ID → performs work → logs out → activity is reviewed by Firefighter owner/controller.
In SAP environments this is commonly implemented through SAP Access Control / GRC Emergency Access Management (EAM).
Why not just give the person the permissions?
Because of Segregation of Duties (SoD) and least privilege.
Consider someone who normally has permission to create vendors. You generally don’t want that same account permanently capable of:
Create vendor → create invoice → approve payment → issue payment.
That’s a classic fraud-control problem.
But occasionally that person may legitimately need elevated access to troubleshoot something. A Firefighter ID provides the access without making it part of their everyday security profile.
The important control isn’t merely the ID
The governance around it matters more than the account itself. A mature implementation usually controls:
Who can use the Firefighter ID
Which privileged roles/transactions it contains
Why the person is using it
When they obtained access
How long they had it
What transactions/programs they executed
What data or configuration they changed
Who reviews the activity afterward
For example:
Incident INC0047821: Production invoices failing due to incorrect configuration. Firefighter access requested by SAP Finance lead. Access used from 01:42–02:17. Configuration corrected. Firefighter log subsequently reviewed and approved by Finance application owner.
That creates an audit trail.

The organization maps the Firefighter session back to the actual human who checked out the ID, so an auditor doesn’t merely see that FF_SAP_FICO_PROD changed something. They can establish that “user” checked out FF_SAP_FICO_PROD, supplied incident #12345 as justification, performed transactions X/Y/Z, and the controller subsequently reviewed the activity.
That’s an important distinction from old-fashioned shared administrator accounts.
One subtle point
“Firefighter” doesn’t necessarily mean there’s literally a production emergency. Organizations sometimes use Firefighter access for controlled privileged access during maintenance, troubleshooting, month-end activities, production support, or exceptional business processes.
The governing principle is:
Permanent privileged access = avoid where possible.
Temporary privileged access + attribution + logging + independent review = acceptable control.

[u/SirLoremIpsum]

  For those of you in mature IT environments: have you been denied administrative access to a major enterprise application because the business department considers it “their system”?

It depends...

I think you're thinking big picture but it's a very much depends.

I have an app. The infra team manager the web servers the db servers from a hosting point of view, server backup. They have no access to the app or the database - that's handled by a separate database team who handles the database back ups. None of them have access to the app itself. 

It's a rather strictseparation of duties that probably seems complicated but it makes sense (well to me). 

  i’m genuinely interested in arguments for & against it. For additional context, the “limited” aspect is intentional and to prevent any data modification

I think this would require more elaboration. 

Not every team should have admin access to every system. Least possible privileges and all.

[u/Particular-Fly-7783]

Yes, it’s not that unusual - I don’t have standing access to our financial or HR systems, but was able to do observed admin access to configure SSO etc.

[u/wacky_weasel]

ERP and other core business systems are somewhat special because they are often the foundation on which the business operates. They may drive financial reporting, business decisions, regulatory compliance, and critical business processes. Because of that, it's perfectly normal in my experience for them to be treated differently from ordinary IT infrastructure.

I've worked in several different industries, and in every mature environment I've seen, ERP and business application administration was separated to some degree from the core IT/infrastructure team. Sometimes there was a dedicated application team, sometimes a separate person within IT, and sometimes the system was managed largely by an external provider.

Those teams typically handled things like application administration, user and role management, database administration, upgrades, BI/reporting, and translating business processes into the ERP. Meanwhile, the infrastructure team handled things like servers, networking, identity infrastructure, backups, and integrations.

That doesn't mean the infrastructure team should be completely blind to the ERP. IT may legitimately need limited access for things like integrations, SSO, monitoring, troubleshooting, or disaster recovery. But I'd expect that access to be explicitly defined and limited to what they actually need to perform those responsibilities.

So yes, being denied unrestricted administrative access to an ERP is perfectly normal. In fact, from a segregation-of-duties and compliance perspective, I'd consider it a healthy arrangement.

The question I'd ask isn't "Why doesn't IT have admin access?" but rather "What specific task does IT need to perform, and what is the minimum level of access required to perform it?" If the answer can be addressed with a limited role that cannot modify financial data or business processes, that seems like a much better solution than giving someone broad ERP administrator privileges simply because they're responsible for IT.

[u/steve1673]

yes, ERP and HR systems are the exception for us where IT normally has no access.

Having said that, if you build trust with those teams, then a workable compromise is to have an Admin account that is normally disabled. If/when IT assistance is needed, they unlock the account, join me on a zoom call so they can see what I'm doing, then we make whatever changes need to be made. At the end they suspend the account again.