What’s Holding Back OpenRoaming and Passpoint Adoption (And How to Fix It)

What’s Holding Back OpenRoaming and Passpoint Adoption

By the WayFi Wireless Team

OpenRoaming and Passpoint have the potential to revolutionize how users connect to wireless networks—enabling seamless, secure roaming across networks with zero user intervention. At WayFi Wireless, we’ve deployed these technologies across diverse environments and have seen the promise firsthand.

But despite years of development and growing awareness, widespread adoption remains limited. Through our work with the Wireless Broadband Alliance (WBA) and our engagements with dozens of organizations trying to adopt these technologies, we’ve identified several systemic issues. This article outlines what’s holding OpenRoaming back—and what we believe needs to happen to move forward.

1. The "Turn-Key" Tooling Isn’t Ready for Production

While OpenRoaming as a concept is technically sound, the tooling intended to support its implementation is still in a nascent stage. Key components like the Onboarding Portal and Connector—which are supposed to serve as the foundation for integrating into the federation—are currently maintained by a very small team, often part-time, and sometimes with minimal background in scalable, production-grade software development.

The result is that these tools, while functional at a basic level, are best described as proofs of concept. They lack the polish, performance, maintainability, and documentation necessary for serious production deployment. Bugs are not uncommon. Updates are infrequent and inconsistently reviewed. There is often no clear roadmap or SLA to rely on. Many adopters find themselves debugging code instead of deploying a network, which defeats the purpose of having standardized tooling in the first place.

For small-to-medium ISPs, MSPs, and venue operators, this becomes a significant blocker. These rganizations often lack the internal engineering depth or budget to dedicate months of work to reverse engineering, modifying, or stabilizing these tools. Most expect to download a container, follow well-documented setup steps, and be up and running within a day or two. That simply isn’t possible today without outside help.

In our direct experience and in discussions with other implementers, setting up OpenRoaming requires aggressive handholding and extensive one-off configuration, even for relatively straightforward deployments. For the system to scale, that cannot remain the norm.

Additionally, these tools tend to assume a level of technical expertise and operational knowledge that most new adopters won’t have. There are few guardrails, no built-in validation, and little in the way of actionable error messages. Troubleshooting is often a black box unless you already know how it’s supposed to work.

This lack of maturity undermines confidence in the broader OpenRoaming ecosystem. A potential partner’s first experience is often plagued by hours of trial and error, confusion over required values or formats, and an unclear understanding of what is broken vs. what is simply misconfigured. That’s not an onboarding experience—it’s a deterrent.

To drive real growth, these tools need to be:

• Well-maintained with a clear ownership model

• Thoroughly documented, with working examples

• Actively tested, with CI pipelines and staging environments

• Modular and flexible, but with sane defaults

• Supported by the community, with responsive issue tracking and contribution guidelines

Ultimately, stable, turnkey tooling is what will enable adoption at scale. Without it, every new implementation becomes a custom integration project—and that simply won’t scale fast enough to meet the ambitions of OpenRoaming.

2. Repositories Are Not Documentation

A key challenge in the current OpenRoaming ecosystem is the conflation of source code repositories with formal documentation. While it’s common for open-source projects to include some guidance within their repos, there is a critical difference between code that evolves and documentation that educates and informs. Unfortunately, that distinction is often blurred or ignored in the current landscape.

Repositories are meant to reflect active development. They are expected to change rapidly, accept community contributions, and prioritize functionality and innovation. In contrast, documentation should be stable, curated, and focused on guiding users—especially new adopters—through consistent and repeatable deployments.

In the OpenRoaming world today, too much essential implementation knowledge is:

• Scattered across multiple unlinked repositories

• Hidden in README files that mix development notes with setup steps

• Outdated due to lack of maintenance or version control tied to releases

• Informally communicated in private Slack channels, meetings, or emails

This lack of structure makes it difficult to know what’s current, what’s deprecated, or what’s required. For new adopters, it’s not always clear which documents are authoritative or whether they apply to a particular version of the codebase.

We’ve encountered many cases where the only way to get clarification on how a component works—or how to configure it properly—is to ask one of the handful of individuals who built it. That kind of tribal knowledge sharing does not scale, and it makes OpenRoaming feel like a closed ecosystem rather than the open federation it aspires to be.

Moreover, the lack of clear documentation standards means even well-intentioned contributors often hesitate to help. Without templates, versioning guidelines, or review processes, writing or editing documentation becomes risky and inconsistent. Contributors don’t know where to place their work, how to submit it, or who reviews it. And users don’t know where to look for answers.

This creates a compounding problem:

• Incomplete or outdated docs lead to frustration.

• Frustrated implementers don’t contribute improvements.

• The next user has the same issue, and the cycle continues.

To break this cycle, we believe the OpenRoaming ecosystem—especially under WBA stewardship—needs to invest in purpose-built, centralized documentation that:

• Lives independently of development repositories

• Clearly separates required steps from optional enhancements

• Follows a consistent format and navigation structure

• Is version-controlled and mapped to software releases

• Supports contributions and feedback through a public-facing editorial process

Adoption depends on accessibility. Right now, too much of the onboarding experience is based on guesswork, Slack messages, or waiting for one of the maintainers to get back to you. That’s not sustainable.

Great documentation is not a nice-to-have—it’s infrastructure. It multiplies the effectiveness of every engineer who reads it. Without it, even the best tools and protocols fail to gain traction.

3. We Need More Identity Providers—Specifically Carriers

The OpenRoaming ecosystem often frames its growth challenge as a need to onboard more Identity Providers (IDPs) and Access Network Providers (ANPs). While this may be directionally accurate, it overlooks where the true bottleneck lies: the identity side of the equation—specifically, large-scale IDPs such as mobile network operators and major service providers.

Access Network Providers are not in short supply. In fact, thanks to rising interest in carrier offload, large venue deployments, and monetized Wi-Fi platforms, the number of ANPs is growing quickly. Many MSPs, ISPs, and Wi-Fi aggregators are already preparing or beginning to support OpenRoaming, driven by both user experience improvements and commercial incentive.

Where the ecosystem is falling short is on the identity side—particularly among the types of IDPs that can unlock instant, massive scale.

The most impactful IDPs are not individual campuses, coffee shops, or cities acting as identity authorities. They are carriers—entities that already manage the digital identities of tens or hundreds of millions of subscribers. These are the organizations that can singlehandedly bring entire populations into the OpenRoaming federation with minimal user friction.

For example, a single Tier 1 mobile carrier integrating as an OpenRoaming IDP could enable automatic roaming for tens of millions of subscribers—on every compatible ANP across the globe. Compare that to the effort required to onboard and support thousands of small IDPs, each with a fragmented user base, limited identity reach, and resource-constrained IT staff. The cost-to-impact ratio is clear.

This isn’t to say smaller IDPs have no role. They absolutely do—especially in education, enterprise, and vertical-specific federations. But if we’re talking about how to achieve user scale, then the path is through carriers.

Unfortunately, the current onboarding process for carriers is slow, expensive, and heavily reliant on legacy vendors like Radiator or Single Digits. As noted earlier, technical integrations alone can take years. Business negotiations add even more time. This makes OpenRoaming adoption unattractive for carriers already juggling complex RAN upgrades, spectrum licensing, and eSIM rollouts.

We’ve seen it firsthand. Many carriers express interest in OpenRoaming, only to walk away when they realize the effort and cost required to onboard as an IDP. That’s not a sustainable model for ecosystem growth.

What’s needed is:

• Streamlined, modern tooling for IDP onboarding

• Better documentation targeted at carrier identity teams

• Support for DIAMETER, 5G-AKA, and HSS/HLR integration

• Clear ROI models to help carriers justify investment

• Reduced reliance on monopolistic vendors

If the WBA and the broader community want real-world adoption at global scale, carrier onboarding must be the top priority. A handful of successful carrier integrations would do more to drive adoption than hundreds of isolated deployments.

Scaling OpenRoaming is not about increasing logos on a webpage. It’s about connecting people. And the fastest, most efficient way to do that is through the networks that already serve them.

4. Carriers Have Too Few Implementation Options

One of the most critical but under-addressed issues in OpenRoaming adoption is the lack of viable implementation paths for carriers. Right now, most mobile network operators that want to join as Identity Providers (IDPs) are effectively limited to choosing between Radiator or Single Digits. These vendors have played an important role in early OpenRoaming deployments, but they now represent a significant bottleneck in the ecosystem.

From a technical perspective, both vendors offer products that can handle DIAMETER conversion, authentication proxying, and basic federation logic. However, they are not built for rapid integration, flexibility, or openness. Their software is complex, expensive, often closed-source, and requires a high level of vendor dependency. Customizations frequently require extended support contracts, and troubleshooting or adapting for modern use cases—such as 5G-AKA or emerging roaming models—can be painfully slow.

In our direct experience, and as echoed by others in the community, just the technical onboarding process can take over two years with these vendors. That timeline doesn’t include business negotiations, regulatory reviews, or the coordination needed across carrier infrastructure teams. At that pace, it becomes nearly impossible for OpenRoaming to achieve meaningful growth through carrier integrations.

