As more VoIP providers shift toward a mutual TLS (mTLS) model to secure voice device provisioning, one of the biggest roadblocks they face is their existing install base: legacy devices with inconsistent capabilities, outdated firmware, and limited support for modern certificate handling. When you have a fleet of Polycom SoundPoint IP 650s mixed with modern Poly, Yealink, and Cisco, you've got a challenging situation.
In this article, we'll provide strategies for migrating to mTLS for your voice device management while minimizing service disruption, avoiding customer attrition, and working within real-world constraints. We'll also explore insights on how to handle legacy devices, smart firmware upgrades, and tools like F5 Labs BIGIP, HAProxy, and BroadWorks DMS. mTLS is one of the standard tools used for Zero Trust Security (aka Zero Trust Architecture).
Why Are Legacy Devices the Hardest Part of mTLS Migration?
For providers with tens or hundreds of thousands of deployed devices, especially white-labeled or older models, transitioning to mTLS isn't as simple as flipping a switch. Legacy devices pose several challenges, including:
-
Incompatible firmware that lacks support for client certificates.
-
No internal clocks or NTP configuration, which is required for certificate validation.
-
Outdated certificate stores that don't recognize modern certificate authorities (CAs).
-
Nonstandard provisioning logic or buggy HTTPS implementations in some cases.
While many devices will accept the new TLS requirements readily, some special steps are necessary for most migrations.
4 Steps for Migrating Legacy Devices
Some providers adopt a "cap-and-grow" strategy, which allows existing devices to continue provisioning through the traditional method (e.g., HTTP authentication) while enforcing mTLS only on new devices or those being actively migrated. Legacy devices may have some mitigating controls, such as ACL/firewall rules, that limit the non-mTLS device management access to only those customers. This phased approach reduces risk and customer disruption, because activating an mTLS requirement is the only reliable way to find out which of the devices is incompatible with mTLS.
Here's how it looks in practice:
-
Deploy a Device Management Solution (DMS) environment that enforces mTLS for all its users. This means that every SIP endpoint device that connects in to retrieve its configuration will be prompted to upload its own certificate, and the DMS platform will verify that certificate has been signed by a trusted party -- usually a device manufacturer.
-
Direct only new or opt-in devices to the new environment.
-
Maintain the existing DMS for legacy hardware still using password- or MAC-based provisioning.
-
After firmware update and certificate readiness, you can migrate the devices of any customer choosing to upgrade or being audited to the mTLS DMS.
This model allows providers to begin enforcing strong security without requiring a complete, immediate forklift upgrade of the entire device base.
Firmware Updates and Certificate Trust Stores
Some devices, especially older SIP phones, require firmware upgrades to enable support for client-side TLS certificate presentation, include an NTP configuration, or install a new CA certificate so the device trusts the mTLS-enabled server.
Two approaches for this are:
-
Provider-Controlled CA: Deploy your own CA (e.g., VoIP Provider CA) and install it on legacy devices.
-
Public CA Integration: Use certificates from DigiCert, GoDaddy, AWS, or Let’s Encrypt, but you may still require a trusted CA installation on each device. Since VoIP devices can be functional for years, even decades, the older signing certificates they were built to trust may have long expired.
Either way, you’ll need tooling and logic to ensure each device is updated before it’s redirected to the mTLS-enabled DMS.
Using F5 and HAProxy as Smart Gateways
Bridging the gap between legacy and modern devices during migration requires a flexible proxy layer like F5 or HAProxy. These act as smart intermediaries between devices and the DMS, enabling conditional logic and phased upgrades.
F5 Labs BIGIP
The F5 Labs BIGIP is a "Swiss Army knife" for mTLS because of its granular inspection and routing capabilities, such as:
-
Inspecting incoming TLS connections and evaluating the client certificate.
-
Examining the firmware version, IP headers, or requested URLs.
-
Using iRules to route to different DMS URLs, trigger a firmware update response, or reject connections from improperly configured devices.
For example, if a device presents a certificate signed by an outdated CA or uses old software, the F5 can respond with a firmware upgrade pointer or redirect to an onboarding service.
HAProxy
The open-source software HAProxy has capabilities in conditional logic, including:
-
Inspecting TLS sessions.
-
Allowing for certificate validation and simple routing rules.
-
Providing a more affordable or simpler alternative for smaller-scale environments.
Some of ECG's service providers use HAproxy in this role, but the vast majority are using the built-in device management (such as the NetSapiens or BroadWorks DMS) or F5 BIGIP LTM.
Using BroadWorks DMS
Cisco BroadWorks DMS has native support for client TLS certificate validation, using a trusted CA list associated with each Identity Device Profile Type (IDPT). However, it lacks some of the detailed behavior control found in F5.
One key limitation is that if a device provides a certificate signed by Poly but requests a config for an OB device, BroadWorks will still allow it as long as the CA is on the trust list. The risk here would be the disclosure of a signing certificate used by one of the manufacturers. For example, if the key used to sign Obi ATA certificates was disclosed, attackers could use it to sign false certificates and launch attacks. While this can work well if you trust manufacturer-issued certificates, you give up tight control over which certs can request which config files.
With the F5 Labs BIGIP, you can ensure that an XYZ-brand device is only downloading a configuration file for XYZ. Furthermore, you can ensure it only downloads the configuration file corresponding to the signed certificate. The Common Name (CN) value of certificates should include the MAC address of the device.
Still, BroadWorks DMS provides a good foundation for providers who aren't ready to add a full F5 layer. You can use it to define trusted CAs, require client certs on specific IDPTs, or monitor compliance with device tagging and logging.
Supporting Tools: Alpaca for Monitoring
Though not a provisioning server, Alpaca is an observability and monitoring layer. It can detect whether devices have successfully downloaded their config files. Providers can also tie it into migration dashboards to track device readiness.
In short, Alpaca doesn't enforce security directly, but it provides visibility into what's working and what's not during a rollout.
Transition to mTLS With Expert Guidance From ECG
mTLS is no longer optional for providers who want to stay competitive and secure. But you don’t need to flip everything overnight. Instead, you can:
-
Segment devices that can access a legacy DMS (Device Management System) by using mitigating controls like Access Control Lists (ACLs) or Firewalls.
-
Cap-and-grow with new provisioning rules to ensure all your new devices receive the best security requirements.
-
Leverage tools like F5 Labs BIGIP, HAProxy, and BroadWorks DMS where appropriate.
-
Plan for firmware and CA updates before the switch.
-
Monitor everything – especially the parts you think are already working.
If you make it hard for attackers and easy for your customers, you’re doing it right.
Need help developing your migration plan, evaluating device readiness, or setting up a smart provisioning gateway? ECG’s team brings both strategic insight and practical engineering to make mTLS possible without blowing up your ops team or budget. Reach out today to learn more.
