Inquiry on TLS 1.2 Cipher Suite Compatibility and Possible Extension for Azure Storage

Question

Inquiry on TLS 1.2 Cipher Suite Compatibility and Possible Extension for Azure Storage

PANNARAT, MASSATRON 0

Dear Azure Support Team,

We have noticed the following notification on our Azure Storage account:

“Storage retired support for TLS 1.0 and 1.1 on February 3, 2026. Please upgrade your minimum TLS version to 1.2.”

Based on this message, we would like to seek clarification regarding the impact on our existing embedded devices.

Currently, our embedded devices support TLS 1.2, however they are using the following cipher suite:

TLS_RSA_WITH_AES_256_CBC_SHA256

We would like to confirm the following points:

Compatibility Will embedded devices that support TLS 1.2 but use the cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 still be able to connect to Azure Storage and download files after the TLS 1.0/1.1 retirement?

Impact if Not Supported If this cipher suite is no longer supported by Azure Storage, will the connection or file download fail completely?

Extension / Grace Period In case the devices are affected, is it possible to request an extension, exception, or temporary grace period to allow continued access while we work on upgrading the firmware and cipher suites on the embedded devices?

Required Actions If an extension is possible, could you please advise:

The required process or request method
- Any limitations or conditions
  - The recommended cipher suites we should migrate to for long-term compatibility

This information is critical for us, as updating embedded device firmware requires careful planning and deployment.

Thank you very much for your support. We look forward to your guidance.Dear Azure Support Team,

We have noticed the following notification on our Azure Storage account:

“Storage retired support for TLS 1.0 and 1.1 on February 3, 2026. Please upgrade your minimum TLS version to 1.2.”

Based on this message, we would like to seek clarification regarding the impact on our existing embedded devices.

Currently, our embedded devices support TLS 1.2, however they are using the following cipher suite:

TLS_RSA_WITH_AES_256_CBC_SHA256

We would like to confirm the following points:

Compatibility
Will embedded devices that support TLS 1.2 but use the cipher suite
TLS_RSA_WITH_AES_256_CBC_SHA256 still be able to connect to Azure Storage and download files after the TLS 1.0/1.1 retirement?

Impact if Not Supported
If this cipher suite is no longer supported by Azure Storage, will the connection or file download fail completely?

Extension / Grace Period
In case the devices are affected, is it possible to request an extension, exception, or temporary grace period to allow continued access while we work on upgrading the firmware and cipher suites on the embedded devices?

Required Actions
If an extension is possible, could you please advise:

The required process or request method
- Any limitations or conditions
  - The recommended cipher suites we should migrate to for long-term compatibility

This information is critical for us, as updating embedded device firmware requires careful planning and deployment.

Thank you very much for your support. We look forward to your guidance.

0 comments

3 answers

Your answer

Answer 1

Hello @ PANNARAT, MASSATRON

Thank you for reaching out to Microsoft Q&A.

I understand your concern, especially when embedded device updates require careful planning.

The good news is that your devices should continue to work with Azure Storage after the retirement of TLS 1.0 and TLS 1.1, as long as they successfully negotiate TLS 1.2.

Your current cipher suite, TLS_RSA_WITH_AES_256_CBC_SHA256, is a valid TLS 1.2 cipher suite. Since Azure Storage will continue to support TLS 1.2, devices using this cipher suite should still be able to connect and download files, provided the TLS handshake completes successfully.

If Azure Storage and the client are unable to agree on a mutually supported cipher suite, the TLS handshake will fail. In that case, the connection will be rejected, and any file transfer operation will not proceed.

Regarding an extension or grace period, Microsoft is retiring support only for TLS 1.0 and TLS 1.1. Since your devices already support TLS 1.2, no exception should be necessary. At this time, Microsoft has not announced any extension program for legacy TLS versions.

For long-term security and compatibility, Microsoft recommends moving to modern cipher suites that support Perfect Forward Secrecy (PFS), such as:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

As a next step, recommend validating connectivity from one of your devices after setting the Storage account minimum TLS version to 1.2. If possible, capture the TLS handshake to confirm the negotiated protocol and cipher suite.

Reference:
https://learn.microsoft.com/azure/storage/common/transport-layer-security-configure-minimum-version

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Answer 2

Hi ,

Thanks for reaching out to Microsoft Q&A.

Short answer: you have a risk. TLS 1.2 alone is not sufficient; the cipher suite matters.

Azure Storage no longer guarantees support for legacy RSA key exchange + CBC suites like TLS_RSA_WITH_AES_256_CBC_SHA256. Modern Azure services are moving toward ECDHE + AES-GCM suites for security (forward secrecy + stronger integrity). So your current devices may fail.

