Dynamics 365 Security Audit Checklist: 12 Points IT Managers Need

Your Dynamics 365 implementation went live. The consultants packed up, the project closure email was sent, and leadership declared success. But here is the uncomfortable question no one is asking six months later: is your D365 environment actually secure?

For IT Managers responsible for Microsoft cloud tenants, the post-implementation phase is where the real security work begins — not ends. Misconfigurations compound quietly. Shadow environments multiply. User permissions drift far beyond their original intent. And legacy integrations that were once "temporary" solutions become permanent liabilities.

This guide gives you a practical, cloud-focused Dynamics 365 security audit checklist — 12 actionable checkpoints you can run quarterly to proactively identify and remediate security exposure before it becomes a breach headline. No fluff, no upsell toward on-premise migration. Just the real work that keeps modern D365 tenants protected.

Why Most Dynamics 365 Security Reviews Fall Short

The majority of post-go-live security reviews focus narrowly on network perimeter controls or basic user password policies. That approach misses the three most dangerous threat surfaces specific to cloud-based Dynamics 365 deployments:

• Environment sprawl: Unmanaged sandbox, development, and trial environments that hold production-grade data with minimal governance.
• Role-based access control (RBAC) drift: Security roles that were cloned and customized during implementation but never reviewed — granting far more privilege than any user actually needs.
• Legacy integration vulnerabilities: Older API connections and service accounts still using basic authentication, shared credentials, or deprecated endpoints.

Add to this the explosive growth of Power Platform adoption within D365 tenants, and you have a threat landscape that changes faster than most IT teams can track. Let us work through each dimension systematically.

The 12-Point Dynamics 365 Security Audit Checklist

Section 1: Identity and Access Foundation

✅ Checkpoint 1 — Microsoft Entra ID Integration Health

Every Dynamics 365 user should authenticate exclusively through Microsoft Entra ID (formerly Azure Active Directory). Verify that no legacy local accounts or non-federated identities exist within your D365 environment. Pull the full user list from the Dynamics 365 admin center and cross-reference it against your Entra ID tenant.

What to look for: disabled Entra accounts that still show active in D365, service accounts without Entra backing, and guest or external user accounts that have accumulated privileges over time.

✅ Checkpoint 2 — Conditional Access Policy Coverage

Conditional Access Policies (CAP) in Microsoft Entra ID are your primary enforcement layer for contextual authentication. Audit whether your policies specifically target Dynamics 365 as a cloud app assignment. Common gaps include:

• No MFA enforcement for D365 access from unmanaged devices
• Missing location-based restrictions for high-privilege admin roles
• CAPs that exclude break-glass accounts without compensating monitoring controls
• No sign-in risk policies tied to Entra ID Protection signals

Navigate to Entra ID > Security > Conditional Access and filter policies by the Dynamics 365 app assignment to validate coverage comprehensively.

✅ Checkpoint 3 — Privileged Identity Management (PIM) for D365 Admin Roles

If your Dynamics 365 System Administrator role assignments are permanent rather than time-bound, you have standing privilege risk. Microsoft Entra Privileged Identity Management (PIM) enables just-in-time activation for high-privilege roles, requiring justification and approval before elevation.

Audit action: confirm that the Dynamics 365 Administrator, Power Platform Administrator, and Global Administrator roles are all PIM-eligible rather than permanently assigned. Review the PIM audit log for any role activations that occurred outside business hours or without documented justification.

✅ Checkpoint 4 — Security Role Least-Privilege Review

Inside Dynamics 365 itself, security roles are the primary access control mechanism. Over time, roles accumulate privilege through project customizations, workaround fixes, and cloned role templates. Run the following review:

• Export all custom security roles and compare privilege levels against the principle of least privilege
• Identify users assigned to multiple roles where combined privileges exceed their job function
• Check for any users still assigned the out-of-box System Administrator role who do not require full system access
• Review field-level security profiles for sensitive entities like pricing, compensation, or contract data

// Power Shell snippet to export D365 security role assignments
// using Microsoft.Xrm.Data.PowerShell module
Get-CrmRecords -conn $conn -EntityLogicalName systemuserroles 
  -Fields roleid,systemuserid 
  -AllRows | Export-Csv -Path "./role_assignments_audit.csv"

Section 2: Environment and Tenant Governance

✅ Checkpoint 5 — Environment Tiering and Data Classification

A healthy Dynamics 365 tenant operates across clearly defined environment tiers: Production, UAT, Development, and Sandbox. The security risk emerges when production data is copied into lower environments without data masking, or when developers have direct write access to production systems.

Verify that your Power Platform Admin Center shows a clear environment inventory with defined data residency settings and that environment-level DLP policies match the sensitivity of the data each environment holds. Production environments should have the most restrictive connector policies; developer sandboxes can have more permissive settings, but should never contain real customer or financial data.

✅ Checkpoint 6 — Tenant Isolation and Business Unit Structure

For organizations with multiple business units or subsidiaries within a single D365 tenant, improper Business Unit hierarchy configuration can expose records across organizational boundaries. Audit that:

