App Registration Security

BI for Defender reads from Microsoft Graph and the Microsoft Defender for Endpoint API through a single Microsoft Entra app registration that holds a client secret. That app registration is the product’s entire security surface. It carries the application permissions listed on the Entra App Permissions page, plus a client secret that authenticates the scheduled data refresh. This page covers how to keep it secure: grant it only what it needs, use it only for what it was made for, protect and monitor the secret, and watch for tampering.

One app registration, one job

Use this app registration only for BI for Defender. Do not reuse it for other scripts, reports, or automation, and do not add permissions our documentation does not call for. A single-purpose identity is the easiest to protect and the safest if the secret is ever exposed.

Least Privilege

Keep this identity as narrow as possible. Two rules:

Grant only the permissions our documentation lists. We strongly discourage adding any Microsoft Graph permission, any Microsoft Defender for Endpoint API permission, or any other API permission that is not explicitly called for in our documentation. The Entra App Permissions page is the complete set BI for Defender needs. Anything beyond it does nothing for the product and only widens what the client secret could reach if it were ever exposed.

Use it only for BI for Defender. We strongly discourage using this app registration for any workload other than the BI for Defender data refresh it was created for. Do not borrow it for one-off scripts, other reports, or any other automation. A single-purpose identity is far easier to monitor, rotate, and reason about, and it keeps one compromised task from putting everything else at risk.

The Client Secret and Why It Is Required

BI for Defender is a Power BI template app. Its semantic model authenticates to Microsoft Graph and the Defender for Endpoint API using values you enter as model parameters, including the tenant ID, client ID, and client secret. A template app has nowhere to attach a managed identity or a Key Vault reference, so a client secret is required. Secretless authentication is not available for this kind of app.

Because the secret cannot be removed, contain it:

• Use the shortest workable expiry, and plan to rotate. Do not accept the longest option out of habit. Put the renewal on a calendar before it expires so a silent expiry never stops your refresh.
• Treat workspace membership as access to the secret. The secret is stored in the semantic model parameters, so anyone with Contributor or higher on the reporting workspace can read it in clear. Keep Admin, Member, and Contributor to a small named group, and give everyone else Viewer access through the published app. Review that membership the way you would review who holds a live credential.
• Never share it. Do not paste the secret into email, tickets, chat, or any store outside the model. Rotate it immediately after any support session where it may have been seen, and after any in-place upgrade.

Monitor Secret Expiration

Microsoft Entra does not send an automatic email when an app registration client secret is about to expire. That built-in reminder exists only for enterprise-application SAML certificates, not for app registration secrets, so you have to monitor for it yourself or a silent expiry will stop the data refresh.

Microsoft provides first-party ways to do this:

• The Renew expiring application credentials recommendation in Microsoft Entra surfaces app registrations whose secrets or certificates are near expiry.
• The Microsoft Entra security operations guide for applications shows how to read credential lifetimes with Microsoft Graph and alert on them.

Alert on Credential and Permission Changes

A new client secret or a new API permission that appears on this app registration and that you did not add yourself is a strong sign of tampering. Watch the Microsoft Entra audit log for changes to this app registration, in particular:

• New credentials (secrets or certificates) added to it.
• New API permissions or admin-consent grants.

Microsoft’s security operations guide for applications documents the exact audit activity to watch (Update application, Certificates and secrets management) and links a ready-made Microsoft Sentinel detection for newly added credentials.

Security Checklist

• The app registration holds only the permissions listed on the Entra App Permissions page.
• The app registration is used only for BI for Defender, nothing else.
• The client secret uses the shortest workable expiry, and its renewal is on a calendar.
• Workspace Admin, Member, and Contributor are limited to a small named group; everyone else has Viewer.
• Secret-expiry monitoring is in place (the Entra recommendation or a Graph query).
• Audit-log alerting is in place for new credentials or permission changes on the app registration.
• The secret is rotated after any support session and after every in-place upgrade.

Questions

For security questions about BI for Defender, contact support@powerstacks.com.