To answer you directly....

Compatibility Not guaranteed. Even though your devices use TLS 1.2, the specific cipher suite you mentioned is considered legacy. Many Azure endpoints already reject RSA key exchange–based suites. You should expect connection failures either now or soon.

Impact if not supported**:** Yes, it is a hard failure. TLS handshake will fail → no HTTPS connection → file download will not work at all. There is no fallback at application level.

Extension / grace period: Practically no. Azure Storage does not offer per-account exceptions for weak cipher suites. The TLS 1.0/1.1 retirement is firm, and cipher hardening is platform-wide. You cannot request a temporary allowance for specific cipher suites.

Required action : You need to upgrade firmware to support modern cipher suites. Minimum recommended:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

If possible, even better to support:

TLS_ECDHE_ECDSA_* variants (if you move to ECDSA certs later)

Bottom line Your setup is not future-safe. Even if it works today in some regions, it can break without notice. Plan firmware upgrade as a priority.

If you want, I can help you validate your device handshake against Azure Storage endpoints or suggest a fallback architecture (for ex, proxy layer to bridge old devices)

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Answer 3

Jerald Felix 11,550 Volunteer Moderator

Hello PANNARAT, MASSATRON

Greetings!

Thanks for raising this question in Q&A forum.

Great news, your devices support TLS 1.2, so you are already on the right protocol version. However, the concern here is specifically about the cipher suite your devices use: TLS_RSA_WITH_AES_256_CBC_SHA256. Let me address each of your points clearly.

1. Compatibility

This cipher suite (TLS_RSA_WITH_AES_256_CBC_SHA256) is a non-forward-secret cipher — it does not support Perfect Forward Secrecy (PFS). Microsoft has been progressively tightening Azure Storage's accepted cipher suites to favor stronger, PFS-enabled ones. While this cipher may still work today, it is considered weak by modern security standards and may be dropped by Azure Storage in a future update without much notice. You should treat this as an urgent firmware upgrade item.

2. Impact if Not Supported

Yes, if Azure Storage stops accepting this cipher suite, the TLS handshake will fail completely and your embedded devices will be unable to connect or download any files. There will be no partial access; it's an all-or-nothing TLS handshake.

3. Extension / Grace Period

Microsoft does not offer formal per-customer cipher suite exceptions or grace periods for Azure Storage, as these are platform-wide security decisions. The TLS 1.0/1.1 retirement already happened on February 3, 2026 with no rollback. The recommended path forward is to plan your firmware upgrade proactively.

4. Recommended Actions

Here's what you should do right now:

Step 1: Test connectivity today Verify whether your devices can currently reach Azure Storage using their existing cipher suite. You can use a tool like openssl or nmap to simulate the TLS handshake from a test environment:

openssl s_client -connect <yourstorageaccount>.blob.core.windows.net:443 -cipher "AES256-SHA256"

If it connects, you still have time. If it fails, the cipher is already blocked.

Step 2: Plan firmware upgrade Prioritize updating your embedded device firmware to support one of these recommended cipher suites that are modern, secure, and PFS-enabled:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Step 3: Open an Azure Support Ticket While a formal extension is unlikely, if your business impact is significant, raise a support request at the Azure Portal under your Storage account. Go to: Azure Portal → Your Storage Account → Support + Troubleshooting → New Support Request. Explain your embedded device constraints — Microsoft support can at least give you an official confirmation of the current cipher suite support status.

Step 4: Monitor Microsoft announcements Keep an eye on the official Azure Storage TLS guidance page at https://aka.ms/azurestoragetls for any updates on cipher suite retirement timelines.

The safest long-term solution is to move your embedded devices to a supported PFS cipher suite as soon as possible, as relying on weaker cipher suites poses a security risk beyond just compatibility.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

PANNARAT, MASSATRON 0 Reputation points

2026-04-29T16:10:30.9366667+00:00
Hello Jerald,

Thank you very much for the clear and detailed explanation. This is very helpful.

I’d like to follow up on one specific point you mentioned:

“may be dropped by Azure Storage in a future update without much notice.”

To help us plan firmware updates for our embedded devices effectively, may I ask:

Is there any indicative timeframe, high‑level estimate, or earliest possible window that Microsoft is internally targeting for deprecating or disabling the TLS_RSA_WITH_AES_256_CBC_SHA256 cipher suite in Azure Storage?

For example, are we potentially looking at a timeframe such as months vs. years, or would this only occur as part of a major, publicly announced security change?

We fully understand that an exact date may not be available, but even a rough planning horizon would greatly help us prioritize firmware rollout, testing, and customer communication for embedded devices that are costly to update.

