For the complete documentation index, see llms.txt. This page is also available as Markdown.

Security and Compliance

Enterprises adopt private cellular partly for security: a network whose access is controlled by SIM credentials you issue, carrying traffic that never leaves your site. What follows is how Onyx delivers that, and where your responsibilities begin.

It is an orientation, not a specification. For the full control-by-control detail, see the Onyx Security Specification.

Why private cellular starts ahead

Two properties are structural, not features that have to be configured:

Access is cryptographic, not shared-secret. There is no password to leak. A device joins because it holds a SIM or eSIM credential you provisioned, authenticated by 4G/5G AKA with Milenage challenge-response. Revoking access means revoking a credential in the Onyx Portal: it takes effect network-wide, immediately.

Traffic can be made not to leave the building. In an on-premises deployment, the user plane and control plane both terminate on the Onyx Edge appliance at your site. Application data is handed to your enterprise network locally. Only minimal operational metadata reaches GXC's cloud Orchestrator.

The three planes

Cellular networks separate traffic into three planes, and Onyx secures each differently. Understanding this split is what makes the rest of the security model legible.

Plane
Carries
Where it terminates (on-premises)

User plane

Application traffic: the actual data payloads moving between devices and your services

Onyx Edge, on site

Control plane

Signaling that establishes sessions, authenticates devices, and enforces mobility and QoS

Onyx Edge, on site

Management plane

Configuration, monitoring, orchestration, authentication records, logs

Onyx Portal / Orchestrator, cloud or on-prem

NOTE: Your enterprise network is deliberately unaware of control plane and management plane operations. It sees user plane traffic handed off at the Onyx Edge and nothing else.

Deployment model changes the boundary

On-premises (4G and 5G): user and control plane traffic terminate locally. Sensitive application and session data stays inside enterprise boundaries. This is the stronger data-sovereignty position and the default assumption throughout this documentation.

Cloud (4G): traffic is routed to a cloud-hosted Onyx Edge over encrypted transport, with IPSec tunnels between the Onyx APs and the Edge using AES-CBC-128 with HMAC-SHA2-256-128 integrity protection. Faster to deploy, no on-site infrastructure, but the data boundary moves.

If data sovereignty is a hard requirement, choose on-premises. Confirm this before the architecture step, because it is expensive to change afterwards.

How each plane is protected

User plane

Over the air, traffic between the device and the network is ciphered and integrity-protected: up to 128-EEA2 / 128-EIA2 on 4G, and up to 128-NEA3 / 128-NIA3 on 5G on-premises.

Inside the enterprise, APN-mapped VLANs isolate traffic by device group. This is the control that matters most in practice and the one most often left unconfigured. It lets you place cameras, handhelds, and AGVs on separate subnets with separate policies, with DHCP-based assignment giving precise IP tracking. Segmentation you would apply to any other enterprise network applies here too, but you have to apply it.

Onyx does not persist user plane data. It remains in volatile memory and is never stored.

You can layer your own end-to-end protection (TLS or VPN between the device and your application services) on top of all of this, and for sensitive workloads you should.

Control plane

  • NAS signaling is encrypted between device and Onyx Edge, using SNOW-3G and AES-CTR across 4G (128-EEA1/EEA2) and 5G (128-NEA1/NEA2).

  • SUCI encryption (5G on-premises) conceals subscriber identifiers using AES-128-CTR with HMAC-SHA-256, per 3GPP Profile A. This is what prevents permanent subscriber identifiers being harvested over the air.

  • IMSI Lock with IMEI binding ties a SIM or eSIM to specific authorised hardware, blocking SIM transfers, SIM-swap attacks, and device impersonation. Worth enabling wherever the device population is known and stable.

Management plane

  • TLS 1.2/1.3 secures management traffic across all components, using ECDHE-RSA-AES-128-GCM-SHA256, DHE-RSA-AES-256-GCM-SHA384, AES-256-GCM-SHA384, and AES-128-GCM-SHA256 cipher suites.

  • Software updates are cryptographically signed and verified before installation.

  • SIM/eSIM credentials and authentication tokens move from the Orchestrator to the Onyx Edge over encrypted channels only.

  • At rest, management data is encrypted; credentials are protected by AWS key management services; backups are encrypted with geographic redundancy; AWS IMDSv2 protects instance metadata.

Administrative access

Onyx Portal

  • Tenant isolation: each partner and customer tenant runs in a logically isolated environment, preventing cross-tenant exposure.

  • SSO with MFA, plus CAPTCHA/reCAPTCHA against automated credential abuse, and bcrypt-hashed credentials against brute-force and rainbow-table attacks.

  • RBAC enforces least privilege across all Portal functions.

  • Enterprise IdP integration aligns Portal authentication with your existing identity framework. See 4G & 5G Onyx Portal Integration with Customer IdP and 4G & 5G Onyx Portal MFA.

  • AWS WAF guards the web interface; AWS GuardDuty watches for infrastructure threats and anomalies.

  • Audit logging covers all access, configuration, and authentication events, retained for 60 days.

Equipment access

Component
Access model

Onyx Edge

Key-based SSH and local console for the agw_user account, for basic debug, service restart, and reboot. Portal users get RBAC-restricted diagnostic commands. GXC Engineering holds direct key-based SSH for troubleshooting. Network port exposure is limited by design. All operations audit logged.

Onyx AP

Generally isolated from the enterprise network, with no direct access. Configuration and updates arrive via the Onyx Edge. GXC Engineering has authenticated access for troubleshooting. All changes audit logged.

Mesh Node

Managed via the Onyx Edge, no direct network access. All changes audit logged.

FHM (5G)

Managed via the Onyx Edge, no direct network access. All changes audit logged.

Third-party API integrations

Exporting telemetry and logs to external systems is optional and entirely under your control. Where enabled, integrations use tokenised, tightly scoped connections with short-lived tokens and continuous validation. All third-party API access is audit logged, with the same 60-day retention.

Certifications

  • SOC 2 Type I - affirms GXC's internal controls for safeguarding customer data.

  • FCC Part 96 - certified for shared CBRS spectrum use in the United States. See Private 5G Spectrum and Regulations.

Per-model regulatory compliance appendices are published in each hardware installation guide.

What remains yours

Onyx secures the network. It does not secure everything that touches the network. These are yours to own:

  • Network segmentation - configuring APN-mapped VLANs and subnet policy so device groups are actually isolated from one another.

  • Firewall policy - filtering at the boundary between the Onyx Edge and your enterprise network. Firewall configuration requirements are provided on request; see 4G & 5G Firewall Configuration for Onyx Networks.

  • Application-layer security - TLS or VPN between devices and your services, for anything sensitive.

  • Credential lifecycle - provisioning SIMs, and revoking them promptly when a device is lost, retired, or reassigned.

  • Portal access governance - RBAC role assignment, MFA enforcement, and periodic access review.

  • Log retention beyond 60 days, where your compliance regime requires it.


Contact GXC

To get in touch with GXC, please visit https://gxc.io/contact-us/.

Last updated

Was this helpful?