Private 5G and CBRS Enterprise Network Security Guide

An enterprise that runs its own private 5G or CBRS network becomes a mobile operator for its own devices, taking on SIM key management, a core network, radio units and spectrum access systems that a Wi-Fi team has never had to secure. Factories, ports, campuses, hospitals and warehouses deploy private cellular networks for coverage, mobility and deterministic performance for robots, sensors and handhelds. The security model differs from Wi-Fi: devices authenticate with SIM credentials or EAP methods to a core you operate, the radio access network connects over backhaul you must protect, and in the US the CBRS band adds a regulated link to a Spectrum Access System. This guide covers deployment models, SIM and device identity, core and radio security, CBRS-specific obligations, slicing and segmentation, monitoring, and a phased rollout. It is for network architects, OT security teams and CISOs evaluating or operating private cellular. The general 5G architecture (5G AKA, SUCI, the service-based core, roaming) is explained in the 5G Security Guide; this page applies it to enterprise ownership.

Key takeaways

You own the subscriber keys. In a standalone private network, the long-term SIM keys, the SUCI home network private key and the subscriber database are yours to generate, store and protect.
Turn on SUCI with a non-null scheme. NIST notes that operators choose whether to enable SUCI; the null scheme sends the permanent identifier unencrypted.
The core is a cloud-native application. Treat network functions, their certificates and OAuth tokens, and the management plane as a high-value workload estate.
CBRS adds regulated device and SAS security. FCC Part 96 requires secure CBSD to SAS communications, protection against firmware modification and professional installation for Category B devices.
Segment by slice and by data network. Map each device class to its own slice or data network name, and enforce policy where cellular traffic meets the enterprise LAN.

Deployment models and who controls what

3GPP Release 16 introduced non-public networks (NPN) in two forms, and ETSI TS 133 501 (3GPP TS 33.501) has a normative annex on non-public network security covering standalone NPN authentication, PNI-NPN authentication, authorisation, interconnect and UE onboarding.

Model	Description	Enterprise controls	Operator or vendor controls
Standalone NPN (SNPN), on-premises core	Enterprise runs its own core and RAN, identified by a PLMN ID and network identifier	SIMs or other credentials, subscriber database, core, RAN, backhaul	Vendor support access and software supply
SNPN with hosted or managed core	Core runs in a vendor cloud; RAN on site	RAN, local breakout, device policy	Core operations, subscriber data, keys (check the contract)
Public network integrated NPN (PNI-NPN)	Private service delivered on a mobile operator's network, often via a dedicated slice or closed access group	Device enrolment, enterprise firewall policy	SIM keys, core, slicing, radio
CBRS LTE or 5G (US)	Enterprise radios (CBSDs) in 3550-3700 MHz managed by a Spectrum Access System	CBSDs, core, SIMs, CPI installation records	SAS administrator, Environmental Sensing Capability

Decision guidance: choose an on-premises SNPN where data must stay on site, latency must be deterministic or the plant must keep working without an internet link; accept that you then hold every key and must patch the core. Choose a managed core or PNI-NPN where you lack telecom operations staff; then your security depends on contract terms for key custody, logging access and incident notification. Small sites with a few dozen devices are often better served by Wi-Fi 6/7 with 802.1X and EAP-TLS (see the 802.1X and EAP-TLS Enterprise Wi-Fi Guide); private cellular earns its complexity at large outdoor or high-mobility sites.

SIM and device identity

Credential choice: SIM-based 5G AKA or EAP-AKA' using a long-term key in the USIM, or, in an SNPN, EAP framework methods. TS 33.501 Annex I covers primary authentication with a credentials holder using an AAA server or AUSF and UDM, and Annex B covers EAP-TLS. Certificate-based EAP-TLS suits devices already managed by an enterprise PKI; SIMs suit high-volume IoT with eSIM provisioning.
SUCI: NIST CSWP 36A explains that SUCI encrypts the SUPI with the home network public key, that Release 15 and later devices and network functions must support it but operators choose whether to enable it, and that the null scheme leaves the SUPI unencrypted. Configure a non-null ECIES profile (NCCoE testing prioritised Profile B), make sure SIMs carry the SUCI parameters, and verify on the air interface that SUCI is encrypted.
Key custody: long-term subscriber keys (K, OPc) are generated at SIM manufacture or eSIM profile creation and must be transferred to your UDM or HSS. Insist on encrypted key file transfer, import into an HSM where the core supports it, and destroy intermediate copies.
Device binding: restrict SIMs to approved device identities (IMEI or PEI lock) so a SIM pulled from a sensor cannot be used in a laptop on the production network.
Lifecycle: SIMs and eSIM profiles are non-human identities with an owner, a device, a slice and an expiry. Suspend on loss, revoke on decommission and review dormant subscriptions monthly.

