Azure Storage - TLS 1.0 and 1.1 retirement
Overview
TLS 1.0 and 1.1 retirement on Azure Storage was previously announced for Nov 1st, 2024, and it was postponed recently to 1 year later, to Nov 1st, 2025.
Despite that, we may see some documentation informing the old date - we are currently updating the date on some documentation.
See : https://learn.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-migrate-to-tls2
What you need to change:
On Nov 1st, 2025, Azure Blob Storage will stop supporting versions 1.0 and 1.1 of Transport Layer Security (TLS) and TLS 1.2 will become the new minimum TLS version.
This change on Azure Storage side will be internally and you don't need to take any action on Azure Storage service.
Despite that, at that time, all clients connecting to Azure storage needs to send and receive data by using TLS 1.2, otherwise will not be able to connect to storage using SSL connections.
So, you may need to make sure your client applications are using TLS 1.2 at that time, and update your applications, if needed, removing all dependencies on TLS version 1.0 and 1.1.
- If your storage accounts are already configured with minimum TLS version 1.2, this means that storage clients are already connecting using TLS 1.2or above, and in that case you don't need to take any action on that client applications.
- If you have some storage account configured with minimum TLS version 1.0 or 1.1, you may need to check what TLS version that storage account's clients are using; if using TLS 1.0 and 1.1, you may need to update that applications to ensure being able to connect to Storage after Nov 1st, 2025.
Once that corrected, you may manually change Azure Storage configurations to enforce minimum TLS 1.2, if you want.
That is not needed, as after Nov 1st, 2025 will be enforced to use minimum TLS 1.2, and this change is something that happening internally.
How to verify what minimum TLS version is configured on each storage accounts, under some Azure Subscription:
To help you on listing the minimum TLS version configured on all storage accounts in your subscription, you can use the below PowerShell script:
If you have some storage accounts using minimum TLS 1.0 or 1.1, you may need to check the TLS version used by the client applications connecting to that Storage account.
The only ways to check that is looking on the application code, or having Storage Diagnostic Logs enabled, to list all storage operations and check the TLS version used.
How to enable/disable Storage Diagnostic Logs on the relevant Storage accounts:
The below PowerShell Script will scan all storage accounts in some Azure subscription, and will enable Storage Diagnostic Logs on the ones configured with minimum TLS version below 1.2.
The logs will be enabled to all services (Blob, Table, Queue and Files), on each storage account.
You need first to have some Log Analytic workspace to accommodate that logs; it’s better to create a new one, just to these proposes, and you can delete it later.
You also need to define the Azure Subscription ID, and the Log Analytic workspace ID, on the $WorkspaceId variable, in the PowerShell script.
At the end of the script, there are some instructions on how to run the script again to remove all Diagnostic settings added, when not needed anymore.
Once Storage Diagnostic Logs enabled on the relevant Storage accounts, wait some time (maybe some days to make sure all your applications interact with all storages), and then you can query Log Analytics Workspace, and look for any requests using TLS version below 1.2.
For that you can use the Kusto query also shared below.
Important:
Please understand the scripts provided on this page are shared as Guidance for you, and as best effort to try be better help you.
Please use any script or query on this page as per you own risk.
We share these scripts, without any guarantee and we can’t assume any responsibility for any unexpected results.
We strongly recommend you to review, test and adjust all scripts and queries as per your needs.
At the end of the script, there are some instructions on how to run the script again to remove all Diagnostic settings added, when not needed anymore.
How to check Storage Diagnostic Logs to identify the client applications using TLS 1.0 or 1.1 to connect to Storage service:
To query Log Analytics Workspace, and look for any requests using TLS version below 1.2, you can use the Kusto query below.
The Kusto query will return all requests using TLS version below 1.2, from all services (Blob, Table, Queue and Files), on all storage accounts that have Logs from Diagnostic Logs, on the same Log Analytic workspace used.
If you want to check only some specific(s) storage account(s), uncomment the 6th line and provide the storage account names(s) you want to check.
The last line select only the relevant fields to you investigation.
CallerIpAddress, UserAgentHeader should help you on identifying the client application;
TlsVersion is the relevant field showing the TLS version on each request;
TimeGenerated, AccountName, ServiceType, OperationName, StatusCode, Uri acn also help you on identifying the service and request URI used,
If you want to check all fields, just remove or comment the last line.
Conclusion:
Azure Storage TLS 1.0 and 1.1 deprecation date was postponed 1 year, to Nov 1st, 2025.
After that date, all clients connecting to Azure Storage services using TLS version below 1.2, will not be able to connect to Azure Storage anymore.
You don't need to take any action on your Azure Storage services; this change will be automatic.
You just need to ensure that all client applications connecting to your Storage accounts are using TLS 1.2 or above, after that date.
Related documentation:
Azure Storage TLS 1.0 and 1.1 deprecation: https://learn.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-migrate-to-tls2
Other Azure products TLS 1.0 and 1.1 deprecation and FAQ's: https://techcommunity.microsoft.com/t5/security-compliance-and-identity/support-for-legacy-tls-protocols-and-cipher-suites-in-azure/ba-p/3952099
Enforce a minimum required version of Transport Layer Security (TLS) for requests to a storage account: https://learn.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-minimum-version?tabs=portal
Use Azure Policy to audit for compliance: https://learn.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-minimum-version?tabs=portal#use-azure-policy-to-audit-for-compliance
Storage Diagnostic Logs:
Create diagnostic settings: https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/diagnostic-settings?tabs=portal#create-diagnostic-settings
Destinations: https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/diagnostic-settings?tabs=portal#destinations
Log Analytics tutorial: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-tutorial
Log Analytic workspace - Sample Kusto queries: https://learn.microsoft.com/en-us/azure/storage/blobs/monitor-blob-storage?tabs=azure-portal#sample-kusto-queries
Log Format and information available: https://learn.microsoft.com/en-us/azure/storage/blobs/monitor-blob-storage-reference#resource-logs
Storage Diagnostic Logs may incur in some additional charges - the most significant charges for most Azure Monitor implementations will typically be ingestion and retention of data in your Log Analytics workspaces;
you can disable Storage Diagnostic Logs again after our investigation, if you don’t need that.
Logs cost calculation: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/cost-logs
Analytic logs pricing: https://azure.microsoft.com/en-us/pricing/details/monitor/
I hope this can be useful!!!
Published on:
Learn moreRelated posts
Azurite: Build Azure Queues and Functions Locally with C#
Lets say you are a beginner Microsoft Azure developer and you want to : Normally, these tasks require an Azure Subscription. But what if I tol...
Data encryption with customer-managed key (CMK) for Azure Cosmos DB for MongoDB vCore
Built-in security for every configuration Azure Cosmos DB for MongoDB vCore is designed with security as a foundational principle. Regardless ...
Azure Developer CLI: From Dev to Prod with Azure DevOps Pipelines
Building on our previous post about implementing dev-to-prod promotion with GitHub Actions, this follow-up demonstrates the same “build ...
Azure DevOps OAuth Client Secrets Now Shown Only Once
We’re making an important change to how Azure DevOps displays OAuth client secrets to align with industry best practices and improve our overa...
Azure Managed Instance for Apache Cassandra v5.0 Generally Available!
Azure Managed Instance for Apache Cassandra Upgrade to Cassandra v5.0 is now generally available, bringing a host of powerful new features and...
Hunting Living Secrets: Secret Validity Checks Arrive in GitHub Advanced Security for Azure DevOps
If you’ve ever waded through a swamp of secret scanning alerts wondering, “Which of these are actually dangerous right now?”— this enhancement...
Real-Time Security with Continuous Access Evaluation (CAE) comes to Azure DevOps
We’re thrilled to announce that Continuous Access Evaluation (CAE) is now supported on Azure DevOps, bringing a new level of near real-time se...