Over the last few years, enterprises have done the hard work of locking down their cloud networks. Public endpoints get switched off. Traffic moves onto private IPs inside a virtual network. Shared secrets get replaced with identities that can be governed and revoked. This is the practical shape of a zero-trust strategy, where you assume breach, never trust, and always verify. It is the right direction, and your messaging infrastructure deserves the same protection as the rest of your estate.

The instinct, though, is to treat network security as a single switch. Turn off public access, and you are done. Real deployments are not that simple. A namespace that backs a payment pipeline, a namespace that ingests telemetry from thousands of devices, and a throwaway namespace for a nightly batch job do not need the same controls, and they do not need to pay the same price for them. Network security is a set of layers you compose to fit the workload, not one toggle you flip and forget.

That matters because a namespace starts out permissive by design. A message broker that you create and walk away from accepts connections from anywhere on the internet so you can get going quickly, authenticated by a key that anyone can copy. Those keys could end up in places they should not, including public source repositories. The job is to move from that open starting point to a posture that fits the workload, with the right controls in front of it.

Why a message broker needs more than one control

Picture a service that processes orders through a message broker. The clients run inside an Azure virtual network. Some run on premises. A few partner systems need to reach the broker from outside your tenant entirely. There is no single rule that covers all of those callers well. An IP allow list is perfect for the partner with a stable address range and useless for the fleet of autoscaling workers whose addresses change by the hour. A private endpoint is exactly right for the in-network clients and irrelevant to the partner who has no presence in your virtual network at all.

This is why network security is layered. Each control answers a different question. Which public addresses may reach this namespace? Which subnets in my virtual network may reach it? Should it have a public surface at all, or should it live entirely on private IPs? And once I have a dozen resources configured this way, how do I manage them as a group rather than one rule at a time? Pick the controls that answer the questions your workload actually asks.

We already solved this once on premises

Nobody secured a datacenter with a single firewall rule. There was a perimeter, then segmentation inside it, then host-level controls, then identity on top. Each layer was there precisely because the one outside it could be breached. Defense in depth was the whole point, because any single barrier eventually has a gap. The cloud did not change that principle. It just gave us cleaner tools to express it, and a default posture that demands we use them.

The network security toolkit in Azure Service Bus

Azure Service Bus gives you a full set of network security controls, and the point is that they layer. You are not choosing one. You are assembling the combination that matches the workload.

• IP firewall rules restrict access to specific public IP addresses or ranges.


• Service endpoints grant access to specific virtual network subnets.


• Private endpoints put a private IP from your own virtual network in front of the namespace, so traffic never touches the public internet.


• Network Security Perimeter draws a logical boundary around the namespace and the other resources it works with, managed as one set of rules.

The sections below walk through each, when to reach for it, and how it fits with the others.

IP firewall rules, service endpoints, private endpoints, and Network Security Perimeter, layered by the caller each answers

IP firewall rules

The simplest control is an allow list of public IP addresses. By default, a namespace accepts connections from all networks, which is equivalent to allowing the entire address range. The moment you switch to selected networks and add a rule, the default flips to deny: add even a single address and every other source is blocked, so the allow list becomes the only way in. This is the right tool for callers with stable, known addresses, such as a partner system or a fixed egress IP. It also has the widest reach of these controls: it works on every tier, while service and private endpoints are a Premium capability. For Premium namespaces you set it up in the portal; on Basic and Standard you configure it through Resource Manager templates, the CLI, PowerShell, or the REST API. One caution: a firewall rule can also block Azure services that legitimately need to reach your namespace. Service Bus lets you exempt trusted Microsoft services from the firewall, and you should pair that exemption with a managed identity on the service using it.

Service endpoints

When your clients live inside Azure virtual networks, service endpoints are the lighter-weight way to secure the namespace. A virtual network rule locks the namespace to specific subnets: every workload in an associated subnet is granted access while the rule exists, and once you pair that with denying public access, the namespace is no longer reachable on a public address at all. Service Bus never makes an outbound connection to your subnet; the trust flows one way. Service endpoints are lightweight and add no moving parts, so when all you need is to keep a namespace reachable only from your own network, this is usually the right choice before you reach for anything heavier.

