We are seeing new AI-assisted scenarios across Dynamics 365 apps and Power Platform, from natural language queries to automated decision-making. As a direct result, Microsoft Dataverse, the underlying data platform for Dynamics 365 and Power Platform, is seeing rapid growth in metadata, solution artifacts, and contextual data.

This shift is driving a new class of workloads that require significantly more storage capacity than traditional systems. As a direct result, we received customer feedback that over time the base entitlement for business apps was not sufficient to get started, which was a hinderance to innovation. Starting in December, we are implementing two updates to address customer concerns:

1. Increasing baseline Dataverse capacity across business applications (Dynamics 365 and Power Platform). This includes an increase to tenant included capacity (specifics can be found on page 43 of the December Issue of the Dynamics 365 Licensing Guide under “Default subscription capacity included per tenant”). These changes ensure customers have the headroom to scale new scenarios without hitting limits. Whether you’re building Copilot experiences, orchestrating workflows, or enabling agentic apps, Dataverse now provides flexibility and capacity to support your innovation.
2. Simplifying the overall storage entitlement across Dataverse and Dynamics 365 ERP applications to make capacity planning easier. This flexibility creates the foundation needed for agentic ERP at scale.

Impact on your Dynamics 365 ERP data storage licensing

For ERP customers using Dynamics 365 Finance and Operations apps, the key update is that default storage capacity is increasing and will now be reported as a shared entitlement across both the ERP operational store and Dataverse. This change gives customers greater flexibility to allocate storage where it’s needed most. Instead of managing separate pools, customers can now apply their storage entitlements seamlessly as ERP workloads grow.

• Before: Operations and Dataverse capacities were capped separately for the same F&O product.
• After: Storage capacity functions as one combined entitlement that can be used for either Dataverse or ERP (see “entitled capacity” in diagram below)

This matters most for Dynamics 365 Finance Premium and Supply Chain Management Premium customers, where the combined entitlement is materially higher than either footprint alone. The increase reflects the way ERP usage is evolving — with more execution context traveling alongside the transaction. In practical terms, this means:

• If AI-assisted approvals generate more annotations or reasoning context, that growth can be absorbed without Dataverse becoming a limiting factor.
• If supplier or operational workflows accumulate larger supporting files, attachments now draw from the full entitlement rather than a smaller segment.
• If orchestration or exception resolution produces more state and process history, it scales as part of ERP rather than hitting a cap early.

Under the previous entitlement model, Dataverse could fill more quickly than the ERP store even if total tenant capacity remained. Under the new model, capacity follows usage — not a system boundary.

Why this accelerates system-of-action ERP

When ERP is purely a system of record, storing the final outcome is enough. But when ERP becomes a system of action, it must also retain how and why an action was taken — not just what was recorded.

The contextual data that enables agentic execution can no longer sit at the edge of the system. It becomes part of the operational story. This update aligns the storage model with that reality, giving organizations the flexibility to modernize without re-engineering their data footprint or rethinking where contextual data is allowed to live.

Capacity now reflects the purpose of ERP in the AI era — not only documenting the state of the business, but helping drive what happens next.

Looking ahead: modernizing storage entitlements

By modernizing storage entitlements now, we are ensuring customers have the runway to support that growth — not after they hit constraints, but ahead of it. This removes friction from ERP transformation and positions organizations to move confidently toward AI-enabled operating models.

The latest Dynamics 365 Licensing Guide reflects the changes and no customer action is required. The updated entitlements will be reflected automatically in Power Platform admin center as the new model takes effect. As these capabilities roll out, customers will gain additional flexibility to grow agentic ERP workloads with confidence, knowing their storage model now matches the future of ERP. To learn more, please review the following resources:

• Review the updated licensing guide: Dynamics 365 Licensing Guide
• Read docs: Dataverse capacity-based storage overview – Power Platform | Microsoft Learn
• Read docs: Finance and operations storage capacity – Power Platform | Microsoft Learn

The post Flexible Dataverse capacity for apps and agents appeared first on Microsoft Power Platform Blog.

