When Your Network Vendor Disappears: Why OpenLAN Changes the Risk Equation
For years, networking vendors have sold customers a simple proposition:
Buy our access points.
Use our switches.
Use our gateways.
Manage everything through our cloud.
It is convenient.
Until the vendor itself becomes the weakest link in the network.
The recent developments surrounding Cambium Networks provide the industry with an important reminder of a risk that is often overlooked when network infrastructure is selected: vendor continuity risk.
On September 14, 2026, Cambium Networks reported that its UK subsidiary, Cambium Networks Ltd., had entered administration. The filing also disclosed a reduction of 260 employees globally, representing more than half of its workforce.
Subsequent reporting indicated another issue that is potentially much more important to network operators: the future availability of parts of the Cambium enterprise networking portfolio and its cloud management infrastructure.
For organizations operating thousands—or hundreds of thousands—of network devices, situations like this raise a difficult question:
What happens to your network when the company controlling it is no longer there?
That question goes far beyond Cambium.
It applies to almost every vertically integrated networking platform.
And it is exactly the problem that OpenLAN is designed to address.
Reducing OpenLAN vendor lock-in is therefore not just a technology consideration—it is becoming an important part of network resilience and business continuity.
The Hidden Dependency in Cloud-Managed Networking
Modern networking has increasingly moved toward cloud-managed architectures.
An access point may physically sit inside your hotel, office, apartment building or customer’s home, but critical functions can depend on infrastructure operated by the vendor:
That architecture works extremely well while the vendor remains healthy.
But it creates another dependency.
The organization operating the network may own the hardware.
Yet it may not fully control the platform required to operate that hardware.
If the vendor:
- shuts down a cloud service,
- exits a product category,
- increases licensing costs,
- gets acquired,
- stops supporting a device,
- changes its commercial strategy,
- or encounters financial difficulty,
the network operator can suddenly be forced into a migration.
The hardware may still work.
The problem is operational control.
And migrating thousands of deployed devices to another proprietary ecosystem can mean replacing perfectly functional hardware.
That is vendor lock-in at its most expensive.
OpenLAN Approaches the Problem Differently
The Telecom Infra Project’s OpenLAN initiative starts from a fundamentally different architectural principle:
Separate the network from the vendor.
TIP describes OpenLAN as a community-led initiative focused on open and interoperable networking solutions designed to provide hardware, software and cloud flexibility while reducing vendor lock-in.
Instead of buying one vertically integrated stack, operators can build a disaggregated network.
The relationship changes.
The vendor becomes a supplier to the network rather than the owner of the network architecture.
If One Vendor Disappears, Your Network Doesn't Have To
This is where the difference becomes significant.
Imagine an ISP has deployed 100,000 access points.
Under a proprietary architecture, replacing the management platform may also require replacing those devices.
That turns a software problem into a hardware replacement project.
100,000 truck rolls.
100,000 device replacements.
Customer disruption.
Capital expenditure.
Operational risk.
With an open architecture, the objective is very different.
The operator should be able to replace individual layers without replacing the whole network.
Testing the Complete Command Path
Validated With Mango Cloud
We have also built unit, integration and system-level testing around the implementation.
The integration environment brings together:
The infrastructure investment remains usable.
That is an enormously different risk model.
OpenWiFi: Decoupling Wi-Fi Hardware From the Cloud
OpenWiFi is the Wi-Fi component of OpenLAN.
TIP describes it as a community-developed, disaggregated Wi-Fi system containing both open-source access-point software and a cloud controller SDK. It is specifically designed to operate across hardware platforms and enable multi-vendor deployments.
That separation matters.
Instead of:
Cambium AP → Cambium Cloud
or
Vendor X AP → Vendor X Cloud
the architecture becomes:
OpenWiFi AP → Open Interface → Controller of Your Choice
An ISP or MSP can therefore choose hardware based on:
cost, availability, radio performance, deployment requirements and supply chain considerations.
The controller can be selected independently.
And both can evolve independently.
Hardware Should Be Infrastructure, Not a Subscription Anchor
There is another important economic consequence.
Networking equipment often has a physical life significantly longer than the commercial lifecycle of the software platform attached to it.
An access point installed today might remain technically capable for many years.
Yet proprietary licensing or cloud dependencies can shorten its economic life.
A discontinued controller can effectively make otherwise functioning hardware obsolete.
Open networking changes that relationship.
The value of the hardware is no longer tied exclusively to the survival of one cloud platform.
That makes infrastructure investments potentially much more durable.
OpenLAN Goes Beyond Wi-Fi
This principle is now expanding across the entire in-building network.
The OpenLAN ecosystem includes three major areas:
OpenWiFi for wireless access.
OpenLAN Switching for Ethernet switching.
OpenLAN Gateway for WAN routing, security and edge compute.
TIP describes the overall architecture as a unified multi-vendor stack spanning Wi-Fi, LAN and WAN.
The result is potentially an entire network built around disaggregation:
There is another important economic consequence.
Networking equipment often has a physical life significantly longer than the commercial lifecycle of the software platform attached to it.
An access point installed today might remain technically capable for many years.
Yet proprietary licensing or cloud dependencies can shorten its economic life.
A discontinued controller can effectively make otherwise functioning hardware obsolete.
Open networking changes that relationship.
The value of the hardware is no longer tied exclusively to the survival of one cloud platform.
That makes infrastructure investments potentially much more durable.
Where Mango Cloud Fits
There is another important economic consequence.
Networking equipment often has a physical life significantly longer than the commercial lifecycle of the software platform attached to it.
An access point installed today might remain technically capable for many years.
Yet proprietary licensing or cloud dependencies can shorten its economic life.
A discontinued controller can effectively make otherwise functioning hardware obsolete.
Open networking changes that relationship.
The value of the hardware is no longer tied exclusively to the survival of one cloud platform.
That makes infrastructure investments potentially much more durable.
Open architecture is only useful if operators have practical choices at each layer.
That is where platforms such as Mango Cloud fit into the OpenLAN ecosystem.
Mango Cloud is an open-source cloud controller being built by Router Architects around the OpenLAN and OpenWiFi operating model. It is designed to manage OpenWiFi access points and, increasingly, other OpenLAN network elements through open interfaces and standards-based device communication.
The important point is not that operators must replace one proprietary cloud with Mango Cloud.
It is exactly the opposite.
With an OpenLAN architecture, an ISP or MSP can choose Mango Cloud, another compatible controller, or operate and extend the software themselves.
That changes the relationship between the operator and the cloud platform:
If requirements change in the future, the underlying network does not have to be discarded simply because the management platform changes.
This is the resilience that open networking is intended to provide: choice at deployment time and choice throughout the lifecycle of the network.
Open Source Alone Is Not Enough
It is important to distinguish open source from open architecture.
Simply publishing source code does not automatically eliminate lock-in.
A genuinely resilient ecosystem requires several things working together:
open device software,
standardized management interfaces,
multi-vendor hardware support,
portable cloud infrastructure,
documented APIs,
community governance,
and multiple organizations capable of operating and extending the platform.
OpenLAN is being built around exactly this model.
TIP states that the ecosystem includes shared open-source infrastructure, interoperability testing, reference architectures, centralized PKI infrastructure and technical governance.
That ecosystem is what ultimately creates resilience.
The Question Every ISP and MSP Should Ask
When evaluating a network platform, technical teams usually ask:
- How many clients can the AP support?
- What Wi-Fi standard does it support?
- What is the controller capacity?
- What analytics are available?
- What does the license cost?
There is another question that deserves to be part of every procurement process:
What happens if this vendor no longer exists five years from now?
Then ask:
- Can we continue operating the equipment?
- Can we run the controller ourselves?
- Can another organization support the platform?
- Can we switch cloud controllers?
- Can we source hardware from another manufacturer?
- Can we access the device configuration and telemetry through documented interfaces?
- Can we maintain the software ourselves?
If the answer to most of those questions is no, the organization does not fully control its networking infrastructure.
Business Continuity Is Now a Network Architecture Decision
Financial resilience is normally discussed in procurement departments.
But cloud-managed networking has turned it into an architecture issue.
A vendor failure should ideally be treated in the same way networks treat other failures.
- A failed server should not bring down a cloud.
- A failed link should not bring down a WAN.
- A failed data center should not bring down an application.
And increasingly:
A failed vendor should not bring down a network.
That is perhaps the most important idea behind open networking.
OpenLAN Is Not About Eliminating Vendors
Open networking does not mean vendors disappear.
Quite the opposite.
It allows specialized companies to compete at different layers.
- One company may build excellent access points.
- Another may build switches.
- Another may build gateways.
- Another may operate the cloud controller.
- Another may provide network analytics.
- Another may provide managed services.
The customer chooses the combination.
That creates a healthier ecosystem because changing one component does not necessarily require replacing everything else.
From Vendor Lock-In to Vendor Choice
The Cambium situation will understandably cause many network operators to review their infrastructure strategy.
The lesson should not be:
“Choose a safer vendor.”
No one can guarantee what any company will look like five or ten years from now.
A better lesson is:
Build networks where changing vendors is expected and architecturally possible.
That is the shift OpenLAN represents.
From proprietary infrastructure to open infrastructure.
From vertically integrated networking to disaggregated networking.
From vendor dependency to vendor choice.
And ultimately:
Own your network—even when your vendor changes.
