Session Border Controller Security: SBC Hardening Guide

The session border controller is the one device that faces both the carrier and the internet on one side and your phone system on the other, so a weak SBC configuration exposes every call, every number and the bill. SBCs terminate SIP trunks, connect on-premises PBXs and contact centres to cloud calling, and for cloud calling platforms such as Cisco Webex Calling, Microsoft Teams Direct Routing and Zoom Phone BYOC they are the customer-run link between the cloud service and the public telephone network. This guide is about securing the SBC itself: where to place it, how to configure TLS and SRTP, how to handle its certificates, how topology hiding and rate limiting work, how to lock down administrative access, and the requirements cloud calling providers document for customer SBCs. The protocol-level threats (SIP, RTP, toll fraud, STIR/SHAKEN) are covered in the VoIP and SIP Security Guide; this page goes deeper on the SBC. It is for voice engineers, network and security architects, and cloud calling administrators.

Key takeaways

Place the SBC as a perimeter device. Put it in a DMZ with separate interfaces for the carrier, the internet or cloud calling provider, and the internal voice network, and allow only the documented peers on each.
Encrypt signalling and media on every leg. SIP over TLS on TCP 5061 and SRTP for media; cloud calling providers document TLS 1.2 and specific cipher suites for the SIP interface.
Certificates are an availability risk as well as a security control. Direct Routing needs a publicly trusted certificate with the SBC FQDN in the CN or SAN; an expired certificate stops calls.
Hide topology and limit rates. Rewrite internal addresses and headers, cap concurrent sessions and call rates, and block unexpected SIP methods and sources to contain toll fraud and denial of service.
Treat SBC administration as privileged access. Management only from a dedicated network, named accounts with multi-factor authentication through central authentication, and logs sent to the SIEM.

What an SBC does and where it sits

NIST SP 800-58 recommends separating voice and data networks where feasible and using firewall mechanisms such as application-level gateways or session border controllers at the voice boundary, with remote management over protected channels. NSA's 2021 guidance on deploying secure unified communications and voice and video over IP systems covers establishing network perimeters and using enterprise session controllers, and its mitigations include segmentation, prompt patching and authenticating and encrypting all signalling and media. In practice the SBC is a back-to-back user agent: it terminates each call leg and re-originates it, which lets it enforce policy on both sides.

Placement pattern	When to use	Security considerations
DMZ with three interfaces (carrier, external or cloud, internal)	Most enterprise SIP trunk and Direct Routing deployments	Firewall each interface to its documented peers; no routing between interfaces except through the SBC
Edge with public IP and NAT	Smaller sites or where the firewall cannot host a DMZ	Keep NAT one to one and static; the SBC must know its public address for SIP and SDP
Cloud-hosted or virtual SBC	Direct Routing without on-premises voice equipment, or hosted by a service provider	Same controls apply in the cloud network: security groups per interface, hardened image, managed identity for administration
Provider-managed (for example Teams Operator Connect)	Organisations that do not want to run SBCs	The operator manages PSTN connectivity; your controls move to contract, Teams admin roles and number management

Decision guidance: run your own SBCs when you need to connect on-premises PBXs, analogue gateways, contact centres or local survivability; choose an operator-managed model when the main need is PSTN calling for Teams users and the team lacks voice engineering capacity. Microsoft's Operator Connect documentation describes the operator as responsible for PSTN connectivity, number provisioning and PSTN support, with administrators managing users in the Teams admin centre.

Encrypting signalling and media

Signalling: use SIP over TLS (SIPS) on TCP 5061 for every leg that leaves the internal voice network. For Teams Direct Routing, Microsoft states that TLS 1.2 is mandatory for the SIP interface and lists the supported cipher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256. Disable older protocol versions and non-ECDHE suites on that interface.
Media: use SRTP. Direct Routing uses SRTP (UDP/RTP/SAVP) between the SBC and Microsoft media processors.
Carrier leg: many carriers still offer only SIP over UDP or TCP with RTP. Where the carrier supports TLS and SRTP, use them; where it does not, restrict the carrier leg to a private interconnect or IPsec tunnel and to the carrier's documented IP addresses.
Internal leg: encrypt to IP phones and PBXs where they support it, and keep the internal voice network segmented so unencrypted legs are not reachable from user networks.
Mutual TLS: where a peer supports it, authenticate both sides. For Direct Routing, Microsoft notes that if mutual TLS is enabled, all required Microsoft trusted root certificates must be installed on the SBC.

See the How TLS Works Guide and the mTLS Guide for the underlying protocol.

Certificate handling

For Direct Routing, Microsoft requires an SBC certificate that carries the SBC FQDN as the common name or a subject alternative name, is signed by a certificate authority in the Microsoft Trusted Root Program, includes the Server Authentication extended key usage and is publicly trusted. Wildcard certificates are supported if they comply with RFC 2818, and Microsoft recommends generating the certificate signing request on the SBC so the private key never leaves it. Government clouds (GCC High and DoD) accept a narrower list of root CAs. The SBC FQDN's domain must be registered in the Microsoft 365 tenant; multiple IP addresses mapped to the same SBC FQDN are not supported.