Long-Term Retention (LTR) is one of data management tools that helps enterprises effectively manage their growing data estates while ensuring compliance with regulatory requirements. By archiving less frequently accessed data, LTR optimizes Dataverse storage usage and reduces costs. 

Long-Term Retention (LTR) in Dataverse helps organizations retain data that’s no longer actively used but still required for regulatory or business purposes. Whether it’s for archiving operational records or meeting audit requirements like 5-year retention mandates, LTR ensures data remains secure, immutable, and compliant—at a fraction of the storage cost. 

But LTR isn’t just about storage—it’s also built for analytics. Retained data is treated as a first-class citizen in Dataverse, seamlessly integrated into the real-time data warehouse. With Microsoft Fabric’s OneLake Shortcuts, you can analyze both live and archived data without copying or duplicating it. For customers preferring their own data lake, Synapse Link offers a flexible alternative for reporting and analytics on business and retained data. 

This blog will focus on how implementing LTR can significantly reduce storage costs for enterprises, providing practical insights and strategies for leveraging LTR to achieve cost efficiency. We will also discuss how you can get deep insights from the retained data. 

What is LTR and how can you enable  

Long-Term Data Retention (LTR) streamlines your data strategy by automatically moving historical records from Microsoft Dataverse and Dynamics 365 Finance & Operations (F&O) into a managed data lake (MDL). This approach ensures efficient, scalable storage—freeing up space in your transactional databases while keeping retained data accessible for analytics and compliance. 

You can enable the LTR for Dataverse using this article Dataverse long term data retention overview – Power Apps | Microsoft Learn 

To enable LTR for F&O, you can follow this article Archive data in Dynamics 365 finance and operations apps with Dataverse – Finance & Operations | Dynamics 365 | Microsoft Learn 

When LTR is the Right Fit 

Long-Term Retention (LTR) is a powerful tool for managing storage in Dataverse and Dynamics 365 Finance & Operations (F&O), but its value is maximized when applied to the right scenarios. LTR allows organizations to move inactive, compliance-bound, or infrequently accessed data to a cost-optimized, read-only storage tier—freeing up space in the primary database while maintaining access for reporting and audits. 

Here’s when LTR is especially relevant: 

✅ 1. Compliance-Driven Data Retention 

If your organization operates in a regulated industry (e.g., finance, healthcare, public sector), you likely need to retain data for 5–10 years or more. LTR ensures that this data remains immutable and accessible for audits, without bloating your operational database. 

Example: Financial records, customer invoices, and customer contracts that must be retained for legal or regulatory reasons. 

✅ 2. Analytics on Historical Data 

LTR doesn’t mean your data is locked away. Retained data can still be queried for trend analysis, forecasting, and AI workloads—especially when integrated with tools like Azure Synapse Link or OneLake shortcuts. This enables long-term insights without compromising performance. 

Example: Analysing 7 years of sales data to forecast seasonal demand patterns. 

✅ 3. Data Relevancy and Lifecycle Management 

Not all data needs to be live forever. LTR helps you separate high-value, frequently accessed data from historical records that are still important but rarely used. This improves system responsiveness and reduces noise in day-to-day operations. 

Example: Archiving closed cases, completed orders, or inactive customer records. 

⚠️ What LTR Does Not Do 

While LTR reduces your operational storage footprint, it does not reduce the size of your analytics store. If you’re exporting data to Synapse, OneLake, or other analytical platforms, you’ll still need to manage retention and tiering strategies there separately. 

Cost savings with LTR 

One of the most impactful benefits of implementing Long-Term Retention (LTR) in Dynamics 365 is the significant reduction in storage costs. On average, LTR compresses archived data by up to 80% and in some cases up to 90%, which can translate into substantial savings. For instance, archiving 1,000 GB of database data could reduce storage expenses from $80,000 to $10,000—a game-changer for data-heavy organizations. 

Here are a few real-world examples of how customers are reaping the rewards: 

• 🥨 A major American food company leveraged LTR to archive historical data in Finance & Operations (F&O), achieving a 50% reduction in data size and freeing up valuable system resources. 

