Security

Securing your Dynamics 365 environment

March 12, 2025
Sabhat Qureshi
11 min read

Why security matters in Dynamics 365

Dynamics 365 environments contain sensitive customer data, financial records, intellectual property, and business-critical workflows. A security breach can result in regulatory fines, reputation damage, operational disruption, and loss of customer trust. Beyond compliance requirements like GDPR, HIPAA, or SOX, robust security is a business imperative for maintaining operational resilience and competitive advantage.

Microsoft provides enterprise-grade security controls built into Dynamics 365 and Power Platform, but configuration is your responsibility. Defaults are designed for ease of use, not maximum security. Organizations must intentionally implement defense-in-depth strategies aligned with their risk profile and compliance obligations. Power Platform security overview.

Layered security model

Dynamics 365 implements a multi-layered security architecture where each layer provides independent controls. Understanding this model is crucial for implementing least-privilege access and preventing unauthorized data exposure. security architecture.

Layer 1: Environment access (Microsoft Entra ID)

First defense layer controls who can authenticate to your organization's tenant. This is managed through Microsoft Entra ID (formerly Azure Active Directory).

  • Conditional Access: Enforce policies based on user, location, device, and risk level
  • Multi-factor authentication: Require additional verification beyond passwords
  • Identity Protection: Detect and respond to identity-based risks and anomalies
  • Privileged Identity Management: Just-in-time admin access with approval workflows
  • External identities: Control B2B collaboration with partner organizations

💡 Best practice:

Require MFA for all users accessing Dynamics 365, especially administrators. Use phishing-resistant methods like Windows Hello, FIDO2 security keys, or Microsoft Authenticator push notifications instead of SMS codes.

Layer 2: Environment assignment (Power Platform admin)

After Microsoft Entra ID authentication, users must be assigned to specific Dynamics 365 environments. This is managed through the Power Platform admin center and determines which environments users can access.

  • Environment security groups: Limit environment access to specific Microsoft Entra ID groups
  • Environment types: Use dedicated environments for development, testing, and production
  • Just-in-time access: Grant temporary access for specific tasks instead of permanent assignments
  • Access reviews: Regularly audit environment membership and remove stale accounts

Layer 3: Security roles (Dataverse)

Security roles define what users can do within an environment—which entities they can access and what operations (Create, Read, Write, Delete, Append, Assign, Share) they can perform. security roles and privileges.

  • Privilege depth: User (own), business unit, parent-child, organization (all records)
  • Custom security roles: Create role definitions aligned with job functions
  • Copy and customize: Start from predefined roles but customize to least-privilege
  • Multiple roles: Users inherit cumulative permissions from all assigned roles
  • Field security: Control read/update access to sensitive fields (SSN, salary, etc.)

Layer 4: Record-level security

Even with security roles, you can further restrict access to specific records using ownership, business units, teams, and sharing.

  • Owner-based security: Users see only records they own (unless role grants broader access)
  • Business unit hierarchy: Parent BUs can access child BU records based on role privileges
  • Teams: Group users for shared record access without individual sharing
  • Sharing: Grant one-time access to specific records for collaboration
  • Access Teams: Automatically share records based on team templates

Layer 5: Field-level security

Protect sensitive fields from unauthorized viewing or editing, even when users have access to the record. This is critical for PII, financial data, or confidential information.

  • Field security profiles: Define which fields users can read or update
  • Encryption: Fields marked secure are encrypted at rest (for compliance)
  • Audit trails: Track who accessed or modified secured fields
  • Performance impact: Field security adds query overhead—use judiciously

Data encryption and protection

Encryption at rest

All data in Dynamics 365 is encrypted at rest using SQL Transparent Data Encryption (TDE) with AES-256. Microsoft manages encryption keys by default, but organizations can bring their own keys (BYOK) for additional control. encryption key management.

  • Microsoft-managed keys: Default option, fully automated key rotation and management
  • Customer-managed keys: Store keys in your Azure Key Vault for full lifecycle control
  • Key rotation: Automated rotation schedules to limit key exposure window
  • Compliance: Required for certain regulatory frameworks (HIPAA, ITAR)

