Private Endpoint Sprawl and Shadow Access: When Private Starts Meaning Unseen

Thu, 18 Jun 2026 00:00:00 +1000

Private Endpoints often arrive with the sort of confidence that makes people stop asking second-order questions.

The first one is usually deliberate. A shared service needs to be consumed privately, the path is approved, DNS is wired up, and everyone feels like exposure has been reduced. Then another team needs access from a different virtual network. Then another environment gets its own endpoint. Then a migration leaves the old one behind. A year later, the architecture still looks private, but it is no longer especially clear.

That is the problem this post is really about.

Private Endpoint sprawl is not just untidy networking. It is the slow expansion of internal reachability to services that many teams still think of as tightly contained. The risk is not that Private Endpoints magically bypass identity or authorisation. The risk is that more internal footholds now inherit viable paths to high-value services, and defenders lose confidence that the approved path is the only path that matters.

That changes something you design, deploy, and operate. If a new Private Endpoint is treated as routine plumbing rather than as a new internal exposure point, your architecture can accumulate shadow access long before anyone notices.

The Mental Model

The common assumption goes something like this:

If a service is only reachable through Private Endpoints, exposure is reduced and control has improved.

That is true only while the private access paths remain deliberate, bounded, and visible.

What breaks the mental model is scale.

A Private Endpoint is not just a safer service setting. It is a new network presence for a platform service inside a virtual network you control imperfectly, with DNS and routing dependencies you may not fully own, and with trust implications that extend beyond the service team.

One endpoint is a design choice.

Several endpoints to the same service across different networks is no longer just connectivity. It is topology. And once those endpoints span different trust zones or administrative boundaries, it becomes security-relevant sprawl.

That is the shift worth holding onto:

Private Endpoint sprawl does not weaken identity controls by itself. It weakens your certainty about where sensitive services are reachable from after a compromise.

How It Really Works

Sprawl is rarely the result of one bad design meeting. It is usually the accumulation of locally reasonable decisions.

Teams create endpoints close to workloads

A workload team needs private access to a Key Vault, Storage Account, SQL Database, or Cosmos DB account owned elsewhere. Rather than consuming an already understood path or challenging the design, they create a new Private Endpoint in their own virtual network.

Technically, that may be fine.

Architecturally, the same shared service now has another private network presence in another part of the estate. That means another trust zone can originate traffic to it, another DNS context can resolve it privately, and another team now influences the effective exposure of the target service.

Service ownership and access-path ownership diverge

This is where the architecture starts to lie to you.

The service owner may still control the Key Vault or Storage Account itself, but they often do not control every network from which private access now exists. A sensitive service can look tightly governed from the resource perspective while being privately reachable from networks the service owner neither administers nor reviews regularly.

At that point, the exposure boundary is no longer defined only by the service configuration. It is also defined by every approved Private Endpoint connection and every network that hosts one.

DNS makes duplication easier to ignore

Private DNS does exactly what it is supposed to do: it makes the service name resolve in the right place without the application caring too much.

Operationally, that convenience can hide architectural drift.

Consumers continue to use the same name. Connections still work. The duplication disappears behind name resolution. Over time, the platform may end up with several private access paths to the same service across linked zones and virtual networks, but very few people can say with confidence where that service resolves privately and where it does not.

Old access paths tend to survive

Private Endpoints are easy to create and oddly persistent.

Migration endpoint? Left behind. Temporary analytics integration? Still there. Retired workload in a linked subscription? Endpoint survives. Replacement endpoint after a redesign? Old one never cleaned up.

This is where shadow access starts to matter. The network path still exists, the name may still resolve, and the target service is still privately reachable from a place that is no longer part of anyone’s active design intent.

A Simple View of Sprawl

flowchart LR subgraph SharedService["Shared Service Subscription"] KV["Key Vault"] SA["Storage Account"] end subgraph Prod["Prod Trust Zone"] PE1["PE to Key Vault"] PE2["PE to Storage"] App1["Prod App"] end subgraph Dev["Lower-Assurance Dev Zone"] PE3["PE to Key Vault"] App2["Dev App"] end subgraph Analytics["Separately Administered Analytics Zone"] PE4["PE to Storage"] PE5["PE to Key Vault"] App3["Data Job"] end KV --> PE1 KV --> PE3 KV --> PE5 SA --> PE2 SA --> PE4 App1 --> PE1 App1 --> PE2 App2 --> PE3 App3 --> PE4 App3 --> PE5