• 🧥 A global leader in outdoor apparel and equipment adopted LTR as part of a broader data archival strategy. By offloading historical records from core transactional systems, they not only cut storage costs but also improved overall system performance. 

• 🍿 The largest private snack food company in the U.S. reduced their InventTrans table from 1.1 TB to 549 GB using LTR—again, a 50% reduction that directly impacted their bottom line. 

• A leading enterprise in the finance and operations space, they faced mounting challenges with data volume and storage costs. As part of their digital optimization strategy, they implemented Long-Term Retention (LTR) to offload historical data from their Dynamics 365 Finance & Operations (F&O) environment into a managed data lake—achieving a remarkable storage reduction of over 90%. 

Seamless insights with combined data 

With Long-Term Retention (LTR), your historical data is securely stored in a Managed Data Lake—keeping storage costs low. But that doesn’t mean you lose visibility. 

Thanks to OneLake shortcuts and Synapse Link, you can seamlessly analyze both live and retained data together. This means you get a complete picture of your business—past and present—without sacrificing performance or budget. 

Whether you’re running reports, building dashboards, or training models, your insights stay connected, and your costs stay optimized. 

We’ll explore further in this blog, how to unlock seamless insights by combining live and retained data using OneLake shortcuts and Synapse Link. These tools allow you to query both retained and real-time data effortlessly—without compromising on performance or cost efficiency. 

Strategy to use LTR to manage the storage 

LTR integrates seamlessly with Quick find in the Dataverse, Bring Your Own Lake (BYOL) for Synapse Link and OneLake for both Dataverse and Finance & Operations (F&O) scenarios. 

• Quick Find: Instantly search archived data directly within Dataverse—no setup required. 

• OneLake: For integrated analytics using Microsoft Fabric OneLake. 

• Synapse Link: For syncing retained data to your own data lake for custom analytics and storage. 

In this section, we will discuss how each strategy helps manage the storage, cost and meet the compliance requirements. 

Quick find 

Quick Find allows users to search across Dataverse tables using indexed columns. Even when data is archived via LTR, it remains within the Dataverse boundary and is still queryable through Quick Find—provided the relevant columns are indexed and the data is not purged. This means: 

• No need to unarchive: Users can locate, and view retained records directly through the familiar Dataverse UI. 

• No pipeline or duplication required: Unlike analytics scenarios that use OneLake or Synapse Link, Quick Find works natively within Dataverse 

Use OneLake shortcut with LTR for Data Warehousing  

Enterprises adopting new technologies like OneLake shortcut can continue to use Long-Term Retention (LTR) to manage data storage, costs, and compliance by archiving historical data into Managed Lake storage. Archiving data in Managed Lake preserves cost savings for the scenario that involves accessing historical data while allowing enterprises to perform analytics by moving the data out to reporting and analytical databases. 

If your enterprise has already invested in OneLake, you can further optimize your data strategy by leveraging OneLake shortcut. Unlike the full OneLake, which syncs data into OneLake, the Shortcut creates a pointer to your data—allowing Fabric to query it in place without duplicating storage or compromising data security. 

This means you can continue to run analytics on both live and retained data while preserving the cost benefits of Long-Term Retention (LTR). 

📊 In the diagram below, we illustrate how an enterprise can reduce storage costs by up to 80%—for example, compressing a 400GB business data down to less than 32GB using LTR—while still enabling seamless insights without incurring additional costs or compromising data security. 

Since no data is physically moved, it also helps preserve LTR savings by avoiding duplication. 

Without LTR: 

With LTR: 

Synapse link works seamlessly with LTR 

Enterprises that have invested in Bring Your Own Lake (BYOL) with Synapse Link can continue to leverage this setup for their data archival scenarios to manage storage, costs, and compliance. However, note that if the Synapse Link is created after the Long-Term Retention (LTR) process has already occurred, it will not include previously retained data. This approach allows enterprises to utilize LTR with their existing Synapse Link investment. 

If your enterprise is already invested in Synapse Link, there’s an opportunity to take your data strategy even further. By pairing it with Long-Term Retention (LTR), you can maintain seamless access to both live and retained data—without duplicating storage or compromising security. 

