Azure Storage Networking UI shows Public network access = Unspecified after NSP GA release (Aug 5, 2025)

Question

Similar to this PREVIEW ticket, which was fixed but different due to the bug still existing for previous network settings.

Azure has caused some confusion with the recent Network Security Perimeter (NSP) GA release on August 5th, 2025 (Azure update link). This rollout changed the Storage Account Networking portal blade UI and has completely hidden the previous version of the networking settings.

Observed Behavior

• About half of our storage accounts’ Networking settings now show:

  Public network access = Unspecified (preview)

• Others still show:

  Public network access = Enabled from selected networks

E.g.

However, when we attempt to view container blobs in the UI in accounts that show “Unspecified,” I still receive access errors consistent with the old rules (e.g., VNets restrictions still in place).

Example

• Before the NSP rollout
  • Storage account 1 was configured with “Enabled from selected virtual networks and IP addresses.”
  • Storage account 2 was configured with “Enabled from selected virtual networks and IP addresses.”
• After the NSP rollout:
  • Storage account 1 was configured with “Unspecified” (unchecked options when view/Manage the settings, which suggests Enable from all networks)
  • Storage account 2 was configured with “Enabled from selected networks” (settings are correct)
  • But:
    • Account 1 is still restricted to VNets (tested with CLI + access attempts)
    • Account 2 is still restricted to VNets (tested with CLI + access attempts)

This strongly suggests the backend rules remain correct, but the portal UI mapping is incomplete.

Verification

Using Azure CLI still shows the correct configuration, for example:

$ az storage account show --name mystorageacc --resource-group myresgroup --query "networkRuleSet"
{
  "bypass": "AzureServices",
  "defaultAction": "Deny",
  "ipRules": [],
  "ipv6Rules": [],
  "resourceAccessRules": null,
  "virtualNetworkRules": [
    {
      "action": "Allow",
      "state": "Succeeded",
      "virtualNetworkResourceId": "/subscriptions/<subid>/resourceGroups/myresgroup/providers/Microsoft.Network/virtualNetworks/myvn/subnets/my-private-snet"
    }
  ]
}

This returns the expected defaultAction, virtualNetworkRules, and ipRules that match the old behavior, even though the portal only displays “Unspecified.”

CLI Commands

• Current CLI commands like:

    az storage account network-rule add \
      --resource-group <rg> \
      --account-name <acct> \
      --vnet <vnet> \
      --subnet <subnet>
  

  still work and remain valid. There’s no deprecation notice in the docs.
• Azure has introduced new NSP commands (az network perimeter ...) but these require:

Installing an extension

• Using Azure CLI 2.61.0 or higher
  • We are currently on 2.38.2 and not ready to roll out the update for all of our systems.

---

Questions

Is this a known issue/bug with the Azure Portal UI not mapping legacy network settings correctly after the NSP rollout?

Will Microsoft fix the portal to show the real effective state of existing accounts, or is the expectation that customers must explicitly migrate to NSP to avoid seeing “Unspecified”?

1. Are there any timelines for deprecating the existing az storage account network-rule commands, or will they remain valid until NSP is enforced?

This mismatch is confusing because “Unspecified” makes it look like the account might be exposed, when in fact the underlying firewall/VNet rules are still enforced correctly.

Thanks in advance!

Answer 1

Hi Knyte,

Thank you for your question on the Microsoft Q&A portal!

Microsoft recently rolled out the new Network Security Perimeter (NSP) feature for Azure Storage in August 2025. Because of this update, you might see your storage account showing “Public network access = Unspecified” in the Azure portal. This can be confusing and might make it seem like your storage is open to everyone, but that’s not the case.

What’s really going on?

This is just a display issue in the Azure portal. If your storage account was created before NSP, the portal sometimes can’t show the exact network access settings properly and shows “Unspecified” instead. But don’t worry—your existing security rules, like limiting access to certain virtual networks or IP addresses, are still in place and working as they should. So even if you see “Unspecified,” your storage account is not necessarily exposed.

Yes, Microsoft knows the portal UI isn’t showing the older network setups correctly after the NSP update. It’s a UI glitch, not a security problem.

What do you need to do?

No immediate action is required from you. Your security settings are still effective. If you want, you can consider switching to NSP features, but that’s optional and would require you to update your Azure CLI tools and You can continue using your current CLI commands like az storage account network-rule to manage network access.

Useful Documents:

• https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security-set-default-access?tabs=azure-portal
• https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security
• https://learn.microsoft.com/en-us/cli/azure/storage/account/network-rule?view=azure-cli-latest

Remember, the “Unspecified” label is just a display issue. Your real network rules are still enforced, and you can always check your settings using CLI or PowerShell.

Please do not forget to "Accept the answer” and “upvote it” wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others

Thanks,

Pranitha

Answer 2

I want to add that we recognize the same situation as described above and additionally we recognized on some storage accounts in "unspecified" state or "Enabled from selected networks" that the portal cannot be used to change any allowed VNets settings because trying to show or to change them ends up in this Error having the contributor role on the subscription. So it cannot be an permission problem.