> ## Content Index
> Fetch the complete content index at: https://www.sajeedmullaji.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# D365 F&O PIM — How to Eliminate Permanent System Administrator Access Forever
- URL: https://www.sajeedmullaji.com/d365-fo-entra-id-pim-eliminate-permanent-sysadmin/
- Published: 2026-09-17T09:55:01.000Z
- Updated: 2026-09-17T09:55:01.000Z
- Description: Ten permanent System Administrators in your D365 environment is an automatic ITGC audit failure. Discover how Entra ID PIM eliminates standing privilege and replaces it with governed Just-In-Time access — request, approve, activate, auto-revoke.
- Author: Sajeed Mullaji
- Tags: D365 FO, Entra ID, Security Governance, ITGC Audit, The D365 Governance Roadmap

When an external auditor reviews your Dynamics 365 Finance & Operations environment, they look for one critical flaw before anything else.  
If they pull your security reports and see ten IT users holding permanent, 24/7 "System Administrator" rights, you fail the ITGC audit instantly.  
Standing privileged access is the number one security governance failure in post-go-live ERP environments. It violates every principle of least privilege.  
If an attacker compromises an engineer’s credentials, or a disgruntled employee decides to act maliciously, permanent access gives them the keys to your entire financial ecosystem.  
Today, we are going to completely D365 eliminate permanent SysAdmin accounts.  
We will use D365 F&O PIM Privileged Identity Management to strip away permanent access and replace it with a time-limited, heavily governed workflow.  
We are moving your ERP to a pure Just-In-Time access D365 architecture. Here is the exact blueprint to build it.  

### The Core Concept: Eligible vs. Active Assignments

Before we touch the system, you must understand the difference between an "Eligible" assignment and an "Active" assignment. This is where most implementations fail.  
An Active assignment means the user holds the security role right now. They can log in and execute administrative tasks immediately.  
An Eligible assignment means the user holds absolutely zero permanent access. They only hold the *right to request* access when an emergency happens.  
By default, we want all IT staff, developers, and support engineers to be Eligible. They remain standard users until they explicitly prove they need elevated rights.  

### Step 1: Create the PIM Security Group

We start by building the container that will control our D365 F&O System Administrator governance.  
Log into the Microsoft Entra admin center at entra.microsoft.com. Navigate to Identity, then Groups, and click New group.  
Select "Security group" and name it `D365_Prod_SysAdmin_PIM`.  
You must flip the toggle for "Microsoft Entra roles assignable" to On. This is a critical architectural requirement.  
Enabling this toggle locks down the group. It prevents other administrators from secretly nesting groups inside it to bypass your security controls. It allows PIM to govern the group.  
Click Create. Finally, click "Enable PIM for this group".  
Notice one vital detail: We are not adding any permanent members. The group remains completely empty. PIM will now control who enters and exits this group.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/1-6.png)

D365\_Prod\_SysAdmin\_PIM security group created — Microsoft Entra roles assignable enabled — PIM will govern all access to this group — zero permanent members by default.

### Step 2: Add Peter as an Eligible Member

We now need to grant our support engineer, Peter Procurement, the ability to request access.  
Navigate to PIM, select Groups, and open our `D365_Prod_SysAdmin_PIM` group. Click Add assignments.  
Select Peter Procurement. Under the assignment type, you must select "Eligible". Do not select Active.  
Peter is now an eligible member. He currently has zero permanent access to the ERP.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/4-3.png)

Peter Procurement added as Eligible member — not Active — zero System Administrator access by default — must request and justify every activation.

### Step 3: Configure PIM Governance Settings

Now we dictate the strict rules of engagement. We must define exactly what Peter has to prove before the system grants him the keys.  
Still in the PIM dashboard for the group, go to Settings, select Member, and click Edit.  
First, we set the maximum activation duration to 2 hours. No human needs 24/7 access to fix a broken journal.  
Next, we enforce our audit requirements. On activation, we require Azure MFA. We toggle "Require justification" to Yes.  
We also toggle "Require ticket information" to Yes. Every elevation must tie back to a formal IT service desk request.  
Finally, we toggle "Require approval" to Yes, and we assign the IT Manager as the designated approver. Save the policy. The governance framework is now locked.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/5-2.png)

PIM governance rules — 2 hour maximum duration — Azure MFA required — business justification mandatory — ticket number required — manager approval before any System Administrator access is granted.

### Step 4: Peter Activates Just-In-Time Access

Let us look at this from the engineer’s perspective during a live production issue.  
A vendor payment posting fails, and Peter needs emergency access to fix it. He logs into Entra ID and searches for Privileged Identity Management.  
He navigates to My roles, selects the Groups tab, and clicks on Eligible assignments. He sees `D365_Prod_SysAdmin_PIM` and clicks Activate.  
The system demands his audit evidence. He sets the duration to 2 hours.  
He inputs his service desk ticket number: INC0008842.  
For the reason, he documents: "Emergency AP journal fix — vendor payment posting failed." He clicks Activate.  
The system does not let him in. His status changes to "Pending approval".

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/8.png)

Peter submits Just-In-Time access request — ticket number and business justification required — pending manager approval — no access granted until approved.

### Step 5: The Manager Approves the Request

Entra ID immediately fires an email alert to the IT Manager.  
The IT Manager logs into the PIM dashboard and clicks on "Approve requests". They see Peter’s request in the queue.  
They verify ticket INC0008842 in ServiceNow, confirming the business impact of the failed AP journal.  
The manager clicks Approve, adds their own justification note, and hits Confirm.  
At this exact millisecond, Peter is dynamically added to the `D365_Prod_SysAdmin_PIM` group. He now holds System Administrator rights.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/9.png)