📊 In the diagram below, we illustrate how an enterprise can utilize their existing investment in synapse link while using LTR. For example, business data is retained in Managed Data Lake — while still enabling powerful analytics through Synapse Link, without incurring additional costs. This approach ensures your insights stay rich, your data stays secure, and your budget stays intact. 

Without LTR: 

With LTR: 

Summary of Benefits

Throughout this blog, we have explored how Long-Term Retention (LTR) can significantly reduce storage costs for enterprises. By archiving less frequently accessed data, LTR optimizes storage usage, leading to substantial cost savings. Additionally, LTR ensures compliance with regulatory requirements, making it a crucial strategy for effective data management. Whether using Synapse Link or OneLake, LTR provides a seamless and efficient way to manage data storage and compliance needs. 

Call to Action

We encourage you to consider implementing LTR in your organization to take advantage of these benefits. For further assistance or more information on how to get started with LTR, please visit our LTR article. Implementing LTR can help you achieve cost efficiency and compliance, ensuring your data management strategy is both effective and sustainable. 

The post Long-Term Retention (LTR): Cost Effective Strategy for Managing Storage and Compliance   appeared first on Microsoft Power Platform Blog.

Overview

Power Platform Managed Identity utilizes workload identities based on Federated Identity Credentials (FIC). You have the option to provision either a User Assigned Managed Identity (UAMI) or an Application Registration and configure Federated Identity Credentials (FIC). Application Registration enables you to apply Azure policies to Power Platform resources, such as Dataverse plug-ins.

You have two options for provisioning of managed identities:

1. User Assigned Managed Identity (UAMI): You can provision a User Assigned Managed Identity (UAMI) in Azure. Dataverse plug-ins can use this identity to connect to Azure resources that support managed identity. In this case, you cannot enforce Azure policies.
2. Application Registration: By provisioning the application in Microsoft Entra ID, you establish an application context and Identity that can connect to Azure resources supporting managed identity.  This allows you to apply Azure policies to the application, ensuring that Power Platform resources, such as Dataverse plug-ins, adhere to these policies.

You need to configure Federated Identity Credentials (FIC) in both options to enable managed identity.

Supported scenario

Currently, Power Platform Managed Identity supports Dataverse plug-ins. This means that Dataverse plug-ins can connect to Azure resources that support managed identities without the need to manage credentials. By leveraging managed identities, the connection process becomes more secure and streamlined, as it eliminates the risks associated with credential management. This feature ensures that Dataverse plug-ins can access necessary Azure resources seamlessly and securely, enhancing overall efficiency and security.

Today we support Managed Identity for Independent Software Vendor (ISV) plug-ins within the context of their environment. For example, an ISV plug-in installed in the environment, will have access to the resources within the scope of the environment. However, it will not have to access resources within the ISV tenant.

Availability

Power Platform Managed Identity support for Dataverse plug-ins is available in public preview to all our customers in public cloud.

Call to action

• Start by following the step-by-step instructions – Set up Managed Identity support for Dataverse plug-ins
• Learn more about Power Platform Managed Identity
• Share your feedback

The post Announcing public preview of Power Platform Managed Identity support for Dataverse Plug-ins appeared first on Microsoft Power Platform Blog.

Overview

Power Platform Managed Identity utilizes workload identities based on Federated Identity Credentials (FIC). You have the option to provision either a User Assigned Managed Identity (UAMI) or an Application Registration and configure Federated Identity Credentials (FIC). Application Registration enables you to apply Azure policies to Power Platform resources, such as Dataverse plug-ins.

You have two options for provisioning of managed identities:

1. User Assigned Managed Identity (UAMI): You can provision a User Assigned Managed Identity (UAMI) in Azure. Dataverse plug-ins can use this identity to connect to Azure resources that support managed identity. In this case, you cannot enforce Azure policies.
2. Application Registration: By provisioning the application in Microsoft Entra ID, you establish an application context and Identity that can connect to Azure resources supporting managed identity.  This allows you to apply Azure policies to the application, ensuring that Power Platform resources, such as Dataverse plug-ins, adhere to these policies.