Certificate task	Practice
Key generation	Generate the key pair and CSR on the SBC; never export the private key to email or shared drives
Names	Include every FQDN the SBC answers for (production and test trunks) in the SAN; Microsoft notes a test trunk on the same SBC needs a different TLS port and a certificate covering both FQDNs
Trust store	Load only the root and intermediate certificates the SBC needs for its peers; review after CA changes
Expiry	Track expiry in the certificate inventory with alerts at 60, 30 and 7 days; shorter public certificate lifetimes make automation more important
Renewal	Renew on a standby SBC or in a maintenance window, then confirm SIP OPTIONS return 200 OK before returning the SBC to service

The SBC certificate is a machine identity. Manage it in the same lifecycle process as other TLS certificates, as described in the Machine Identity, PKI and Certificate Lifecycle Guide and the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Topology hiding, access lists and rate limiting

Topology hiding: rewrite Via, Contact, Record-Route and SDP addresses so internal IP addresses, PBX host names and internal extensions never appear on the carrier or internet side. Strip or normalise headers that reveal internal products and versions (for example User-Agent and Server).
Header policy: forward identity headers only where needed. In Direct Routing, ForwardPAI (forward the P-Asserted-Identity header) and ForwardCallHistory (History-Info and Referred-By) are off by default; enable them only when a call flow requires them.
Peer access lists: accept SIP only from known peers. For Direct Routing, Microsoft documents the signalling FQDNs (sip.pstnhub.microsoft.com, sip2 and sip3) and the IP ranges 52.112.0.0/14 and 52.120.0.0/14 for signalling and media in commercial clouds, and says to allow all Teams ranges, not only addresses returned by DNS. For carriers, use the addresses in the trunk contract.
Media ports: restrict media ports to the documented ranges and sources. Microsoft lists UDP 3478 to 3481 and 49152 to 53247 between media processors and the SBC, and recommends at least two media ports per concurrent call.
Rate limiting: set call admission limits per trunk and per source, limits on registrations and INVITEs per second, and drop unknown SIP methods. Blacklist sources that send repeated scans or failed registrations.
Toll fraud controls: block premium rate and high-risk international destinations by default, allow-list destinations per user group, cap concurrent calls, and alert on calls outside working hours. In Direct Routing, set MaxConcurrentSessions on each PSTN gateway; Microsoft alerts when concurrent sessions reach 90 percent of the value.

Cloud calling platform requirements

Each cloud calling provider publishes its own SBC requirements. The platforms below are listed alphabetically as examples; order is not a ranking, and other providers publish equivalent guidance.

Cisco Webex Calling (Local Gateway)

Cisco's Local Gateway configuration guide for Webex Calling describes a SIP over TLS trunk restricted to TLS 1.2, SRTP with the AES_CM_128_HMAC_SHA1_80 suite, and validation of the Webex access SBC certificate against a trusted root bundle, with the tenant host name checked in the certificate CN or SAN. A registration-based trunk authenticates with a username and password, so encrypt stored credentials on the gateway; a certificate-based trunk needs a certificate on the gateway trustpoint. Confirm settings against Cisco's current documentation before a change.

Microsoft Teams Direct Routing

Microsoft supports only Microsoft-certified SBCs for Direct Routing, and support requests start with the SBC vendor. The table summarises the documented security-relevant settings as of November 2026; confirm them against Microsoft's current documentation before a change.

Setting or requirement	Documented value or behaviour	Security purpose
SIP signalling to Microsoft	SBC to SIP proxy on TCP 5061 (SIP/TLS); proxy to SBC on the port set in SipSignalingPort	Encrypted signalling on fixed, filterable ports
TLS	TLS 1.2 mandatory, four ECDHE cipher suites	Forward secrecy and modern ciphers
SBC FQDN	Domain registered in the tenant; *.onmicrosoft.com not supported	Ties the trunk to a verified domain
SendSIPOptions	On by default; Microsoft highly recommends keeping it on, otherwise the SBC is excluded from monitoring and alerts	Health monitoring and failover
Enabled	Set to false to take the SBC out of service for maintenance	Safe changes and certificate renewal
MaxConcurrentSessions	Alerts at 90 percent of the configured value	Early warning of abuse or capacity issues
MediaBypass	Set per SBC with Set-CsOnlinePSTNGateway; clients reach the SBC public IP for media	Lower latency, but a larger exposed UDP range

Media bypass trade-off: with media bypass, Teams clients send media directly to the SBC's public IP (client source ports UDP 50000 to 50019), and clients that cannot reach it use Teams transport relays (UDP 50000 to 59999 and 3478 to 3481 from the Microsoft ranges). Microsoft notes that direct access from external clients is not recommended because it bypasses transport relays. A conservative design restricts the SBC's media ports to the Microsoft ranges and internal client subnets, uses NAT hairpinning for internal clients, and lets external clients use relays.

On the Teams side, limit who can run the Direct Routing cmdlets (New-CsOnlinePSTNGateway, Set-CsOnlinePSTNGateway, voice routing policies) to the Teams administrator roles that need them, and review changes to voice routes and PSTN usages. The Microsoft Teams Security Guide covers the wider tenant controls.