IT Manager approves Peter's request — access dynamically granted — 2 hour timer starts — complete approval chain documented.

### Step 6: The PIM Resource Audit Log (Forensic Proof)

When your external auditors arrive, they do not want to hear a story about how secure you are. They want cryptographic proof.  
You navigate to PIM, open the `D365_Prod_SysAdmin_PIM` group, and click on Resource audit.  
The system provides an unalterable, automated timeline of the entire event.  
At 11:41am, the log shows Peter requesting access.  
At 11:52am, the log shows the IT Manager approving it.  
At 11:53am, the log proves access was formally granted.  
Exactly two hours later, at 1:53pm, the log shows Azure AD PIM automatically removing Peter from the group. His access expired.  
There was zero manual intervention required to revoke his rights. The audit evidence is completely flawless.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/9.1.png)

PIM complete audit trail — request at 11:41am — manager approval at 11:52am — access granted at 11:53am — automatic revocation at 1:53pm — zero manual intervention — complete ITGC forensic evidence.

### The CFO Cross-Examination

When I present this zero-trust architecture to enterprise leadership, the room usually goes quiet. Then, the CFO and IT Director start asking the hard operational questions.  
Here are the three most common challenges you will face when proposing Entra ID privileged access D365.  
  
**Cross question 1: What happens to our automated batch jobs if we remove permanent SysAdmins?**  
Answer: If your batch jobs fail because a human lost their SysAdmin rights, your architecture is deeply flawed.  
Batch jobs should never run under a human user account. They must execute under a dedicated, non-interactive service account or managed identity.  
Deploying PIM forces your technical team to fix this bad technical debt. As we discussed in our previous batch job identities guide, humans use PIM; system automation uses dedicated service accounts.  
  
**Cross question 2: What if production crashes at 3am on a Sunday? Does the engineer wait for approval?**  
Answer: Absolutely not. A rigid security system that breaks business continuity is a failed system. PIM allows for highly controlled emergency "break glass" configurations.  
Standard daily access requires explicit manager approval. However, emergency off-hours access can be configured to activate immediately upon request.  
The catch? When an engineer triggers immediate access, the system simultaneously fires a high-severity alert to the CFO and IT Director. You get emergency speed, but you never lose visibility.  
  
**Cross question 3: When the 2-hour timer expires, does the system kick the developer out mid-session?**  
Answer: No. Dynamics 365 relies on Entra ID token validation.  
When the timer hits zero, Entra ID instantly removes the user from the administrative group. However, their active browser session will continue until they naturally close it.  
What happens instead is that the access slowly suffocates. They cannot open new sessions, they cannot open new tabs, and if they refresh the browser, they are permanently locked out. To continue working, they must submit a brand new PIM request with a new justification.  

### Securing the Ultimate Governance Layer

This implementation perfectly connects with our previous work on network perimeters.  
In our Conditional Access deployment, we built the outer wall. We ensured no one could reach the ERP from an untrusted location.  
Today, we completed the identity governance layer. We ensured that even from a trusted location, no one holds the keys to the kingdom permanently.  
This dual-layered approach is how you modernize your enterprise security footprint and guarantee a flawless audit.  
You can explore the entire step-by-step masterplan at [sajeedmullaji.com/tag/d365-governance-roadmap](https://www.google.com/search?q=https%3A%2F%2Fsajeedmullaji.com%2Ftag%2Fd365-governance-roadmap&ref=sajeedmullaji.com).  
If you are looking for standardized, audit-ready matrices to accelerate your internal role design, download my professional frameworks directly at [sajeedmullaji.com/tag/templates](https://www.google.com/search?q=https%3A%2F%2Fsajeedmullaji.com%2Ftag%2Ftemplates&ref=sajeedmullaji.com).  
To permanently eliminate standing access in your ERP and build an unbreakable zero-trust architecture, reach out to me at sajeedmullaji.com to schedule a technical security assessment.  

### Executive Q&A: Advanced PIM Governance

**Q: Do we need expensive additional licensing to deploy this specific PIM workflow?**  
Yes. To utilize Privileged Identity Management, specifically PIM for Groups, your organization must hold Microsoft Entra ID P2 licenses. These are typically bundled in Microsoft 365 E5 or Enterprise Mobility + Security (EMS) E5 suites. However, if your enterprise is spending millions on a tier-one ERP like D365 F&O, operating without P2 governance is an unacceptable risk profile for any modern audit committee.  
  
**Q: What stops an engineer from activating PIM, going into D365, and creating a secret local Admin account that bypasses Entra ID entirely?**  
This is a sophisticated insider threat scenario. PIM governs Entra ID, not the internal D365 user table. To mitigate this, you must engineer strict Segregation of Duties (SoD) alerts inside D365\. Furthermore, your ITGC controls must mandate a weekly automated reconciliation report comparing active D365 users against your Entra ID master group. If a rogue local account appears, your security team is alerted immediately.  
  
**Q: How does Just-In-Time access impact our internal Segregation of Duties (SoD) conflict reporting?**  
It drastically cleans up your reporting. When developers hold permanent SysAdmin access, your SoD conflict reports light up with thousands of false positives because the SysAdmin role conflicts with every financial duty in the system. By using PIM, developers are standard users 99% of the time. When the auditor pulls the SoD report, it accurately reflects your clean, daily operational state.