You need to configure Federated Identity Credentials (FIC) in both options to enable managed identity.

Supported scenario

Currently, Power Platform Managed Identity supports Dataverse plug-ins. This means that Dataverse plug-ins can connect to Azure resources that support managed identities without the need to manage credentials. By leveraging managed identities, the connection process becomes more secure and streamlined, as it eliminates the risks associated with credential management. This feature ensures that Dataverse plug-ins can access necessary Azure resources seamlessly and securely, enhancing overall efficiency and security.

Today we support Managed Identity for Independent Software Vendor (ISV) plug-ins within the context of their environment. For example, an ISV plug-in installed in the environment, will have access to the resources within the scope of the environment. However, it will not have to access resources within the ISV tenant.

Availability

Power Platform Managed Identity support for Dataverse plug-ins is available in public preview to all our customers in public cloud.

Call to action

• Start by following the step-by-step instructions – Set up Managed Identity support for Dataverse plug-ins
• Learn more about Power Platform Managed Identity
• Share your feedback

The post Announcing public preview of Power Platform Managed Identity support for Dataverse Plug-ins appeared first on Microsoft Power Platform Blog.

We are excited to announce that the virtual network support for Dataverse plug-ins within Microsoft Power Platform is now generally available for all our customers in public cloud! This feature allows you to protect your outbound connections from Power Platform Dataverse plug-ins to resources within your private network. Virtual network support for Power Platform is based on Azure subnet delegation. With Azure subnet delegation, you can delegate your subnets to the Power Platform and configure it to run the services within your delegated subnet. This way, you can securely manage your egress traffic from the Power Platform according to your network policy.

Power Platform Approach to securing outbound connectivity.

Virtual network support for Power Platform is optimized to handle API (Application Programming Interface)-centric workloads, and hence is the recommended approach for outbound connectivity from Power Platform services to resources within your network when using Dataverse plug-ins and Power Platform Connectors. For Power BI and Power Platform Dataflows (PPDF), the recommended approach is to use virtual network data gateway, which is optimized to handle ETL (Extract, Transform, Load) workloads.

Overview of the feature

This feature is particularly useful for customers who have security and compliance requirements to secure their data by protecting outbound traffic from Power Platform.

With virtual network support, you will be able to solve following key problems.

• You don’t have to expose private endpoint protected resources within your VNet to the internet to allow Power Platform services to connect to these protected resources, thereby protecting your data.
• You don’t have to allow-list sets of Power Platform IP’s ranges or service tags to allow Power Platform services to connect to resources within your VNet, thereby protecting the resources from unauthorized access.

Currently, you can use secured private outbound connectivity from Dataverse plug-ins to enhance the security of data integration with external data sources within your secured private network from your Power Apps, Power Automate, and Dynamics 365 apps.

Unlocking Secure Data Integration with Microsoft Copilot Studio in Power Platform

In today’s interconnected world, secure data integration is crucial for organizations. Microsoft Copilot Studio offers robust solutions for fetching and processing data securely. Let’s explore scenario where Copilot Studio demonstrates the network security capability of Power Platform:

Scenario #1: Fetching Customer Data from a Web API Hosted in Azure

Imagine you need to retrieve customer data securely from your Web API hosted in Azure. Copilot Studio seamlessly orchestrates the process:

1. Microsoft Copilot Studio Initiates a Power Automate Flow: Copilot Studio triggers Power Automate flows through a command that include Dataverse unbound plug-in action.
2. Dataverse Plug-in Calls a Web API: The Power Automate flow makes a secure call using Dataverse Plug-in to a private endpoint-protected Web API. This ensures that customer data retrieval remains secure.

Learn more about this scenario through this video, please note the SQL connector VNet support is in preview.

Availability and Licensing

Virtual network support for Dataverse plug-ins is generally available to all our customers in public cloud and licensing information is available in this article Virtual Network support for Power Platform overview – Power Platform | Microsoft Learn
Call to action.

