Azure Weekly Intelligence #8 - 28 September-2 October 2026

The week in one paragraph

Thirty-nine announcements across five working days, and the shape of them is unusual: eight were retirements and nineteen were SQL-family. The SQL concentration has a mundane explanation — SQLCon and FabCon Europe ran this week, and Microsoft shipped the keynote list on the Tuesday. The retirement cluster does not. Four of the eight are VM series, they arrived two days after a blog post announcing a new VM lifecycle policy, and the interesting part is not the retirements at all: it is that the policy they belong to has a capacity-restriction half that took effect in July and was never announced this loudly. If you run v1-to-v3 VMs, something already changed for you three months ago.

The retirement wave is the visible half of something that started in July

The week’s announcements were the stage names. Microsoft now sorts every VM size series into four lifecycle stages — “Current, Extended, End of Life, and Retired” — and for general purpose sizes the mapping is concrete: “v6 and v7 series are Current, v4 and v5 series are Extended, and v1 through v3 series with an announced retirement are End of Life.” Both of the first two count as modern: “Current and Extended sizes are both considered modern sizes because they're fully supported.”

The retirement dates themselves are generous. Dv3, Dsv3, Ev3 and Esv3 retire on November 15, 2029 — three years of notice, covering “all 32 sizes in these series”, and explicitly not applying to “Azure Government, Azure operated by 21Vianet, or sovereign cloud regions.” DCsv3 and DCdsv3 go on 10/31/29. On the face of it, nothing to do this quarter.

Except the documentation separates two things the announcements blur together, and says so twice:

So the thing that affects a running estate this quarter is not the 2029 date. It is the quota behaviour that started in July, and it is sharper than “restrictions” suggests:

The affected list is not short. It covers D, Ds, Dv2, Dsv2, Dv3, Dsv3, B, Bs, Av2, Amv2 in general purpose, F, Fs, Fsv2 in compute optimized, Ev3, Esv3, G, Gs in memory optimized, and Ls, Lsv2 in storage optimized. That is a large fraction of what long-running estates actually run.

Two clarifications in the FAQ are worth having in front of you before a capacity conversation. First, the restrictions “don't affect existing running VMs” — this is about growth, not about what is already deployed. Second, and this is the sentence to quote at anyone who thinks quota is protection: “Quota is an approved limit; it isn't a capacity reservation or guarantee.”

One more, for anyone running these series in scale sets and worried about the word “deallocated”: reimaging is safe. “Reimaging replaces the OS disk… It doesn't remove the VM or change its VM series.”

The part that is a financial deadline, not a technical one

Buried in the reserved-instance FAQ is the only date this week that falls inside the next sixteen months, and it is about money rather than compute:

“RI exchanges are available until February 1, 2027. After that date, each eligible active reservation purchased before the deadline retains one final exchange.”

That matters because reservations do not follow you when you modernise: “RIs don't automatically transfer when you modernize to a different VM series… If you don't make an update, the RI might no longer apply, which could result in additional costs.” And for the affected generations the exit is one-way — “new or renewed one-year and three-year RIs are no longer available” for the A, B, D, E, F and L variants of v1 through v3, and they “can't be renewed or repurchased after expiration”, at which point “usage moves to pay-as-you-go rates.”

The accompanying correction to a widespread assumption: “Purchasing an RI doesn't reserve capacity or protect against capacity growth restrictions.” If you need capacity assurance the answer is an on-demand capacity reservation — “RIs provide billing discounts, while ODCRs reserve capacity for a specific VM size, region, and zone.”

Every date this week put on the calendar

Eight retirement notices, and they span three years. Sorted by how soon they bite:

The first row is the one worth a second look. NVv3 and NVv4 were announced for retirement on 04/15/25 with a planned date of September 30, 2026 — and the retirement notices appeared in the update feed on 30 September 2026, the day itself. If you still had NVv3 or NVv4 running this week, the feed was not your warning.

An intrusion that began at the self-service password reset page

Microsoft published five threat-intelligence posts this week. One of them is a direct footnote to #50, which argued two days ago that SSPR is the wrong recovery path for privileged accounts. Storm-3068 used it as the front door.

“Storm-3068 gaining access to a user account through a self-service password reset process and then taking full control of the identity by registering its own authentication methods.”

That is the complete pattern this series has been building toward, executed in order: reset the password through a self-service flow, then enrol your own MFA method so the account is yours rather than merely accessible. #43 covered why method registration is the real control surface; this is what it looks like when nobody is watching it.

What followed was a CI/CD escalation rather than a cloud-console one. The actor “deployed the pipeline that was authorized to access more than 50 resources and authenticated to services”, then “deployed a kube agent and executed multiple jobs intended to collect kubeconfig files containing cluster connection details and authentication information.” The exfiltration method is almost comically direct: the actor “added seven stolen kubeconfig files to a repository.” Persistence came from off-the-shelf tooling — “the Atera remote management agent” and “the Chisel tunneling utility.”