This is not just a time issue—it’s a risk management issue. Carriers evaluating OpenRoaming are already making massive infrastructure decisions around eSIM, Wi-Fi offload, 5G, and private networking. When the only way to onboard is by engaging in a long, expensive, high-friction technical process with a single vendor, most carriers will opt to deprioritize or abandon the initiative altogether.

The Problem Is Structural

Radiator and Single Digits are not inherently malicious actors. The problem is that they have too much control, and there is too little competition. When just two companies are gatekeepers for core integration functions—like DIAMETER-to-RADIUS conversion, HSS/HLR connectivity, and federation routing—the ecosystem becomes fragile and slow-moving.

In any healthy standards-driven environment, multiple vendors and open-source solutions exist to offer choice, innovation, and cost efficiency. That’s not the case here. And without viable alternatives, carrier adoption will continue to stagnate.

What the Ecosystem Needs

To break this bottleneck, the OpenRoaming community needs to:

• Encourage new vendors to enter the market with interoperable solutions

• Support open-source tooling for critical functions like DIAMETER proxying, 3GPP authentication integration, and dynamic realm routing

• Provide reference implementations that are modern, tested, and well-documented

• Allow for modular architectures so carriers can plug OpenRoaming into their existing AAA stack without rearchitecting everything

The goal should be to make it as easy to onboard OpenRoaming as it is to deploy any standard 802.1X-based identity system. Carriers should have multiple vendors to choose from, competitive pricing models, and flexibility in deployment.

In the long term, vendor diversity will reduce costs, increase innovation, and significantly accelerate adoption.

More options = faster growth = better outcomes for everyone.

The current duopoly isn’t sustainable if OpenRoaming is to meet its global ambitions. It’s time to open the doors to new players, encourage competition, and treat carrier onboarding as a community-wide priority.

5. Documentation Is Confusing, Incomplete, and Inaccessible

Of all the challenges facing OpenRoaming adoption, documentation may be the most fundamental and pervasive issue. For any open standard to succeed, especially one as technically intricate as OpenRoaming, clear and accurate documentation is critical. Without it, even the best code and the most compelling use cases are inaccessible.

Unfortunately, OpenRoaming’s documentation today suffers from multiple systemic problems:

1.Contradictory and Fragmented Sources

There is no single, up-to-date, authoritative source of truth for OpenRoaming implementers. Instead, technical guidance is scattered across:

• IETF drafts and specifications

• Outdated GitHub repositories

• Inconsistent Markdown files

• Presentation slides and PDFs

• Conversations with a handful of core contributors

Worse still, many of these sources conflict with each other. A setting recommended in one document may be explicitly discouraged in another. Diagrams and examples often reference legacy components or deprecated behaviors, with no indication of what’s current.

This creates confusion even among experienced engineers, and it makes getting started a slow and error-prone process.

2.Nonfunctional Defaults and Half-Implemented Features

In multiple cases, key features—such as dynamic policy assignment, DIAMETER conversion hooks, or advanced federation controls—are enabled in configuration by default but don’t work properly out of the box. They are either incomplete, nonfunctional, or only work in very specific deployment scenarios that aren’t clearly documented.

This leads to situations where a new adopter thinks everything is properly configured, but user sessions silently fail or produce cryptic errors that are nearly impossible to trace.

As a result, first impressions of OpenRoaming are often negative—not because the technology is flawed, but because the deployment experience is unnecessarily frustrating.

3.Not Enough Distinction Between Required and Optional Features

Another major problem is the lack of clarity around what is mandatory, what is optional, and what is deprecated.

Current documentation mixes critical must-haves (such as support for specific EAP methods or certificate formats) with optional features (like advanced logging or analytics integration) without clearly labeling them. This forces implementers to guess what is necessary to achieve basic federation, what can be deferred, and what may already be outdated.

Without that clarity, teams waste time chasing requirements that aren’t needed, skipping over those that are, or replicating functionality already handled by upstream systems.

4.Adoption Is Falling Short of the Documentation

The real-world deployments we’ve supported and studied consistently implement only a small fraction of what is described in official or semi-official documentation.

There are a few key reasons for this:

• The full documented stack is too complex or fragile to maintain in production

• The documentation does not reflect what other operators are actually running successfully

• The documentation does not align with what is possible without involving some custom development

The delta between what’s written down and what’s deployed is massive—and it’s not just us saying that. In consulting with nearly two dozen organizations attempting to deploy OpenRoaming, we’ve found that none have managed to follow the documentation to completion without intensive, direct guidance.

