# TLS versions and cipher support across UC platforms

Canonical: https://warmtransfer.net/knowledge/tls-version-support-uc

Last verified: 2026-10-02

Microsoft forces TLS 1.2 on the Teams Direct Routing SIP interface, while Webex Calling supports TLS 1.2 and TLS 1.3 for secure SIP[^9][^13]. RFC 8996 and RFC 9325 set the baseline: TLS 1.0 and TLS 1.1 must not be used, TLS 1.2 must be supported, and TLS 1.3 should be supported[^2][^3][^5].

## Standards baseline

RFC 8996 states that TLS 1.0 MUST NOT be used and that negotiation of TLS 1.0 from any version of TLS MUST NOT be permitted[^2]. RFC 8996 states the same for TLS 1.1: it MUST NOT be used, and negotiation of TLS 1.1 from any version of TLS MUST NOT be permitted[^3]. RFC 9325 says implementations MUST support TLS 1.2 and SHOULD support TLS 1.3[^5]. If TLS 1.3 is implemented, RFC 9325 says the implementation MUST prefer to negotiate it over earlier versions[^5].

RFC 9325 recommends 4 TLS 1.2 cipher suites[^4]:

- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256[^4]
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384[^4]
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256[^4]
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384[^4]

## Microsoft Teams Direct Routing

Microsoft forces TLS 1.2 on the Teams Direct Routing SIP interface, and SBCs must be configured to support TLS 1.2[^9]. SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061[^11]. The port toward the SBC is whatever is configured on the SBC[^11].

Teams Direct Routing accepts SBC connections that use any of these cipher suites[^7]:

- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384[^7]
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256[^7]
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384[^7]
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256[^7]

The GCM suites in that list are also among the TLS 1.2 suites that RFC 9325 recommends[^7][^4]. The CBC suites accepted by Teams Direct Routing are not among the RFC 9325 recommendations[^7][^4]. Neither ECDSA suite recommended by RFC 9325 appears in the Teams Direct Routing list[^7][^4].

Microsoft SIP endpoints currently trust SBC certificates that lack the Client Authentication EKU[^8]. Microsoft says it will communicate in advance if that changes[^8].

WarmTransfer's reading of the sources is that, as of 2026-10-02, Microsoft's Direct Routing connect, plan and what's-new pages document only TLS 1.2 cipher suites and do not state that the SIP interface negotiates TLS 1.3[^10]. We infer that an SBC trunk to Teams Direct Routing restricted to TLS 1.3 only would risk handshake failure, because Microsoft documents only TLS 1.2 cipher suites for that interface, and that such trunks should allow TLS 1.2[^6].

Microsoft began deprecating TLS 1.0 and 1.1 for commercial Office 365 customers on October 15 2020[^1]. That deprecation started in January 2020 for DoD and GCC High instances[^1].

