Azure Service Bus and Event Hubs Security: Move From Connection Strings to Entra ID

A Service Bus or Event Hubs connection string is a bearer credential: whoever holds it can send, read or, with Manage rights, reshape the whole namespace, and it works from anywhere the namespace is reachable. Both services support two ways to authorise clients: shared access signature (SAS) keys held in authorisation rules, and Microsoft Entra ID with Azure RBAC data roles. Microsoft recommends Entra ID wherever possible, and both services let you turn SAS off entirely. This guide covers the two authorisation models side by side, the roles and rules to govern, how to migrate applications to managed identities, network isolation, customer-managed keys, logging and a hardening baseline. It is written for cloud engineers, application teams and security architects running messaging and streaming workloads on Azure. Secrets handling in general is covered in the Secrets Management Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public Service Bus and Event Hubs documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Use Entra ID for every client. Assign Data Sender, Data Receiver or Data Owner roles to managed identities so no key is stored in code or configuration.
• Keep RootManageSharedAccessKey out of applications. It is created with every namespace with Manage rights over everything; Microsoft says to treat it like an administrative root account.
• Disable local authentication when migration is done. Setting disableLocalAuth to true means SAS rules can no longer produce working tokens, and Azure Policy can audit or deny namespaces that leave it on.
• Isolate the network on the right tier. Use Service Bus Premium and Event Hubs tiers above Basic for private endpoints and virtual network rules.
• Prove it with runtime audit logs. RuntimeAuditLogs (Premium and Dedicated) record whether each client authenticated with SAS or Entra ID, which tells you when it is safe to switch SAS off.

How identity and access work in Service Bus and Event Hubs

By default, a namespace accepts requests from the internet that carry valid authentication and authorisation. Authorisation comes from one of two models.

For Entra ID, the token resource for Event Hubs is https://eventhubs.azure.net/, and Kafka clients connecting to Event Hubs request a token for https://<namespace>.servicebus.windows.net. Client SDKs accept a credential object such as DefaultAzureCredential in place of a connection string, so the switch is usually a small code change plus a role assignment.

SAS rules and tokens

Each namespace, queue, topic and event hub can hold up to 12 authorisation rules. A rule has a name, a primary and secondary key, and any combination of rights: Send, Listen and Manage (which includes Send and Listen and can create and delete entities). A namespace-level rule applies to every entity in the namespace. Service Bus subscriptions cannot have their own rules, so they are secured through the topic or namespace. Microsoft notes that the 12-rule limit means the rule store is not meant to be a user or service account store: if you need per-client SAS, put a token service in front that issues short SAS tokens after its own authentication and access check.

A SAS token carries an expiry (se) and the rule name (skn). Regenerating a key invalidates tokens signed with it immediately, although connections already open keep working until their token expires. Renew tokens well before expiry, allow for up to 15 minutes of clock skew, and always create and distribute tokens over HTTPS. Do not paste tokens into tickets, logs or screenshots.

Admin roles and privileged access

• Assign at the narrowest scope: Give a producer Data Sender on its own queue, topic or event hub rather than the namespace, and a consumer Data Receiver on its own entity.
• Keep Data Owner rare: Most applications never need to create or delete entities at run time. Manage topology through infrastructure as code under a deployment identity.
• Guard who can assign roles: Assigning these roles needs Owner or User Access Administrator at the target scope. Make those roles eligible rather than permanent, as described in the Azure RBAC and Service Principals Guide.
• Remember the control plane reads keys: Anyone who can list authorisation rule keys has the same access as the rule. While local authentication is on, Contributor on the namespace is effectively data access.
• Use current Event Hubs roles: Event Hubs data privileges once added to Owner or Contributor during the preview are no longer honoured; use Azure Event Hubs Data Owner.

Integrations, API tokens and service accounts

Every producer and consumer is a non-human identity. The aim is for each one to have its own managed identity with one role on one entity.