Nothing here is automatically insecure.

That is exactly why sprawl survives.

The issue is not endpoint count in isolation. The issue is that shared services are now privately reachable from multiple trust zones with different operational controls, different DNS views, and potentially different security assumptions. If one of those zones is compromised, the attacker may inherit private line of sight to services that were mentally modelled as more tightly contained.

Real-World Impact

This is the point where the article has to matter beyond architecture diagrams.

Design impact

A second Private Endpoint to the same service is not automatically a problem.

A second Private Endpoint in a different trust zone should be treated as architectural debt by default until someone can justify why compromise of that zone should still permit private reachability to the target service.

That is the design decision most teams skip.

They ask whether the application needs private access. They do not ask whether this particular network should be allowed to host a private access path to that service. Those are different questions. The second one is the security question.

If the hosting network is lower-assurance, loosely governed, or simply administered by a different team with different standards, then the new endpoint is not just enabling connectivity. It is extending the service’s effective internal exposure.

Deployment impact

Private Endpoint sprawl is often created by valid infrastructure-as-code.

That is why it is easy to miss.

Every endpoint can be deployed through a clean module, approved through a normal workflow, and attached to the right subnet. Nothing looks broken in the deployment pipeline. The problem is that deployment success says very little about whether the overall estate should contain that many private access paths to the same service.

In other words, good IaC can still encode a bad reachability model.

Operational impact

In an incident, the question is no longer:

Does this service have private access?

It becomes:

How many private origins can still reach it, and which of those no longer belong to a workload anyone actively operates?

That is a much harder question to answer under pressure.

The moment suspicious access appears against a vault, storage account, or database, responders need to understand:

Which Private Endpoints connect to it
Which subscriptions and resource groups own those endpoints
Which virtual networks and subnets host them
Which DNS zones make the target resolvable
Which endpoints still correspond to real workloads
Which paths were approved historically but no longer fit the current design

If you cannot answer those questions quickly, your containment options are slower and your confidence in the service boundary is weaker than you thought.

Security impact

The security issue is not that Private Endpoints bypass service authentication. They do not.

The issue is that they increase the set of internal origins from which authenticated access can be attempted after compromise, reduce confidence in where the service is actually reachable from, and make it harder to distinguish intended private access from inherited shadow paths.

That matters in practice.

An attacker with a foothold in a lower-assurance or forgotten network does not need the endpoint itself to be misconfigured. If that network still has private resolution and routable reachability to a high-value service, the attacker has inherited a path that may not exist in anyone’s current threat model. Even if identity controls still block them initially, the blast radius, staging options, and containment assumptions have changed.

That is why sprawl is an attack-surface problem rather than just an inventory problem.

Architectural Symptoms of Sprawl

Sprawl is usually visible through patterns, not labels.

The same service has Private Endpoints in multiple differently trusted networks

That should trigger scrutiny immediately.

Not because multiple endpoints are always wrong, but because duplicated private access across trust zones should be presumed to be debt until proven otherwise. If the justification does not survive compromise-based reasoning, it is not a strong justification.

Service owners cannot enumerate all private access paths confidently

If the team responsible for a sensitive shared service cannot quickly identify all approved Private Endpoint connections and where they land, then part of the service boundary already lives outside that team’s usable control.

That is not a documentation issue. It is an exposure issue.

DNS behaviour varies by environment in ways no one can explain cleanly

When a service resolves privately in some places, publicly in others, and through different linked DNS constructs across the estate, teams tend to treat it as naming complexity.

Often it is evidence that connectivity spread faster than architecture discipline.

Retired workloads still leave active private access behind

This is one of the clearest forms of shadow access.

The application may be gone, but the endpoint remains, the connection is still approved, and the target service is still privately reachable from that network. That path may not be monitored closely because everyone thinks the workload was retired.

Environment separation exists on paper more than in reachability

The problem is not that dev, test, analytics, and prod are different labels.

The problem starts when differently administered or lower-assurance networks can host equivalent private access paths into shared services that people assume sit behind production-grade controls. At that point, your environment model is doing more work than the network design.