See also [Microsoft teams direct routing](https://warmtransfer.net/knowledge/microsoft-teams-direct-routing).

## Webex Calling

Webex Calling supports TLS 1.2 and TLS 1.3 for secure SIP[^13]. For mutual TLS with Webex Calling, a local gateway certificate must be signed by a supported CA[^12]. That certificate must also carry the trunk FQDN as common name or subject alternative name[^12].

See also [Certificate lifecycle management for voice](https://warmtransfer.net/knowledge/certificate-lifecycle).

## Diagnosing version mismatches

On a trunk to Teams Direct Routing, first confirm that the SBC offers TLS 1.2, because Microsoft forces TLS 1.2 on that interface[^9]. Confirm that the SBC offers a cipher suite that Teams Direct Routing accepts[^7]. Confirm that the SBC targets destination port 5061 on the Microsoft SIP proxy[^11]. We infer that an SBC policy restricted to TLS 1.3 only risks handshake failure on that interface[^6]. On a Webex Calling local gateway using mutual TLS, check that the certificate's common name or subject alternative name matches the trunk FQDN and that a supported CA signed it[^12].

See also [SIP TLS handshake failures on trunks](https://warmtransfer.net/knowledge/sip-tls-handshake-failures).

## Applicability

Applies to: Microsoft Teams Phone Direct Routing, Cisco Webex Calling, and Microsoft Office 365. Deployments: multi-tenant. Sources checked 2026-10-02. Microsoft's own deprecation of TLS 1.0 and 1.1 began on October 15 2020 for commercial Office 365 customers and in January 2020 for DoD and GCC High instances[^1]. WarmTransfer's reading of the sources is that Microsoft's Direct Routing pages document only TLS 1.2 cipher suites as of 2026-10-02[^10].

## What remains uncertain

WarmTransfer's reading of the sources is that Microsoft's Direct Routing pages, as of 2026-10-02, do not state that the SIP interface negotiates TLS 1.3[^10]. A Microsoft roadmap or forward-looking support statement for TLS 1.3 on Teams Direct Routing is not covered by the sources below. Third-party SBC support for TLS 1.3 on Teams and Webex trunks is not covered by the sources below. TLS version and cipher policies for bring-your-own-carrier trunks into contact-centre cloud platforms are not covered by the sources below.

## Sources

[^1]: Microsoft began deprecating TLS 1.0 and 1.1 for commercial Office 365 customers on October 15 2020, after starting in January 2020 for DoD and GCC High instances. Source: [Preparing for TLS 1.2 in Office 365 and Office 365 GCC](https://learn.microsoft.com/en-us/purview/prepare-tls-1.2-in-office-365), More information. Checked 2026-10-02.
[^2]: RFC 8996 (BCP 195) states TLS 1.0 MUST NOT be used and negotiation of TLS 1.0 from any version of TLS MUST NOT be permitted. Source: [RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://www.rfc-editor.org/rfc/rfc8996.html), Section 4. Checked 2026-10-02.
[^3]: RFC 8996 (BCP 195) states TLS 1.1 MUST NOT be used and negotiation of TLS 1.1 from any version of TLS MUST NOT be permitted. Source: [RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://www.rfc-editor.org/rfc/rfc8996.html), Section 5. Checked 2026-10-02.
[^4]: RFC 9325 recommends four TLS 1.2 cipher suites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. Source: [RFC 9325: Recommendations for Secure Use of TLS and DTLS](https://www.rfc-editor.org/rfc/rfc9325.html), Section 4.2. Checked 2026-10-02.
[^5]: RFC 9325 (BCP 195) says implementations MUST support TLS 1.2 and SHOULD support TLS 1.3, and if TLS 1.3 is implemented MUST prefer to negotiate it over earlier versions. Source: [RFC 9325: Recommendations for Secure Use of TLS and DTLS](https://www.rfc-editor.org/rfc/rfc9325.html), Section 3.1.1. Checked 2026-10-02.
[^6]: An SBC trunk to Teams Direct Routing that is restricted to TLS 1.3 only would risk handshake failure, because Microsoft documents only TLS 1.2 cipher suites for that interface; such trunks should allow TLS 1.2 (inferred). Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), Connect the SBC to the tenant; Considerations, TLS bullet. Checked 2026-10-02.
[^7]: Teams Direct Routing accepts SBC connections using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 or TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256. Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), Connect the SBC to the tenant; Considerations, cipher suite list. Checked 2026-10-02.
[^8]: Microsoft SIP endpoints currently trust SBC certificates that lack the Client Authentication EKU and Microsoft says it will communicate in advance if that changes. Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Clarification on Client Authentication Extended Key Usage (EKU). Checked 2026-10-02.
[^9]: Microsoft forces TLS 1.2 on the Teams Direct Routing SIP interface and SBCs must be configured to support TLS 1.2. Source: [Connect your Session Border Controller (SBC) to Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-connect-the-sbc), Connect the SBC to the tenant; Considerations, TLS bullet. Checked 2026-10-02.
[^10]: As of 2026-10-02 Microsoft's Direct Routing connect, plan and what's-new pages document only TLS 1.2 cipher suites and do not state that the SIP interface negotiates TLS 1.3 (inferred). Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Whole page (no TLS 1.3 entry); compare ms-learn-dr-connect-sbc Considerations. Checked 2026-10-02.
[^11]: Teams Direct Routing SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061, while the port toward the SBC is whatever is configured on the SBC. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling ports table. Checked 2026-10-02.
[^12]: For mutual TLS with Webex Calling a local gateway certificate must be signed by a supported CA and carry the trunk FQDN as common name or subject alternative name. Source: [Security requirements for Webex Calling](https://help.webex.com/en-us/article/jwkbt2/Security-requirements-for-Webex-Calling), Local Gateway certificate requirements for mutual TLS. Checked 2026-10-02.
[^13]: Webex Calling supports TLS 1.2 and TLS 1.3 for secure SIP. Source: [Security requirements for Webex Calling](https://help.webex.com/en-us/article/jwkbt2/Security-requirements-for-Webex-Calling), TLS version supported for secure SIP. Checked 2026-10-02.
[^14]: The Webex Calling secure SIP cipher list includes the TLS 1.3 suites TLS_AES_256_GCM_SHA384 and TLS_AES_128_GCM_SHA256 alongside ECDHE, DHE and ECDH TLS 1.2 suites with AES-GCM and AES-CBC. Source: [Security requirements for Webex Calling](https://help.webex.com/en-us/article/jwkbt2/Security-requirements-for-Webex-Calling), TLS ciphers supported for secure SIP. Checked 2026-10-02.