Dynamics 365 and Power Platform Security Guide

Dynamics 365 and Power Platform hold customer, finance and case data in Dataverse, and every app, flow and agent built on them reaches that data through connections, application users and admin roles that few security teams review. This guide explains how identity and access work across those layers, how to control privileged roles and service principals, what to log, and how to apply the CISA SCuBA Power Platform baseline. It is written for Power Platform administrators, Dynamics 365 platform owners and the security engineers who support them. Governance of citizen developers and internal AI apps is covered in the Citizen Developer and Internal AI App Governance Guide; this page goes deeper on the platform controls.

Key takeaways

Four layers decide access. Entra tenant roles, environment roles, Dataverse security roles and data policies each grant or block something different; review all four, not just the security roles.
Tenant admins are no longer automatic system administrators. Global, Power Platform and Dynamics 365 administrators must self-elevate to System Administrator in an environment, which makes PIM with short activations practical.
Application users are unlicensed, powerful NHIs. Each one maps to an Entra app registration or managed identity, acts with its own security roles and usually authenticates with a client secret that nobody rotates.
Connections are stored credentials. Data policies, endpoint filtering and tenant isolation decide which connectors can move data, and they need to be set before makers build, because enforcement can take up to 24 hours.
Logging is split and partly off by default. Purview captures admin activity automatically, but Dataverse auditing, access logging and read logging must be switched on per environment and per table.

How identity and access work in Dynamics 365 and Power Platform

Power Platform covers Power Apps, Power Automate, Copilot Studio and Power Pages. Dynamics 365 customer engagement apps such as Sales, Customer Service and Field Service run as model-driven apps on Dataverse in the same environments, so the controls in this guide apply to both. Dynamics 365 finance and operations apps use a separate role model and are out of scope.

Users authenticate with Microsoft Entra ID, so Conditional Access, MFA and sign-in risk policies apply before any platform permission is evaluated. See the Conditional Access Guide. After sign-in, four layers decide what the user can do.

Layer	Examples	Scope	What it controls
Entra tenant roles	Global Administrator, Power Platform Administrator, Dynamics 365 Administrator	Every environment in the tenant	Tenant settings, environment creation, data policies, capacity, self-elevation to System Administrator
Environment roles	Environment Admin, Environment Maker	One environment without Dataverse	Creating apps, flows, connections and custom connectors; Environment Maker has no data access
Dataverse security roles	System Administrator, System Customizer, Basic User, app roles such as Salesperson	One environment with Dataverse	Table privileges, access level, miscellaneous and privacy-related privileges
Data policies and tenant isolation	Business, non-business and blocked connector groups; endpoint filtering	Tenant, environment group or environment	Which connectors, actions and endpoints apps, flows and agents can use together

Dataverse security roles in practice

Privileges are cumulative: a user with several roles gets the union of all of them, so one broad role assigned "temporarily" overrides careful design elsewhere.
Table privileges: Read, Create, Write, Delete, Append, Append To, Assign and Share, each at an access level of User, Business Unit, Parent: Child Business Units or Organization. Organization-level Read on the account or contact table is effectively a full customer export.
Privacy-related privileges: exporting to Excel, printing and similar actions that move data outside Dataverse are separate privileges. Remove them from roles that do not need bulk extraction.
Column (field) security: field security profiles hide sensitive columns such as national ID or bank details even from users who can read the record.
Environment security group: associating an Entra security group with an environment limits who can be added to it at all, which is the simplest way to keep production Dynamics 365 away from the wider tenant.

Admin roles and privileged access

Microsoft no longer assigns the System Administrator Dataverse role automatically to Global, Power Platform or Dynamics 365 administrators. Those tenant admins can still change tenant settings, view analytics and capacity, but to update security roles or install apps in an environment they must self-elevate to System Administrator through the Power Platform admin center or the elevation API. When the tenant role is held through Microsoft Entra Privileged Identity Management, Microsoft removes the elevated System Administrator role when the PIM assignment expires. Two documented limitations matter: role assignment through groups is not supported for this flow, and a Dynamics 365 administrator must be a member of an environment's security group to elevate there.

