O-RAN Security Guide: Securing Open RAN Interfaces, RICs and Apps

Open RAN breaks the radio access network into components from different vendors connected by open interfaces, and every new interface, controller and third-party app is a place where authentication, integrity and accountability can fail. The O-RAN Alliance architecture adds RAN Intelligent Controllers that run xApps and rApps, an open fronthaul between radio and distributed units, and a cloud platform underneath, none of which existed as attack surface in a single-vendor base station. This guide covers the O-RAN security model as the O-RAN Alliance Security Work Group (WG11) specifies it, the risks the US Enduring Security Framework identified, how to secure each interface, the RIC app supply chain and the cloud layer, and how to roll out and measure it. It is for mobile operator security architects, private network operators and vendor security teams. The 3GPP 5G architecture itself is covered in the 5G Security Guide, which this guide does not repeat. Specification versions were checked on 27 October 2026.

Key takeaways

• Every O-RAN interface has a defined protection. WG11 specifies TLS with mutual TLS for A1, O1, O2, R1 and Y1, IPsec for E2, and on the fronthaul management plane TLS or SSH with 802.1X port-based access control; operators should insist on these rather than accept "secured by network isolation".
• The real-time fronthaul is the weakest link. Control, user and synchronisation planes rely on 802.1X port access control with only optional MACsec, so physical security and network access control are first-line defences, as the NSA and CISA assessment stresses.
• xApps and rApps are third-party code with control over the radio. Require vendor signing validated by the SMO, signed NTIA-compliant SBOMs, least-privilege OAuth 2.0 authorisation and conflict mitigation before onboarding.
• Multi-vendor means multi-owner. Patch timing, vulnerability ownership and interoperability testing across suppliers become security problems that contracts and an integration test lab must solve.
• Management credentials are the prize. Password-based SSH to radio units, shared secrets and static device accounts are exactly what telecom intruders have exploited; move to certificate-based mutual TLS and centrally managed identities.

The O-RAN architecture and its attack surface

The O-RAN Alliance organises its work in eleven work groups, from use cases and architecture (WG1) through the RICs (WG2 and WG3), open fronthaul (WG4), cloudification and orchestration (WG6) and OAM (WG10) to security (WG11). Its specifications are publicly downloadable. The components and interfaces that matter for security are:

The NSA and CISA Enduring Security Framework assessment found that Open RAN is not inherently less secure than proprietary RAN, but that disaggregation enlarges the threat surface at the interfaces between vendors, and that the RIC applications, open fronthaul, AI/ML, open source components and cloud layer each bring specific risks. The EU NIS Cooperation Group published its own Open RAN cybersecurity report in May 2022 to complement the EU 5G Toolbox; see the EU 5G Security Toolbox Guide.

Interface security: what WG11 specifies

The table below follows the O-RAN Alliance's published summary of the WG11 Security Protocols Specification. WG11 states that support for TLS 1.3 is mandatory, and that API security requires mTLS certificate-based authentication with least-privilege OAuth 2.0 authorisation.

Two details are often misread. First, 802.1X authenticates the device plugged into a port and controls its network access; it does not authenticate the data exchanged between O-DU and O-RU. Second, E2 relies on IPsec at the network layer with no authorisation mechanism specified, so the Near-RT RIC's own controls over which xApp may act on which E2 node carry the authorisation burden. Synchronisation over PTP is covered in the PTP Time Synchronisation Security Guide.

Securing the open fronthaul

• Network access control first: enable 802.1X on every fronthaul switch port so only authenticated O-RUs and O-DUs join the network; the ESF assessment names network access control as the first line of defence against unauthorised devices launching denial of service.
• Management with certificates: replace password-based SSH to O-RUs with mutual TLS using X.509 certificates from an operator PKI, as the ESF recommends. Where SSH remains, use key-based authentication and NACM to restrict commands.
• MACsec where the budget allows: MACsec is optional on the real-time planes and PTP; the ESF notes that cryptography must keep pace with real-time requirements at acceptable cost. Prioritise links that leave operator-controlled premises.
• Physical protection: harden O-RUs, lock cabinets, disable unused ports and alarm on enclosure opening; a radio site is a physical attack surface.
• Rely on 3GPP air interface protections: NAS and AS ciphering, user-plane integrity protection and SUCI remain effective end to end, so fronthaul compromise does not automatically expose subscriber traffic when they are enabled.

