When I audit Azure environments, the Azure Storage TLS 1.2 picture is nearly always the same. Most production workloads already use modern protocols. Somewhere in the background, though, there are legacy apps, old backup tools and fragile homegrown integrations that still talk TLS 1.0 or 1.1. Microsoft has announced that from 3 February 2026, Azure Storage will only accept TLS 1.2 connections, so those stragglers are running out of time. Finding out where TLS 1.0/1.1 is still in use, and making sure every storage account is locked down, takes more effort than you might expect, particularly in tenants with a long history and patchy documentation.

Every storage account has its own minimum TLS setting

I start by checking where legacy TLS is still allowed. In the Azure Portal, open the Storage Account and go to Settings → Configuration, where you'll find the 'Minimum TLS version' option. Any account still set to TLS 1.0 or 1.1 should move to TLS 1.2 soon. Keep in mind that enabling TLS 1.2 blocks all older clients immediately. If you haven't done your homework, you can break backup pipelines or third-party integrations. I regularly come across shadow IT or old .NET Framework apps (pre-4.6 in particular) that fail silently after the switch. Check first, then enforce.

Azure Policy enforces TLS 1.2 across all storage accounts

If you want certainty that no new or existing storage account slips through, Azure Policy is the only reliable option. The built-in policy 'Configure minimum TLS version for Storage Accounts' lets you require TLS 1.2 at subscription or management group level. I usually run it in audit mode first to see what's non-compliant and switch to enforce mode later. The Compliance section in the Azure Policy portal gives you a clear view of what's still open. You should also document every policy exception for legacy apps. That keeps the migration work visible and helps you avoid outages at the last minute.

Field tip: Whenever legacy tools need an exception, I keep a register, even if it only has two or three entries. It prevents nasty surprises at the final cut-over, and it makes migration costs much easier to justify to management.

StorageBlobLogs in Log Analytics reveals the legacy clients

You also need to know which clients are actually connecting with old TLS. With diagnostic logging sent to a Log Analytics workspace (Storage Account → Diagnostic settings → Log Analytics), the StorageBlobLogs table records a TlsVersion column for every storage request. For real-world discovery, nothing beats this data. At a minimum, logging has to be enabled for blob read operations.

This is the KQL query I run (Log Analytics Workspace → Logs) to find connections that used TLS 1.0 or 1.1 over the last 30 days:

StorageBlobLogs
| where TlsVersion in ('TLS1_0', 'TLS1_1')
| summarize Count=count() by AccountName, ClientIP, TlsVersion, bin(TimeGenerated, 1d)
| sort by Count desc

The results show you which accounts, IPs or apps still fall back to legacy protocols. Microsoft explains how to configure the diagnostic settings in its documentation on configuring the minimum TLS version for Azure Storage.

The same legacy culprits show up in almost every tenant

In my experience, these cause most of the trouble in Azure Storage TLS 1.2 migrations:

  • .NET Framework applications (pre-4.6) that don't use strong crypto by default
  • Java clients on outdated JVMs (TLS 1.2 only became the default with Java 7u131)
  • Third-party backup or migration tools that haven't been updated in a while
  • Old in-house scripts or automations that call obsolete REST APIs
  • Embedded or IoT devices with hardcoded TLS versions

Backup and archiving tools are the ones that tend to go unnoticed until something breaks. After TLS 1.2 is enforced, teams sometimes discover critical jobs failing and have very little time to fix them. I'd deal with this now rather than in the last few weeks before the deadline.

The diagram shows how legacy TLS usage gets caught

The flow is simple. An old client tries to connect with TLS 1.0/1.1, Azure Storage rejects the connection, and the event lands in Log Analytics where admins can investigate it:

sequenceDiagram
    participant Client as "[Client TLS1.0/1.1]"
    participant AzureStorage as "[Azure Storage Account]"
    participant LogAnalytics as "[Log Analytics Workspace]"
    Client->>AzureStorage: "[Connect with TLS1.0]"
    AzureStorage-->>Client: "[Connection rejected]"
    AzureStorage->>LogAnalytics: "[Event with TlsVersion]"

Figure: A legacy TLS connection is rejected and logged in Log Analytics.

I would find and fix legacy TLS now instead of waiting for 2026

If your Azure tenant has any history at all, the Azure Storage TLS 1.2 change will affect you. My advice is to audit the TLS settings on all storage accounts, enforce TLS 1.2 through Azure Policy and go through StorageBlobLogs for signs of legacy usage. Once you've done that, you know how much migration work is really ahead of you, and you can plan it with business owners and developers instead of scrambling at the end. Microsoft's guidance on monitoring Blob Storage has more practical detail. And test enforcement in a pre-production environment first. If you leave this until the final weeks, you will almost certainly run into surprises.