As part of Step 2: Plan firmware upgrade, we would like to clearly understand the officially supported TLS 1.2 cipher suites for Azure Storage, so we can ensure our embedded device firmware aligns with Azure’s current and future security requirements.

Could you please help confirm:

The complete or official list of TLS 1.2 cipher suites that are currently supported by Azure Storage.

Is there an official Microsoft document or reference page that we should follow as the source of truth for supported Azure Storage cipher suites?

Thank you so much.****
Jerald Felix 11,550 Reputation points Volunteer Moderator

2026-04-29T16:20:30.9133333+00:00
Thank you for your follow-up, these are very practical questions, especially when you are managing firmware rollouts for embedded devices. Let me address both points as clearly as possible.

On the deprecation timeframe for TLS_RSA_WITH_AES_256_CBC_SHA256

Microsoft has not published a specific date for retiring individual TLS 1.2 cipher suites in Azure Storage. However, based on Microsoft's security roadmap and industry trends, here is a realistic planning horizon:

The deprecation of weak TLS 1.2 cipher suites (especially non-PFS ones like TLS_RSA_WITH_AES_256_CBC_SHA256) is more likely to happen on a scale of months to a couple of years, rather than many years away. The TLS 1.0/1.1 retirement took several years to roll out with advance notice, but cipher suite hardening tends to happen faster and with less fanfare. The safest assumption for planning purposes is to treat this as a 12–18 month window and prioritize firmware upgrades accordingly.

On the officially supported TLS 1.2 cipher suites for Azure Storage

Microsoft does not publish a static list of supported cipher suites per service. Instead, Azure Storage inherits the cipher suite policy from the underlying Azure platform (Schannel on Windows / OpenSSL on Linux). The authoritative reference page you should bookmark and follow is:

https://learn.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-minimum-version

For the most current list of cipher suites supported across Azure, also refer to:

https://learn.microsoft.com/en-us/azure/security/fundamentals/tls-certificate-changes

Recommended cipher suites to target in your firmware upgrade

For long-term compatibility and security, plan your firmware to support these cipher suites in priority order:

Step 1: Target these as your primary cipher suites (strong, PFS-enabled, widely supported):

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Step 2: These are acceptable as fallback options (PFS-enabled, CBC-mode):

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Step 3: Avoid these entirely in your new firmware (no PFS, legacy RSA key exchange):

TLS_RSA_WITH_AES_256_CBC_SHA256 ← your current cipher

TLS_RSA_WITH_AES_128_CBC_SHA256

Practical suggestion for your planning

Since you cannot get an exact date from Microsoft, a good strategy is to use a proxy or TLS termination layer (such as Azure API Management or an Azure Application Gateway) as an interim bridge. Your embedded devices would connect to the proxy using the old cipher suite, while the proxy connects to Azure Storage using modern cipher suites. This buys you additional time for the firmware rollout without any risk of sudden connectivity loss.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards, Jerald Felix.Hello PANNARAT, MASSATRON Greetings! Thanks for raising this question in Q&A forum.

Thank you for your follow-up — these are very practical questions, especially when you are managing firmware rollouts for embedded devices. Let me address both points as clearly as possible.

On the deprecation timeframe for TLS_RSA_WITH_AES_256_CBC_SHA256

Microsoft has not published a specific date for retiring individual TLS 1.2 cipher suites in Azure Storage. However, based on Microsoft's security roadmap and industry trends, here is a realistic planning horizon:

The deprecation of weak TLS 1.2 cipher suites (especially non-PFS ones like TLS_RSA_WITH_AES_256_CBC_SHA256) is more likely to happen on a scale of months to a couple of years, rather than many years away. The TLS 1.0/1.1 retirement took several years to roll out with advance notice, but cipher suite hardening tends to happen faster and with less fanfare. The safest assumption for planning purposes is to treat this as a 12–18 month window and prioritize firmware upgrades accordingly.

On the officially supported TLS 1.2 cipher suites for Azure Storage

Microsoft does not publish a static list of supported cipher suites per service. Instead, Azure Storage inherits the cipher suite policy from the underlying Azure platform (Schannel on Windows / OpenSSL on Linux). The authoritative reference page you should bookmark and follow is:

https://learn.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-minimum-version

For the most current list of cipher suites supported across Azure, also refer to:

https://learn.microsoft.com/en-us/azure/security/fundamentals/tls-certificate-changes

Recommended cipher suites to target in your firmware upgrade

For long-term compatibility and security, plan your firmware to support these cipher suites in priority order:

Step 1: Target these as your primary cipher suites (strong, PFS-enabled, widely supported):

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Step 2: These are acceptable as fallback options (PFS-enabled, CBC-mode):

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Step 3: Avoid these entirely in your new firmware (no PFS, legacy RSA key exchange):

