Azure Weekly Intelligence #13 — 2–6 November 2026

The week in one paragraph

Networking took the two announcements with the most design consequence, and both landed on material this series covered in the last fortnight: route maps for Azure Route Server went generally available, and Azure Firewall's IPv6 preview picked up application rules. Around them sat an unusually coherent cluster on recovery — Site Recovery for Azure Local, Site Recovery for VMSS Flex, crash-consistent multi-disk restore points, and immutability for SQL point-in-time backups — plus new ransomware recovery guidance for Azure SQL. Two services were put on the retirement list. And the MSRC feed carried zero Azure CVEs in the window, with 25 non-Azure Microsoft advisories filtered out.

Networking: two items that change designs

Route maps for Azure Route Server — generally available

#80 described Azure's BGP as a system you configure rather than one you program: fixed timers, prefix limits, an ASN that is both the default and reserved against you. #83 then used Route Server as one of four NVA high-availability designs, where failover is expressed by advertising a shorter AS path. Route maps are the missing control surface for both, and they are now GA in the public cloud.

What they do is narrow and useful: “Route maps process routing information, not data packets”, applied “in the inbound or outbound direction” on BGP peerings, ExpressRoute and VPN gateway connections, and virtual network connections to peered spokes. Four capabilities: aggregation, filtering, AS path modification and community tagging.

Three constraints are worth reading before planning around them. The first removes a use that looks obvious:

The second is a self-defeating combination. Route summarization is listed first among the reasons to use route maps, and then: “Route summarization strips the BGP community and AS path attributes from summarized routes. This limitation applies to both inbound and outbound routes.” Tagging and path control are two of the other three stated benefits, so summarising a prefix range costs you the ability to tag or path-manipulate it. You can have fewer routes or you can have attributes on them.

The third is a default that runs opposite to the rest of this series' subject matter. #84 opened on Azure Firewall's “denies all traffic until you manually configure rules”. Route maps invert it: “When no rule is matched, the default is to allow, not to deny.” A route map built as an allow list by writing permit rules for the prefixes you want does not filter anything — everything unmatched passes. Filtering requires explicit Drop rules, and “to avoid unintended traffic flows, configure rules to match only the routes you intend.”

Two smaller items that will cost someone an afternoon. Route maps “only support 2-byte ASN numbers”, so a 4-byte ASN estate cannot use AS path actions. And the first one you create is not a configuration change:

“The first time you create a route map on an Azure Route Server, the route server undergoes an upgrade that can take up to 30 minutes.”

Finally, the reserved-identifier list is longer than it first appears. Azure reserves eight ASNs against prepending — public 8074, 8075, 12076 and private 65515, 65517, 65518, 65519, 65520 — and eleven BGP communities you must not remove, for nineteen identifiers in total that a route map has to leave alone. 65515 appears here for the third time in this series: #80 found it is simultaneously Azure's default gateway ASN and reserved against your use, and it is now also on the do-not-prepend list.

One more interaction, documented as a hard failure rather than a warning: “Azure Route Server doesn't support point-to-site configurations on Azure VPN Gateway. If the Azure VPN gateway has a P2S configuration, route map creation on Route Server fails.” #74's subject is therefore mutually exclusive with this one in the same virtual network.

Azure Firewall IPv6 now supports application rules — public preview

#84, published on Thursday, spent most of its length on the DNAT → network → application rule pass order and what application rules can match. This week's announcement fills the IPv6 gap in the middle of that: “Azure Firewall fully supports IPv6 traffic in application rules.” The documentation page carries the change already.

The limitations list is the part that matters, because it does not shrink proportionally:

Read that against #84 and two things follow. Threat intelligence is the control #84 found runs before every configured rule and can block traffic before any rule is processed; IDPS is the Premium engine with over 67,000 signatures. Neither applies to IPv6 traffic. So a dual-stack firewall enforces your rules on both protocols and applies its two signature-based controls to one of them — which means enabling IPv6 on an existing firewall silently narrows the coverage of the Premium features it was licensed for, on the new protocol only.

The second is a direct contradiction of #85's architecture: “Virtual hub (vHub) Firewall isn't supported.” A secured virtual hub cannot do IPv6 firewalling at all. #85 already found that WAF and NVAs must live in a spoke rather than the hub in that architecture; IPv6 is now a third thing the secured hub cannot host.

And there is a familiar shape in the upgrade path:

One detail connects back to #79's SNAT finding with an exception worth knowing: “For all outbound connections… Azure Firewall applies SNAT by using the firewall instance's IP address. If the destination address is within the IANA-defined unique local address (ULA) range (fc00::/7), SNAT isn't applied. This behavior is by design and can't be changed.” So on IPv6, private-range traffic preserves the source address that #79 showed IPv4 traffic loses — and you cannot turn that off either way.

The rest of the networking week

Route summarization in Route Server got its own engineering blog post alongside the GA, which is the same capability from the operator's side. Azure DNS Traffic Manager linked records reached GA — the public preview of that feature appeared in #2 of this series in August, so this is the follow-up rather than a repeat. Front Door added a post-quantum TLS key exchange policy at GA. And Application Gateway for Containers had three previews land on the same day: JWT validation, an MCP gateway, and private ingress.