• Managed identities: Azure Functions, App Service, Container Apps, AKS workloads and virtual machines can all use a managed identity with the SDK's credential class. See the Azure Managed Identities Security Guide.
• Workloads outside Azure: Use workload identity federation for CI/CD and external platforms rather than a client secret or connection string. See How to replace Azure app secrets with federated credentials.
• Kafka clients on Event Hubs: Kafka clients can authenticate with Entra OAuth tokens instead of a connection string. Plan Kafka client changes before disabling local authentication, because clients configured with a connection string depend on SAS. Wider Kafka credential handling is covered in the Kafka Credentials Security Guide.
• Connection strings that must remain: Where a third-party product can only take a connection string, create a dedicated rule on the single entity it needs with only Send or Listen, store the string in Azure Key Vault, and record an owner and rotation date. See the Azure Key Vault Security Guide.
• Key rotation: For routine rotation, copy the primary key into the secondary slot, regenerate the primary, move clients to the new primary, then regenerate the secondary. If a key may be exposed, regenerate both keys at once. Tools include the portal, New-AzServiceBusKey and az servicebus namespace authorization-rule keys renew.
• Secret scanning: Connection strings include the namespace host name and SharedAccessKey, which makes them easy for scanners to match. Scan repositories, pipelines and container images, and treat any hit as a key to regenerate. See the Secrets Management Guide.

Migrating from SAS to Entra ID

1. Inventory: List every authorisation rule at namespace and entity level, and use RuntimeAuditLogs (Premium and Dedicated) to see which AuthKey values authenticate with SAS, and from which client IPs.
2. Assign roles: Give each client identity the Data Sender or Data Receiver role on its entity.
3. Change code: Replace the connection string with the fully qualified namespace and a credential object.
4. Test with SAS still on: Confirm in runtime audit logs that the client now authenticates as Entra ID and that the SAS rule shows no traffic.
5. Disable local authentication: Set disableLocalAuth to true in the portal (Overview, Local Authentication), with az servicebus namespace update --disable-local-auth true, or in Bicep. Existing SAS rules remain but cannot produce working tokens.
6. Clean up: Remove unused rules, leaving RootManageSharedAccessKey unused.
7. Roll back if needed: Setting disableLocalAuth back to false restores SAS immediately, which gives a safe fallback for a client you missed. Regenerate the affected keys if you do.

Network isolation and encryption

Rejected connections receive an unauthorised response that does not mention the firewall, so record network rules in your runbooks to speed up troubleshooting. Choosing the right pattern:

Customer-managed keys

Data is always encrypted at rest with Microsoft-managed keys. With a customer-managed key, that Microsoft-managed key is itself encrypted with your key in Azure Key Vault or Managed HSM. Requirements are the same in both services: soft delete and purge protection on the vault, a managed identity with get, wrapKey, unwrapKey and list key permissions (or Key Vault Crypto Service Encryption User for Event Hubs under Azure RBAC), and up to three keys for redundancy. Infrastructure encryption (requireInfrastructureEncryption) adds a second layer with a different algorithm and key. The service polls keys every five minutes; if all keys become inaccessible, every entity becomes unavailable and the namespace status shows Revoked, so treat key access changes as production changes. Use versionless key IDs so rotation is picked up automatically. Plan Geo-Disaster Recovery pairing before enabling customer-managed keys, as pairing constraints apply. See the Cloud Customer-Managed Keys and BYOK/HYOK Decision Guide.

Logging and detection

Create diagnostic settings for each namespace and send them to Log Analytics. Resource-specific tables (prefixed AZMS) are available for most categories.

Pair these with the Azure Activity Log for listKeys, key regeneration, local authentication changes and network rule changes. Useful detections include any SAS authentication after a namespace was declared Entra-only, SAS use from a new client IP, a rule name appearing from public networks when clients should be private, and authorisation failures in bursts. Metrics that show progress:

• Percentage of namespaces with local authentication disabled.
• Percentage of runtime operations authenticated with Entra ID rather than SAS.
• Number of SAS rules with Manage rights in use by applications (target zero).
• Namespaces holding sensitive data that use private endpoints with public access closed.
• Age of the oldest SAS key still in use.

Collection at scale is covered in the Azure Monitor, Activity Log and Diagnostic Settings Guide.

Hardening baseline

1. Audit with Azure Policy: Assign "Service Bus namespaces should have local authentication methods disabled" and "Azure Event Hub namespaces should have local authentication methods disabled" in Audit mode, plus "Event Hub namespaces should use private link" and "All authorization rules except RootManageSharedAccessKey should be removed from Event Hub namespace".
2. Turn on logs: Enable diagnostic settings, including RuntimeAuditLogs where the tier supports it.
3. Migrate clients: Follow the migration steps above, one application at a time.
4. Disable local authentication: Then switch the policies to Deny so new namespaces start Entra-only.
5. Isolate: Add private endpoints or virtual network rules on the supported tiers, and IP firewall rules elsewhere.
6. Set TLS: Keep the minimum at TLS 1.2 or raise it to 1.3 where all clients support it.
7. Encrypt with your key where required: Create new Premium or Dedicated namespaces with customer-managed keys and move workloads, since keys cannot be added to namespaces that already hold entities.
8. Review quarterly: Role assignments, remaining SAS rules, key age and network rules.

Common misconfigurations

• RootManageSharedAccessKey in application settings: The default connection string copied from the portal carries Manage rights over the whole namespace. Replace it with a managed identity, or at most an entity-scoped Send or Listen rule.
• Namespace-level rules for single-entity clients: A namespace rule reaches every queue, topic and event hub. Create rules or roles on the entity.
• Local authentication left on after migration: Old connection strings keep working until local auth is disabled. Finish the job and enforce it with policy.
• One shared rule for many applications: Runtime audit logs then show one AuthKey for all of them, and rotating it breaks everyone at once. Give each client its own identity.
• Rotating only one key after exposure: The other key stays valid. Regenerate both.
• Pinning a key version for customer-managed keys: The service keeps using the pinned version after rotation. Use versionless key IDs.

Framework mapping

Practitioner checklist

• Give every producer and consumer its own managed identity with a Data Sender or Data Receiver role on its entity.
• Keep RootManageSharedAccessKey out of every application and configuration file.
• Use RuntimeAuditLogs to find remaining SAS clients before switching SAS off.
• Set disableLocalAuth to true on each namespace and enforce it with the built-in Azure Policy definitions.
• For any connection string that must remain, use an entity-scoped Send or Listen rule stored in Key Vault with an owner and rotation date.
• Regenerate both keys of a rule after any suspected exposure.
• Use private endpoints on Service Bus Premium and Event Hubs tiers above Basic, and IP firewall rules elsewhere.
• Keep minimum TLS at 1.2 or higher.
• Where policy requires, create Premium or Dedicated namespaces with customer-managed keys, purge protection and versionless key IDs.
• Alert on SAS use in Entra-only namespaces, listKeys, key regeneration and local auth changes.

Standards and references

• Microsoft Learn: Service Bus authentication and authorization
• Microsoft Learn: Service Bus access control with Shared Access Signatures
• Microsoft Learn: Disable local or SAS key authentication with Azure Service Bus
• Microsoft Learn: Authenticate an application with Microsoft Entra ID to access Event Hubs resources
• Microsoft Learn: Authorize access to Event Hubs resources using Shared Access Signatures
• Microsoft Learn: Network security for Azure Service Bus
• Microsoft Learn: Configure customer-managed keys for Azure Event Hubs
• Microsoft Learn: Monitoring data reference for Azure Service Bus

Related NHI Mgmt Group resources: Azure Managed Identities Security Guide · Azure Key Vault Security Guide · Kafka Security Guide · Secrets Management Guide