How to Configure Emergency "Firefighter" Access in D365 F&O to Pass IT Audits

IT Directors often inherit this exact mess from implementation partners. During a high-stress go-live, partners grant SysAdmin to everyone to bypass security bottlenecks and resolve tickets faster. Post go-live, nobody cleans it up. The next annual ITGC audit surfaces it as a critical finding.

Auditors understand that IT teams need elevated access to fix broken transactions or unblock system crashes. What they demand is that this access be Just-In-Time, heavily monitored, and automatically revoked.

Here is the exact technical blueprint to engineer a compliant, automated Firefighter access process in current versions of D365 F&O (10.0.40 and later).

Why Persistent System Administrator Access Is an Automatic Audit Failure

In the D365 F&O architecture, the System Administrator role is hardcoded to bypass every single security layer:

• Bypasses Extensible Data Security (XDS): Row-level filtering policies that prevent a European user from seeing North American data are completely ignored.
• Bypasses the Table Permissions Framework (TPF): Field-level security meant to mask vendor bank routing numbers or employee salaries is overridden entirely.
• Breaks Segregation of Duties: A user with persistent SysAdmin can create a vendor, raise an invoice, approve the payment, post it, and delete the batch job history. The native SoD engine cannot even run conflict checks against this role.

Step 1 — Engineer a Custom Elevated Firefighter Role

Never use the out-of-the-box System Administrator role for temporary support access. Because you cannot run SoD conflict reports against it, you can never prove to an auditor what the user didn't do while holding it.

Navigate to System administration → Security → Security configuration. Click Create new and name the role Firefighter - Elevated Support.

Assign the functional duties required for IT troubleshooting — view access across ledgers, ability to run batch jobs, access to module parameters. Then explicitly exclude these privileges:

• SecurityRoleMaintain — prevents the firefighter from granting themselves additional access while elevated
• SysSecConfigurationMaintain — prevents alteration of the fundamental security architecture
• All Treasury and Payment duties — vendor bank account maintenance, payment journal creation, workflow approval limit modification

By building a custom role, your Firefighter access remains bound by the SoD engine. When the auditor asks for proof that the support team couldn't manipulate payments during a troubleshooting session — generate the SoD conflict report for the custom role and hand it over.

Step 2 — Time-Bound Assignment via Entra ID PIM

Manual role assignment is prone to human error. Helpdesk staff will inevitably forget to remove the role at end of shift, leaving access persistent and failing the next audit cycle. The enterprise standard is to outsource the time-bound logic completely to Microsoft Entra ID Privileged Identity Management.

Prerequisite: Enable the Entra ID security groups feature. Put the environment in Maintenance Mode via LCS or Power Platform Admin Center → System administration → Setup → License configuration → expand Administration node → check Microsoft Entra ID security groups.

When the timer expires, PIM automatically ejects the user from the group. Their Firefighter access in D365 F&O is immediately severed. You now have an immutable, time-stamped audit trail outside the ERP showing exactly who requested access, who approved it, and when it was revoked.

Step 3 — Database Logging on SecurityUserRole and SysUserInfo

Experienced ITGC auditors will immediately ask: how do you prove a rogue administrator didn't bypass your Azure PIM process and manually assign the Firefighter role directly inside D365 F&O?

Navigate to System administration → Setup → Database log setup. Click New and target two specific tables:

SecurityUserRole (User to role assignment): Expand the Security node, select User to role assignment, check Insert, Update, and Delete. This creates a permanent ledger entry if anyone manually assigns a role through the F&O interface, completely bypassing PIM.

SysUserInfo (User information): Log the Update event. Malicious actors with temporary elevated access frequently alter the email field on an executive's user record — rerouting workflow approval emails to their own inbox, approving a fraudulent transaction, then changing the email back before their access expires. This log catches intercept attempts.

Step 4 — Real-Time Governance Alerts

A database log gives the auditor a historical record — but your governance team needs real-time alerts when manual role assignments happen outside the PIM process.

• Navigate to System administration → Users → Users
• Select any user → right-click the Roles grid header → Create alert rule
• Set Event to Record has been created → change scope to All users
• Under Action tab → toggle Send email to Yes → enter your IT Security distribution list

Whenever a role is manually added to any user, your governance team receives an immediate email. They cross-reference it against active PIM requests. No corresponding PIM ticket means a manual security breach is in progress.

Step 5 — Quarterly Access Review

Auditors want proof of execution, not just configuration. Every quarter, your compliance team should:

• Generate the User Role Assignment report at System administration → Inquiries → Security → User role assignments
• Export the database log for SecurityUserRole
• Pull the PIM activation history from Azure Portal
• Cross-reference all three sources to prove 100% of Firefighter access over the last 90 days was documented, manager-approved, and successfully reverted

If you have this reconciliation completed and sitting in a folder before the Big 4 auditor asks for it, you completely control the narrative of the audit.