Azure Front Door Standard WAF creation fails while AllowFrontdoor remains Pending I cannot create an Azure Front Door Standard WAF policy.

Hello Emil Kanneworff,

Sorry you’re hitting this. Based on the information you shared, the symptom looks like the WAF-related provider feature/operation isn’t fully enabled yet, and the error you’re seeing (“Policy ArmResourceId has incorrect formatting”) is consistent with a control-plane/feature state mismatch rather than your WAF rule content (especially since you also tested a minimal Standard_AzureFrontDoor WAF policy with no custom configuration).

From the docs, the most relevant matching guidance is that Azure Front Door control plane restrictions can temporarily block changes, and in those cases, you may see related feature states remain Pending until Microsoft lifts the restriction window. During a control-plane restriction period, changes to Azure Front Door are blocked (including creation of new Front Door profiles), and that the lift is tied to a specific date/time update.

What to try / check next (public-forum friendly)

• Confirm the feature registration/state is still “Pending” for Microsoft.Network/AllowFrontdoor.
  • If it’s still pending, you likely won’t be able to create WAF policies successfully yet.
• Check if there are ongoing Azure Front Door control plane restrictions/outages in your region/tenant
  • The provided Q&A specifically mentions that control plane restrictions can block Front Door changes and that they are lifted on a scheduled date.
• Retry after the feature/controls become active
  • If the backend restriction is the root cause, retries after the lift should resolve the issue without changes to your template/policy content.
• If the Front Door profile is already “Active”
  • That matches your case; however, WAF policy creation can still fail independently if the WAF feature/control-plane registration isn’t fully active.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.

Thank you. I rechecked the subscription directly.

Microsoft.Network/AllowFrontdoor remains Pending.

Microsoft.Network and Microsoft.Cdn are Registered.

The Front Door profile is Succeeded, while WAF policy count remains zero.

A minimal standalone WAF policy still fails with:

“Policy ArmResourceId has incorrect formatting.”

The issue has persisted beyond the normal propagation period, so the proposed

wait-and-retry action has not resolved it. Could you please initiate a private

message and escalate this to Azure Networking / Front Door for subscription-

level backend feature approval? I can provide the subscription ID, resource

IDs, timestamps and correlation IDs privately.

Thank you. The proposed configuration guidance does not resolve the issue.

Microsoft.Network/AllowFrontdoor remains Pending beyond the normal

propagation period. Microsoft.Network and Microsoft.Cdn are Registered,

and a minimal unassociated Standard_AzureFrontDoor WAF policy still fails

with:

WebApplicationFirewallPolicy validation failed.

Policy ArmResourceId has incorrect formatting.

The Azure support portal classifies this as a technical issue, for which

our subscription currently has no support plan. Could you please initiate

a private escalation to Azure Networking / Front Door? I can provide the

subscription ID, resource IDs, timestamps and correlation details privately.

Here is a draft response you can post to help move the issue forward or clarify the situation:

The error message Policy ArmResourceId has incorrect formatting combined with a stuck Pending state for Microsoft.Network/AllowFrontdoor strongly points to a subscription-level feature gate or a backend control-plane restriction rather than an issue with your template/ARM formatting.

A few things worth checking or including in your request:

• Subscription Type & Quotas: Certain subscription types (e.g., Free Trial, Azure in Open, or specific sponsored subscriptions) require manual backend whitelisting for Front Door / WAF feature flags before Microsoft.Network/AllowFrontdoor transitions to Registered.
• Re-registering the Provider: Sometimes re-triggering registration via Azure CLI/PowerShell helps kick off the state machine if it got stuck: Bash

    az feature register --namespace 
  

• Support Request Path: Since technical support tickets require a plan, you can file a Subscription Management / Billing & Account Management support request (which is free for all subscriptions). Select Issue Type: Subscription Management and request backend feature flag activation for Microsoft.Network/AllowFrontdoor.

Hello Emil Kanneworff,

Thank you for the additional information and for confirming that:

• Microsoft.Network/AllowFrontdoor remains in a Pending state.
• Microsoft.Network and Microsoft.Cdn are already Registered.
• Azure Front Door Standard resources deploy successfully, while creation of a standalone Standard_AzureFrontDoor WAF policy consistently fails during validation with"Policy ArmResourceId has incorrect formatting."

Based on the details shared, the behavior appears to be occurring during the WAF policy validation stage rather than due to any Front Door association, origin configuration, custom rule, or managed rule configuration, especially since the issue reproduces with a minimal standalone policy.

To help investigate further, could you please share:

• The API version used for the Microsoft.Network/FrontDoorWebApplicationFirewallPolicies deployment.
• The deployment correlation ID from the failed operation.
• The deployment operation details/JSON (with any sensitive information removed).
• Whether the deployment was performed through the Azure portal, ARM template, Bicep, Terraform, or Azure CLI.

Additionally, please verify that the generated resource ID follows the expected format:

/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/FrontDoorWebApplicationFirewallPolicies/{policy-name}

These details will help determine whether the validation is being triggered by a deployment payload issue or whether the pending feature registration state is contributing to the behavior. Please share any findings, and we will continue to review the scenario.