Role	Risk if compromised	Recommended control
Global Administrator	Everything in the tenant, including Power Platform	Break-glass and PIM only; never used for routine platform work
Power Platform Administrator	All environments, data policies, tenant isolation, self-elevation anywhere	PIM eligible, approval, short activation, small named group
Dynamics 365 Administrator	All environments it can reach, self-elevation	PIM eligible; prefer this or Environment Admin over Power Platform Administrator where scope allows
System Administrator (Dataverse)	All data and customisation in one environment, audit settings	Assign per environment, review quarterly, remove standing assignments left from the old auto-assignment
System Customizer	Schema, apps, plug-ins and audit configuration	Development and test environments; production through pipelines
Environment Maker	Creates connections and custom connectors in the environment	Grant in governed maker environments, not by default in production

Clean up legacy assignments first: Microsoft's prerequisite for the PIM model is removing old System Administrator assignments that were granted automatically. Inventory them per environment before enabling PIM.
Use the narrowest admin role: Microsoft's guidance for the default environment is to limit the Power Platform Administrator role to a few users and consider Environment Admin or System Administrator instead. See the Privileged Identity Management (PIM) Guide.

Integrations, API tokens and service accounts

Integration platforms, data migration tools, portals and custom code reach Dataverse as application users. An application user is created in the Power Platform admin center (Environment, Settings, Users + permissions, Application users), linked to one Microsoft Entra app registration or managed identity, placed in a business unit and given security roles. It needs no paid licence, and every operation it performs is recorded as the application user, not as the person using the integration. Only one application user can exist per Entra application per environment.

Credential options for application users

Option	Where the credential lives	Strength	Weakness
Client secret on the app registration	Integration server config, pipeline variables, key vault	Easy to set up; documented default in the S2S walkthrough	Static bearer secret, often long-lived and copied between environments
Certificate on the app registration	Certificate store or key vault, private key not shared	Proof of possession; harder to leak in code	Expiry must be tracked; private keys still exported carelessly
Managed identity application ID	No credential handled by the customer	No secret to rotate or leak	Only for workloads running in Azure that support managed identity

One app registration per integration: a shared app user cannot be scoped or attributed.
Design a custom security role per application user: do not assign System Administrator to an integration because the vendor's setup guide says so. Start from the tables it actually reads and writes.
Prefer certificates or managed identity over secrets: a client secret on an app registration with Dataverse access is a high-value target. See the Azure Entra Client Secrets Security Guide and the Azure Managed Identities Security Guide.

Connections, connectors and agents

When a maker adds a connector to an app, flow or Copilot Studio agent, a connection is created with the authentication the connector supports and stored in the environment. Microsoft describes connections as saved credentials. A shared app or a flow that runs on a schedule therefore acts with the maker's identity or with whatever service account the maker signed in with. Custom connectors wrap any REST API and can carry API keys; Model Context Protocol connectors expose MCP tools to Copilot Studio and are governed through advanced connector policies.

Data policies: classify connectors as Business, Non-business or Blocked. An app or flow cannot combine Business and Non-business connectors. Microsoft states that enforcement usually completes within an hour and can take up to 24 hours, after which violating resources are suspended and blocked connections disabled.
Endpoint filtering: for connectors marked "Endpoint configurable" (HTTP, HTTP with Microsoft Entra ID, HTTP Webhook, SQL Server, Azure Blob Storage, SMTP and the browser and UI automation connectors), restrict which URLs, servers or environments makers can target inside the data policy.
Tenant isolation: off by default, which allows cross-tenant connections with valid Entra credentials. When on, inbound and outbound cross-tenant connections are blocked for Entra-authenticated connectors unless the tenant is on the allowlist. It does not block connectors that use other authentication, so pair it with data policies.
Agents: Copilot Studio agents use the same connectors and connections. The CoPhish research showed how an agent's demo site on a Microsoft domain could front an OAuth consent phishing prompt and forward the resulting token. See the Securing Microsoft Copilot Studio Agents Guide.

Logging and detection

Power Platform logging is spread across Microsoft Purview, Dataverse auditing and per-product telemetry. Only admin activity is collected by default.

