D365 FO

D365 F&O API Security: Stop Client Secret Leaks and Enforce Least Privilege

Sajeed Mullaji

Sajeed Mullaji

— 5 min read
Share
D365 F&O API Security: Stop Client Secret Leaks and Enforce Least Privilege

Right now, your third-party vendors are extracting data from your ERP using a shared Client Secret. When that static text string leaks—and it is only a matter of time—your entire financial database is compromised.

In enterprise architecture, relying on client secrets and over-privileged service accounts is a guaranteed SOX ITGC audit deficiency. I have already configured a secure Workload Identity Governance architecture in my live environment. Let’s look at exactly what I built to enforce certificate rotation and lock down D365 F&O API integrations to absolute least privilege.

The Problem: Client Secrets and the Admin Trap

In the Microsoft Entra admin center, setting up an App Registration usually starts with generating a client secret.

If Microsoft builds client secrets into Azure by default, how is using them an ITGC audit deficiency?

Because client secrets are just passwords for machines. They get hardcoded into scripts, accidentally committed to GitHub repositories, and passed around in Teams chats. In a SOX audit, a static string that grants direct database access without MFA is an immediate deficiency.

Entra ID Client Secret Deletion — Deleting the generated client secret in the Vendor Invoice Integration App Registration to eliminate the supply chain vulnerability.

The vulnerability multiplies when implementation teams map that application into D365 Finance and Operations.

Mapping integrations to the System Admin account prevents go-live API errors and saves hours of troubleshooting. Why break what works?

Yes, it is faster during implementation. But speed at go-live becomes a catastrophe during a breach. If a vendor's system is compromised and you mapped their integration to the Admin account, their API token now has God-mode access to your ERP.

The Fix: Certificates and Least Privilege Mapping

We are killing the client secret. Instead, this integration uses Certificate-based authentication.

Do we have to procure premium public PKI certificates for this to work in production, or can we bypass the licensing cost?

You do not need to buy premium certificates for internal server-to-server integrations. Microsoft Entra ID does not validate the certificate chain for Application objects; it strictly uses the public key for cryptographic signature verification. I generated a self-signed certificate natively in PowerShell, providing the exact same asymmetric encryption strength at zero cost.

Entra ID Certificate Upload — The self-signed certificate successfully uploaded to Entra ID, establishing a cryptographic baseline with a strict thumbprint and expiration date.

Inside D365 F&O, the identity bridge must be surgically restricted. Rather than mapping the App Registration Client ID to the System Administrator, I have mapped it to a dedicated, non-interactive service account: SVC Financial Batch.

F&O Identity Mapping — The Microsoft Entra ID applications screen proving the Client ID is mapped strictly to the SVC Financial Batch user to enforce least privilege.

The Proof: 403 Forbidden vs 200 OK

To prove this architecture works, I generated a bearer token using my certificate and pushed an API call through Postman to the F&O Bank Accounts endpoint. The result is a raw 403 Forbidden.

Does the F&O API require a separate security matrix, or does it natively inherit the exact RBAC roles assigned to the service account?

F&O does not maintain a separate API security matrix. The OData endpoint inherently respects the exact same Role-Based Access Control assigned to the SVC Financial Batch user. Because that user has no business reading bank accounts, the kernel drops the request.

Postman 403 Forbidden — Live Postman API call to the BankAccounts endpoint returning a 403 Forbidden, proving the F&O kernel blocks unauthorized data extraction.]SVC Financial Batch holds only the Batch job manager role — a non-financial operational role with zero access to banking or vendor payment data. The kernel enforces this boundary at the OData layer before any data is serialized.

To prove the contrast, look at the exact same Postman call using an App Registration mapped to the System Administrator account.

Postman 200 OK Admin Mapping — The exact same Postman call returning a 200 OK, exposing the entire Bank Accounts payload due to a dangerous Admin mapping.

The entire payload is exposed.

If an auditor pulls our API logs and sees third-party integrations running as System Administrator, what is the exact penalty?

It is a material weakness finding. The auditor will force you to prove exactly what data was extracted over the past year, triggering an exhausting forensic investigation. By mapping integrations strictly to non-interactive, least-privilege service accounts, you contain the blast radius to only the data they actually need.

Stop using client secrets. Enforce certificates, and map to least privilege.

Visit sajeedmullaji.com.

Frequently Asked Questions (FAQ)

What is Workload Identity Governance in D365 F&O? Workload Identity Governance is the practice of securing non-human API integrations and service principals. It ensures third-party applications connecting to D365 F&O are authenticated securely and restricted to least privilege access.

Why are client secrets a risk for D365 F&O integrations? Client secrets are static text strings that act as passwords for applications. Because they lack MFA and are easily hardcoded or leaked, they represent a severe supply chain vulnerability in enterprise ERP environments.

How do certificates improve D365 F&O API security? Certificates use asymmetric cryptography, meaning the private key never travels across the network. They also force a lifecycle governance event via hard expiration dates, ensuring continuous rotation and auditing.

Can I use a self-signed certificate for D365 F&O integrations? Yes. Entra ID utilizes the public key strictly for signature verification on application objects. A self-signed certificate provides the necessary cryptographic strength for internal API integrations without external licensing costs.

Why shouldn't I map Entra ID applications to the System Administrator in F&O? Mapping to the System Administrator grants the external application global access to all ERP data. If the third-party system is breached, attackers can extract highly sensitive financial data, resulting in catastrophic SOX audit failures.

Read more