With 5G Standalone, the core is increasingly decoupled from dedicated network appliances. Functions such as authentication, session management and data forwarding now commonly run as containerised Kubernetes workloads – in the operator’s own data centre, on external cloud infrastructure or at the edge.
‍

This article examines where this creates a critical security gap, how Confidential Computing addresses it, and what operational and commercial value it can deliver to mobile network operators (MNOs) and private 5G providers.

‍

The 5G core as a cloud-native software architecture

‍

The 5G core acts as the network’s control and trust layer. It authenticates subscribers and devices, manages connections and sessions, enforces access and quality-of-service policies, and controls how data is routed through the network. These responsibilities are distributed across specialised Network Functions.
‍

In cloud-native architectures, these functions often run as containerised applications deployed and managed through Kubernetes. Operators can update and scale individual functions as required. Traffic-processing components such as the User Plane Function (UPF) can be deployed at the edge, while other core functions remain centralised.
‍

This development is particularly relevant for public 5G Standalone networks. An MNO may operate the core on its own systems or use compute resources provided by an external cloud or technology provider. Private 5G networks in factories, ports or energy sites increasingly follow a similar model, with the core often running on a local cluster managed either by the organisation itself or by a service provider.
‍

The host operating system, virtualisation layer, Kubernetes stack and their administration therefore also become relevant to core security. At the same time, regulatory requirements around sovereignty, together with third-party and supply-chain risks, are increasing pressure on telcos to retain control over critical systems and protect them against unauthorised access.
‍

Closing the data-in-use gap with Confidential Computing

‍

Cloud-native core deployments introduce additional privileged layers beneath the workload. This matters because conventional encryption does not protect data in the same way at every stage of processing.
‍

An encrypted database protects subscriber information while it is stored (data at rest). TLS or IPsec can secure communication between systems and Network Functions while data is transferred (data in transit). But when the core authenticates a device, establishes a session or applies a policy, the required information has to be available to the software in memory. That exposure is the data-in-use gap in conventional architectures.
‍

Confidential Computing addresses this gap by processing data inside a hardware-based Trusted Execution Environment (TEE). The TEE isolates code and data during execution from other workloads and privileged infrastructure components. Remote Attestation adds cryptographically verifiable evidence that a workload is running inside an untampered TEE with an approved configuration.
‍

‍

How telcos benefit from Confidential Computing

‍

Confidential Computing is more than an additional security control. For MNOs and private 5G providers, it affects how shared compute resources can be used, and how technical evidence supports compliance requirements. It can also provide the technical basis for new services offered to customers with particularly high security or sovereignty requirements.
‍

Key benefits for telcos include:
‍

• New revenue streams: Operators can make verifiable security and data control part of their service portfolio. Potential offerings include sovereign hosting, Private 5G with an attested trust boundary, confidential edge or AI services, and compliance services for regulated customers. For these customers in particular, privileged access to the underlying systems should not automatically provide access to data while it is being processed.
  ‍
• More efficient use of compute resources: Sensitive workloads do not always have to run on completely separate systems. Where legal and operational requirements allow it, hardware-based isolation can enable greater consolidation on shared infrastructure.
  ‍
• Verifiable compliance evidence: Attestation data adds technical proof to audits and security assessments. It does not replace a full audit, but it reduces reliance on organisational assurances and manually documented target configurations.
  ‍
• Shorter security reviews: Enterprise customers and public-sector buyers often subject 5G and cloud services to extensive security assessments. Technical evidence of workload integrity and key access gives reviewers a clearer basis for assessment.
  ‍
• Customer retention through differentiation: An operator that technically supports a customer’s compliance and security requirements differentiates its offering beyond price and bandwidth. The underlying trust architecture becomes part of the service proposition.

‍

Typical deployment scenarios

‍

Requirements vary depending on the operating model. What these scenarios have in common is that sensitive workloads run on infrastructure where not every underlying layer can be assumed to be fully trusted.

‍