Zoom Phone BYOC

Zoom's documentation for Bring Your Own Carrier and Zoom Phone Local Survivability describes using an SBC certified for Zoom Phone BYOC, with TLS 1.2, SRTP and mutual TLS support, topology hiding, and Zoom's DigiCert root and intermediate certificates installed on the SBC for TLS to Zoom. It also describes routing inbound PSTN calls to the primary and secondary Zoom SIP zones. Confirm settings against Zoom's current documentation before a change.

Administrative access and hardening

Management plane: bind the web, SSH and API management interfaces to a dedicated management network only; never expose them on the carrier or internet interface.
Authentication: integrate with central authentication (RADIUS, TACACS+ or LDAP as the product supports) so each administrator has a named account with multi-factor authentication through the identity provider; keep one local break-glass account in a vault.
Roles: separate read-only monitoring, operator and full administrator roles.
Services: disable unused protocols and services (telnet, HTTP, SNMP v1 and v2c, unused SIP interfaces) and use SNMPv3 where monitoring needs it.
Updates: apply SBC vendor security updates promptly, following the vendor's security advisories, and keep a tested configuration backup before each upgrade.
Configuration control: store the configuration in version control, compare running configuration with the approved baseline, and require change tickets for routing and access list changes.

For privileged access patterns, see the Privileged Remote Access Buyers Guide.

Implementation roadmap

Inventory: every SBC, trunk, peer, certificate, firmware version, admin account and voice route.
Baseline: document allowed peers, ports, codecs, destinations and session limits per trunk.
Harden management first: move management to a dedicated network and central authentication; remove default and shared accounts.
Encrypt: enable TLS and SRTP leg by leg, starting with internet and cloud legs, then carrier and internal.
Restrict: apply peer access lists, topology hiding, rate limits and destination blocks; start in log or monitor mode where the product allows, review a week of traffic, then enforce.
Test and roll back: make changes on the secondary SBC first, set Enabled to false on the gateway during the change, test inbound, outbound, transfer and emergency calls, and keep the previous configuration ready to restore.
Operate: monthly review of call detail records and blocked traffic, certificate expiry tracking, quarterly access review.

Detection and measurement

Monitor: SBC system logs, failed registration and INVITE floods, calls to blocked or unusual destinations, after-hours call spikes, admin logins and configuration changes, certificate expiry and TLS handshake failures, and SIP OPTIONS health. Send all of these to the SIEM.
Metric: share of call legs using TLS and SRTP, by trunk.
Metric: days to certificate expiry for every SBC certificate, with zero expired.
Metric: blocked SIP requests per day from unknown sources, as a trend.
Metric: international and premium rate call cost anomalies detected and closed.
Metric: admin accounts with multi-factor authentication, target 100 percent apart from the vaulted break-glass account.

Framework mapping

Control area	NIST CSF 2.0	NIST SP 800-53 Rev 5	ATT&CK
Perimeter placement and peer access lists	PR.IR-01	SC-7
TLS and SRTP	PR.DS-02	SC-8, SC-13	T1557 Adversary-in-the-Middle
Certificates	PR.AA-01	SC-17, IA-5
Rate limiting and call admission	PR.IR-01	SC-5	T1498 Network Denial of Service
Admin access	PR.AA-05	AC-17, IA-2	T1078 Valid Accounts
Hardening and baseline	PR.PS-01	CM-2, CM-7
Logging and monitoring	PR.PS-04, DE.CM-01	AU-2, SI-4

Common failure patterns

Management interface on the public side. The web interface answers on the external address because it was enabled during setup and never moved.
Any-source SIP. The external interface accepts SIP from anywhere instead of only the carrier and cloud provider ranges, inviting scanning and fraud attempts.
Expired SBC certificate. Nobody owns renewal and calls stop on the expiry date.
No destination controls. International and premium rate destinations are open to every user, so a compromised extension or trunk can run up large bills.
Media bypass with wide open UDP. Media ports are opened to the whole internet rather than to the provider's documented ranges and internal subnets.
Shared admin account. A single admin login is used by staff and the integrator, with no multi-factor authentication or audit trail.

Practitioner checklist

Place each SBC in a DMZ with separate carrier, external and internal interfaces filtered to documented peers.
Use SIP over TLS and SRTP on all external legs; for Direct Routing enforce TLS 1.2 with the documented cipher suites.
Generate SBC keys on the device, track certificate expiry with alerts and test renewal on the standby SBC.
Enable topology hiding and strip product and version headers on external legs.
Set session limits, call rate limits and destination blocks per trunk; set MaxConcurrentSessions in Direct Routing.
Keep SIP OPTIONS health checks on (SendSIPOptions in Direct Routing) so provider monitoring and failover work.
Restrict management to a dedicated network with named, MFA-protected accounts and a vaulted break-glass account.
Apply vendor security updates promptly and compare running configuration with the approved baseline monthly.
Send SBC logs and call detail records to the SIEM and alert on fraud and flood patterns.

Session Border Controller Security Guide: Hardening SBCs for SIP Trunks and Teams