Source	Default	What it records	How to enable or read
Purview: Power Platform admin activity	On, cannot be disabled	Environment lifecycle, setting changes, data policy changes, lockbox and licensing actions	Purview Audit with the Audit Logs or View-Only Audit Logs role; Office 365 Management Activity API
Purview: connector activity	Requires environment auditing	Custom API created, edited or deleted; connection created, edited, deleted; connection permission added or removed	Turn on auditing for production environments
Purview: Power Automate	Requires environment auditing	Flow created, edited, deleted; flow permission changes; trial events	Purview Audit; flow runs need Application Insights or Dataverse run records
Dataverse auditing	Off until started	Record create, update, delete, sharing changes, security role changes, audit log deletion	Environment setting Start Auditing, then per table and column; System Administrator or System Customizer
Dataverse access and read logging	Off	Sign-in access (Log access) and read activity to Purview (Read logs)	Environment auditing settings; Read logs needs qualifying Microsoft 365 licensing

Dataverse auditing does not record retrieve or export operations, so bulk export only appears through read logging. Audit retention defaults to Forever with a custom maximum of 24,855 days, and a change applies only to new records, so set it before go-live.

Detections worth building

Privilege change: security role assigned to a user or team, especially System Administrator, and self-elevation events outside a PIM activation window (ATT&CK T1078.004 Cloud Accounts).
New credentials on integration apps: a client secret or certificate added to an app registration that backs an application user (T1098.001 Additional Cloud Credentials), correlated with Entra audit logs.
Connection sharing: "Connection permission added or edited" on connections to SQL Server, SharePoint or HTTP, which hands the maker's credential to others.
Data policy or tenant isolation changes: any edit outside a change window, since a single connector move from Blocked to Business opens an exfiltration path (T1567 Exfiltration Over Web Service).
Bulk reads by an application user: unusual read volume from Read logs against customer tables (T1213 Data from Information Repositories).
Session replay: sign-ins rejected by IP cookie binding or the IP firewall, which indicate stolen cookies or tokens being used elsewhere (T1550.004 Web Session Cookie, T1528 Steal Application Access Token).

Forward Purview records to the SIEM; see the Microsoft Sentinel Guide.

Hardening baseline

CISA's Secure Cloud Business Applications (SCuBA) project publishes a Power Platform baseline and the ScubaGear tool that checks most of it automatically. Several policies are marked as requirements under Binding Operational Directive 25-01 for US federal agencies; for everyone else it is a credible, testable minimum.

SCuBA policy	Requirement	Level	Where to set it
MS.POWERPLATFORM.1.1v1	Restrict creation of production and sandbox environments to administrators	SHALL	Admin center tenant settings, environment creation
MS.POWERPLATFORM.1.2v1	Restrict creation of trial environments to administrators	SHALL	Same setting for trial environments
MS.POWERPLATFORM.2.1v1	Create a DLP (data) policy restricting connector access in the default environment	SHALL	Data policies
MS.POWERPLATFORM.2.2v1	Non-default environments have at least one DLP policy	SHOULD	Data policies scoped to environments or groups
MS.POWERPLATFORM.3.1v1	Enable Power Platform tenant isolation	SHALL	Security, Identity and access, Tenant isolation
MS.POWERPLATFORM.3.2v1	Configure an inbound and outbound connection allowlist	SHOULD	Tenant isolation rules (manual check)
MS.POWERPLATFORM.4.1v1	Enforce Content Security Policy for model-driven and canvas apps	SHALL	Environment privacy and security settings (manual check)
MS.POWERPLATFORM.5.1v1	Restrict Power Pages site creation to administrators	SHOULD	Tenant settings
MS.POWERPLATFORM.6.1v1	Disable "Share with everyone"	SHOULD	Tenant setting disableShareWithEveryone

Controls beyond the SCuBA baseline

Managed environments: enable them for production and the default environment. They unlock sharing limits, the IP firewall and IP-based cookie binding. Unmanaged developer environments are being deprecated.
IP firewall: allow Dataverse requests only from listed CIDR ranges and service tags. It starts in audit-only mode by default, which is the right way to test; review the "Allow access for Microsoft trusted services" bypass, which is on by default.
IP-based cookie binding: Settings, Product, Privacy + Security. Expect reauthentication when users switch VPN or networks, and configure reverse proxy addresses so the forwarded client IP is used.
Content Security Policy: canvas apps default to frame-ancestors 'self' https://*.powerapps.com; enable it in a dev or test environment first, use report-only mode with a reporting endpoint in production, then enforce.

