RDK-B Penetration Accelerates as Deutsche Telekom Confirms Deployments Surpass 1 Million

In June 2026, German Internet Service Provider (ISP) Deutsche Telekom (DT), which ranks 1st domestically in Germany and 8th globally in terms of total fixed broadband subscribers, revealed that over 1 million Wi-Fi Customer Premises Equipment (CPE) operating on the Reference Design Kit-Broadband (RDK-B) middleware platform have been deployed within its network. This is a major milestone in DT’s RDK-B journey, which began in October 2021 when DT abandoned its proprietary Linux-based middleware platform and chose to gradually migrate to the RDK framework. This announcement also signifies an important advancement in the journey of RDK itself. Since RDK’s inception in 2012, the open-source standard’s primary sponsor has been U.S. cable ISP Comcast, and until recently, large-scale adoption of RDK was limited to cable ISPs like Comcast and Charter. DT’s mass deployment of RDK CPE, therefore, heralds a significant expansion of the platform’s reach, as it is the first time that an ISP relying on predominantly fiber and DSL broadband infrastructure has successfully scaled up the technology across its network.

Historically ISPs and, to a lesser extent, CPE vendors themselves have built and maintained their own proprietary middleware platforms, which are used to remotely manage CPE and deliver services. While this proprietary approach does allow for unique differentiation between platforms, it is also a significant financial and resource burden on ISPs, and means that ISPs must start from scratch each time they decide to develop a platform. Yet, the industry is in the process of shifting away from this model as ISPs gradually move over to open-source code, with developers using this as their base, and then adding differentiating features on top. There are numerous advantages of an open-source approach, including:

• Accelerated Time to Market (TTM): Developers do not need to start from scratch with each new product, as they can use the open-source code as their starting foundation.
• Reduced Resource Requirements: Development can draw upon the resources of the entire community, accelerating production.
• More Thorough Code Testing: Community feedback, testing, and reviews ensure that the code is inspected in greater detail, and issues are identified faster. The community can also contribute fixes to issues, helping to bring their swift resolution.
• Engagement with Wider Number of Vendors: There are often only a limited number of suppliers/partners capable of working with a proprietary source code, with this number decreasing the more advanced the code becomes. In contrast, open-source frameworks are well understood throughout the ecosystem. Having more vendors to work with increases flexibility and helps drive down costs.
• Enhanced Scalability: A common infrastructure approach helps support scaling up across platforms and different technology generations.
• Smoother Third-Party Integrations: It is not realistic for third-party developers to modify their product so that it is compatible with numerous different proprietary platforms. With open-source approaches, third parties have a common framework with consistent Application Programming Interfaces (APIs) to work with, helping to facilitate their integrations (and the cost of doing so). Supporting the smooth adoption of third-party applications will also help boost the pace of service innovation.

Despite the many benefits of open-source approaches, there are also several major downsides, such as:

• Potential for Free Riders: Many members of an open-source ecosystem are prone to taking the available code, but never contributing themselves. This damages the long-term sustainability of open-source initiatives.
• Unclear Accountability: A dispersed open-source ecosystem means that no single entity is responsible for the overall upkeep of the platform, so it is unclear where the buck stops.

RDK-B and prplOS are the two open-source middleware platforms most commonly used by ISPs. RDK’s initial development was spearheaded by large U.S. Tier One cable ISPs, and they continue to exert a controlling influence over the standard. On the other hand, prplOS is managed by the prpl Foundation membership community, and is more closely associated with ISPs with predominantly fiber networks, such as Orange and Verizon. In terms of market penetration, RDK-B is considerably more established than prpl. Whereas the first RDK-equipped CPE was launched by Comcast in late 2015, it wasn’t until late 2024 that Orange deployed the first prpl-based CPE.

During the course of its 10+ years on the market, RDK-B has matured into a tried and tested platform receiving widespread, and expanding, support throughout the Wi-Fi ecosystem. All of the mainstream Wi-Fi infrastructure System-on-Chip (SoC) vendors support the technology, and most of the major Wi-Fi CPE vendors (Vantiva, Sagemcom, Sercomm) have also released hardware pre-integrated with RDK-B. There is also an ever-expanding list of ISPs deploying RDK-B-enabled CPE. In late 2025, Vodafone confirmed that it would leverage RDK for its fiber and cable Wi-Fi 7 CPE in both the United Kingdom and Germany.

Yet, prplOS interest and adoption is growing fast, driven by demand for its many advanced differentiating features. Chief among these is support for the containerization of services, which helps with deploying and monetizing value-added services. prpl also boasts strong mesh Wi-Fi capabilities thanks to prplMesh, which makes it ideal for multi-Access Point (AP) networking. Membership in the prpl Foundation is expanding rapidly, and now counts CPE vendors such as Actiontec, Arcadyan, and Askey among its ranks. The member community hosts annual prpl Summits to stimulate the platform’s development and commercialization, although the ecosystem is still significantly smaller than RDK-B’s.

By adopting RDK-B, DT is able to deploy a unified platform across all variants of broadband access (Digital Subscriber Line (DSL), cable, fiber, Fixed Wireless Access (FWA)) and throughout its sprawling global network of broadband subscribers, which spans Germany, the United States, and nine other European countries, including Austria, Poland, and Hungary. Standardized middleware also enables DT to effortlessly deploy new value-added services and smart home capabilities simultaneously to its millions of residential customers. As to why DT opted for RDK-B over prpl, it is likely that DT took a conservative approach and felt more comfortable with RDK-B’s mature ecosystem and extensive pre-integrated broadband stack over prpl’s nascent, but yet not widely tested offering.

ABI Research recommends that ISPs contemplating adopting or expanding their utilization of open-source middleware platforms should consider the following:

• Fulfill Obligations to the Open-Source Ecosystem: For open-source initiatives to achieve long-term sustainability, it is vital that ecosystem participants do not merely adopt the open-source code, but also that they become active contributors to its development and refinement. That means contributing new features that they have created, or patches to the original code. Without this ecosystem-wide input, the open-source project becomes unsustainable, and it will be unable to realize its full potential.
• Adapt to the Needs of Open-Source Communities: ISPs, CPE vendors, or software developers adopting open-source platforms are likely to have to make significant adjustments to their product development process to succeed within the open-source framework. Whereas companies used to proprietary development may be more familiar with top-down decision-making, total executive control, and rapid execution, working within an open-source community requires time and patience, as it is necessary to work with the broader community and the project’s governing body in order to get changes accepted.
• Invest in Full Integrations: There are two distinct approaches to development with open-source middleware. Either the developer conducts a full integration of its product with the source code via APIs, or it chooses the forking method, in which a separate copy of the original Software Development Kit (SDK) is created. Meanwhile, the forking method does give the developer full control over the code, allowing it to integrate non-standard features; for example, in the long run, product maintenance becomes more challenging, and vulnerabilities addressed in the original source code will persist in the forked version. Therefore, it is recommended that developers invest in full integrations, as this will create a more stable, long-term product that requires less maintenance.
• Select the Optimal Open-Source Middleware Platform: Each middleware platform has its own unique advantages and disadvantages, and it is vital that ISPs choose the one that is best aligned with their needs. If unsure, and if it is within their capabilities, ISPs may also consider working within multiple ecosystems, so they can benefit from the advantages of multiple platforms and achieve greater interoperability throughout the entire ecosystem.