Openness changes the security picture
Open RAN is often described as a way to diversify suppliers, and supplier diversity can improve resilience. It also changes the security picture. A disaggregated network has more interfaces, more vendors and more software components than an integrated one, and each is a place where something can go wrong. Security teams must therefore treat Open RAN as a system to be defended end to end, not as a drop-in replacement for an existing base station.
Areas that need attention
- Interfaces: open fronthaul, E2, A1, O1 and O2 each need authentication, integrity protection and access control appropriate to their risk.
- Cloud platform: the O-Cloud inherits container, hypervisor and orchestration risks.
- RIC applications: third-party xApps and rApps could access data or influence the network, so vetting and permissions are essential.
- Supply chain: many software and hardware suppliers create dependency and provenance questions.
- Management plane: administrative access to the SMO is a high-value target.
Applying zero trust
Zero trust architecture, as described in NIST SP 800-207, removes implicit trust based on network location and evaluates each request using identity and policy. For Open RAN, that suggests giving every network function and application a verifiable identity, using mutual authentication on interfaces, granting least-privilege access to data and control functions, and logging decisions for review. The O-RAN ALLIANCE has a working group focused on security, and its specifications describe requirements and threat analyses. Operators should consult the current documents for details.
Supply chain assurance
Request a software bill of materials for components, ask how vulnerabilities are disclosed and patched, require signed software and secure boot where supported, and test updates before rollout. Where possible, validate that products meet recognized security assurance schemes. Governments in several regions have issued guidance on telecom supply chain security, and operators should follow requirements applicable to their markets.
Preparing for 6G
6G discussions emphasize security and privacy by design, resilience, and readiness for quantum-capable adversaries, which has driven interest in post-quantum cryptography across telecom. Standards for 6G security are still developing. In the meantime, operators can build practices that will carry forward: automated certificate management, crypto agility, strong identity for network functions and continuous monitoring.
No design removes risk entirely. The aim is to make compromise harder, limit its spread and detect it quickly. Treat statements that any architecture is inherently secure with skepticism, and ask for evidence from testing and independent assessment.
A starter security program
Begin with an inventory of every network function, interface and administrative account in the Open RAN deployment. Rank them by impact, apply strong authentication and encryption where supported, and segment management traffic from user traffic. Add continuous monitoring for unusual behavior, such as unexpected application actions on the RIC or administrative logins from new locations. Run a tabletop exercise that assumes one vendor component is compromised, and use the findings to refine isolation and response plans.
Shared responsibility
In a multi-vendor network, no single supplier sees the whole system. Write down which party is responsible for patching each component, who monitors which interface and who leads an incident. Unclear ownership is a security risk in its own right, because it delays the response when speed matters most.
Metrics to track
Track the share of interfaces with mutual authentication, the number of components with a current software bill of materials, the time to apply critical patches, the number of vetted RIC applications and the time to detect and contain a test incident. These figures show whether the security program is improving.
