Azure Data Factory: Inquiry on New Undocumented Property 'trustModeClaimForMi'
It looks like PG added a new undocumented property on data factory resource properties:
"trustModeClaimForMi": {
"value": "Enabled",
"editable": true
}
Any ideas about this and any ETA when REST API spec is being updated if ever?
My guesses are that this might be related with upcoming trusted bypass changes and API SPEC ever updates.
2 answers
-
Jaap van der Herberg 0 Reputation points
(Update: I now see that the information that was Available in August 2025 had been mentioned already in another thread in this question. Sorry for the partly duplicate information. Have also added the latest (May 2026) information.
The
trustModeClaimForMiproperty is probably connected to a new feature flag in ADF that we can use to preview upcoming behavior:From the Microsoft notification e-mail (August 2025): As part of an upcoming security update, Azure Data Factory will retire support for the trusted services firewall exception that allows access to Azure Storage accounts and Azure Key Vault by using a managed identity. This change will take effect on 1 August 2026. "To help you prepare, we’ve introduced a new toggle in the Azure Data Factory user interface. This toggle lets you opt in to the new security behavior before the retirement date, so you can validate your configurations and identify issues early."
- You can enable the toggle by adding the feature flag
feature.enableTrustMIToken=trueto the end of the Azure Data Factory Studio URL, then refreshing the page. - After the toggle is enabled, your factory will no longer use the trusted services firewall exception. Instead, it will require one of the supported secure network configurations.
- You can enable the toggle at any time before 1 August 2026 to test and transition at your own pace. We strongly recommend enabling the toggle in test or non-production environments first, and then gradually rolling it out to production after validation.
E-mail May 2026:
Action Recommended: Upcoming Changes to Managed Identity Token Behavior in Azure Data Factory
You're receiving this notification because you're associated with one or more Azure subscriptions that use Azure Data Factory. Following our earlier communications regarding firewall-protected Azure Storage and Azure Key Vault resources, we are sharing an important update that introduces new configuration flexibility for Azure Data Factory (ADF) workspaces. What’s changing
- A new factory-level setting will allow administrators to choose how ADF accesses Azure Storage and Azure Key Vault when firewalls are enabled.
- This setting provides flexibility and control, enabling you to select the token behavior that best aligns with your security and architectural requirements. Key Dates:
- The opt-in/opt-out toggle will be available before August 2026.
- Starting 1 August 2026, the default for new and existing factories if no opt-in action is taken will change to “opt-out” (network-scoped access).
- You will still be able to opt in to the previous behavior if required, with associated security considerations. About the configuration options A new setting will be available in: Azure Data Factory Studio → Manage → Factory Settings Opt-in enabled When this setting is enabled, ADF continues to use the current trusted token behavior for accessing Azure Storage and Azure Key Vault. The Azure Data Factory studio will display additional guidance outlining considerations associated with this approach, allowing administrators to review and make informed decisions before enabling it. Opt-in disabled (default for new factories; will become the default for existing factories in August 2026 if no opt-in action is taken by customers prior to that date) With this selection, ADF uses a network-scoped access pattern. Access to Azure Storage and Azure Key Vault in this configuration requires:
- Managed Virtual Network
- Private Endpoints This option is supported for both new and existing factories. What this means for you
- No immediate action is required for existing factories.
- Existing factories will continue operating with their current behavior unless administrators explicitly change the setting.
- Customers adopting a network-isolated architecture (e.g., Managed Virtual Network-enabled factories) can leverage this configuration to align with their security posture. Planning and evaluation Testing, rollout, and timing guidance To ensure a smooth transition and avoid disruptions, this change will be introduced in phases. Phase 1: Early access and self-testing (before August 2026) A new Managed Identity Token Trust setting will be available at the factory level. During this phase:
- Existing factories will continue using the current (trusted token) behavior by default.
- Administrators can proactively disable the trusted token option to test the new network-scoped access behavior.
- You can switch between enabled and disabled states to:
- Validate workload behavior
- Identify required networking changes (Managed Virtual Network, Private Endpoints)
- Assess operational and cost impact
- Prepare your environment ahead of the default change
Recommended action:
Use this period to test the new behavior in non-production or pilot factories and confirm your networking configuration is ready. Phase 2: Default behavior change (starting August 2026) Beginning August 2026:
- Trusted token will be disabled by default for all new data factories
- Trusted token will be disabled by default for existing data factories if no opt-in action is taken by customers prior to that date.
- Factories will use network-scoped access for Azure Storage and Azure Key Vault After this change:
- Customers already using Managed Virtual Network and Private Endpoints should experience no disruption Customers requiring the previous trusted token behavior must explicitly opt in via the factory security setting Ensure your factory networking configuration is fully prepared before August 2026, or opt in if additional migration time is needed. Why we recommend early testing Testing ahead of the default change helps you:
- Avoid unexpected access issues
- Plan networking updates on your own timeline
- Align with Azure’s long-term security and compliance direction Updated documentation and migration guidance will be published as the rollout progresses. Microsoft support teams are available to help you evaluate the best option for your environment.
Action Recommended: Upcoming Changes to Managed Identity Token Behavior in Azure Data Factory
You're receiving this notification because you're associated with one or more Azure subscriptions that use Azure Data Factory. Following our earlier communications regarding firewall-protected Azure Storage and Azure Key Vault resources, we are sharing an important update that introduces new configuration flexibility for Azure Data Factory (ADF) workspaces. What’s changing
- A new factory-level setting will allow administrators to choose how ADF accesses Azure Storage and Azure Key Vault when firewalls are enabled.
- This setting provides flexibility and control, enabling you to select the token behavior that best aligns with your security and architectural requirements. Key Dates:
- The opt-in/opt-out toggle will be available before August 2026.
- Starting 1 August 2026, the default for new and existing factories if no opt-in action is taken will change to “opt-out” (network-scoped access).
- You will still be able to opt in to the previous behavior if required, with associated security considerations. About the configuration options A new setting will be available in: Azure Data Factory Studio → Manage → Factory Settings Opt-in enabled When this setting is enabled, ADF continues to use the current trusted token behavior for accessing Azure Storage and Azure Key Vault. The Azure Data Factory studio will display additional guidance outlining considerations associated with this approach, allowing administrators to review and make informed decisions before enabling it. Opt-in disabled (default for new factories; will become the default for existing factories in August 2026 if no opt-in action is taken by customers prior to that date) With this selection, ADF uses a network-scoped access pattern. Access to Azure Storage and Azure Key Vault in this configuration requires:
- Managed Virtual Network
- Private Endpoints This option is supported for both new and existing factories. What this means for you
- No immediate action is required for existing factories.
- Existing factories will continue operating with their current behavior unless administrators explicitly change the setting.
- Customers adopting a network-isolated architecture (e.g., Managed Virtual Network-enabled factories) can leverage this configuration to align with their security posture. Planning and evaluation Testing, rollout, and timing guidance To ensure a smooth transition and avoid disruptions, this change will be introduced in phases. Phase 1: Early access and self-testing (before August 2026) A new Managed Identity Token Trust setting will be available at the factory level. During this phase:
- Existing factories will continue using the current (trusted token) behavior by default.
- Administrators can proactively disable the trusted token option to test the new network-scoped access behavior.
- You can switch between enabled and disabled states to:
- Validate workload behavior
- Identify required networking changes (Managed Virtual Network, Private Endpoints)
- Assess operational and cost impact
- Prepare your environment ahead of the default change
Recommended action:
Use this period to test the new behavior in non-production or pilot factories and confirm your networking configuration is ready. Phase 2: Default behavior change (starting August 2026) Beginning August 2026:
- Trusted token will be disabled by default for all new data factories
- Trusted token will be disabled by default for existing data factories if no opt-in action is taken by customers prior to that date.
- Factories will use network-scoped access for Azure Storage and Azure Key Vault After this change:
- Customers already using Managed Virtual Network and Private Endpoints should experience no disruption Customers requiring the previous trusted token behavior must explicitly opt in via the factory security setting Ensure your factory networking configuration is fully prepared before August 2026, or opt in if additional migration time is needed. Why we recommend early testing Testing ahead of the default change helps you:
- Avoid unexpected access issues
- Plan networking updates on your own timeline
- Align with Azure’s long-term security and compliance direction Updated documentation and migration guidance will be published as the rollout progresses. Microsoft support teams are available to help you evaluate the best option for your environment.
-
Janne Kujanpää 266 Reputation points
Trying to understand newest migration guide(May 2026):
- does mention if trsuted access claim chnages cover SHIR or also azure hosted IRs
Does that mean that there is no trusted bypass when trustModeClaimForMi is Disabled when:
- Using SHIR
- Using Azure hosted IRs
- Only use cases with Azure hosted IRs?
- REST linked service to key vault and storage
- Does trusted bypass still work with Azure hosted IR + web activity + key vault?
ref: earlier impact list
As a result, you may be impacted if you're using one of the following options to access an Azure Storage account or Azure Key Vault:
- Data Factory's self-hosted IR (SHIR) with a system-assigned managed identity to access a storage account (trusted bypass).
- The Azure-SQL Server Integration Services (SSIS) IR via Azure Storage Connection Manager or Data Factory's SHIR as a proxy feature with a system-assigned managed identity and storage firewall exception.
- A REST linked service with a system-assigned managed identity to access a storage account (trusted bypass).
- A REST linked service with a system-assigned or user-assigned managed identity to access a key vault (trusted bypass).
Sign in to comment - You can enable the toggle by adding the feature flag
-
Amira Bedhiafi 42,941 Reputation points • MVP • Volunteer Moderator
Hello Janne !
Thank you for posting on Microsoft Learn.
The trustModeClaimForMi property you've come across is likely related to security or identity management feature in ADF. Since it appears undocumented, I think it could be part of an upcoming update or feature related to managed identity (MI) trust or secure bypass configurations or simply it will be deprecated.
My guess it might be related to managed identity trust and it could be used to indicate whether a specific MI is trusted for certain operations, potentially bypassing traditional identity checks or allowing broader access for ADF resources.
As for the REST API spec update, it may take some time for Microsoft to update official documentation and API references for this property, especially if it's part of an experimental or gradual rollout. It might be available in upcoming preview versions of the ADF REST API, but without formal documentation, it's challenging to get a precise timeline.
In the meantime, I'd recommend keeping an eye on:
Azure Release Notes for new features related to security or identity management.
Azure SDK or ADF API documentation for any updates regarding this property.
- Azure forums or Microsoft support for further clarification or possible insights from internal documentation.
-
Janne Kujanpää 266 Reputation points
This might be related with retirement that was announced three days ago. Sadly only customer-specific health advisories are available.
I wonder if this setting can be used to turn off bypass trust (on SHIR) or could this be related with security perimeter.
sources to earlier discussions about trusted bypass issues:
- https://learn.microsoft.com/en-us/answers/questions/1838277/data-factory-managed-identity-is-not-being-identif
- comments: https://techcommunity.microsoft.com/blog/azuredatafactoryblog/data-factory-is-now-a-trusted-service-in-azure-storage-and-azure-key-vault-firew/964993
""""
You're receiving this notice because you're using one or more Azure products with a managed identity and firewall exception for trusted services.
As part of a security update, the trusted services function allowing Azure Data Factory to access Azure Storage accounts and Azure Key Vault using a managed identity and firewall exception will be retired on 6 August 2026.
As a result, you may be impacted if you're using one of the following options to access an Azure Storage account or Azure Key Vault:
- Data Factory's self-hosted IR (SHIR) with a system-assigned managed identity to access a storage account (trusted bypass).
- The Azure-SQL Server Integration Services (SSIS) IR via Azure Storage Connection Manager or Data Factory's SHIR as a proxy feature with a system-assigned managed identity and storage firewall exception.
- A REST linked service with a system-assigned managed identity to access a storage account (trusted bypass).
- A REST linked service with a system-assigned or user-assigned managed identity to access a key vault (trusted bypass).
If you're using one of the options above, you'll need to transition to IP allow-listing, a managed virtual network, or your own virtual network before 6 August 2026.
If none of the above apply, no further action is required.
Required action
To avoid service disruptions, update your IR and linked service configurations using one of the options below before 6 August 2026:
- IP Allow-listing: This option enables you to add the IP address of your SHIR or Azure-SSIS IR to the firewall rules of your Azure Storage account and Azure Key Vault. For more information, refer to our guides for Azure Storage and Azure Key Vault.
- Managed virtual network: This option enables you to access your Azure Storage account and Azure Key Vault using private endpoints from Azure IR. For more information, refer to our guide.
- Customer-owned virtual network: This option allows you to access your Azure Storage account and Azure Key Vault that Azure-SSIS IR joins via a virtual network service endpoint or private endpoint. For more information, refer to our guide.
If you don't transition to one of these alternatives before 6 August 2026, you'll no longer be able to use Data Factory's SHIR, Azure-SSIS IR, and REST Linked Service to access an Azure Storage account or Azure Key Vault with a managed identity and firewall exception for trusted services.
You're receiving this notice because you're using one or more Azure products with a managed identity and firewall exception for trusted services.
As part of a security update, the trusted services function allowing Azure Data Factory to access Azure Storage accounts and Azure Key Vault using a managed identity and firewall exception will be retired on 6 August 2026.
As a result, you may be impacted if you're using one of the following options to access an Azure Storage account or Azure Key Vault:
- Data Factory's self-hosted IR (SHIR) with a system-assigned managed identity to access a storage account (trusted bypass).
- The Azure-SQL Server Integration Services (SSIS) IR via Azure Storage Connection Manager or Data Factory's SHIR as a proxy feature with a system-assigned managed identity and storage firewall exception.
- A REST linked service with a system-assigned managed identity to access a storage account (trusted bypass).
- A REST linked service with a system-assigned or user-assigned managed identity to access a key vault (trusted bypass).
If you're using one of the options above, you'll need to transition to IP allow-listing, a managed virtual network, or your own virtual network before 6 August 2026.
If none of the above apply, no further action is required.
Required action
To avoid service disruptions, update your IR and linked service configurations using one of the options below before 6 August 2026:
- IP Allow-listing: This option enables you to add the IP address of your SHIR or Azure-SSIS IR to the firewall rules of your Azure Storage account and Azure Key Vault. For more information, refer to our guides for Azure Storage and Azure Key Vault.
- Managed virtual network: This option enables you to access your Azure Storage account and Azure Key Vault using private endpoints from Azure IR. For more information, refer to our guide.
- Customer-owned virtual network: This option allows you to access your Azure Storage account and Azure Key Vault that Azure-SSIS IR joins via a virtual network service endpoint or private endpoint. For more information, refer to our guide.
If you don't transition to one of these alternatives before 6 August 2026, you'll no longer be able to use Data Factory's SHIR, Azure-SSIS IR, and REST Linked Service to access an Azure Storage account or Azure Key Vault with a managed identity and firewall exception for trusted services.
"""
-
Venkat Reddy Navari 5,840 Reputation points • Microsoft External Staff • Moderator
Hi Janne Kujanpää Thanks for raising this, really insightful observation. You're likely right that the
trustModeClaimForMiproperty is connected to the recent announcement about the retirement of the trusted services access model, effective August 6, 2026. Although the property isn’t officially documented yet, it seems aligned with the broader shift toward stricter identity and network controls in Azure Data Factory.At the moment, there’s no confirmed ETA for when this will be included in the REST API specs or public documentation. These kinds of properties often surface as part of a backend rollout or private preview before wider announcements.
If you're planning ahead for the deprecation of trusted bypass, recommend starting the transition to one of the supported alternatives such as IP allow-listing, managed virtual networks, or private endpoints rather than relying on undocumented settings. That will help ensure continuity and compliance once the change takes effect.
It’s worth keeping an eye on the Azure Data Factory release notes and the Azure REST API specs repo for updates.
Hope this helps. If this answers your query, do click
Accept AnswerandYesfor was this answer helpful. And, if you have any further query do let us know. -
Venkat Reddy Navari 5,840 Reputation points • Microsoft External Staff • Moderator
Hi Janne Kujanpää Following up to see if the above answer was helpful. If this answers your query, do click
Accept AnswerandYesfor was this answer helpful. And, if you have any further query do let us know.
Sign in to comment
