Enterprise Wi-Fi has operated for decades on a simple premise: buy the access points, controller, and firmware from one vendor as a single indivisible package. That model made sense when wireless was a novelty. It makes considerably less sense today, when Wi-Fi is load-bearing infrastructure for campuses, hospitals, transit hubs, and carrier deployments spanning hundreds of thousands of endpoints.

The cost of that coupling is well understood. Hardware refresh cycles are dictated by software end-of-life dates. Licensing fees apply to what is increasingly commodity silicon. Innovation waits on proprietary roadmaps.

Established under the Telecom Infra Project, OpenWiFi addresses this by separating hardware from the software stack and the software stack from the management plane – a disaggregated, open-source architecture now spanning 150+ member organizations and nearly 400,000 operational access points globally.

This article covers how OpenWiFi actually works, the engineering choices behind each layer, and where the model extends into the wired infrastructure that determines real-world performance.

How OpenWiFi Works: The Three-Layer Stack

The OpenWiFi architecture separates wireless network infrastructure into three distinct layers: the hardware (any certified whitebox access point), the Access Point Network Operating System (APNOS, the software running on the AP), and the Cloud SDK (the management and orchestration plane). Each layer is independently replaceable.

The Access Point NOS (APNOS)

APNOS is the enterprise-grade software stack deployed on OpenWiFi-compliant hardware. Built on an OpenWrt base and augmented by the uCentral agent, it applies a coordinated, validated, cloud-manageable codebase across all certified hardware.

The uCentral agent maintains a persistent, TLS-encrypted WebSocket connection to the Cloud SDK gateway, transmitting real-time telemetry and receiving configuration payloads. Configuration is rendered locally via JSON schemas and ucode scripts, translating data models into system-level calls without shell interpreters, eliminating a class of shell-injection vulnerabilities common in earlier architectures.

The APNOS package system is modular by function: core packages handle WebSocket communication and schema management; monitoring packages collect device stats, DHCP binding data, and DNS activity; policy packages enforce QoS and airtime fairness; security packages handle 802.1X and RADIUS; RRM packages coordinate client steering and BSS transitions.

The Cloud SDK

The management plane is a set of cloud-native, provider-agnostic microservices deployable on-premises or on any public cloud. The OWGW gateway terminates WebSocket connections from APNOS instances; telemetry streams are published to a Kafka message bus for consumption by the OWANALYTICS service or third-party platforms. The Cloud SDK supports SQLite and PostgreSQL backends, scaling from single-venue to carrier-grade deployments without application-layer changes. Open northbound APIs allow analytics engines, SASE platforms, and security services to integrate once and operate across any certified ODM hardware – a structural shift from proprietary controllers that tied integrations to vendor-specific APIs.

Zero Trust Without Compromise: The PKI 2.0 Transition

In a disaggregated model with hardware from multiple vendors across geographically distributed sites, device identity is foundational. Zero Touch Provisioning depends entirely on a functional PKI.

The original DigiCert-based PKI served OpenWiFi through its growth phase. By 2023, two converging problems made it untenable: certificates approaching end of validity, and DigiCert’s scheduled decommissioning of the lookup service by March 2026. A dedicated working group evaluated six vendors through a formal RFP and selected Finnish cybersecurity specialist Insta to deliver PKI 2.0.

The architectural shift is significant. Legacy PKI used a single, statically provisioned device certificate. PKI 2.0 introduces a two-certificate model:

• Birth Certificates are factory-installed at manufacturing time with a 10-year validity period, establishing permanent hardware identity and serving as the trust anchor for subsequent enrollment.
• Operational Certificates are acquired dynamically post-deployment using EST (Enrollment over Secure Transport, RFC 7030) with a 5-year validity that renews automatically at two-thirds of its lifetime.

EST is chosen over ACME deliberately: ACME requires open listening ports for its TLS challenge mechanism, introducing an unacceptable attack surface for field-deployed APs. EST has the APNOS initiate enrollment outbound via open-source libest library – no inbound port required. The replacement Cloud Discovery Service is a serverless AWS architecture enforcing mTLS for device lookups and four-tier role-based access control. Legacy DigiCert certificates serve as birth certificates for initial EST enrollment, providing a structured migration path for existing deployments.

Wi-Fi 7 and the OpenWiFi 4.0 Generation

Released in June 2025, OpenWiFi 4.0 introduced full Wi-Fi 7 (IEEE 802.11be) compatibility across APNOS and the Cloud SDK. Wi-Fi 7’s key technical advances:

• Multi-Link Operation (MLO) allows a single device association to operate concurrently across 2.4, 5, and 6 GHz bands, routing traffic dynamically to whichever band offers the lowest latency or highest throughput. The client appears as a single logical device regardless of which physical radio carries the traffic.
• 320 MHz channel widths – double Wi-Fi 6E’s maximum – increase throughput capacity in the 6 GHz band. 4096-QAM modulation increases per-subcarrier data density by 20% under strong signal conditions.
• Preamble Puncturing marks occupied sub-channels in the OFDMA preamble and transmits only on available portions, preserving most of a 320 MHz channel’s capacity when regulatory incumbents occupy segments of the spectrum.