• Enable Virtual Network support for Dataverse plug-ins.
• Learn more about supported services within Power Platform Virtual Network support for Power Platform overview – Power Platform | Microsoft Learn
• Get started – Step by step instructions Set up Virtual Network support for Power Platform – Power Platform | Microsoft Learn
• Watch these demos.
  • Set up virtual network support for Power Platform (youtube.com)
  • Copilot Studio: Secure Data Access via Dataverse Plug-in & SQL Connector​ (youtube.com)
  • Power Apps accessing the SQL database using SQL connector (youtube.com)

The post Next-Level Connectivity Security: Dataverse Plug-ins Embrace Virtual Networks! appeared first on Microsoft Power Platform Blog.

Introduction

Power Platform Approach to securing outbound connectivity

Virtual network support for Power Platform is optimized to handle API (Application Programming Interface)-centric workloads, and hence is the recommended approach for outbound connectivity from Power Platform services to resources within your network when using Dataverse plug ins and Power Platform Connectors. For Power BI and Power Platform Dataflows (PPDF), the recommended approach is to use virtual network data gateway, which is optimized to handle ETL (Extract, Transform, Load) workloads.

Overview of the feature

This feature is particularly useful for customers who have security and compliance requirements to secure their data by protecting outbound traffic from Power Platform.

With virtual network support, you will be able to solve following key problems.

• You don’t have to expose private end protected resources within your VNet to internet to allow Power Platform services to connect to these protected resources, thereby protecting your data.
• You don’t have to allow-list sets of Power Platform IP’s ranges or service tags to allow Power Platform services to connect to resources within your vNet, thereby protecting the resources from unauthorized access.

Currently, you can use secured private outbound connectivity from custom 3rd party Dataverse plug-ins and connectors to enhance the security of data integration with external data sources within your secured private network from your Power Apps, Power Automate, and Dynamics 365 apps.

Unlocking Secure Data Integration with Copilot Studio in Power Platform

In today’s interconnected world, secure data integration is crucial for organizations. Copilot Studio offers robust solutions for fetching and processing data securely. Let’s explore two scenarios where Copilot Studio demonstrates the network security capability of Power Platform:

Scenario #1: Fetching Customer Data from a Web API Hosted in Azure

Imagine you need to retrieve customer data securely from your Web API hosted in Azure. Copilot Studio seamlessly orchestrates the process:

1. Copilot Studio Initiates a Power Automate Flow: Copilot Studio triggers Power Automate flows through a command that include Dataverse unbound plug-in action.
2. Dataverse Plug-in Calls a Web API: The Power Automate flow makes a secure call using Dataverse Plug-in to a private endpoint-protected Web API. This ensures that customer data retrieval remains secure.

Scenario #2: Securely Accessing Azure SQL Database

Suppose you want to access enriched customer data stored in an Azure SQL database. Copilot Studio simplifies this process:

1. Copilot Studio Initiates a Power Automate Flow: Copilot Studio triggers a Power Automate flow through a command.
2. Power Automate Uses a SQL Connector: The Power Automate flow securely retrieves data from the private endpoint-protected Azure SQL Database using the SQL connector.

In both scenarios, Copilot Studio empowers you to handle data seamlessly while maintaining the highest level of security. Whether it’s APIs or databases, Copilot Studio keeps your organizational data safe and protected.

Securely Managing Customer Data with Virtual Tables and Power Apps

In a world where data security is paramount, Virtual Tables and Power Apps provide robust solutions. Let’s explore a scenario where you can securely manage customer data stored in an Azure SQL database:

Scenario: Leveraging Virtual Tables for Secure Connectivity

Suppose you need to securely manage customer data using Power Apps:

1. Virtual Tables: Power Apps uses virtual table.
2. Virtual Network-Supported SQL Connector: By leveraging the virtual network-supported SQL connector within Virtual Table, you can securely connect to your Azure SQL database.
3. Power Apps in Action: Power Apps interacts seamlessly with the virtual tables and Azure SQL Database, allowing you to manage customer data securely.

In summary, with Virtual network support, you can securely manage customer data stored in an SQL database through Power Apps using Virtual Tables.