If consistent and successful deployment requires this level of handholding, the documentation is failing its most basic purpose.

5.It’s Behind a Paywall

To make matters worse, some of the most important documentation is hidden behind WBA’s member-only portal. This undermines the goal of growing OpenRoaming adoption.

If only large, paying members can access the most up-to-date deployment guidance, the ecosystem becomes closed by design. Smaller ISPs, MSPs, startups, integrators, and open-source developers are effectively excluded or forced to reverse-engineer the system.

Ironically, 90% or more of what’s required to deploy OpenRoaming is available publicly through IETF drafts and community content (at least from an ANP context), yet the latest updates and clarifications are behind a paywall. This inconsistency only increases confusion and slows down implementation timelines.

What Needs to Change

To accelerate adoption and reduce onboarding friction, OpenRoaming documentation needs a complete overhaul. Specifically, we recommend:

• A centralized, version-controlled documentation portal that is public and searchable

• Clear separation between:

  • Required features

  • Optional features

  • Deprecated functionality

• Documentation that maps directly to supported software versions and real-world reference deployments

• A clear distinction between standards-based behavior and WBA-specific federation requirements

• Example configurations for common roles (e.g., ANP, IDP, combined role) with minimal dependencies

• A documented contribution process so operators and developers can report gaps, submit fixes, and improve clarity collaboratively

If properly maintained, documentation should empower any capable engineer to understand and deploy OpenRoaming in one or two days—without needing insider access, closed-door meetings, or expensive consulting engagements.

Right now, that’s not the case. And until it is, adoption will remain limited to a small group of highly technical insiders—defeating the very idea of a global roaming standard.

6. The Paywall Problem

One of the most counterproductive barriers to OpenRoaming adoption is the restricted access to key technical documentation. Much of the Wireless Broadband Alliance’s (WBA) implementation guidance—including best practices, configuration examples, and architectural diagrams—is gated behind a membership paywall.

This creates a fundamental contradiction. The WBA openly advocates for increased adoption, broader industry participation, and faster rollout across carriers, enterprises, and public networks. Yet, by placing the most up-to-date and authoritative documentation behind a paywall, it effectively excludes the very engineers, startups, and integrators who are most likely to drive that adoption.

A False Sense of Exclusivity

While some level of internal documentation is understandable in a membership-based organization, the reality is that 90% or more of the information needed to deploy OpenRoaming is already publicly available through IETF drafts, open-source community contributions, and public-facing guides like those created by WayFi Wireless and others.

The unfortunate result is confusion—not clarity.

Operators and developers are left asking:

• What is the official, up-to-date configuration required by the federation?

• What is actually needed to make OpenRoaming work in production?

• What are other adopters successfully running today?

This disconnect forces implementers to rely on outdated specs, guesswork, or tribal knowledge shared in Slack threads, private chats, or consulting engagements. That’s not how open standards are supposed to function.

Reinforcing Inequity and Slowing Progress

By keeping essential documentation behind a paywall, the WBA unintentionally enforces a two-tier ecosystem:

• Tier 1: Large companies that can afford the WBA’s annual membership fees gain access to the latest technical information, meeting recordings, and early guidance on new features.

• Tier 2: Everyone else—including small ISPs, managed service providers, startups, open-source developers, and educators—are left out.

This model leads to bureaucracy and bottlenecks. Only well-funded members can contribute meaningfully or raise issues through official channels. Everyone else is stuck reverse-engineering solutions, leading to duplication of effort, inconsistent deployments, and missed opportunities for collaboration.

Worse yet, community contributions are discouraged. Most developers simply won’t contribute to a standard they can’t access freely or verify against official materials. That slows iteration and keeps the feedback loop closed—an especially serious problem for something that aspires to become a global identity federation.

A Better Approach: Open the Docs, Monetize the Value

The WBA’s real value lies not in its documentation, but in its governance model, its trusted PKI, and its ability to manage a federated identity infrastructure at scale. These are the services worth paying for—things that add direct commercial value to members.

But documentation? That should be freely and publicly accessible. Just like IETF specifications, it should serve as a foundation for interoperability, innovation, and community growth.

By opening the documentation, the WBA could:

• Lower the barrier to entry for small and mid-sized providers

• Attract new developers, integrators, and contributors

• Improve transparency and consistency across deployments

• Reduce confusion and support costs

• Accelerate real-world adoption

In fact, making the documentation open could indirectly increase membership. Organizations are far more likely to join when they’ve already succeeded in deploying OpenRoaming and want to contribute more deeply to its evolution.