Identity object	Where it lives	Risk if mishandled	Control
Long-term subscriber key (K/OPc)	USIM and UDM/HSS	Cloning, impersonation of devices	Encrypted transfer, HSM storage, no plaintext exports
SUCI home network private key	UDM (SIDF)	De-anonymising every device	HSM, restricted admin, rotation plan
Network function certificates and OAuth tokens	Core NFs and NRF	Rogue NF calling core services	Private CA, short lifetimes, mutual TLS
CBSD certificates	Radio units	Unauthorised radio registration with the SAS	CBRS PKI per WInnForum certificate policy, secure storage
EAP-TLS device certificates	Device and enterprise PKI	Device impersonation	Hardware-backed keys, revocation checking
Vendor support accounts	Core and RAN management	Remote takeover	PAM, just-in-time access, session recording

Securing the core and the radio access network

Core network functions: AMF, SMF, UPF, AUSF, UDM and NRF run as containers or VMs. Apply container platform hardening, mutual TLS between network functions and OAuth 2.0 token authorisation through the NRF, as described in the 5G Security Guide.
Platform integrity: NIST CSWP 36B covers hardware-enabled security to ensure 5G system platform integrity; prefer hosts with measured boot and attestation for the core.
Interfaces to protect: N2 (RAN to AMF) and N3 (RAN to UPF) over backhaul should be protected with IPsec where the backhaul is shared or leaves a secured cabinet; N6 is where cellular traffic enters enterprise networks and needs a firewall.
Radio units: small cells and radio units sit in ceilings and on poles. Lock management ports, disable unused services, sign and verify firmware, and alarm on tamper or unexpected reboot.
Management plane: the element management system and orchestration platform can reconfigure every function. Put them on a separate management network, require MFA through central AAA and record sessions.
Network device credentials: SNMP community strings, local accounts, SSH keys and shared AAA secrets on routers and switches in the backhaul are credentials. The Salt Typhoon telecom intrusions mostly began with valid stolen credentials and then harvested configurations, SNMP strings and TACACS and RADIUS secrets to move between devices.

CBRS-specific security obligations

The Citizens Broadband Radio Service is authorised in 3550-3700 MHz under 47 CFR Part 96. Federal incumbent users have priority; Priority Access Licensees operate in 3550-3650 MHz in 10 MHz channels; General Authorized Access users may use the whole band without protection from each other. Security-relevant rules (eCFR text checked 27 October 2026):

Rule	Requirement	Enterprise action
§ 96.39(c)	Information a CBSD gives the SAS must be true, complete and correct; registration changes reported within 60 seconds	Accurate location and height records; change control on radio moves
§ 96.39(f)(1)	CBSDs may contact only SASs run by FCC-approved SAS administrators	Pin SAS endpoints; block other outbound destinations from radios
§ 96.39(f)(2)-(3)	CBSD to SAS and CBSD to end user device communications must use secure methods that protect against corruption or unauthorised modification	Certificate-based communications per WInnForum specifications; monitor for failures
§ 96.39(g)	CBSDs and end user devices must have security features sufficient to protect against modification of software and firmware	Signed firmware, secure boot, controlled update process
§ 96.45(a)	Category B CBSDs must be professionally installed	Use accredited Certified Professional Installers; keep installation records
§ 96.61(b)-(c)	CBSD, SAS and ESC communications must be secure against corruption or interception; SAS must not serve uncertified devices	Buy only FCC-certified CBSDs; confirm SAS onboarding

The Wireless Innovation Forum maintains the supporting specifications: WINNF-TS-0016 (SAS to CBSD protocol), WINNF-TS-0065 (CBRS Communications Security), WINNF-TS-0022 (CBRS PKI Certificate Policy, version 1.5.1 of March 2026) and WINNF-TS-0247 (CPI Accreditation Standard). CPI credentials and CBSD certificates are identities: store them in a vault, restrict who can register radios and review SAS account users.

Network slicing and segmentation

Map device classes to slices or DNNs: for example one for safety-critical machines, one for video, one for handhelds and one for guest or contractor devices.
Isolation: NSA and CISA slicing guidance recommends logical and performance isolation between slices, and physical isolation of resources, separate management systems and administrators where confidentiality, integrity and availability needs are high. It also suggests per-slice certificate authorities and role-based access.
Slice-specific authentication: TS 33.501 clause 16 defines network slice-specific authentication and authorisation (NSSAA) with an AAA server, including AAA-triggered re-authentication and revocation. Use it to tie access to a sensitive slice to enterprise credentials as well as the SIM.
Denial of service: rate-limit and firewall user traffic per slice at N6 and rate-limit signalling towards AAA, DNS and DHCP, as the slicing guidance recommends, so one compromised device class cannot starve another.
Enterprise boundary: the UPF hands traffic to your LAN. Treat each DNN as a zone and apply the same zone and conduit rules as the OT network. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Implementation plan