Microsoft’s two headline recommendations read like a summary of this phase of the series: “strengthening protection for privileged accounts by limiting exposure to self-service password reset workflows and requiring phishing-resistant multifactor authentication”, and “controlling pipeline permissions and limiting who can create, modify, or execute build and deployment pipelines.”

Separately, the 2026 Microsoft Digital Defense Report landed on 1 October. The blog summary is thin on figures, but the one it does give is a significant shift: “government agencies and services were the sector most impacted by cyber threats in 2026, accounting for 27% of observed activity, up from 17% in 2025.” A ten-point move in one year, in one sector.

The rest, briefly

• Nineteen SQL-family announcements, which is SQLCon/FabCon Europe rather than a strategy shift. The substantive ones: vector search and vector indexes GA in Azure SQL, DiskANN vector index GA, Hyperscale Serverless auto-pause and auto-resume in preview, local time zone support in preview, and a Database Hub in Fabric that now covers Azure SQL and PostgreSQL estates.
• PostgreSQL got four: major version upgrades for elastic clusters, cross-tenant customer-managed keys, Ultra Disk, and long-term retention v2. Cross-tenant CMK is the one with architectural consequences — it changes where a key can live relative to the data.
• Entra Kerberos authentication for Azure NetApp Files entered preview, which is the same mechanism #51 is about, pointed at a file service.
• Passkeys from external identity providers can now sign in to Microsoft apps — the federated-passkey case #44 left open.
• Network security perimeter metrics reached GA in public cloud.
• Automatic Zone Placement for Virtual Machine Scale Sets in preview, and regional resiliency for Azure Virtual Desktop GA — two availability features in the same week.
• Intel TDX confidential VMs reached GA, in the same week DCsv3 and DCdsv3 — an older confidential generation — were announced for retirement.
• Lasv5 and Laosv5 storage-optimised VMs GA on 5th Gen AMD EPYC, which is a Current-stage landing spot while the v3 series wind down.
• Fifteen Microsoft Foundry posts, including GPT-6.1 Sol and Claude Sonnet 5.5 becoming available. Volume rather than news.
• Luxembourg Azure Extended Zones GA, and Ubuntu 26.04 support in AKS in preview.

One note on sources, in the interest of not overclaiming completeness: four of the forty-plus feeds this roundup reads are stale — the Identity devblog (nothing since 29 April), Tech Community Network Security (13 July), FastTrack (8 June) and Defender for Cloud (3 August). None is the backbone. The Azure Updates archive is queried by date range rather than sliced from a capped feed, so the 39-item inventory below is not subject to a truncation window.

What I would act on

1. Inventory your v1-to-v3 VM series this week, not in 2029. The retirement is far off; the quota freeze is not. If any part of your growth plan assumes you can request more Dv3, Dsv3, Ev3, Esv3, Fsv2, Lsv2 or B-series quota, that assumption expired in July.
2. Put 1 February 2027 in the finance calendar. Review the reservation portfolio before then and decide which exchanges to use. After that date each reservation has exactly one exchange left, and modernising without exchanging silently moves usage to pay-as-you-go.
3. Check whether anything you believed was capacity assurance is actually a reservation. If an RI was the plan for DR or failover capacity on an affected series, it was never the right instrument; an ODCR is.
4. Audit who can reset a privileged account’s password, and who can register an authentication method on it. Storm-3068 is the second intrusion in two weeks that began with an identity-recovery flow rather than an exploit.
5. Audit pipeline permissions as identity surface. A pipeline authorised to more than 50 resources is a privileged identity whether or not anybody filed it as one.
6. If you had NVv3 or NVv4 running, check it now. Their retirement date was 30 September.

Complete inventory — all 39

Every Azure Updates announcement dated 28 September to 2 October 2026, from the Azure Updates archive. Eight retirements, nineteen SQL-family, four PostgreSQL, and eight everything else.

Counts reconcile: 1 on 2 October, 1 on 1 October, 6 on 30 September, 27 on 29 September, 4 on 28 September — 39 in total.

Official Azure references

• VM lifecycle overview — the four stages, which generations sit in each, and why a capacity restriction is not a retirement
• VM size series retirements and capacity growth restrictions — the retirement tables, the quota outcomes, and the reserved-instance deadlines
• Beyond source code: A path to the keys to the kingdom — Storm-3068, from a self-service password reset to seven stolen kubeconfig files
• Insights from the 2026 Microsoft Digital Defense Report — the sector shift, and the entry point to the full report
• Enhancing Microsoft Azure Virtual Machine lifecycle — the announcement post that opened the week (no claims drawn from it; the figures above come from Microsoft Learn)