.png){kind=logo}
Confidential 5G: seal the core that sees everything on your network
Every subscriber identity, session key and policy decision passes through the 5G core — in memory, in cleartext. enclaive seals core network functions in hardware, with attestation-gated keys.
Kubernetes-native, no changes to core network function code. Selected for the NATO DIANA 2026 cohort.
The core must see everything to do its job
The core is the software-defined control plane behind every 5G network: it authenticates subscribers, manages sessions, routes traffic, enforces policy and holds subscriber data. In modern deployments it runs as containerized network functions on Kubernetes.
It cannot authenticate a device without decrypting its identity, or route a session without knowing its keys. All of it exists in memory, in cleartext — and in a conventional deployment, anything that can read the core's memory can read your entire network: a compromised hypervisor, a privileged cloud operator, an insider, or anyone with physical access to the server.
They protect data at rest and in transit; the core's exposure is data in use.
Core-network trust is now a matter of regulation across the EU, and “the vendor promised” no longer passes review. Supplier independence is the thread through all of it — a core whose integrity you can verify is a core whose suppliers you needn't take on faith.
Two layers create an end-to-end chain of cryptographic trust: confidential computing seals the core workloads from the infrastructure, and the virtual HSM seals the key material from the core itself — releasing keys only to network functions that prove their integrity.
AMF, SMF, UPF, UDM, AUSF, NRF and other containerized network functions run inside hardware trusted execution environments. The CPU encrypts memory during execution — the host OS, hypervisor and hardware owner see nothing readable. No changes to CNF code.
Long-term subscriber keys, session master keys and signing certificates live in a software-defined HSM running inside its own sealed environment — HSM-grade custody as a Kubernetes workload, no physical appliance. A network function receives a key only after attestation proves it's running expected, unmodified code.
Operators, regulators and partners can cryptographically verify — in real time — that the core runs genuine, unmodified code in a genuine trusted environment. Trust in the core stops being an assumption and becomes a checkable fact.
Integrates with SUSE Rancher Prime RKE2, Red Hat OpenShift and other distributions — the orchestration model modern cores already use. A reference deployment with the open-source Open5GS core demonstrates the pattern end to end, including sealed subscriber databases.
The working material behind this page: the full Open5GS reference deployment on SUSE Rancher RKE2 and Red Hat OpenShift — sealed network functions, the vHSM key custody model for subscriber credentials, the attestation flow, and the component-by-component architecture including the sealed subscriber database.
The same protection model covers the full spectrum — from hyperscaler-hosted cores to hardware that leaves the building. Running private 5G rather than a network? The short version: your most sensitive box becomes unreadable to everyone who shouldn't read it.
Host core functions on hyperscalers or European clouds while the cloud operator, its staff and its hypervisor stay outside the sealed boundary — the supply-chain and operator-trust answer regulators increasingly expect from MNOs.
Factories, ports, hospitals and energy grids running private 5G under NIS2 and GDPR get vendor-independent trust verification and sealed subscriber data — evidence included for the audit.
Offshore platforms, remote industrial sites and portable “5G-in-a-box” units run the core on hardware that can be lost, stolen or seized. Sealed workloads and hardware-bound keys mean extracted equipment yields nothing.
Contested-environment scenarios, coalition attestation and classified requirements are covered in a closed briefing rather than on the website. Request a briefing →
Third-party selection, not self-assessment
Chosen among 150 companies in NATO's DIANA Challenge Programme under Advanced Communications Technologies, for resilient post-quantum 5G infrastructure in contested and disaster environments.
Findings from enclaive's work in the German Cyberagentur's EC2 research program feed directly into the Confidential 5G architecture.
Incubated in VTT's Dual-Use LaunchPad accelerator, connecting the solution to Finland's applied-research and telecom ecosystem.
Traffic recorded today can be decrypted tomorrow — the “harvest now, decrypt later” strategy targets exactly the long-lived secrets a core network carries. An optional PQC module applies NIST-standardized post-quantum algorithms to key exchange and authentication within the core and vHSM stack. Availability is subject to applicable export control regulations.
A sealed core is what these enforce together — the runtime, the custody and the proof.
Containerized core functions run in hardware enclaves on standard Kubernetes distributions.
Long-term keys, session master keys and certificates in a software-defined HSM, released only against attestation.
Sealed VMs with post-quantum safe encryption — the tier behind portable and remote deployments.
Operate cores across cloud, on-prem and portable sites with per-function attestation evidence.
What network architects ask
Does this work with our 5G core vendor?
The protection applies at the runtime layer: containerized network functions run inside sealed environments without code changes, so the model is core-vendor-neutral. The reference deployment runs the open-source Open5GS core end to end; commercial core stacks follow the same pattern. Bring your stack to the first call and we'll map it.
What about latency — the UPF is performance-critical.
Memory encryption runs in CPU hardware, so overhead is small for control-plane functions. For the user plane, performance depends on traffic profile and hardware generation. [PLACEHOLDER — insert UPF benchmark figures from engineering before launch.]
What hardware does an on-prem or portable deployment need?
Servers with current-generation confidential computing support — a selection criterion for private deployments and for vendors building integrated 5G units. In public cloud, the major hyperscalers already offer TEE-capable instances. [PLACEHOLDER — confirm the supported CPU list with product before launch.]
Which Kubernetes distributions are supported?
The solution deploys as a Kubernetes extension on SUSE Rancher Prime RKE2, Red Hat OpenShift and other standard distributions — not as a separate appliance and not as a replacement for your orchestration choice.
Can a regulator or partner verify the core independently?
Yes — that's the point of remote attestation. Any authorized party can cryptographically verify, in real time, that the core is running genuine, unmodified code in a genuine trusted environment, instead of relying on contractual assurances.
We have defense or classified requirements. Where do we start?
In a closed briefing rather than on this page — tactical scenarios, coalition attestation and classified deployment detail are handled there deliberately. Request a briefing and we'll route it to the right team.
Put your core's trust on provable ground
Tell us your deployment model — cloud core, private campus, or portable — and your core stack. We'll show you what a sealed core looks like on your infrastructure.
Request a briefing.