Encryption in transit

All communications between clients and Dynamics 365 services use TLS 1.2 or higher. This protects data from interception during transmission over networks.

  • Disable legacy protocols (TLS 1.0, 1.1) through tenant settings
  • Enforce HTTPS for all custom integrations and APIs
  • Use certificate pinning for mobile apps
  • Monitor for protocol downgrade attacks

Data loss prevention (DLP)

DLP policies prevent sensitive data from leaving your organization through Power Platform connectors, emails, or exports. DLP policy configuration.

  • Connector classification: Label connectors as business, non-business, or blocked
  • Cross-tenant restrictions: Block data sharing with external tenants
  • Endpoint DLP: Control screenshots, copy/paste in Power Apps mobile
  • Pattern matching: Detect and block sensitive data like SSNs or credit cards
  • Policy scope: Apply policies to specific environments or tenant-wide

⚠️ Common mistake:

Don't wait until after deployment to implement DLP policies. Implement them early in development to prevent app architectures that violate security requirements. Retrofitting DLP to existing apps often requires significant rework.

Audit logging and monitoring

Comprehensive logging provides visibility into user activities, security events, and system changes. This is essential for compliance, threat detection, and incident response. auditing for Dataverse.

Dataverse audit logging

  • Entity-level auditing: Enable auditing on specific entities (account, contact, etc.)
  • Field-level auditing: Track changes to specific fields for compliance
  • User access auditing: Log all user read operations for sensitive entities
  • Retention: Audit logs retained for 30-365 days depending on license
  • Audit reports: Built-in views for change history and user activity
  • Export: Export audit logs to Azure Data Lake or Log Analytics for long-term retention

Microsoft 365 unified audit log

Power Platform activities are logged to the unified audit log, providing centralized visibility across Microsoft 365 services.

  • Admin activities: Environment creation, DLP policy changes, role assignments
  • User activities: App launches, data exports, record access
  • Retention: 90 days standard (up to 10 years with E5 license)
  • Search and alerts: Search logs and create alerts for suspicious activities
  • SIEM integration: Stream logs to Microsoft Sentinel or third-party SIEM

Activity logging and analytics

  • Power Platform analytics: Built-in dashboards for usage trends
  • Application Insights: Detailed telemetry for custom apps and integrations
  • Custom logging: Implement plugin logging for business logic events
  • Alerting: Configure alerts for anomalous behavior (login spikes, mass exports)

Securing integrations and APIs

Service principal authentication

Never use user credentials for application integrations. Service principals (Microsoft Entra ID app registrations) provide identity for applications without exposing user accounts. server-to-server authentication.

  • Application users: Non-interactive users representing applications
  • Certificate-based auth: Use certificates instead of client secrets when possible
  • Secret rotation: Rotate client secrets every 90 days minimum
  • Least privilege: Grant only necessary security roles to service principals
  • Monitoring: Track service principal activities separately from user actions

API security best practices

  • OAuth 2.0: Require OAuth tokens for all API access
  • Scopes: Request minimal OAuth scopes needed for operations
  • Rate limiting: Implement throttling to prevent abuse (built into Dataverse)
  • IP restrictions: Limit API access to known IP ranges when possible
  • Request validation: Validate all inputs to prevent injection attacks
  • CORS policies: Restrict cross-origin requests to trusted domains

Webhook and plugin security

  • HTTPS only: Webhooks must use HTTPS endpoints with valid certificates
  • Authentication headers: Include shared secrets or JWT tokens in webhook calls
  • Sandbox isolation: Plugins run in sandboxed environment (required for online)
  • Code reviews: Security review all plugin code before deployment
  • Input sanitization: Never trust user input—validate and sanitize

Compliance and governance

Regulatory compliance

