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.
Standards and references
- ETSI: TS 133 501 (3GPP TS 33.501) Security architecture and procedures for 5G System
- eCFR: 47 CFR Part 96 Citizens Broadband Radio Service
- NIST: CSWP 36A Protecting Subscriber Identifiers with SUCI
- NIST NCCoE: 5G Cybersecurity project
- NSA and CISA (ESF): 5G Network Slicing Security Considerations
- Wireless Innovation Forum: CBRS specifications
Related NHI Mgmt Group resources: 5G Security Guide · Industrial IoT (IIoT) Security Guide · 802.1X and EAP-TLS Enterprise Wi-Fi Guide · Salt Typhoon Threat Actor Profile