In This Post
- The week in one paragraph
- Standard service endpoint went GA, and it is not what service endpoints were
- The word that changed in the comparison table
- Key management shipped and got patched in the same week
- Thirteen Azure CVEs, and the shape of them
- The rest, briefly
- What I would act on
- Complete inventory — all 7
- Official Azure references
The week in one paragraph
Seven announcements across five working days — down from twenty the week before and thirty-nine the week before that, and the thinnest official channel since this series started. Five generally available, two preview, and for the first time in a month no retirements at all. But the count understates the week, because one of the seven is a networking change that quietly alters a decision most Azure estates have already made, and because Patch Tuesday landed on the 13th carrying thirteen Azure CVEs. The hardware side was busy in a way the updates feed does not capture: OCP Global Summit produced a cluster of infrastructure posts, including a deep dive on Maia 300 silicon.
Standard service endpoint went GA, and it is not what service endpoints were
The item worth reading twice is Generally Available: Standard service endpoint, on 15 October. The documentation now states it plainly: “Standard service endpoint is generally available.”
A classic service endpoint extends your VNet's identity to a PaaS service so the service can allow your subnet. That works and it does not scale: every subnet is its own entry on the service side. The new thing replaces subnet identity with a network identifier, and the definition is the whole feature:
“A standard service endpoint introduces the concept of a network identifier — a public IP address that you associate with service endpoints on your subnets. The public IP address is only used as method of identification of the traffic connecting directly to the virtual network to the service.”
A public IP used purely as a label, not as a path. The payoff is the line after it: “You can assign the same public IP address to all subnets in a region and subscription, which dramatically reduces the number of ACL entries required compared to basic service endpoints. A single network identifier can represent many VNets and subnets.”
Authorisation moves too: the identifier names the traffic and a network security perimeter decides on it, which is how the per-resource ACL disappears. Four services are covered, all “Generally available in all Azure regions” — Storage, Key Vault, SQL Database and Cosmos DB.
Three constraints to know before planning around it. “All service endpoints in a subnet must reference the same network identifier, otherwise the operation fails.” Reuse is narrower than it sounds — “across subscriptions within the same tenant and region… doesn’t support cross-tenant and cross-region sharing”, and “Public IPs must be unique per region and can’t overlap.” And enabling it is not free of impact: “Active flows reset when you add or change a network identifier on an existing service endpoint… Plan this change for maintenance windows when possible.”
The perimeter brings its own ceiling, which is the number to check against your estate before committing: “Up to 200 prefixes and 1,000 PaaS resources per network security perimeter are supported”, alongside “100 network security perimeters per subscription, 200 profiles per network security perimeter”. And it is allow-only: “Network security perimeter only supports allow rules, not deny rules.”
“Review and verify all traffic patterns on network security perimeter before moving resources to enforced mode. Use network security perimeter diagnostic logs to confirm all traffic is approved… Monitor for one to two weeks to ensure all access patterns are covered.”
An allow-only perimeter with nothing to deny into means anything you did not anticipate simply fails once enforcement is on. The monitoring window is the whole safety mechanism.
One documentation inconsistency, flagged because it will mislead anyone who reads the older page first: the service endpoints overview still lists “Standard service endpoint” under its Public Preview heading, while the dedicated page says generally available. The dedicated page is the current one.
The word that changed in the comparison table
Microsoft publishes a three-way comparison, and reading it as a whole is more useful than the GA headline. The row that matters most to anyone choosing today is the last one.
| Capability | Basic service endpoint | Standard service endpoint | Private Link |
|---|---|---|---|
| Private connectivity, no public endpoint exposed | Not supported | Not supported | Supported |
| On-premises connectivity | Not supported | Not supported | Supported |
| Data exfiltration protection | Not supported | Not supported | Supported |
| Scalable solution | Not supported | Supported | Supported |
| Ease of setup | Simple | Simple | Complex |
| Service availability | approximately 10 services | 4 services | 70+ services |
| Pricing | Free | Paid | Paid |
Standard service endpoint fixes exactly one row — scale — and changes the pricing row from free to paid while doing it. The three rows that drive most private-connectivity decisions are unchanged: it still exposes a public endpoint, still cannot be reached from on-premises, and still offers no exfiltration protection. Whatever made Private Link the answer before is still the answer.
So the honest framing is narrow and useful: this is for estates that chose service endpoints, hit the ACL ceiling, and were facing a rewrite to private endpoints they did not otherwise need. It is not a new contender for a greenfield design, where the standing recommendation has not moved — “Microsoft recommends use of Azure Private Link and private endpoints for secure and private access to services hosted on the Azure platform.”
Worth keeping the free option's own numbers in view when comparing: on basic endpoints “There’s no extra charge… There’s no limit on the total number of service endpoints in a virtual network”, and the ceiling people actually hit is elsewhere — “A virtual network can be associated with up to 500 different subscriptions and regions by each supported service with active virtual network rules configured.”
Key management shipped and got patched in the same week
Three of the seven announcements and one of the four Azure blog posts were about key custody, and the same surface appears repeatedly in the week's CVE list. Taken together that is the week's second story.
| Date | Item | Stage |
|---|---|---|
| 16 Oct | External key management for Azure Key Vault Managed HSM | GA |
| 14 Oct | Azure Cloud HSM hardware audit logging | GA |
| 13 Oct | Advancing hardware security with open-source Integrated HSM technology | Blog |
External key management reaching GA on Managed HSM is the one with governance consequences: it is the control that satisfies an auditor who wants the key held somewhere the cloud provider cannot reach. Hardware audit logging on Cloud HSM is the companion — custody is only defensible if use is recorded.
And in the same week, Patch Tuesday carried three separate Key Vault items: an information disclosure vulnerability, a security feature bypass, and an elevation of privilege in the client SDK. Shipping and patching the same surface in one week is not a contradiction, but it does make the point that the SDK version in your build is part of your key-custody posture.
Thirteen Azure CVEs, and the shape of them
Patch Tuesday was 13 October. Thirteen of the month's CVEs name an Azure service, and the distribution is lopsided in a way worth noticing:
| Class | Count | Services named |
|---|---|---|
| Information disclosure | 7 | API Center, HDInsight, DevOps, Active Directory, Key Vault, Attestation (×2) |
| Elevation of privilege | 4 | Arc, Key Vault Client SDK, Storage Library, Defender for Endpoint |
| Security feature bypass | 1 | Key Vault |
| Remote code execution | 1 | CycleCloud |
Seven of thirteen being information disclosure is the detail I would carry into a risk conversation. These are not the headline class, and they are the class that a network control does not help with — which lands squarely on the point this week's architecture post ended on: an IP allow-list is a filter, not an identity, and a service that discloses more than it should to a caller it correctly admitted is unaffected by any NSG rule.
Two of the four are in client libraries rather than services — the Key Vault Client SDK and the Storage Library — which means they are fixed by a dependency bump in your own pipelines, not by Microsoft deploying something. Those are the ones that sit unpatched longest because nothing in the portal reports them.
The security blog ran two pieces the same week, both on infrastructure rather than products: the phishing infrastructure ecosystem and managing open-weight model risk.
The rest, briefly
- Automatic zone balance for Virtual Machine Scale Sets went GA (15 Oct). Scale sets drifting out of even zone distribution after scale operations has been a long-standing manual chore; this is the platform taking it over. Covered the same day on the compute blog.
- Azure Databricks Private network gateway entered preview (16 Oct) — the second networking item of the week, and one to watch rather than adopt.
- Azure Files cross-region data copy and synchronization with Azure Storage Mover entered preview (15 Oct).
- Azure Site Recovery support for Arc-enabled Windows VMware and physical servers went GA (14 Oct) — ASR reaching workloads that were never Azure VMs.
- Azure Container Apps Sandboxes went GA (15 Oct), alongside a three-post push on the Azure SRE Agent.
- Windows Server 2012 and 2012 R2 end of lifecycle (15 Oct) — a date-bearing item for anyone still running those under Arc.
- OCP Global Summit produced five infrastructure posts in three days, on AI-era networking, hardware security, fleet reliability and power, plus an Azure blog deep dive into Maia 300.
- Azure MCP Server 3.0 reached stable (14 Oct), and the infrastructure blog published a threat model for Azure MCP two days later — a useful pairing.
What I would act on
- If you run service endpoints at scale, read the standard service endpoint page this week. It is the only thing in the week that changes an existing decision. The test is narrow: are you hitting per-subnet ACL limits on the service side? If yes, this is your fix and it costs money. If no, nothing changes — and if you were weighing service endpoints against Private Link for a new build, the three unsupported rows mean the answer is unchanged.
- Bump the Key Vault and Storage client libraries. Two of the week's thirteen CVEs are in SDKs. Nothing in the Azure portal will tell you a pipeline is shipping a vulnerable client library; only your dependency manifest knows.
- Check whether external key management on Managed HSM closes an open audit finding. It went GA this week, and for organisations that have been carrying a compensating control over key custody, this is the control they were waiting for.
- Put the Windows Server 2012 end-of-lifecycle date into the migration plan, if Arc is reporting any. The announcement is the warning, not the deadline.
Complete inventory — all 7
Every Azure Updates announcement dated 12 to 16 October 2026, from the Azure Updates archive. Five GA, two preview, no retirements. The archive is queried by date rather than read off the top of a fixed-size feed, so there is no truncation window on this list.
| Date | Announcement | Stage |
|---|---|---|
| 16 Oct | External key management for Azure Key Vault Managed HSM | GA |
| 16 Oct | Azure Databricks Private network gateway | Preview |
| 15 Oct | Standard service endpoint | GA |
| 15 Oct | Automatic zone balance for Virtual Machine Scale Sets | GA |
| 15 Oct | Azure Files cross-region data copy and synchronization with Azure Storage Mover | Preview |
| 14 Oct | Azure Site Recovery support for Azure Arc-enabled Windows VMware and physical servers | GA |
| 14 Oct | Azure Cloud HSM hardware audit logging | GA |
Beyond the official channel, this week's sweep covered twenty sources and returned 62 items in total: 7 Azure Updates, 4 Azure blog posts, 13 Azure CVEs in the MSRC Update Guide, 2 security blog posts, 5 developer-blog posts across SDK, DevOps, Cosmos DB and SQL, 30 Tech Community posts, and one Terraform AzureRM release (v5.10.0).
Three Tech Community feeds returned nothing because they are themselves stale rather than quiet — FastTrack last published 8 June, Defender for Cloud 3 August, ITOps Talk 1 September. Four sources have no machine-readable feed at all and are checked by hand: the AKS blog, Azure VMware Solution, Microsoft Fabric, and the Ignite and Build announcement pages.
Official Azure references
- What is a standard service endpoint? — the GA statement, the network identifier definition, the three-way comparison table, the perimeter limits, and the flow-reset and maintenance-window warnings
- Azure virtual network service endpoints — the Private Link recommendation, the free-and-unlimited basic endpoint terms, the 500-subscription association limit, and the source-address switch that breaks existing firewall rules
- What is a network security perimeter? — the authorisation half of a standard service endpoint (no claims drawn from it)
- Azure Key Vault Managed HSM overview — context for the external key management GA (no claims drawn from it)
Comments