Technical Support Request: Azure Sphere / IoT Hub Network Requirements and Akamai CDN Firewall Blocks

Dear Microsoft Azure Support Team,

I am reaching out to request official clarification and technical guidance regarding the network connectivity requirements for Azure Sphere devices communicating with Azure IoT Hub.

Our team is currently deploying Azure Sphere devices, and our network security team has configured the enterprise firewall according to the official documentation: Azure Sphere - Ports, protocols, and domains (https://learn.microsoft.com/en-us/azure-sphere/network/ports-protocols-domains).

We have explicitly allowed the required Fully Qualified Domain Names (FQDNs), including:

• global.azure-devices-provisioning.net

[www.msftconnecttest.com](https://www.msftconnecttest.com)

prod.update.sphere.azure.net

prod.core.sphere.azure.net

(and all other endpoints listed in the documentation for Ports 8883, 443, 80, 53, and 123).

The Issue: Despite allowing the exact URLs and hostnames, our firewall is still blocking outgoing traffic from the Azure Sphere devices. The block logs indicate that the devices are attempting to reach highly dynamic IP addresses belonging to the Akamai Content Delivery Network (CDN).

Because Akamai utilizes dynamic, geo-specific DNS resolution and complex CNAME chains (e.g., routing prod.update.sphere.azure.net through akamai.net endpoints), our firewall is experiencing DNS mismatches between what its own FQDN engine resolves and what the Sphere device resolves. As a result, the physical Akamai IP addresses the devices try to communicate with are being dropped.

Our Questions: To resolve this with our security team, we need an official explanation and solution from Microsoft regarding the following:

Handling CDN Routing: What is the official best practice for configuring strict enterprise firewalls to support Azure Sphere’s reliance on the Akamai CDN when standard FQDN allow-listing fails due to dynamic IP rotation and CNAME chaining?

DNS Mismatches: Does Microsoft recommend specific firewall configurations (such as DNS snooping, wildcard allowances for specific Akamai domains, or CNAME alias tracking) to ensure the firewall and the devices authorize the same IP addresses?

Static Alternatives: Are there any Azure Service Tags, static IP ranges, or dedicated ASNs that we can securely allow-list for Azure Sphere traffic, or is FQDN routing the only supported method?

TLS/SNI Inspection: Can you confirm the official requirement regarding SSL/TLS Deep Packet Inspection (DPI) for Azure Sphere traffic, and whether strict TLS bypass rules are mandatory for these CDN endpoints?

We need to provide our security engineers with a definitive, official solution to unblock these devices without compromising our network’s egress policies.

Thank you for your time and technical assistance. I look forward to your guidance.

Best regards,Dear Microsoft Azure Support Team,

I am reaching out to request official clarification and technical guidance regarding the network connectivity requirements for Azure Sphere devices communicating with Azure IoT Hub.

Our team is currently deploying Azure Sphere devices, and our network security team has configured the enterprise firewall according to the official documentation: Azure Sphere - Ports, protocols, and domains (https://learn.microsoft.com/en-us/azure-sphere/network/ports-protocols-domains).

We have explicitly allowed the required Fully Qualified Domain Names (FQDNs), including:

global.azure-devices-provisioning.net

[www.msftconnecttest.com](https://www.msftconnecttest.com)

prod.update.sphere.azure.net

prod.core.sphere.azure.net

(and all other endpoints listed in the documentation for Ports 8883, 443, 80, 53, and 123).

The Issue: Despite allowing the exact URLs and hostnames, our firewall is still blocking outgoing traffic from the Azure Sphere devices. The block logs indicate that the devices are attempting to reach highly dynamic IP addresses belonging to the Akamai Content Delivery Network (CDN).

Because Akamai utilizes dynamic, geo-specific DNS resolution and complex CNAME chains (e.g., routing prod.update.sphere.azure.net through akamai.net endpoints), our firewall is experiencing DNS mismatches between what its own FQDN engine resolves and what the Sphere device resolves. As a result, the physical Akamai IP addresses the devices try to communicate with are being dropped.

Our Questions: To resolve this with our security team, we need an official explanation and solution from Microsoft regarding the following:

Handling CDN Routing: What is the official best practice for configuring strict enterprise firewalls to support Azure Sphere’s reliance on the Akamai CDN when standard FQDN allow-listing fails due to dynamic IP rotation and CNAME chaining?

DNS Mismatches: Does Microsoft recommend specific firewall configurations (such as DNS snooping, wildcard allowances for specific Akamai domains, or CNAME alias tracking) to ensure the firewall and the devices authorize the same IP addresses?

Static Alternatives: Are there any Azure Service Tags, static IP ranges, or dedicated ASNs that we can securely allow-list for Azure Sphere traffic, or is FQDN routing the only supported method?

TLS/SNI Inspection: Can you confirm the official requirement regarding SSL/TLS Deep Packet Inspection (DPI) for Azure Sphere traffic, and whether strict TLS bypass rules are mandatory for these CDN endpoints?

We need to provide our security engineers with a definitive, official solution to unblock these devices without compromising our network’s egress policies.

Thank you for your time and technical assistance. I look forward to your guidance.