Implementation Example: Inspecting for Duplicated Private Reachability

For this topic, the useful artefact is not deployment code. It is an inspection pattern.

A simple Private Endpoint inventory is rarely enough. What matters is whether the same target resource is reachable through several endpoints spread across different subscriptions or ownership boundaries. That is the shape of sprawl.

Azure CLI example

The following command is intentionally basic, but it is more useful than deployment syntax for this discussion because it starts with the right question: which target resources have multiple Private Endpoints pointing at them?

1
2
3
4
5
6
7
8
9


az network private-endpoint list \
 --query "sort_by([].{
 pe:name,
 rg:resourceGroup,
 subscription:id,
 subnet:properties.subnet.id,
 targets:properties.privateLinkServiceConnections[].properties.privateLinkServiceId
 }, &pe)" \
 -o json

On its own, this is just raw inventory. The useful next step is analytical, not procedural:

Group by target resource ID
Look for shared services with multiple endpoints
Check whether those endpoints sit in different subscriptions or trust zones
Identify endpoints whose owning workload is retired, unclear, or differently administered

The interesting cases are not simply “many Private Endpoints exist”. The interesting cases are “this one high-value service is privately reachable from more places than the architecture claims”.

What to look for

A small synthetic example makes the point:

Target service	Private Endpoint count	Subscription spread	Trust zone spread	Owner clarity
Shared Key Vault A	3	3	Prod, Dev, Analytics	Partial
Storage Account B	2	1	Prod only	Clear
SQL Server C	1	1	Prod only	Clear

Only one of these rows should make you uncomfortable immediately.

Not because three is a magic number, but because a shared secret store privately exposed across multiple administrative or trust boundaries is exactly where “private” starts to mean “unseen”.

Gotchas and Edge Cases

Some multi-endpoint designs are valid

Yes, there are legitimate reasons to expose the same service privately into multiple networks.

But legitimacy should be demonstrated, not assumed. If those endpoints cross trust boundaries, the burden of proof should be higher. “The application needed to connect” is not enough on its own.

Counting endpoints alone is a weak metric

A large estate may have many Private Endpoints without having serious sprawl.

The stronger signal is duplicated reachability to the same sensitive service across different trust zones, ownership boundaries, or stale workload footprints.

Endpoint inventory is not the same as effective reachability

Even with a good list of endpoint resources, you can still misunderstand exposure if you ignore DNS links, peering, routing, or path changes introduced by centralised network patterns.

Private access is a system property, not just a resource property.

Approved once does not mean appropriate now

An endpoint may have been justified when created and still be risky now.

Architectures change. Environments get repurposed. Ownership shifts. Old exceptions become inherited assumptions. Historical approval does not preserve present validity.

Best Practices

Within the bounds of this post, the strongest practices are architectural.

Treat every new Private Endpoint as a new internal exposure point

Do not review it as routine plumbing.

Ask which new network origins now gain private line of sight to the service, and whether those origins still fit the intended trust model.

Default to suspicion when duplicate endpoints cross trust zones

This is the opinionated line worth keeping.

If the same service needs multiple Private Endpoints in differently trusted or differently administered networks, treat that as architectural debt by default until the design can justify it under compromise assumptions.

Review target-service spread, not just endpoint counts

A platform can have a high number of endpoints and still be relatively disciplined.

What you need to understand is which high-value services are privately reachable from how many distinct places, under whose control, and whether those paths still map to live business intent.

Include DNS and ownership in the exposure model

Private access is only meaningful if you understand how workloads discover the service and who controls the network objects that make that possible.

If service ownership does not include usable visibility of private access paths, the service boundary is already weaker than it appears.

Treat orphaned private paths as security-relevant until proven otherwise

A Private Endpoint attached to a retired, forgotten, or poorly understood workload should not be considered harmless background noise. It should be treated as shadow access until someone proves it still belongs in the architecture.

🍺

Brewed Insight:

Private Endpoint sprawl is what happens when private connectivity stops being a deliberate design and becomes a habit.

The danger is not that private access makes a service insecure by itself. The danger is that duplicated private paths quietly reshape trust, reachability, and incident assumptions until your architecture says “contained” while your network says otherwise.

Architecture on Brewed in the Cloud by Chris Hailes