RIC applications: xApps and rApps

RIC apps are the most novel part of Open RAN: software from third parties that reads RAN data and changes radio behaviour. WG11 added 39 AI/ML threats to its threat model, which now covers over 160 threats, and introduced requirements on model integrity and confidentiality, A1 authentication and authorisation, data poisoning prevention and application lifecycle security.

Cloud, open source and supply chain

• O-Cloud hardening: RAN functions run as containers or virtual machines. Apply the NSA and CISA Kubernetes Hardening Guide and NIST SP 800-190 container guidance, micro-segmentation and mutual authentication between workloads. See the Container Security Guide.
• Responsibility: in hybrid or public cloud deployments, write the division of security responsibilities into the cloud service agreement and reassess it periodically; the ESF found this commonly unclear.
• SBOM and composition analysis: WG11 makes a vendor-signed, NTIA-compliant SBOM mandatory with every software delivery. Feed it into software composition analysis to find vulnerable open source components. See the SBOM Guide.
• Security assurance: the O-RAN Alliance has established a GSMA NESAS-based O-RAN Security Assurance Program and is developing Security Assurance Specifications for O-RU, O-DU and SMO with GSMA. See the GSMA NESAS Network Equipment Security Guide.
• Machine identities at scale: every RAN function, app and radio needs a certificate and every API client an OAuth client credential. Treat certificate and token lifecycle as a core operational capability: an issuing CA hierarchy dedicated to the RAN, automated enrolment for radios and network functions at first boot, short validity with automated renewal, and revocation that the SMO and RICs actually check. A single expired intermediate certificate can take down every mTLS-protected interface at once. See the Enterprise PKI Design and CA Hierarchy Guide and the IoT and Device Certificate Provisioning (EST, SCEP) Guide.

Zero trust and logging in WG11

WG11 says it has assumed a zero trust environment since 2020, aligned with NIST SP 800-207, and assessed its requirements against the CISA Zero Trust Maturity Model, finding most assets at the Initial stage. Additions since then include least-privilege access control, pre-configured expiry of authorisation decisions and application package protection. Security log management is mandatory: defined security events, collection from all O-RAN elements, least-privilege log access, integrity and confidentiality protection for logs at rest and in transit, timestamps and element identity. See the CISA Zero Trust Maturity Model Guide.

Rolling out O-RAN security

1. Write requirements into procurement: cite the current WG11 Security Requirements and Controls, Protocols and Tests specifications (version 14.0, 14.0 and 12.0 respectively as published in February 2026; ETSI and ATIS published the security documents in 2025) and require evidence per interface.
2. Build the PKI and identity layer: issue device and function certificates, OAuth authorisation servers for A1, O2, R1 and Y1, and NACM roles for O1 and M-plane, before the first site goes live.
3. Lab first: stand up a multi-vendor integration lab and run the WG11 security tests, interoperability tests and negative tests (expired certificates, wrong client, unauthenticated fronthaul device).
4. Pilot cluster: deploy a small set of sites with full protections enabled, and measure latency and throughput impact of MACsec and TLS on real traffic.
5. App onboarding gate: define the xApp and rApp onboarding process: signature validation, SBOM review, security test results, least-privilege scopes and staged activation in observe-only mode before control.
6. Scale with rollback: expand by region with configuration templates; keep the previous signed software and configuration available so a failing release or app can be rolled back from the SMO without site visits.
7. Operate: centralise security logs, run joint vulnerability handling with every vendor, and use the O-RAN coordinated vulnerability disclosure programme for specification-level issues.