Dynamics 365 maintains compliance certifications for major regulatory frameworks, but organizations must configure environments properly to meet specific requirements. compliance and data privacy.

  • GDPR: Data subject rights (access, deletion, portability), consent management
  • HIPAA: Business associate agreement (BAA), encryption, audit logging
  • SOC 2: Access controls, change management, incident response procedures
  • ISO 27001: Information security management system requirements
  • FedRAMP: Government cloud requirements and controls

Data residency and sovereignty

  • Geography selection: Choose environment region based on data residency requirements
  • Multi-geo: Store data in multiple geographies for global organizations
  • Data transfer: Understand cross-border data transfer implications
  • Compliance boundaries: Use Microsoft Compliance Manager to assess gaps

Center of Excellence (CoE)

Establish governance framework for Power Platform to balance innovation with security and compliance. CoE Starter Kit.

  • Environment strategy: Define when and how to provision environments
  • Naming conventions: Standardized naming for resources and solutions
  • Approval workflows: Governance gates for production deployments
  • Maker training: Security awareness for citizen developers
  • Resource monitoring: Identify and remediate orphaned or non-compliant resources

Threat protection and incident response

Microsoft Defender for Cloud Apps

Cloud App Security Broker (CASB) providing threat protection, anomaly detection, and policy enforcement for Power Platform and Dynamics 365.

  • Anomaly detection: Identify unusual activity patterns (impossible travel, mass downloads)
  • Session policies: Real-time monitoring and blocking of risky sessions
  • App discovery: Detect shadow IT and unauthorized app usage
  • Conditional Access integration: Enforce adaptive access controls

Incident response planning

  • Playbooks: Document response procedures for security incidents
  • Roles and responsibilities: Define who does what during incidents
  • Communication plans: Templates for user notification and stakeholder updates
  • Backup and recovery: Regular environment backups, tested restore procedures
  • Forensics: Preserve audit logs and artifacts for investigation
  • Lessons learned: Post-incident reviews to improve security posture

Security awareness training

  • Phishing simulations: Test user awareness with simulated attacks
  • Security champions: Identify and train security advocates in each team
  • Policy communication: Regularly communicate security policies and updates
  • Metrics: Track training completion and security incident trends

Security hardening checklist

Identity and access

  • ☐ Enforce MFA for all users, especially admins
  • ☐ Implement Conditional Access policies
  • ☐ Use Privileged Identity Management for admin roles
  • ☐ Regularly review and remove inactive user accounts
  • ☐ Restrict environment access with security groups

Data protection

  • ☐ Enable field-level security for sensitive data
  • ☐ Configure DLP policies to prevent data leakage
  • ☐ Implement customer-managed encryption keys if required
  • ☐ Classify data and apply sensitivity labels
  • ☐ Disable data export for unauthorized users

Monitoring and compliance

  • ☐ Enable comprehensive audit logging
  • ☐ Configure alerts for suspicious activities
  • ☐ Export audit logs to long-term storage
  • ☐ Review audit logs monthly
  • ☐ Document compliance controls for auditors

Integration security

  • ☐ Use service principals for app integrations
  • ☐ Rotate credentials every 90 days
  • ☐ Restrict API access to known IP ranges
  • ☐ Review plugin code for security vulnerabilities
  • ☐ Validate all external inputs

Conclusion

Securing Dynamics 365 environments requires continuous attention to identity management, data protection, access controls, audit logging, and threat detection. Security is not a one-time implementation but an ongoing process of assessment, hardening, monitoring, and improvement.

Start with fundamentals: enforce MFA, implement least-privilege access through security roles, enable comprehensive auditing, and establish DLP policies. Then layer on advanced controls like field-level security, customer-managed keys, and threat detection based on your risk profile.

Most importantly, foster a security-conscious culture where developers, admins, and users understand their role in protecting sensitive data. Technology controls are necessary but insufficient—people and processes are equally critical to maintaining robust security posture in Dynamics 365 environments.

Need help with your Dynamics 365 project?

I can help you apply these practices in your own Dynamics 365 environment.