Azure Weekly Intelligence #14 — 9–13 November 2026

The week in one paragraph

Azure Front Door had the week: mutual TLS reached general availability, edge actions reached general availability, and gRPC support, JWT validation through Auth Policy and rate limit grouping for the Premium WAF all entered public preview — five of the thirteen Azure Updates entries in the window, from one service. Azure Route Server dual-stack IPv4/IPv6 went to public preview, which matters to anyone running a network virtual appliance hub, and comes with a documentation state worth knowing about before you plan around it. Patch Tuesday landed on 10 November and brought twenty distinct Azure CVEs, with Azure CycleCloud alone accounting for four of them — a sharp contrast with the previous window, which carried none at all. Beyond that the week was Ignite 2026 prologue: a large share of the Tech Community output was session guides and partner announcements rather than shipped capability. Two retirements were posted, one of them with a deadline that had already passed by the time the notice appeared in the feed.

Route Server gets IPv6, and the FAQ has not heard

The announcement is Public Preview: Azure Route Server dual-stack IPv4/IPv6 support, dated 10 November. The tutorial that backs it is explicit: “Azure Route Server IPv4/IPv6 dual-stack mode is in preview”, available in eleven regions, two of which are EUAP canary regions.

The reason to read this one carefully rather than filing it under “IPv6 catch-up” is that the Route Server FAQ, last updated on 3 November, still answers the question directly and in the negative.

Both are probably accurate for what they describe — the FAQ for a Route Server outside the preview, the tutorial for one inside it — but nothing on either page says so, and the FAQ's answer is the one a search engine returns. If you are citing Route Server IPv6 support in a design document this fortnight, cite the region list and the preview note, not the FAQ.

What the preview actually requires

The design detail with the longest reach is that last row of mechanics: IPv6 routes ride multiprotocol BGP over the IPv4 sessions — “the address-family ipv6 unicast block activates IPv6 on the same IPv4 neighbors” — and no separate IPv6 peer is created. So the appliance needs MP-BGP, not a second session, and the Route Server limits are unchanged by the second address family: 16 BGP peers, 4,000 routes per peer, 500 virtual networks, 10,000 prefixes.

Those numbers have an edge to them that is easy to miss. A single peer may advertise 4,000 routes and there are 16 peers, so one deployment can be offered 64,000 routes — but the ceiling towards an ExpressRoute circuit with branch-to-branch enabled is 1,000, four times less than one peer alone may send. Dual-stack does not change that arithmetic; it gives you a second address family to spend it on.

Worth remembering alongside it: “Azure Route Server system routes for traffic related to virtual network, virtual network peerings, or virtual network service endpoints, are preferred routes, even if BGP routes are more specific”. The appliance does not win against a service endpoint route by advertising a longer prefix, in either address family.

Front Door took five of thirteen

Thirteen Azure Updates entries landed in the window and five of them were Front Door: mutual TLS generally available, edge actions generally available, and native gRPC, JWT validation with Auth Policy and WAF rate limit grouping in public preview. Two of them change how an edge is secured rather than what it can serve.

Mutual TLS, now generally available on Premium

“Mutual TLS (mTLS) authentication, also known as client certificate authentication, is generally available in Azure Front Door Premium”, validating certificates at the edge before a request reaches an origin. Four modes, and the gap between them is larger than the names suggest.

Three of those four leave real validation work at the origin, so “mTLS is enabled” is not a statement about security posture until you know which mode. The operational constraints are where this gets expensive to retrofit:

• No caching. “When you enable mTLS, you can't enable caching on routes or rules engine route overrides with caching” — deliberately, to stop cached content reaching unauthenticated clients. A CDN that cannot cache is a reverse proxy.
• Endpoint-level gating comes first. mTLS must be enabled on the endpoint before the custom domain, and “you can't associate domains with mixed state of mutual authentication to the same endpoint”. So the unit of migration is an endpoint, not a domain.
• Downtime in both directions. Turning it on for an existing domain requires disassociating and reassociating the domain; turning it off does too. The documented advice is to enable it on new domains and new endpoints.
• Certificate plumbing. A root CA alone, or a root plus up to three intermediates, PEM-encoded and under 25 KB, with no auto-rotation and two certificates attachable for rollover. A client chain of more than five certificates including the leaf is rejected outright as ClientCertTooLongChain.