Phased rollout

Inventory: run ScubaGear and the CoE Starter Kit or admin center inventory to list environments, admins, application users, connections and cross-tenant connections.
Admin roles: remove legacy System Administrator assignments, move tenant admin roles into PIM, restrict environment and Power Pages creation.
Default environment: rename it, apply a strict data policy, enable managed environment features and sharing limits.
Logging: start Dataverse auditing, access logging and read logging in production; set retention; forward Purview to the SIEM.
Network and session: IP firewall and CSP in audit or report mode for two to four weeks, then enforce; enable cookie binding.
Tenant isolation: review cross-tenant connections from the inventory, build the allowlist, then turn isolation on.
Integrations: give each application user its own app registration and role, migrate secrets to certificates or managed identity.

Rollback: data policies, tenant isolation and IP firewall can each be switched back in the admin center, but data policy changes propagate with the same latency as the original change, and suspended flows must be reactivated by their owners.

Small and large organisations

A small tenant with one Dynamics 365 environment can get most of the value from four actions: restrict environment creation, a default environment data policy, PIM on admin roles and Dataverse auditing in production. Large tenants also need environment groups with rules, tiered data policies, a named platform security owner and SIEM detections.

Common misconfigurations

Integrations running as System Administrator: vendor setup guides often request it, and the application user then has every table, audit settings and customisation rights.
Client secrets that never expire: secrets created during a migration project years ago still authenticate integration app users; nobody owns the app registration. Forgotten applications with live credentials are a recurring breach path: in the Microsoft Midnight Blizzard Breach an OAuth application in a neglected test tenant led to production mailboxes.
Default environment left open: no data policy, sharing unrestricted and production data reached through personal connections, which is exactly what SCuBA 2.1v1 targets.
Auditing assumed to be on: admin activity appears in Purview, so teams assume data access is logged too; Dataverse auditing, access and read logs are still off.
IP firewall left in audit-only mode: the setting is on by default when the firewall is first configured and is easy to forget, so nothing is ever blocked.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Admin roles, PIM, security roles	AC-2, AC-6, AC-6(5)	PR.AA-05	5, 6	A.5.15, A.8.2
Application users and credentials	IA-5, AC-2	PR.AA-01	5, 6	A.5.17, A.8.5
Data policies, tenant isolation, IP firewall	SC-7, AC-3, CM-7	PR.PS-01	3, 4	A.8.20, A.8.22
SCuBA baseline settings	CM-6	PR.PS-01	4	A.8.9
Auditing and monitoring	AU-2, AU-6, AU-12	PR.PS-04, DE.CM-03	8	A.8.15, A.8.16

Detection and measurement

Standing privileged access: number of permanent System Administrator assignments in production environments (target: break-glass only).
Baseline conformance: percentage of SCuBA Power Platform policies passing in ScubaGear, tracked monthly.
Integration credential hygiene: share of application users backed by certificates or managed identity, and the age of the oldest client secret.
Audit coverage: percentage of production environments with Dataverse auditing and read logging on.
Data policy coverage: environments without a data policy (SCuBA 2.2v1) and number of active data policy exceptions.

Practitioner checklist

Run ScubaGear against the Power Platform baseline and record every failed policy with an owner.
Restrict production, sandbox, trial and Power Pages creation to administrators.
Put Global, Power Platform and Dynamics 365 administrator roles in PIM and remove legacy System Administrator assignments.
Apply a strict data policy to the default environment and at least one policy to every other environment.
Bind each production environment to an Entra security group and enable managed environment features.
Give every integration its own app registration, application user and custom security role; replace client secrets with certificates or managed identity.
Start Dataverse auditing, access and read logging in production, set retention and forward Purview records to the SIEM.
Test the IP firewall and CSP in audit or report mode, then enforce them.
Review cross-tenant connections, build the allowlist and enable tenant isolation.

Microsoft Dynamics 365 and Power Platform Security Guide: Dataverse Roles, Connectors and Baselines