• Business Unit ownership is correctly mapped to your organizational structure
• Sharing rules and Access Teams have not been used as workarounds that break intended data isolation
• The root Business Unit does not hold active users who should be scoped to child units

Section 3: Integration and API Security

✅ Checkpoint 7 — App Registration and Service Principal Audit

Every integration connecting to Dynamics 365 via the Web API should authenticate through a dedicated Entra ID App Registration with a scoped service principal — not through a named user account or shared credentials. Pull your app registration list from Entra ID and verify:

• No app registrations are using client secrets with expiry dates that have already passed or are overdue for rotation
• All app registrations have documented owners and business justification
• Applications use certificate-based authentication rather than shared secrets where possible
• Permissions granted are application-scoped and minimal — not delegated user permissions with broad access

✅ Checkpoint 8 — Legacy Integration Protocol Review

If your D365 implementation inherited integrations from an older CRM or ERP system, there is a high probability that some connections still use basic authentication, SOAP endpoints, or deprecated Organization Service patterns that Microsoft has been actively retiring. Audit all active integrations against current Dynamics 365 Web API standards and flag any that rely on authentication methods Microsoft no longer recommends for modern cloud deployments.

Section 4: Power Platform Security Controls

✅ Checkpoint 9 — Data Loss Prevention (DLP) Policy Coverage

Power Platform DLP policies control which connectors can work together within Power Apps and Power Automate. Without deliberate DLP governance, a single overprivileged cloud flow can exfiltrate CRM data to an unsanctioned external service. Audit your DLP policies for:

• A tenant-level DLP policy that applies to all environments as a baseline
• Clear classification of connectors into Business, Non-Business, and Blocked categories
• HTTP connectors classified appropriately — these are a frequent data exfiltration vector
• Custom connectors reviewed and governed, not automatically trusted

✅ Checkpoint 10 — Cloud Flow Ownership and Sharing Audit

Power Automate cloud flows that connect to Dynamics 365 often run under the flow creator's identity, meaning when that employee leaves, the flow breaks — or worse, continues to run under a deprovisioned account that was never properly offboarded. Run a flow ownership audit quarterly:

• Identify all flows using the Dataverse connector or Dynamics 365 triggers
• Flag flows owned by former employees or generic accounts
• Review flows shared with entire security groups or "Everyone" — these represent uncontrolled access surface
• Migrate business-critical flows to solution-aware, service principal-owned flows managed through ALM pipelines

✅ Checkpoint 11 — Unmanaged Environment Remediation

Microsoft's default Power Platform tenant settings historically allowed any licensed user to create their own environments. This creates a shadow IT problem at scale. In the Power Platform Admin Center, audit the full environment list and identify any environments that were:

• Created by individual users without IT approval
• Still in active use but with no assigned security group for access control
• Trial environments that contain real business data

Restrict environment creation permissions to designated administrators through the Power Platform tenant settings if this has not already been done.

Section 5: Monitoring and Incident Readiness

✅ Checkpoint 12 — Unified Audit Log and SIEM Integration

Security without visibility is security theater. Confirm that your Dynamics 365 tenant has Microsoft Purview Audit enabled and that audit logs are being retained for a period appropriate to your regulatory obligations. For organizations using Microsoft Sentinel or a third-party SIEM, validate that Dynamics 365 and Power Platform audit events are flowing into your security operations pipeline with alerting rules for:

• Bulk record exports or mass data deletions
• System Administrator role assignments outside change management windows
• Failed login spikes or impossible travel sign-in patterns
• New app registrations with Dynamics 365 permissions

How to Run This Audit Quarterly

Security hygiene degrades between reviews. We recommend structuring this 12-point checklist as a quarterly IT governance ritual rather than an annual compliance checkbox. Assign ownership of each section to a specific team member, document findings in a risk register, and track remediation progress against a defined SLA — critical findings within 14 days, medium findings within 60 days.

For organizations without a dedicated Dynamics 365 security resource, partnering with a Microsoft Solutions Partner for a structured D365 Security Health Check can compress months of internal review into a focused engagement with immediate remediation guidance.

Final Thoughts: Security Is a Posture, Not a Project

The organizations that get breached through their Dynamics 365 environment are rarely victims of sophisticated zero-day exploits. They are victims of misconfigured security roles that were never reviewed, integration service accounts that were never rotated, and Power Automate flows that were created by a former employee and forgotten. These are all preventable with disciplined, recurring governance.

Use this Dynamics 365 security audit checklist as your starting point. Run it this quarter. Fix what you find. Then run it again. The investment in quarterly review is orders of magnitude smaller than the cost of a data breach, a compliance violation, or a customer trust failure.

At CRMONCE, we work with IT Managers and CRM teams across India and globally to implement and harden Dynamics 365 environments that are built to last. If you would like expert eyes on your current security posture or need help implementing any of these controls, reach out to our team for a no-obligation consultation.

This article was researched and written by the CRMONCE technical team, drawing on Microsoft's official Power Platform security documentation, Microsoft Entra Conditional Access guidance, and real-world implementation experience across enterprise Dynamics 365 deployments.