And one item that is a calendar problem rather than a configuration one: Front Door checks Extended Key Usage, “due to industry changes, public certificate authorities (CAs) soon stop issuing client authentication certificates with the required EKU”, and the documented remedy is to move to a private CA. Anyone planning mTLS on Front Door with publicly issued client certificates is planning around a supply that is being withdrawn.

Rate limit grouping: the preview that changes what a threshold means

This is the item I would read first. Until now a Front Door WAF rate limit rule counted per socket IP address. The preview adds four more groupings — country/region, AS number, JA4 client fingerprint, and None, which counts every matching request together — on Premium only, with socket IP remaining the generally available default.

The motivation is stated without euphemism: a per-IP limit “is less effective against distributed attacks, in which a botnet spreads its traffic across thousands of IP addresses so that each one stays under the threshold”. Grouping by JA4 fingerprint counts clients that negotiate TLS the same way as one, regardless of address.

That was always true of per-IP rules and barely mattered, because one client's traffic usually lands at one edge. It matters enormously for a grouping, because a country, an ASN or a popular browser fingerprint arrives everywhere at once. A threshold set from total application traffic “might never be reached at any one edge location” — the rule exists, passes review, and never fires.

The documentation does the honest thing and supplies the sizing method rather than a recommended number: a Log Analytics query over FrontDoorAccessLog for the last 7 days, binned at five minutes, grouped by pop_s so the count matches how the limit is enforced, reporting peak and 99th percentile per fingerprint. Measure for at least a week so daily and weekly peaks are represented.

The fourth column is the risk, and the documentation names it: “A breach affects every client in the group… legitimate users who share that country/region, network, or client software are limited along with the attack traffic”, with the aggravating detail that “popular browsers present the same JA4 fingerprint for very large numbers of users”. Which is why the two pieces of guidance that come with it are deploy with the Log action first, and keep a per-IP rule alongside rather than instead — “a client can change its TLS fingerprint, while IP addresses remain the most expensive attribute for an attacker to change”.

One number worth carrying out of it: the documented JA4 example allows 500 requests per five-minute window, an average of 100 a minute, and sits below the threshold at which the documentation warns enforcement stops being precise — “for a low threshold (for example, less than about 200 requests per minute), you might see some requests above the threshold get through”. So the example is deliberately in the approximate zone, because for a grouped rule the alternative is a threshold nothing ever reaches.

Patch Tuesday: twenty Azure CVEs

The MSRC feed carried 21 Azure-tagged entries in the window, all dated 10 November, covering 20 distinct CVEs — one was listed twice. The previous window carried none, so this is the whole month's Azure exposure arriving on one day rather than a change in rate.

The shape is worth a second look. Two of the three remote code execution entries are in the build pipeline rather than in a running workload — Azure DevOps Server and Azure Pipelines — and the third is in the Azure CLI, which is to say in the thing your pipeline runs. For most estates the CLI entry is the one with the widest blast radius, because the CLI is installed on build agents, jump boxes and laptops, and none of those are patched by the platform.

Four separate CycleCloud entries in one release is unusual enough to note. Microsoft Security's own research output for the week also leaned on the agent supply chain: Trained to betray: How post-training supply chain attacks hijack coding agents, and Detecting sleeper agents hiding in AI model neurons.

Retirements and one deadline already past

Three years of notice for Azure Data Share. One day for .NET 8 and .NET 9 on Static Web Apps — the notice appeared in the feed on 9 November for a deadline of 10 November, which is a reminder rather than an announcement, and only useful to anyone who had already been told. If you run Static Web Apps on either runtime, that date is behind you.

What I would act on

