Your Teams Direct Routing SBC Has a Deadline. Here’s What to Do Before March Ends.
Microsoft is replacing the Certificate Authority (CA) root chain it uses for Teams Direct Routing. Every SBC connected to your deployment needs its trust store updated before the end of March 2026. Miss that window, and when Microsoft starts rotating its server-side certificates in April, your SBC will fail the TLS handshake and calls will stop connecting.
The failure mode is a hard stop, not a gradual degradation, and nothing in the Teams interface points back to the certificate mismatch as the cause.
The June 2026 date you may have seen in advisories is full enforcement. March 31 is the operational deadline for SBC-side updates. This guide covers exactly what’s changing, the specific certificates you need to install, and how to verify your SBC is ready.
Why This Is Happening
This change doesn’t originate with Teams. It starts in the trust stores.
In February 2025, Google updated its Chrome Root Program Policy (v1.6), deprecating the Client Authentication Extended Key Usage (EKU) in TLS server certificates trusted by Chrome and Mozilla. Starting June 2026, certificates must use Server Authentication EKU exclusively.
Microsoft Teams uses mutual TLS (mTLS) for SIP signaling between its infrastructure and your SBC. Both sides present and validate certificates. Microsoft’s existing CA chain included the Client Authentication EKU, exactly what the browser policy targets. To stay aligned with browser trust stores, Microsoft is moving to a DigiCert-rooted chain and its own Microsoft 2017 Root CAs.
This doesn’t change anything about the Teams user experience. Voice quality, call routing, and meeting features are unaffected. What changes is the certificate chain your SBC validates when it receives a TLS handshake from Microsoft’s SIP endpoint.
The Timeline
| Date | Event |
|---|---|
| February 2026 (passed) | SBCs should already trust the new DigiCert and Microsoft 2017 Root CAs |
| End of March 2026 | Hard deadline: SBC trust stores must be updated; Microsoft provides a test SIP endpoint to validate |
| April 2026 | Microsoft begins deploying new server-side certificates on the Teams SIP interface |
| June 2026 | Full enforcement: old CA chain retired; non-updated SBCs lose connectivity |
If your SBC hasn’t been updated, you’re already past the recommended window.
After April, connections that fail due to certificate mismatch produce TLS handshake errors rather than graceful SIP responses. For organizations using Direct Routing for PSTN calls, that means calls stop connecting across your entire SBC deployment.
The 7 Root CAs You Need to Add
Microsoft’s updated requirements specify seven root CAs. All seven must be present and trusted in your SBC’s TLS configuration; each covers a different part of Microsoft’s certificate issuance infrastructure.
| Root CA Name | Thumbprint (SHA-1) |
|---|---|
| DigiCert Global Root CA | A8985D3A65E5E5C4B2D7D66D40C6DD2FB19C5436 |
| DigiCert Global Root G2 | DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 |
| DigiCert Global Root G3 | 7E04DE896A3E666D00E687D33FFAD93BE83D349E |
| DigiCert TLS ECC P384 Root G5 | 17F3DE5E9F0F19E98EF61F32266E20C407AE30EE |
| DigiCert TLS RSA 4096 Root G5 | A78849DC5D7C758C8CDE399856B3AAD0B2A57135 |
| Microsoft ECC Root Certificate Authority 2017 | 999A64C37FF47D9FAB95F14769891460EEC4C3C5 |
| Microsoft RSA Root Certificate Authority 2017 | 73A5E64A3BFF8316FF0EDCCC618A906E4EAE4D74 |
Two operations are involved here, and they’re distinct. What you’re updating is the list of CAs your SBC trusts when validating the certificate Microsoft presents during the mTLS handshake. Your SBC’s own certificate (the one it presents to Teams) is not changing; it still needs to be issued by a CA on Microsoft’s approved SBC certificate issuers list.
How to Verify the Update Worked
Microsoft has published a dedicated test SIP endpoint for validating TLS connectivity against the new CA chain. It accepts SIP OPTIONS only and is designed exclusively for connectivity testing; don’t route voice traffic through it.
A successful TLS handshake with the test endpoint confirms your SBC trusts certificates issued by the new chain. A handshake failure means you have missing or untrusted root CAs.
Watch for these failure indicators if the Microsoft CA change has already taken effect for your deployment:
- SIP OPTIONS not received from Microsoft: usually the first sign of a TLS handshake failure
- “Certificate validation failed” errors in the SIP trace
- Direct Routing domain deactivation in the Teams admin center (Teams reads sustained SIP OPTIONS failure as an SBC outage)
If you’re seeing any of these and your trust store hasn’t been updated, adding the seven root CAs above resolves them.
Where ProSBC Comes In
ProSBC is TelcoBridges’ software-based, carrier-grade SBC. Here’s how it maps to everything covered in this article:
- Supports SIP over TLS natively: TLS is mandatory for Teams Direct Routing and ProSBC enforces it at the NAP level
- TLS trust store updates are applied at the Network Access Point (SIP Trunk) level: import the PEM text-based content of the seven root CAs into the TLS profile assigned to your Microsoft Teams NAP, save, and apply
- PEM text-based content can be found here: DigiCert Trusted Root Authority Certificates
- SRTP for media encryption is configured as a separate layer and is unaffected by this CA root change
- Built-in call trace captures SIP signaling at the NAP level, showing TLS session establishment and SIP OPTIONS exchange
- Live Wireshark capture provides packet-level visibility into the TLS handshake, useful for pinpointing exactly which certificate step is failing
No hardware changes, no software upgrades, no re-certification with Microsoft. The update is a configuration task.