• Public 5G Standalone core: core functions run in a telco cloud, sovereign cloud or on hyperscaler infrastructure. Confidential Computing isolates the workload from the host, hypervisor and privileged administration.
  ‍
• Managed Private 5G and Network Slicing: An operator provides logically separated networks for enterprises or public-sector organisations on shared infrastructure. Hardware-based isolation and Attestation enforce the promised tenant separation at a technical level.
  ‍
• Industrial campus networks: In factories, ports or hospitals, the core connects machines, sensors, vehicles or medical devices. It processes their identities and session information and controls which network services they may access. Protection becomes particularly relevant when a service provider administers the local Kubernetes environment.
  ‍
• Distributed and remote sites: Offshore platforms, energy facilities or logistics sites may require local core and edge functions even when connectivity to central services is limited. Encrypted workloads reduce the risks associated with exposed hardware and unauthorised privileged access.
  ‍
• Mobile 5G for disaster response and public safety: During a flood, wildfire or major police operation, a mobile 5G unit can provide connectivity for emergency personnel, drones and sensors. core and edge applications run on portable hardware and may be used by several organisations. Confidential Computing enables protected and confidential communication in such environments.
  ‍
• Mobile 5G for disaster response and public safety: During a flood, wildfire or major police operation, a mobile 5G unit can provide connectivity for emergency personnel, drones and sensors. core and edge applications run on portable hardware and may be used by several organisations. Confidential Computing helps to protect communication and processing in these field deployments.

‍

How enclaive implements Confidential 5G

‍

enclaive brings together the core components required for Confidential 5G in an integrated Kubernetes architecture.

‍

The technical foundation is provided by Confidential VMs with enclaive Buckypaper, which create the protected runtime environment. Within these Confidential VMs, enclaive Dyneemes deploys and orchestrates dedicated Kubernetes pods. Sensitive 5G core functions therefore run in a flexible, highly secure environment that is isolated from the host, hypervisor and infrastructure operator.

‍

Protected execution is combined with identity verification and key management. Within enclaive’s virtual HSM (vHSM), Nitride handles Workload Identity & Access Management (WIAM) and Attestation, while Vault manages keys and secrets. Vault releases the required key material only after Nitride has verified that the expected workload is running in the intended protected state.

‍

The components therefore work as one chain:

‍

Dyneemes orchestrates the pod → Buckypaper protects its execution → Nitride verifies identity and state → Vault releases the keys.

‍

enclaive supports two deployment models. With on-premises deployment, the customer runs the full solution on its own systems. Alternatively, enclaive provides the solution as SaaS through the enclaive Multi-Cloud Platform (eMCP), handling provisioning and operations for the Confidential Computing stack. Hybrid deployments are also possible. The 5G core might, for example, remain on-premises while separate workloads use the SaaS model.

‍

Requirements for a robust implementation

‍

Confidential Computing makes a significant contribution to securing operations on the underlying infrastructure. It does not, however, remediate code vulnerabilities in a core application. Patch management, access controls and network segmentation remain necessary, and Attestation policies need to be clearly defined.

‍

The VM-based approach described here also requires TEE-capable hardware with Confidential Computing features such as Intel TDX or AMD SEV-SNP. Firmware and the virtualisation environment must support the respective technology as well.

‍

Integration effort depends on the specific 5G core. Key factors include how its functions run on Kubernetes and how certificates, keys and other secrets are provisioned.

‍

Conclusion

‍

The move towards cloud-native 5G Standalone makes the 5G core more portable and scalable. At the same time, operators need ways to run critical core functions without having to exercise complete control over every layer of the underlying infrastructure.

‍

Confidential Computing extends existing security controls to a layer that has often received less attention: data while it is being processed. Combined with Remote Attestation and controlled key provisioning, it creates a trust boundary that can extend from the central data centre to the edge.

‍

For telcos, this connects security with commercial objectives. Sensitive core and edge workloads can run on modern infrastructure, technical evidence can support customer and audit requirements, and existing service portfolios can be strengthened or expanded.

‍

‍

‍

‍

‍

‍

‍