Security
Every PowerStacks product installs into your Azure tenant or your Power BI workspace. We never have access to your data. Here is exactly how that works, so your security team can check it.
The short version
Most tools in this space run in the vendor's cloud. You grant their app registration broad Graph permissions, and from then on their service holds the keys to your Intune tenant. If they get breached, you get breached.
We built ours the other way around. The code runs on resources in your subscription. The identities live in your Entra ID. The data sits in your SQL database and your Power BI workspace. There is no PowerStacks service that can reach into your tenant, because there is no PowerStacks service in the path at all.
You don't have to trust what we do with your data. We don't have your data.
App Store for Intune: what the ARM template deploys
You install it from the Azure Marketplace into a resource group you choose. Everything below is created in your subscription and billed to you.
| Resource | What it does |
|---|---|
| App Service (Linux) | Runs the .NET API and the React portal. HTTPS only, TLS 1.2 minimum. |
| Azure SQL Database | Requests, approvals, settings, audit log. Encrypted at rest with Transparent Data Encryption. |
| Azure Key Vault | Holds the SQL and storage connection strings. Only the App Service's managed identity can read them. Soft delete is on. |
| Storage account | Queue and blob storage for the packaging pipeline. |
| Application Insights and Log Analytics | Application logs and monitoring, in your workspace. |
| Azure Bot (optional) | Teams notifications. It has its own managed identity with no Graph or Intune permissions. |
Identity: a managed identity, not a client secret
The App Service authenticates to Microsoft Graph as its own system-assigned managed identity. Azure creates it, Azure rotates it, and there is no secret for anyone to copy, leak, or forget to renew. The Microsoft Graph application permissions App Store needs (read and write Intune apps, manage groups, read users, send mail) are granted to that identity by your tenant administrator, during setup, in your tenant.
The app registration you create for sign-in is just that: sign-in. Client ID only. No client secret, no certificate, no Graph permissions.
The managed identity can read its own Key Vault secrets, read and restart its own App Service, and call Graph with the permissions you granted. It cannot touch other resources in your subscription, write to Key Vault, or reach SQL without the connection string from Key Vault.
Because sign-in goes through your Entra ID, your Conditional Access policies apply. We recommend requiring MFA and compliant devices for the portal, the same way you would for any internal app.
BI for Intune, BI for SCCM, and BI for Defender
The BI products are Power BI template apps. They install into your Power BI workspace, and the semantic model refreshes on the schedule you set, using the Power BI service in your tenant. The reports and the data behind them never leave your Microsoft 365 environment. Who can open a report is controlled by your workspace permissions and your Microsoft 365 policies, not by us.
BI for Intune and BI for Defender read data through Microsoft Graph and the Defender API using an app registration you create. Power BI cannot use a managed identity for this, so that registration does use a client secret or certificate, held in your tenant, with read-only permissions that are listed in the setup guide. BI for SCCM connects to your Configuration Manager database with a read-only SQL account through your own data gateway.
The optional enhanced inventory script runs on your devices and writes to a Log Analytics workspace in your subscription. Its app registration can write to those inventory tables and nothing else.
Data handling
- ✓Data at rest is encrypted. SQL uses Transparent Data Encryption, Key Vault and Log Analytics use Azure-managed keys.
- ✓Data in transit is TLS 1.2 or newer everywhere, including the SQL connection.
- ✓User sign-in tokens stay in the browser session and are not stored on the server.
- ✓Every request, approval, settings change, sign-in, and administrative action is written to an audit log in your SQL database. It is never purged automatically, and admins can read it under Reports, Analytics, Audit Trail.
- ✓No device, user, app, or inventory data is sent to PowerStacks. The one call to us is the license check, once a day: your tenant ID and your managed device count, so we can tell the store whether the license is valid for that many devices. The store also downloads its catalog index and its own update packages from bi.powerstacks.com. Those are downloads. Nothing about your tenant rides along.
- ✓Updates are packages you apply from inside the portal. The store verifies the package before installing it.
Things worth tightening after install
The template ships with defaults that work in every tenant. A few of them you should tighten to match your own policies, and the docs show how.
- The SQL Server firewall starts with the "allow Azure services" rule. Replace it with a private endpoint or a VNet rule if your policy requires it.
- Add a Conditional Access policy that targets the App Store app registration.
- Put the App Service behind your own custom domain and certificate.
- Set an Admin Group. On upgraded stores without one, every signed-in user stays an administrator until you do.
Full detail, including every role assignment and Graph permission, is in the App Store for Intune security guide.
Have a security questionnaire?
Send it over. A real engineer answers it, usually the one who built the thing.