Design: choose the deployment model; decide key custody (who generates and holds K/OPc and the SUCI private key); define slices, DNNs and zones; set contract terms for vendor access, logging and incident notification.
Build in a lab or pilot area: enable SUCI with a non-null profile, mutual TLS between network functions, IPsec on backhaul and the N6 firewall. Test SIM-to-device binding and slice isolation.
Pilot ring: a single production cell with non-critical devices; run alongside existing Wi-Fi so devices can fall back. Rollback is moving devices back to Wi-Fi and disabling the cell or slice.
CBRS onboarding (US): register CBSDs through a CPI, confirm SAS grants, and record installation parameters.
Scale: add device classes slice by slice; integrate core and RAN logs with the SOC; bring vendor support access under PAM.
Operate: monthly SIM and certificate reviews, patch windows for the core agreed with production, and annual penetration testing of the core and management plane by authorised testers.

Detection and measurement

Signal	Source	Why it matters
Authentication failures and unknown SUPI or SUCI attempts	AMF, AUSF logs	Cloned or stolen SIMs, misconfigured devices
IMEI or PEI change for a subscription	Core subscriber events	SIM moved to an unapproved device
Unexpected cell or false base station reports	RAN and measurement reports	Rogue radio (NIST CSWP 36G on false base stations was open for comment until 31 October 2026)
CBSD grant loss or SAS communication errors	Domain proxy or CBSD logs	Availability incident or certificate problem
Admin logins and configuration changes on core and RAN	EMS, AAA, PAM	Valid account misuse (T1078)
Traffic from a DNN to unexpected enterprise zones	N6 firewall	Segmentation failure or compromised device

Metrics: percentage of subscriptions using a non-null SUCI scheme (target 100%); dormant SIMs older than 30 days; percentage of SIMs bound to an approved device identity; core and RAN components within patch SLA; vendor access sessions through PAM (target 100%); slice isolation test pass rate each quarter.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ATT&CK
Device authentication (SIM, EAP-TLS)	IA-3	PR.AA-05	T1200 Hardware Additions
Wireless access and link protection	AC-18, SC-40	PR.IR-01	T1557 Adversary-in-the-Middle
Segmentation at N6 and between slices	SC-7	PR.IR-01	T1499 Endpoint Denial of Service
Core and management plane exposure	SC-23, AC-6	PR.PS-01	T1190, T1078
Inventory of radios, SIMs and devices	CM-8	ID.AM-01	n/a

Common failure patterns

SUCI left on the null scheme: the default works, so nobody configures encryption, and device identifiers travel in clear.
Vendor holds the keys by default: SIM keys and the core are managed by the integrator, with shared support accounts and no logging the enterprise can see.
Flat N6: every cellular device lands in one VLAN with access to the plant network, undoing the isolation the slices were meant to provide.
Backhaul trusted implicitly: N2 and N3 run unencrypted over shared campus fibre or a leased line.
Network device credentials never rotated: SNMP strings and local passwords in backhaul routers are copied across sites, the pattern exploited in the Salt Typhoon telecom intrusions.
CBRS records drift: radios moved or replaced without updating SAS registration, risking compliance and loss of grants.

Lessons from incidents

Public incident reporting on private 5G networks themselves is thin, but the operator networks they copy have been heavily targeted. In the Salt Typhoon telecom intrusions, attackers used valid credentials, exfiltrated device configurations containing SNMP strings and weakly encrypted local passwords, captured TACACS and RADIUS traffic, added local accounts and SSH keys, and in one case kept access for more than three years. The lessons carry straight into a private network: centralise device administration through AAA with MFA, remove weak password types, move to SNMPv3, treat configuration backups as credential stores, and alert on new local accounts, added keys or changed AAA server addresses. See the Salt Typhoon Threat Actor Profile.

Practitioner checklist

Document the deployment model and who holds each key: K/OPc, SUCI private key, NF CA, CBSD certificates.
Enable SUCI with a non-null ECIES profile and verify over the air.
Bind SIMs to approved device identities and review dormant subscriptions monthly.
Use mutual TLS and token authorisation between core network functions; harden the container platform.
Protect N2 and N3 backhaul with IPsec where it leaves secured space; firewall N6 per DNN.
Define slices or DNNs per device class, with NSSAA for sensitive slices.
Put vendor and administrator access to core, RAN and SAS portals under PAM with MFA.
For CBRS, buy certified CBSDs, use accredited CPIs and keep registration data accurate.
Feed core, RAN and SAS logs to the SOC with the detections above.

Private 5G and CBRS Enterprise Network Security Guide: Securing SIMs, Cores and Spectrum Access