The endpoint that did not reduce the blast radius
A storage account sits behind a private endpoint. No public route reaches it — the storage firewall is set to deny all public traffic. The network team has done exactly what was asked. Then an attacker who has compromised a service principal issues a server-side copy operation: az storage blob copy start, pointing to an attacker-controlled storage account in a separate tenant as the destination.
The source credential is valid, scoped to the storage account, and belongs to a service principal that was over-provisioned eighteen months ago. No AllowedCopyScope restriction is in place. The private endpoint carried the initiation of every copy request. Nothing was broken. Nothing was misconfigured at the network layer.
This is the core problem with treating private endpoints as a complete security control rather than a routing decision. The endpoint changes where traffic flows. It does not change whether the credential presenting that traffic has the right to do what it is doing, nor does it constrain where data can be sent once a permitted operation begins.
A private endpoint alone does not constrain authorization. That narrower claim is the one this article defends.
What object is actually created (Azure)
This article uses Azure Private Endpoints throughout. The same conceptual gap — private path, unrestricted authorization — exists in AWS, but the mechanics differ enough that mixing the two produces misleading guidance.
When an Azure private endpoint is provisioned, a network interface is created in the consumer's subnet and assigned an address from that subnet's range. That interface gives the Azure service a presence inside the consumer's virtual network, reachable over private routing without traversing the public internet. A private DNS zone — for example, privatelink.blob.core.windows.net — is linked to the virtual network so the service's standard hostname resolves to the private interface address rather than the public one.
At the routing level, Azure injects a /32 host route for the private endpoint's IP address directly into the subnet route table. This route takes precedence over any broader prefix, including a default route pointing to a network virtual appliance or Azure Firewall. The consequence is significant: traffic destined for the private endpoint bypasses your hub firewall entirely unless you account for this behavior explicitly. Architectures that rely on a hub firewall to inspect east-west traffic need UDRs that redirect endpoint-destined traffic back through the inspection path, or they need endpoint-adjacent controls — NSGs, resource policies — to compensate for what the firewall cannot see.
The private endpoint creates a network interface your tooling can observe. It does not represent a separate authorization boundary. The connection from a workload reaches the endpoint over a private path, but what the caller is permitted to do once connected is governed entirely by the identity and resource policies on both sides.
Endpoint-adjacent controls Azure provides
Before examining what the endpoint leaves unchanged, it is worth naming the controls Azure does provide that work alongside private endpoints. These are frequently omitted from deployment checklists, which is how the authorization gap opens.
Network-conditioned resource policies. The storage account firewall can be set to deny all public traffic and permit only traffic originating from specific virtual networks or private endpoint connections. This is the step that makes the endpoint a constraint rather than an additive path. Until public network access is disabled at the resource, the endpoint is optional routing — the public path remains open.
Shared key disablement. Azure Storage accounts accept both Azure AD-based authentication and shared key (storage account key) authentication by default. A private endpoint does nothing to change this. An attacker with a storage account key can reach the account through whatever path is available, authenticate without going through Azure AD, and bypass conditional access policies entirely. Disabling shared key access at the account level forces all callers through Azure AD and makes identity-based controls meaningful.
AllowedCopyScope. The AllowedCopyScope property on a storage account restricts where server-side copy operations can send data. Setting it to AAD limits destinations to storage accounts within the same Azure AD tenant. Setting it to PrivateLink limits destinations further to accounts reachable over private endpoints. Without this restriction, a service principal with read access to a storage account can initiate a server-side copy to any destination the Azure service can reach — including attacker-controlled accounts in foreign tenants. The private endpoint is not the enforcement point for destination validation; AllowedCopyScope is.
Cross-tenant replication controls. Azure Storage's object replication and blob copy features can move data across tenants by design. At the subscription or management group level, Azure Policy can deny storage configurations that permit cross-tenant replication. This is a preventive control that applies regardless of whether endpoints are in use.
Conditional access for workload identities. Azure AD conditional access can be applied to workload identities (service principals and managed identities) to require that authentication occur from specific networks or meet other conditions. This is a relatively recent capability and not universally deployed, but it is the mechanism that makes the private endpoint's network boundary relevant to identity policy — the credential is only valid when used from inside the defined network.
What changes about reachability
Placing a storage account behind a private endpoint and disabling public network access removes it from internet-routable address space. A scanner querying public IP ranges will not find the service. Credential-stuffing attacks against a public service endpoint and unauthenticated exploitation of a public interface become impossible. For services that previously required broad IP allowlisting to support remote access, an endpoint replaces that allowlist with a network-layer constraint that is simpler to audit.
DNS behavior changes in a specific way that practitioners should verify explicitly, and the verification is more involved than a single command.
When private DNS integration is enabled, the service's standard hostname — for example, mystorageaccount.blob.core.windows.net — should resolve to the private endpoint's assigned IP address inside the configured network. The CNAME chain should pass through the privatelink.blob.core.windows.net zone rather than resolving directly to a Microsoft public IP. The two-part verification test:
First, resolve the hostname from a workload inside the virtual network and confirm the returned address matches the IP assigned to the private endpoint's network interface — not a public address block. Second, inspect the CNAME chain (using dig or Resolve-DnsName with the full chain visible) and confirm that resolution passes through the privatelink zone. If it does not, the private DNS zone is not linked correctly and some workloads may resolve to the public IP.
The hybrid DNS problem. In environments where on-premises clients need to reach the private endpoint, on-premises DNS resolvers cannot query the Azure private DNS zone directly. An on-premises client that sends a resolution request to its local DNS server will receive the public IP for the storage account unless the architecture explicitly routes those queries to Azure.
The standard resolution: deploy Azure DNS Private Resolver with an inbound endpoint in the virtual network and configure on-premises DNS forwarders to forward privatelink.blob.core.windows.net queries to the inbound resolver's IP. Without this, on-premises workloads resolve to the public IP and, if public network access is disabled at the resource, fail to connect — or, if public access was never fully disabled, connect over the public path, defeating the purpose of the endpoint.
What does not change
This is where the endpoint's limits are sharpest.
A stolen credential's validity is unchanged. A credential with read access to a blob container still has read access after the endpoint is created. The network path is now private; the credential still traverses that path successfully. Endpoint provisioning does not rotate secrets, does not expire tokens, and does not narrow the scope of IAM policies attached to the resource.
Over-broad role assignments are unchanged. A service principal granted Storage Blob Data Contributor six months ago retains that role. The endpoint did not trigger a review. In environments where access reviews are infrequent or skipped when other controls are added, the private endpoint can create a false sense of containment that delays that review further.
Data transfer to a permitted destination is unchanged. An identity with write access to a destination storage account can receive data from a server-side copy initiated at the source. Without AllowedCopyScope set, the destination can be in any tenant. The endpoint is not the enforcement point for destination validation.
Audit logging must be configured separately. The private endpoint does not automatically enable or forward logs. Data-plane logging — read, write, delete, and copy operations — is configured at the resource level, in Azure Monitor diagnostic settings or via CloudTrail equivalents in other platforms, not at the endpoint. An endpoint that carries exfiltration traffic without data-plane logging enabled produces no forensic record of the operation. Enable logging before the endpoint is considered live; adding it after an incident closes a gap that should never have been open.
Lateral movement within the network is not addressed by private access. Network segmentation controls relevant to the endpoint's network interface — NSG rules, subnet isolation — belong to a separate analysis of east-west traffic control.
| Property | Changed by a private endpoint | Unchanged | Control that covers the gap |
|---|---|---|---|
| Internet reachability of the service path | Removed when public access is also disabled at the resource | — | Disable public network access at the resource after endpoint validation |
| Firewall inspection of endpoint traffic | /32 route bypasses hub firewall by default | Inspection path unless UDRs redirect traffic through firewall | UDRs to force endpoint traffic through inspection, or NSGs and resource policies at the endpoint |
| DNS resolution path | Resolves to private interface address when private DNS is configured correctly | On-premises resolution without DNS forwarding to Azure resolver | Private DNS zone linked to VNet; DNS Private Resolver with inbound endpoint for hybrid scenarios |
| Credential validity and scope | Not changed | Role assignments remain as-is | Azure AD access reviews on a cadence tied to risk; least-privilege scoping |
| Server-side copy destination | Not changed | Copy operations can target foreign-tenant accounts | Set AllowedCopyScope to AAD or PrivateLink |
| Shared key authentication | Not changed | Storage account keys remain valid | Disable shared key access to force Azure AD authentication |
| Cross-tenant replication | Not changed | Replication policies can target external tenants | Azure Policy deny assignment at management group level |
| Data-plane audit logging | Not changed | Log configuration at the resource level | Enable diagnostic settings for data-plane events before endpoint goes live |
When private access is the right control
Private endpoints reduce a specific, real risk: exposure of a service path to the public internet. That reduction is worth implementing when workloads that consume the service operate inside a defined network boundary, when private DNS can be enforced reliably across all resolution paths including hybrid, and when the endpoint is paired with the resource-level and identity-level controls that cover what it does not address.
The decision criterion is whether your threat model includes opportunistic internet-facing exploitation of the service endpoint. If the service previously required public access and its consumers are now fully inside a controlled network, an endpoint removes a genuine exposure. If the primary risk is a compromised internal identity, an over-privileged service principal, or a misconfigured copy-scope setting, the endpoint does not reduce that risk.
Four controls should accompany every Azure private endpoint deployment, ordered by impact:
Disable public network access at the resource. This is the single step that makes the endpoint meaningful as a security control rather than an additive path. Until public access is disabled, the endpoint is optional routing, not a constraint. Verify by attempting to reach the service from outside the configured network after disabling public access and confirming the connection fails.
Disable shared key access. Forcing all authentication through Azure AD makes identity-based controls — role assignments, conditional access, access reviews — apply uniformly. A storage account that still accepts shared key authentication is partially outside the identity control plane regardless of its network configuration.
Set AllowedCopyScope before the resource is used in production. Cross-tenant server-side copy is an exfiltration path that exists independently of network controls. Setting AllowedCopyScope to AAD closes it for the majority of threat scenarios; PrivateLink closes it further if your architecture supports it.
Enable resource-level diagnostic logging before the endpoint goes live. Configure data-plane logging — read, write, delete, and copy operations — at the resource. Confirm logs are flowing to a destination your security operations team can query. An endpoint deployed without logging leaves a visibility gap that persists until logging is added later, possibly after an incident.
Review and scope role assignments on the resource before treating the endpoint as a compensating control. The endpoint does not change the blast radius of an over-privileged identity. Identify which principals hold write or admin roles, remove grants that lack a current business justification, and document approved access. The review should happen before the endpoint is considered sufficient, not after.
A private endpoint is most effective when it is one layer in a stack that includes current role assignments, disabled public access, disabled shared key authentication, constrained copy scope, and enabled logging — not when it substitutes for any of those. The reachability problem it solves is real. The authorization problem it does not solve remains exactly as it was before the endpoint existed.