Choosing your approach

• Single integrator vs operator integration: a prime integrator simplifies accountability for patching and vulnerabilities but reduces visibility; operator-led integration needs a strong vendor management and test capability.
• Private and enterprise Open RAN: smaller deployments often run all components on one site with one integrator; the interface protections still apply, and management credentials are frequently the weakest point. See the Private 5G and CBRS Enterprise Network Security Guide.
• RIC adoption: start with rApps for non-real-time optimisation and observe-only xApps before allowing third-party xApps to control radio parameters.
• MACsec on the real-time planes: enable it where fronthaul crosses third-party fibre, shared transport or leased premises, and where the O-RU and O-DU hardware supports line-rate encryption; on short, physically protected links inside an operator site, 802.1X with physical controls may be an accepted residual risk, recorded as such.
• Public cloud hosting: acceptable for SMO and Non-RT RIC functions with clear contractual responsibility; real-time functions usually stay on operator-controlled edge infrastructure.

Detection and measurement

• Monitor: 802.1X authentication failures and new MAC addresses on fronthaul ports, certificate validation failures on O1, O2 and A1, NACM and OAuth denials, xApp and rApp onboarding and activation events, configuration changes pushed from the SMO, and anomalous RIC control actions.
• Metrics:
  1. Percentage of O-RAN interfaces in production with the WG11 specified protection enabled.
  2. Percentage of O-RUs managed with certificate-based authentication rather than passwords.
  3. Percentage of onboarded apps with validated signatures, signed SBOMs and recorded security test results.
  4. Median days from vendor patch availability to deployment across all vendors in a release.
  5. Number of certificates expiring within 30 days without automated renewal.

Common failure patterns

• Static management credentials: radio units and network elements managed with shared passwords and SNMP strings. The Salt Typhoon telecom intrusions show how stolen credentials and secrets in device configurations let intruders persist in carrier networks for years.
• Fronthaul treated as trusted: no 802.1X and no physical controls, so any device on a cell site switch can inject traffic.
• Optional protections left off: TLS or MACsec disabled at integration "for performance" and never revisited.
• App onboarding without gates: xApps installed with broad scopes and no signature or SBOM checks.
• Patch deadlock: vendors patch on different schedules and the operator delays all updates to avoid breaking interoperability.
• Unclear cloud responsibility: nobody owns hardening of the O-Cloud host or container platform.

Framework mapping

Practitioner checklist

• Reference the current WG11 security specifications by version in every O-RAN contract and acceptance test.
• Enable the WG11 protection on every interface: TLS with mTLS on A1, O1, O2, R1 and Y1, IPsec on E2, and TLS or SSH with 802.1X on the M-plane.
• Enforce 802.1X on all fronthaul ports and physical protection at cell sites; enable MACsec where links leave controlled premises.
• Manage O-RUs and RAN functions with certificates, not shared passwords; automate certificate renewal.
• Gate xApp and rApp onboarding on SMO signature validation, signed SBOMs, security tests and least-privilege scopes.
• Harden the O-Cloud with Kubernetes and container guidance and document cloud responsibilities in contracts.
• Centralise mandatory security logs from all O-RAN elements and alert on authentication and configuration anomalies.
• Run joint vulnerability and patch management with all vendors and test fixes in a multi-vendor lab.

Standards and references

• O-RAN Alliance: Security Work Group Continues to Advance O-RAN Security (2026 update)
• O-RAN Alliance: Security Update 2025
• O-RAN Alliance: Specifications
• O-RAN Alliance: Technical Groups
• NSA and CISA: Open Radio Access Network Security Considerations
• European Commission: NIS Cooperation Group Report on the Cybersecurity of Open RAN
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: 5G Security Guide · Telecom Network Security Guide · Salt Typhoon Threat Actor Profile · GSMA NESAS Network Equipment Security Guide