The week's real theme: recovering from something that already happened

Four of the twenty platform announcements, plus one guidance document, point the same way. Grouped, they read less like a coincidence and more like a push:

The immutability item and the ransomware guidance arriving in the same week is the part to notice. Immutable backups are specifically a ransomware control — they defend against an attacker with valid credentials deleting the restore path before encrypting the data. A preview plus a guidance document is Microsoft telling you the threat model it has in mind, and the crash-consistent multi-disk restore points fit the same picture: a restore that is useless because three disks were captured at three different moments is a recovery plan that fails at the only moment it matters.

Also in the reliability column, though editorial rather than product: an Azure blog post on predicting and detecting failures for mission-critical workloads.

Two retirements

Both were announced on Monday, and both are the kind of item that is easy to miss in a week whose headline was elsewhere.

Security: no Azure CVEs, and three research items worth the time

The MSRC Update Guide returned zero Azure advisories for the window, with 25 non-Azure Microsoft CVEs filtered out. A quiet week on that feed is information and nothing more should be read into it.

The Microsoft Security blog published seven items, three of which are research rather than product news:

• Threat actors use agentic AI tooling to find and abuse exposed secrets — the credential-hygiene problem with a faster adversary attached to it.
• What exploited vulnerabilities have in common: a data-driven analysis of real-world attacks — the useful question for anyone doing patch prioritisation, which is not “what is critical” but “what actually gets used”.
• Email threat landscape: Q3 2026 trends and insights — quarterly data rather than an incident.

Two further items are worth a note for different reasons: new investments to reduce on-premises security risk, and an Azure DevOps advisory on the October 2026 Node.js vulnerabilities with specific guidance for DevOps users — the only item this week that names a patch action for a named platform.

Both of this window's Azure Network Security blog posts — the PHP2Shell and Brotli CVE WAF mitigations — were already covered in #11. Their feed timestamps moved into this window; the posts did not change. They are excluded from the inventory below rather than counted twice.

What I would act on

1. If you run a dual-stack Azure Firewall, check what your Premium features actually cover. Threat intelligence and IDPS do not apply to IPv6 traffic. Enabling IPv6 on an existing Premium firewall extends your rules to the new protocol and does not extend the two signature-based controls you are paying for. That belongs in the risk register, not in a backlog.
2. Do not enable dual stack on a firewall you might want back. Reverting to IPv4-only is unsupported until dual stack reaches GA. Test it on a firewall you are willing to rebuild.
3. If you were planning route maps as a filter, write Drop rules. The unmatched default is allow. A route map containing only permit rules filters nothing, and the failure mode is routes you meant to exclude being advertised normally.
4. Schedule the first route map, do not slot it into a change window. The first one triggers a Route Server upgrade taking up to 30 minutes. Check for a point-to-site configuration on the VPN gateway first — if one exists, creation fails outright.
5. Read the two retirements against your own estate now. Fluid Relay and Defender for IoT's OT security are both the kind of dependency that is one team's whole product and nobody else's problem until the date arrives.
6. Take the immutable-backup preview seriously if you hold regulated data in Azure SQL. It and the ransomware recovery guidance published in the same week are the same thought, and immutability is the control that survives an attacker who has your credentials.

Complete inventory — all 71

Everything the monitored feeds carried for 2–6 November 2026, built by fetch_azure_week.py across 43 sources and reconciled below. The feed audit reported 0 sources 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,028 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 7 November 2026, before the inventory was built.

Official Azure references

• About route maps for Azure Route Server — the GA statement, where route maps can be applied and in which direction, one per direction per connection, outbound maps not influencing best-path selection, the four capabilities, the aggregation example, rule and match-condition semantics with allow as the unmatched default, the match-condition and route-modification tables, summarization stripping community and AS path, the reserved public and private ASNs and the Azure BGP communities, the 2-byte ASN restriction, the default-route and virtual-network-address-space limits, the MSEE and point-to-site exclusions, the 30-minute first-route-map upgrade, and the extra charges
• Deploy Azure Firewall in dual stack mode (preview) — IPv6 preview status, full support for IPv6 in both network and application rules, DNS proxy support, IPv4-only and dual stack modes with IPv6-only unsupported, the unsupported list covering DNAT rules, threat intelligence, IDPS, Explicit Proxy, IP Groups, classic firewall and virtual hub firewall, the unsupported revert to IPv4-only, the fc00::/7 SNAT exception, the upgrade steps, and the zone guidance for new deployments
• How to configure route maps — the configuration steps and route-map restrictions referenced above (no claims drawn from it)
• Apply route maps to an NVA in a spoke virtual network — the worked example for the spoke-NVA case (no claims drawn from it)
• Overview of IPv6 for Azure Virtual Network — the platform IPv6 model the firewall's dual stack mode sits on (no claims drawn from it)
• IPv6 hub-spoke network topology — the reference architecture for dual-stack hub and spoke (no claims drawn from it)