OpenWiFi 4.0 also extended 6 GHz MPSK and EMPSK support for secure onboarding of clients and IoT devices, enabling per-client key isolation in high-density environments without requiring 802.1X infrastructure for every device category.

Closing the Loop: OpenLAN Switching and the Wired Access Layer

A disaggregated wireless infrastructure delivers its benefits only to the edge of the Ethernet port. Beyond that lies the access switch — in most deployments, proprietary, vendor-locked, and managed through a separate operational silo. TIP expanded OpenWiFi into OpenLAN Switching (OLS): the same open-source philosophy extended to the wired layer, managed by the same CloudSDK controller with the same ZTP model.

OLS defines two product classes with distinct operating system bases and feature sets. The Base Class targets cost-sensitive environments – small businesses, schools, limited-scale venues – using a silicon vendor SDK for entry-level L2 VLANs and PoE management. The Advanced Class (OLS SONiC) targets enterprise deployments requiring multicast routing, multi-chassis redundancy, and granular access control, built on SONiC Lite developed by PLVision.

SONiC at the Edge: How SONiC Lite Enables OLS Advanced Class

Community SONiC was designed for cloud-scale data center switching – hardware with multi-core CPUs, 8-32 GB of RAM, and substantial storage. That architecture runs in fully containerized Docker workloads and carries the corresponding resource overhead. Deploying it on an access switch with 2 cores, 2 GB of RAM, and limited flash storage is not a matter of porting – the resource model is fundamentally mismatched.

SONiC Lite solves this directly. It is an enterprise SONiC distribution purpose-built for resource-constrained access and edge platforms, preserving vendor-specific SAI and platform integrations while eliminating the overhead that Community SONiC’s containerized architecture requires for data center workloads. The result is a production-quality NOS that runs on the hardware class that OLS deployments actually use – validated, for example, on Edgecore’s ECS4650-54P and ECS5550 series switches.

For organizations evaluating SONiC distributions for OEM switch development or custom deployments beyond the OLS framework, PLVision also offers custom SONiC-based product development – design and build of networking products tailored to specific hardware, feature requirements, and lifecycle needs. The same engineering depth that underlies SONiC Lite’s OLS integration is available for organizations with requirements outside the standard OLS product classes.

OLS 4.0: Enterprise Feature Parity

Released in June 2025, OLS 4.0 brought the wired layer to full enterprise parity: IGMP snooping/MVR multicast management, MC-LAG for active-active redundant uplinks, cable diagnostics, port mirroring, IP Source Guard, and MAC/IP ACLs. MC-LAG in particular closes a critical operational gap – without it, SONiC-based access switches could not bond uplinks to two separate upstream switch chassis in an active-active configuration, eliminating the single-chassis failure risk that standard LACP cannot address.

Unified Management: One Controller, Full Visibility

When APs and switches are managed through separate controllers, troubleshooting requires correlating across two operational systems. With OLS Advanced Class switches speaking uCentral to the same CloudSDK, administrators correlate user traffic logs, VLAN tagging, PoE allocation, and AP performance metrics from a single interface. ZTP works identically for switches and APs – a new OLS switch connects, authenticates via PKI 2.0, locates its controller through the Cloud Discovery Service, and receives its configuration payload without manual intervention.

Security: Threat Vectors and Countermeasures in a Disaggregated Model

Disaggregation leaves the 802.11 protocol and its known attack surface intact – it centralizes and standardizes the platform’s countermeasures.

Pre-authentication window. Every Wi-Fi connection begins with an unprotected management frame exchange before session keys are established. Attackers can execute denial-of-service by blocking authentication commits or handshake frames. IEEE 802.11w Protected Management Frames (PMF) encrypt post-association unicast frames and integrity-protect broadcast deauthentication frames. OpenWiFi mandates PMF across certified hardware and validates it in its continuous testing pipeline.

Open network and hotspot threats. Captive portal environments leave the wireless link unencrypted, enabling passive sniffing and session cookie interception. OpenWiFi counters with MPSK, assigning distinct pre-shared keys to device groups or individual devices, which isolates encrypted sessions across what appears to be a shared SSID; 802.1X with RADIUS for per-user enterprise authentication where infrastructure supports it; and CoovaChili integration for captive portal redirection where it doesn’t.

Continuous validation. OpenWiFi runs an automated CI/CD pipeline with over 1,500 nightly tests across automated RF chambers, covering APNOS and Cloud SDK behavior against multiple hardware configurations – conformance, TR-398 throughput benchmarks, roaming stability, and protocol regression coverage across the multi-ODM hardware matrix.

Conclusion

OpenWiFi’s architectural choices follow the same engineering discipline that made SONiC viable in data center switching. Wi-Fi 7 adds the radio-layer capabilities high-density environments need. PKI 2.0 puts trust infrastructure on a foundation that survives vendor transitions. OLS closes the last operational gap by extending the same model to the wired access layer.

A network where APs operate on open, cloud-managed infrastructure but access switches remain in a proprietary silo is only partially disaggregated. OLS Advanced Class completes the picture: the same CloudSDK controller, the same uCentral protocol, the same ZTP and telemetry workflows, extended from wireless to wired.

PLVision works across the SONiC and open networking stack. If your organization is evaluating SONiC-based switching for OpenLAN or enterprise campus deployments, contact our engineering team to discuss your hardware configuration and what production deployment actually requires.