> For the complete documentation index, see [llms.txt](https://docs.gxc.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gxc.io/security-and-compliance.md). # 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. This page explains how Onyx delivers that, and — just as importantly — where your responsibilities begin. It is an orientation, not a specification. For the full control-by-control detail, see the [*Onyx Security Specification*](https://docs.gxc.io/onyx-software/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.
PlaneCarriesWhere it terminates (on-premises)
User planeApplication traffic — the actual data payloads moving between devices and your servicesOnyx Edge, on site
Control planeSignalling that establishes sessions, authenticates devices, and enforces mobility and QoSOnyx Edge, on site
Management planeConfiguration, monitoring, orchestration, authentication records, logsOnyx Portal / Orchestrator, cloud or on-prem
{% hint style="info" %} **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. {% endhint %} ### 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 signalling 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*](https://docs.gxc.io/docs/application-notes/4g-and-5g-onyx-portal-integration-with-customer-idp) and [*4G & 5G Onyx Portal MFA*](https://docs.gxc.io/docs/application-notes/4g-and-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**. {% hint style="warning" %} **NOTE**: Audit log retention is 60 days. If your compliance regime requires longer, export logs to your own SIEM through the API integration before they age out. {% endhint %} ### 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*](/private-5g-spectrum.md). 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*](https://docs.gxc.io/application-notes/4g-and-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. *** ## Related reading * [*Onyx Security Specification*](https://docs.gxc.io/onyx-software/onyx-security-specification) — the complete control-by-control detail, with data flow and sequence diagrams * [*Private 5G Spectrum and Regulations*](/private-5g-spectrum.md) — spectrum licensing and regulatory obligations * [*4G & 5G Onyx Networking Modes*](https://docs.gxc.io/application-notes/4g-and-5g-onyx-networking-modes) — how Onyx integrates with enterprise network topology * [*Glossary*](/glossary.md) — AKA, NAS, SUCI, IMSI, APN, RBAC, and related terms ## Contact GXC To get in touch with GXC, please visit . --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.gxc.io/security-and-compliance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.