What's New - CIS Microsoft Dynamics 365 Power Platform Benchmark v1.0.1

CIS released version 1.0.1 of the Microsoft Dynamics 365 Power Platform Benchmark on 7th October 2026, almost four years after v1.0.0. There are no new controls, none removed and no changes of profile level, and every audit and remediation step is the same. So why write about it? Because what changed is how you can evidence those settings. Every recommendation now maps to NIST SP 800-53 Rev. 5 and NIST CSF 2.0. It's also comparing the controls against the M365 Foundations Benchmark v7.0.0.

What is the benchmark?

CIS benchmarks are consensus-driven hardening guidelines. The Microsoft Dynamics 365 Power Platform Benchmark covers Dataverse environments, Dynamics 365 and the Power Platform admin centre. Each control is rated Level 1 (baseline) or Level 2 (stricter, may affect functionality).

It's a small benchmark with 16 recommendations across four sections (Accounts and Authentication, Permissions, Data Management, and Logging and Auditing).

What's changed in v1.0.1?

The change log has one line: "Updated CIS Controls mappings and added NIST 800-53r5 and CSF 2.0". I compared the text of every control in both versions to confirm that. Apart from the mappings, the only changes are formatting.

Just as notable is what wasn't updated. The text still says Azure AD rather than Entra ID, tenant isolation is still labelled (preview), app creation alerts still point to compliance.microsoft.com, and the MFA description still lists SMS as an option. Expect to translate several audit steps into today's admin centres.

NIST SP 800-53 Rev. 5 and CSF 2.0 mappings

To decode the two frameworks:

• NIST SP 800-53 Rev. 5 is a detailed catalogue of security controls, organised into families such as AC (Access Control), IA (Identification and Authentication) and AU (Audit and Accountability). It's the "what exactly should be in place" layer.
• NIST CSF 2.0 is the higher-level framework many organisations use to report security maturity to leadership. It has six functions (Govern, Identify, Protect, Detect, Respond and Recover).

What the mappings tell you

• It's an access control benchmark. 11 of the 16 recommendations map to the NIST AC family, and 3 of those are AC-4 (controlling where information is allowed to flow). That fits Power Platform. Its biggest risk isn't someone breaking in, it's who can reach data and where connectors let that data go.
• Almost everything sits under Protect. 15 recommendations map to the CSF Protect function. The other one, app creation alerts (4.3), maps to Detect. Nothing maps to Govern, Identify, Respond or Recover. If you're producing a CSF maturity report, implementing the whole benchmark will raise your Protect score and do very little for the other 5 functions.

Same controls as the M365 Foundations Benchmark v7.0.0

Three Power Platform recommendations do the same job as controls in the M365 benchmark. If you've implemented M365 v7.0.0, you've probably met these already. In each case, the M365 version is better.

1.3 Administrative accounts vs M365 1.1.1 and 1.1.4

The Power Platform title says "cloud-only", but the audit step only checks that each admin has a separate account. It never checks whether the account is synced from on-premises Active Directory, which M365 1.1.1 does. Power Platform also says "unassigned", meaning no licence at all. This is covered by the M365 control 1.1.4 which is more practical and keeps the accounts in scope for Conditional Access, PIM and Identity Protection.

1.4 MFA for all users vs M365 5.2.2.2

Level 2 in Power Platform, Level 1 in M365. The Power Platform steps go through the Microsoft 365 admin centre to Azure Active Directory and then Enterprise applications, and still list SMS as an MFA option. M365 5.2.2.2 uses the Entra admin centre and applies to all resources, so it automatically covers Dataverse. M365 5.2.3.5 goes further and disables SMS and voice call.

2.4 Location restrictions vs M365 5.2.2.14 and 5.2.2.15

Both are Level 2. M365 splits this into two steps, define trusted named locations, then block the places you don't operate in. Both can be checked automatically and apply to every resource in the tenant. The Power Platform control only targets the Dataverse and Dynamics 365 Finance and Operations apps. A tenant-wide geographic block already covers Dataverse. The Power Platform approach is only useful as an extra layer, when Dynamics 365 needs a tighter location rule than the rest of the tenant.

Top 3 controls to revisit

None of these are new, but this release is a good excuse to check them again. None of them have an equivalent in the M365 benchmark.

1. DLP policies restrict connector usage (3.4, L1)

By default, no data policies exist. Any maker can combine a business connector, such as SharePoint or Dataverse, with a consumer one in the same flow. It's the most common way data leaves a tenant through Power Platform, and Purview DLP doesn't stop it. Purview covers Exchange, SharePoint, OneDrive and Teams, not Power Platform connectors.

Remediation: in the Power Platform admin centre, go to Policies > Data policies. Sort connectors into Business, Non-business and Blocked, and scope the policy to every environment it applies to. To audit with PowerShell:

# Requires Microsoft.PowerApps.Administration.PowerShell
Add-PowerAppsAccount
Get-AdminDlpPolicy | Select-Object DisplayName, PolicyName

Watch out: start with a tenant-wide policy that covers the default environment, then add stricter policies for specific environments. Blocking a connector that existing flows already use will stop those flows working, so check what's in use before you enforce anything.

2. Cross-tenant isolation (2.5, L1)

Tenant isolation is off by default. Without it, a user can connect an app or flow to another tenant's Entra-secured resources, inbound or outbound. An attacker who has compromised an account can use the same route to keep access.

Remediation: In the Power Platform admin centre, turn on tenant isolation and add any partner tenants that need access to the allowlist. To audit with PowerShell:

$policy = Get-PowerAppTenantIsolationPolicy -TenantId $tenantId # Supply your tenant ID directly
$policy.properties.isDisabled          # False = isolation is on
$policy.properties.allowedTenants

Watch out: Review the allowlist before you switch isolation on, or partner connections will break.

3. Environment activity logging (4.2, L1)

Dataverse auditing is off by default and set per environment, so you can't investigate data access in Dynamics 365 or Power Apps even when Microsoft 365 auditing is working.

Remediation: in each environment, go to Settings > Audit and logs > Audit settings. Turn on Start Auditing, Log access and Read logs, and set a retention period that matches your policy. Make sure Microsoft 365 audit log search is enabled (M365 3.1.1), because that's where these logs end up.

Watch out: audit data uses Dataverse log storage, so plan retention against your capacity before turning it on everywhere. New environments don't inherit these settings, so add them to your environment provisioning process.

In summary

v1.0.1 doesn't change anything in your tenant, but it changes how you can talk about it. With NIST 800-53 and CSF 2.0 mappings on every recommendation, this small benchmark can go straight into a risk register or an audit pack. Where the benchmark has the same control as the M365 version, follow the M365 version, then spend your effort on the controls only this benchmark covers.

Resources

• CIS Microsoft Dynamics 365 Power Platform Benchmark
• CIS Microsoft 365 Benchmark
• NIST SP 800-53 Rev. 5
• NIST Cybersecurity Framework 2.0