If the WBA truly wants to promote global adoption and build a lasting federation, the first step is simple: open the docs.

7. Collaboration Should Be the Norm

One of the quiet but persistent challenges in the OpenRoaming ecosystem is the imbalance in participation and contribution. While many organizations benefit from the collective work of the community, not all of them contribute back. Some remain passive participants—or worse, extract value without offering any in return.

This dynamic creates friction. It places a heavier burden on the few contributors who do share openly, support others, and move the project forward. Over time, it also erodes the very spirit of collaboration that OpenRoaming relies on.

Unlike centralized platforms, OpenRoaming is built on the idea of federation—where independent entities cooperate under shared rules to deliver a unified experience. That only works if everyone plays an active role, whether through technical contributions, documentation, peer support, or feedback loops.

Too often, though, we see organizations:

• Consuming open tools and documentation without reporting bugs or suggesting improvements

• Participating in working groups without sharing real-world data or deployment insights

• Building proprietary enhancements on top of community tools without contributing upstream

• Advocating for the standard publicly, but withholding their implementation practices privately

While some of this behavior may be unintentional or driven by resource constraints, the net result is the same: slow progress, knowledge silos, and duplicated effort.

A Healthier Ecosystem Is a Participatory One

If OpenRoaming is to succeed as a truly global standard, it needs more than adoption—it needs active stewardship from its members and implementers.

That means:

• Reporting issues and edge cases

• Proposing improvements and enhancements

• Publishing real-world implementation examples

• Contributing to open documentation

• Participating in working groups with transparency and a service mindset

These are not just nice-to-haves—they are critical to the long-term viability of the ecosystem.

WayFi Wireless’s Commitment

At WayFi Wireless, we believe strongly in the power of shared knowledge. That’s why we:

• Publish free educational videos and tutorials to demystify complex OpenRoaming topics

• Create implementation guides and walk-throughs based on our real-world experience

• Offer feedback to working groups when documentation, code, or policy falls short

• Support other MSPs, ISPs, and network operators trying to get started with Passpoint and OpenRoaming

• Advocate for more open access, vendor diversity, and realistic technical pathways

We do this not because we’re required to—but because it makes the ecosystem stronger for everyone. A thriving OpenRoaming community is one where knowledge flows freely, good ideas are rewarded, and success is shared.

Reciprocity Drives Resilience

When everyone gives a little, the system becomes exponentially more resilient and scalable. Collaboration ensures faster problem solving, better security, and wider adoption. More importantly, it helps avoid the stagnation and vendor lock-in that has plagued other federation models in the past.

The future of OpenRoaming depends on creating an environment where collaboration is not the exception, but the expectation.

Conclusion: Prioritize Growth, Not Gatekeeping

OpenRoaming and Passpoint are powerful technologies—designed to solve some of the most persistent challenges in modern wireless connectivity. But power alone doesn’t drive adoption. To realize their full potential, the ecosystem must remove unnecessary roadblocks and make it easier for organizations of all sizes to participate.

At WayFi Wireless, we’ve had the opportunity to speak directly with WBA leadership and share many of the concerns raised in this article. To their credit, they’ve been receptive and open to dialogue. We’re actively working to contribute back to the organization in every way we can—within the limits of our resources.

As of this writing, WayFi Wireless is still a small team. But we’re deeply committed to this space. We’ve helped nearly two dozen organizations begin their OpenRoaming journeys, and we’re continuing to produce public-facing educational resources, deployment guides, and feedback to help others do the same.

Our goal is not to criticize—but to collaborate. We believe a stronger, more open, and more accessible ecosystem benefits everyone involved.

To grow OpenRoaming and Passpoint, we believe the following must happen:

✅ Improve and stabilize the core tools so they can be used in production with confidence

✅ Open up technical documentation to lower the barrier to entry and promote transparency

✅ Prioritize carrier onboarding to drive scale through high-impact Identity Providers

✅ Foster vendor diversity to avoid bottlenecks and encourage innovation

✅ Reduce bureaucracy and create faster paths for meaningful contributions

✅ Clarify and simplify the implementation process for newcomers and advanced operators alike

These are not just technical fixes—they are strategic necessities. Together, they form the foundation for turning OpenRoaming into a truly global platform.

We’re excited for what’s ahead, and we’re committed to doing our part. If you’re working to deploy or evaluate OpenRoaming, we’d love to connect. If you’re involved with the WBA or helping shape the standards, we encourage you to keep pushing—for openness, clarity, and collaboration.

Let’s build this future together.

– The WayFi Wireless Team