TLS_RSA_WITH_AES_256_CBC_SHA256 ← your current cipher

TLS_RSA_WITH_AES_128_CBC_SHA256

Practical suggestion for your planning

Since you cannot get an exact date from Microsoft, a good strategy is to use a proxy or TLS termination layer (such as Azure API Management or an Azure Application Gateway) as an interim bridge. Your embedded devices would connect to the proxy using the old cipher suite, while the proxy connects to Azure Storage using modern cipher suites. This buys you additional time for the firmware rollout without any risk of sudden connectivity loss.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.
PANNARAT, MASSATRON 0 Reputation points

2026-04-29T16:47:01.9533333+00:00
Hello Jerald,

Thank you very much for your previous explanations and recommendations.

We would like to explain our situation in more detail and kindly ask for your guidance.

Currently, our Azure Storage account is used to host firmware files that are downloaded by embedded devices as part of an OTA firmware upgrade process.

At this moment:

Some of our deployed and in‑stock embedded devices can only connect using TLS 1.2 with cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256

The new firmware, once downloaded and applied, will upgrade the devices to support a modern and PFS‑enabled cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

However, due to operational constraints:

We cannot immediately trigger OTA updates for all devices.

A significant number of embedded devices are currently stored in stock / warehouse, not yet deployed or remotely reachable.

These devices must first be able to download the firmware from Azure Storage using their existing cipher suite in order to upgrade.

Because of this dependency, we would like to ask the following:

Temporary Access Possibility Is there any supported or recommended way to temporarily allow connections using TLS_RSA_WITH_AES_256_CBC_SHA256 only for the purpose of downloading the OTA firmware, so that devices can be upgraded to a compliant cipher suite?

Alternative Architectures / Workarounds If direct support or exceptions are not possible on Azure Storage, do you have any recommended alternative approaches, for example:

Using a different Azure service as an intermediate download endpoint

Best‑Practice Recommendation Based on Microsoft’s experience, what would be the best and safest approach to handle this transition without risking availability for legacy embedded devices?

We fully understand Azure’s security direction and do not intend to rely on legacy cipher suites long‑term. Our goal is to ensure a controlled and safe migration path so that all devices can be upgraded to modern, PFS‑enabled cipher suites as soon as technically possible.

Thank you very much for your understanding and guidance.
Vallepu Venkateswarlu 8,430 Reputation points Microsoft External Staff Moderator

2026-04-30T19:15:25.68+00:00
Hi @PANNARAT, MASSATRON,

Is it possible to temporarily allow TLS_RSA_WITH_AES_256_CBC_SHA256 on Azure Storage?

At this time, Azure Storage does not support configuring or allowing specific TLS cipher suites, including legacy RSA-based suites.

Azure Storage enforces a platform-managed TLS policy

While TLS 1.2 is supported, non-PFS cipher suites (such as TLS_RSA_*) are not supported

There is no mechanism to create exceptions or temporary allowances

A recommended approach is to introduce a proxy or TLS termination layer, such as Azure API Management or Azure Application Gateway. This allows your embedded devices to communicate using legacy cipher suites, while the proxy handles secure communication with Azure Storage using updated cipher standards

Please "upvote" if the information helped you. This will help us and others in the community as well.
PANNARAT, MASSATRON 0 Reputation points

2026-05-02T01:16:20.66+00:00

Hi @Vallepu Venkateswarlu
Thank you reply. Your recommended to Azure API Management.

We would like to inquire about the future roadmap regarding weak or legacy TLS cipher suites in Azure API Management (Managed / Cloud).

Currently, we observe that Azure API Management provides a “Protocols + ciphers” configuration page where certain cipher suites marked as “Weak cipher enabled” (for example, RSA-based or CBC-mode cipher suites) can still be enabled or disabled by customers. However, we have not found any official announcement or timeline regarding their deprecation or removal.

To support our long-term architecture planning and compliance strategy, we would appreciate your clarification on the following points:
Ravi Varma Mudduluru 11,235 Reputation points Microsoft External Staff Moderator

2026-05-04T19:24:46.2866667+00:00

Hello @ PANNARAT, MASSATRON

About the future roadmap regarding weak or legacy TLS cipher suites in Azure API Management. Share your ideas in this feedback form concern team will check on this feature. https://feedback.azure.com/d365community and once the feature is enabled team will update the updates in this page https://azure.microsoft.com/en-us/updates

Please "upvote" if the information helped you. This will help us and others in the community as well.

Share via

Inquiry on TLS 1.2 Cipher Suite Compatibility and Possible Extension for Azure Storage

3 answers

Your answer