Private endpoints

Private endpoints do everything a service endpoint does and add two things it cannot. First, they put a private IP from your virtual network in front of the namespace, so clients on-premises or in peered virtual networks can reach it over the Microsoft backbone on a private address that never touches the public internet. Second, they let you prevent data exfiltration: combined with network policies, a workload in your subnet can be allowed to reach that namespace and nothing else. Resolution depends on Azure DNS private zones, which point the namespace name to the private IP while public DNS still resolves to the public address, so the private path only works where that private zone is in scope. All of this comes with more configuration than a service endpoint, so reach for private endpoints when you need private-IP access from outside the virtual network or exfiltration control, not simply to secure a namespace that a service endpoint could already lock down.

A perimeter over the controls you already manage

Configuring firewall rules and endpoints one resource at a time becomes its own risk as an estate grows. Network Security Perimeter takes a different approach: you draw a logical boundary and associate your platform resources with it. Inside the perimeter, resources communicate with each other freely, while public access from outside is denied unless an explicit inbound or outbound rule allows it. This is especially useful for keeping a namespace and the resources it depends on, like the Key Vault holding your customer-managed keys, under one consistent set of rules. It is complementary to private endpoints rather than a replacement: private endpoints secure the path from your virtual network into the namespace, while the perimeter secures the namespace’s own public surface and its conversations with neighbors. Used together they give you defense in depth, and you can start a resource in transition mode to observe traffic before switching to enforced mode and locking it down.

How the network layer meets reliability

Geo-Replication requires careful thought about networking, because clients have to keep their access as the primary instance moves from one region to another. Service endpoints make this easy: because the rule lives on your subnet rather than on a region-specific address, it keeps working across a Geo-Replication promotion with no reconfiguration. Private endpoints take more care. A private endpoint is an IP in one region, and Azure DNS private zones map the namespace name to it while public DNS still resolves to the public address. Without the right setup, a promotion to the secondary region can leave clients resolving to a private IP that no longer answers. The fix is to create a private endpoint in each region, peer the virtual networks so clients can reach either one, and manage DNS so the namespace name always resolves to the private endpoint in the current primary, updating it as part of the promotion. If on-premises clients reach the namespace over private endpoints, their on-premises DNS has to be updated to point to the correct regional endpoint as part of that promotion too. Plan the network and the failover together and the two reinforce each other rather than fight.

Identity is the layer on top

Network controls decide who can reach the namespace; identity decides who can do what once they arrive. The weakest option is a shared access signature, a string tied to send, listen, or manage rights. It works, and it is far better than nothing, but it is a string, and strings get copied. The stronger path is a managed identity authenticating through Entra ID, which removes the secret from the equation entirely and lets you grant least-privilege roles like Azure Service Bus Data Sender or Data Receiver. Since Entra ID is already part of your subscription, there is rarely a reason not to use it everywhere. Network isolation keeps the wrong callers out; identity makes sure the right ones can only do what they should.

Right-size the stack to the workload

None of this means turning every control on for every namespace. The workload makes most of the calls for you. IP firewall rules and service endpoints are easy to apply, so there is rarely a reason to leave a namespace open to all networks. Zone redundancy spreads your namespace across availability zones and is on by default in supported regions, so the reliability floor is already in place. Private endpoints and a second region are larger steps you take only where the workload genuinely needs them. A nightly batch namespace does not need private endpoints and a second region. A payment pipeline does.

So treat network security as a stack you assemble, not a switch you flip. Start from a namespace that is closed to all networks by default, add the control that matches how your clients actually connect, and put identity on top of all of it. The strongest security is rarely a single dramatic setting. It is the combination of controls, each one assuming the layer in front of it might fail, that makes a namespace genuinely hard to reach for anyone who should not.

Getting started

Open your namespace’s Networking tab in the portal and check one thing first: whether it still accepts traffic from all networks. If it does, that is the change to make today. Switch to selected networks and add the single control that matches how your clients connect, an IP rule for a fixed public address, a service endpoint for a subnet, or a private endpoint for traffic that should never leave the backbone. The network security documentation walks through each control step by step. Pick the one your workload calls for and close the biggest gap first.