1. Patch the Azure CLI everywhere it is installed, not just where it is managed. CVE-2026-109457 is remote code execution in the CLI, and the CLI lives on build agents, admin workstations and container images that no platform update reaches. The two DevOps Server remote code execution entries point the same direction: this month's Azure exposure is concentrated in the toolchain rather than the workload.
2. If you have a Front Door WAF rate limit rule, re-read its threshold against the per-edge-location rule. This applies before you adopt anything new: counts have always been kept per edge location, and the preview makes it consequential. Run the documented Log Analytics query — 7 days, five-minute bins, grouped by pop_s — and compare the 99th percentile at a single edge with the number in your rule. A threshold sized from total traffic is a rule that does not fire.
3. Treat Front Door mTLS as an endpoint-level migration, not a domain setting. Caching cannot be enabled with it, domains of mixed mTLS state cannot share an endpoint, and both enabling and disabling it on an existing domain cause downtime. The documented path is new endpoints and new domains. Decide that before the certificate work starts, not after.
4. Check whether your mTLS plan depends on publicly issued client certificates. Front Door enforces an Extended Key Usage check, and public CAs are documented as about to stop issuing client authentication certificates carrying it. The recommended answer is a private CA, which is a PKI project rather than a configuration change.
5. Do not enable Route Server dual-stack mode on anything you care about yet. It is preview, in eleven regions, two of them canary; the switch is irreversible and takes up to 40 minutes; and the FAQ still answers “no” to the question of IPv6 support. Build it in a new Route Server in a test subscription, confirm your appliance does MP-BGP over an IPv4 session, and keep the production hub IPv4-only until the two pages agree.

Complete inventory — all 88

Everything the monitored feeds carried for 9–13 November 2026, built by fetch_azure_week.py across 43 sources and reconciled below. The feed audit reported 1 source broken or empty; three feeds are known-stale and reported as such, and four have no feed and are checked by hand.

How the count reconciles

The Azure Updates backbone is a queried archive holding 10,040 records rather than a sliced feed, so there is no truncation window on the primary source and no risk that an in-range item aged out unseen.

Feed health

Reported by fetch_azure_week.py --audit on 14 November 2026, before the inventory was built.

One thing the five cross-week exclusions make visible: a Tech Community entry's feed timestamp is a last-modified date, not a publication date. Five posts already covered in earlier roundups reappeared with dates inside this window, one of them from August. Deduplicating by URL rather than by title and date is what keeps an inventory from counting the same post twice across two Saturdays.

Official Azure references

• Tutorial: configure dual-stack Azure Route Server with PowerShell — the preview statement, the eleven-region availability list, the irreversible 40-minute switch, the dual-stack RouteServerSubnet requirement, the Az.Network version and preview-access prerequisites, the Standard IPv4 public IP, and MP-BGP for IPv6 over the IPv4 sessions
• Azure Route Server FAQ — the standing “no IPv6” answer and the peered dual-stack behaviour, the per-deployment limits, the 4,000-route calculation and session teardown, the 1,000-route ExpressRoute ceiling with branch-to-branch, routing infrastructure units, the keepalive and hold timers, the create/delete downtime, the reserved ASNs and 65515 loop prevention, and the RouteServerSubnet UDR and NSG restrictions
• Mutual TLS authentication for Azure Front Door — the Premium GA statement, the four validation modes, the SAN/CN allowlist and wildcard behaviour, OCSP-only revocation and the 403 response, the CA configuration quota and the five-certificate chain limit, the EKU withdrawal warning, the caching and endpoint-association restrictions, the downtime in both directions, and the dropped client-supplied headers
• WAF rate limiting for Azure Front Door — the preview groupings and their API values, the per-edge-location counting and the 1,000-to-3,000 worked example, the one- and five-minute windows, the documented JA4 and sign-in examples, the sub-200-requests-per-minute accuracy caveat, the fixed-window blocking behaviour, the sizing query, and the considerations for grouped limits
• Enable dual-stack mode on an existing Azure Route Server — the upgrade path for an IPv4-only deployment (no claims drawn from it)
• Client fingerprint matching for Azure Front Door — what a JA4 fingerprint is and how it is matched (no claims drawn from it)
• Secure traffic to Azure Front Door origins — the origin access control that stops mTLS being bypassed (no claims drawn from it)