Availability and Licensing

Virtual network support for Dataverse plug-ins and Power Platform Connectors is available for public preview in public cloud. We will be announcing licensing requirements near general availability.

Call to action.

• Try out Public Preview
• Learn more about supported services within Power Platform Virtual Network support for Power Platform overview (preview) – Power Platform | Microsoft Learn
• Get started – Step by step instructions Set up Virtual Network support for Power Platform (preview) – Power Platform | Microsoft Learn
• Protect enterprise solutions with new Microsoft Power Platform security features  – Microsoft Power Platform Blog

The post Announcing public preview of virtual network support for Power Platform Dataverse plug-ins and Connectors appeared first on Microsoft Power Platform Blog.

We’re excited to let you know that the IP firewall feature is now generally available for the Power Platform environments across all regions. This feature allows you to control access to Dataverse, enabling you to implement stricter security measures. With IP Firewall, Power Platform administrators can configure IP restrictions on each of the Power Platform environments, allowing access to Dataverse only from allowed IP ranges. This helps mitigate risks of insider exfiltrating the data and prevents token replay attack from restricted IP ranges. We hope this feature will help you keep your organizational data secure and protected.

When you configure the IP firewall on the Power Platform environment, it will only allow the requests from the configured IP ranges and reject all other requests, thereby allowing you to restrict the access to Dataverse.

Get Started

Power Platform admins can enable IP restrictions on Power Platform environments (available per licensing requirement) individually via Power Platform admin Center, by default this feature is turned off.

To enable the IP firewall on a Power Platform environment, you can pursue the configuration steps outlined in this article. You can also refer to this demo on IP firewall.

Finally, your environment IP firewall settings will look like below.

Call to Action:

1. Enable IP firewall in Audit-Only Mode: If you haven’t already, enable the IP firewall feature to protect your organizational data by limiting user access to Dataverse from only allowed IP ranges. You can learn more about how to enable this feature by visiting the following link: IP firewall in Power Platform environments – Power Platform | Microsoft Learn
2. Review firewall audit logs: You can review the audit logs and It’s helpful when you’re configuring restrictions on a Power Platform environment. We recommend that you enable audit-only mode for at least a week and disable it only after careful review of the audit logs. IP firewall in Power Platform environments – Power Platform | Microsoft Learn
3. Enable IP firewall in enforcement mode: Once you have tested the IP firewall in audit-only mode and reviewed the audit logs, you can go ahead and enable the IP firewall in enforcement mode.

Learn More:

• IP firewall in Power Platform environments – Power Platform | Microsoft Learn
• (451) IP Firewall in Dataverse – YouTube
• Protect enterprise solutions with new Microsoft Power Platform security features – Microsoft Power Platform Blog

The post Control Access to Dataverse with IP Firewall: Secure Your Data with Ease appeared first on Microsoft Power Platform Blog.

IP cookie binding in Dataverse

IP based cookie binding is a security technique that helps protect Dataverse against cookie replay attacks. A cookie replay attack occurs when an attacker intercepts a valid cookie and exploits it to impersonate the user who originally created the cookie. IP based cookie binding addresses this threat by evaluating the IP address associated with the cookie in the request. If the IP address in the request does not match the IP address of the device where the cookie was originally created, the Dataverse API will automatically reject the cookie and prompt the user with a message indicating that their session may have been compromised. This ensures that only the legitimate and authorized user is able to access the protected resources and prevents attackers from using stolen cookies to gain unauthorized access. IP based cookie binding is a real-time solution, which means it can detect and prevent cookie replay attacks as soon as they occur, providing an added layer of security for the customer’s organization.

How can I enable this feature?

Power Platform administrators can enable this feature in their environments via Power Platform admin center. This feature is turned off by default.

• Select the Environments from the left navigation bar and click on the environment where you want to enable this feature.
• Select Settings –> Product –> Privacy + Security
• Turn on the “Enable IP address-based cookie binding”

More details about this feature are available here

The post IP based cookie binding in Dataverse is Generally Available. appeared first on Microsoft Power Platform Blog.