Modern 5G cores are software. The AMF, SMF, NRF, AUSF, UDM and the Service-Based Interface functions around them increasingly run as cloud-native components in containers and Kubernetes, communicating through well-defined 3GPP protocols. But deploying these functions successfully is not the same as proving they behave according to the standards they implement. Following the introduction of CNTC, we are extending the framework with 5G Core Control-Plane certification.
A 5G Core may start correctly. A UE may register. A PDU session may establish. Yet deeper questions remain: does the AMF correctly execute 5G-AKA authentication? Is NAS traffic actually integrity protected and ciphered after the Security Mode procedure? Does the SMF create the expected N4/PFCP state in the user plane? Does the NRF reject an unauthenticated service-discovery request? Are SBI security mechanisms such as TLS and OAuth2 genuinely enforced? These are protocol-level questions, and answering them requires evidence.
CNTC converts 3GPP and Security Assurance Specification (SCAS) requirements into automated tests, evaluates observable protocol behaviour, applies deterministic certification criteria, and generates a verdict independently for each supported 5G Core network function. The objective is straightforward: turn published standards into measurable evidence, and measurable evidence into reproducible certification.
Why 5G Core Control-Plane Certification Matters
The telecom industry has mature approaches for validating handsets and radio equipment. The cloud-native 5G Core introduces a different certification challenge: its behaviour is distributed across independently deployed network functions, and a single procedure may span N1, N2, N4 and the Service-Based Interfaces.
A successful end-to-end call flow does not necessarily prove that each participating network function satisfied the protocol and security requirements applicable to it. For example, successful registration alone does not establish whether 5G-AKA was executed correctly, invalid authentication credentials were rejected, NAS integrity protection was activated, NAS ciphering was enabled after Security Mode, SBI communication was protected using TLS, OAuth2 authorization was enforced, or the correct PFCP state was created on N4.
Commercial telecom test systems provide extensive validation capabilities, but these are generally proprietary environments. CNTC addresses a different requirement: an open, transparent and reproducible certification framework that teams can run against their own live cloud-native 5G Core deployment.
The goal is not simply another test report. The goal is to create a traceable chain: published requirement, to automated test, to observed evidence, to deterministic verdict, to network function certificate.
The CNTC Certification Model
CNTC follows one fundamental principle: a certification verdict should come from something that was actually observed. The framework stimulates a network function using specification-compliant peers and then observes what the implementation actually does.
For the 5G Core control plane, evidence can be obtained from NAS exchanged through N1/N2, NGAP signalling over N2, PFCP exchanges over N4, HTTP/2 communication over the Service-Based Interface, TLS and OAuth2 behaviour on SBI endpoints, and authentication and registration outcomes from real UE procedures. CNTC does not infer that a security property exists simply because a configuration file claims it is enabled; where protocol evidence can be collected, the framework validates the behaviour directly.
Measure First, Certify Second
A deliberate architectural decision in CNTC is to separate measurement from certification. The framework is built around three logical elements.
- Measurement engine. Executes the protocol procedure, captures observable behaviour, and records the result.
- Requirement catalog. The certification requirements are represented in a versioned YAML catalog, defining which requirement is being evaluated, which standard it maps to, which test provides the evidence, whether the requirement is essential, and how the result contributes to the certification gate.
- Certification engine. Evaluates the recorded results against the applicable versioned requirement catalog and produces the network function verdict.
Execution results are stored separately in results.json. This means the certification threshold is data-driven rather than hardcoded into the measurement engine. Changing or extending the certification bar means evolving a reviewable requirement catalog, not rewriting the entire certification system. That separation also makes the basis of every result visible and auditable.
Per-Function Certification Anchored to 3GPP and SCAS
CNTC does not treat the 5G Core as a single monolithic system. Each network function is evaluated independently against the protocol and security requirements relevant to its role. Control Plane Level 1 currently covers five network functions:
| Network function | Protocol spec | SCAS | Exercised via |
|---|---|---|---|
| AMF | TS 24.501 (NAS) · TS 38.413 (NGAP) · TS 33.501 (5G-AKA) | TS 33.512 | Spec-compliant gNB + UE over N1/N2, with on-the-wire NAS capture |
| SMF | TS 29.502 (Nsmf) · TS 29.244 (N4/PFCP) | TS 33.515 | PDU session establishment with N4 capture |
| NRF | TS 29.510 (Nnrf) | TS 33.518 | Service-Based Interface client (HTTP/2, TLS, OAuth2) |
| AUSF | TS 29.509 (Nausf) | TS 33.516 | SBI client, and transitively via UE registration |
| UDM | TS 29.503 (Nudm) | TS 33.514 | SBI client, and transitively via UE registration |
The methodology follows a simple engineering model: stimulate, observe, decode, evaluate. A network function is driven by a specification-compliant peer, for example a simulated gNB and UE or a purpose-built SBI client. The resulting protocol exchange is captured and decoded. The verdict is based on observed behaviour, not on an assumption about what the implementation should have done.
Proving Behaviour on the Wire
Direct protocol observation becomes particularly important when evaluating security.
AMF. CNTC can drive a real UE registration procedure and observe whether the expected authentication and NAS security procedures actually occurred. Test coverage includes initial registration, 5G-AKA authentication, the NAS Security Mode procedure, NAS integrity protection, NAS ciphering, and rejection of a UE presenting invalid credentials. A successful registration alone is not enough: CNTC observes the signalling required to demonstrate how that registration was achieved.
SMF. N4 traffic is captured and decoded to verify that PDU-session establishment produces the expected PFCP interaction with the user plane. The question is not simply whether the session established, but whether the SMF programmed the user plane in the way defined by the applicable N4/PFCP requirements.
NRF, AUSF and UDM. For SBI network functions, CNTC uses a purpose-built client capable of exercising HTTP/2, TLS and OAuth2, allowing security behaviour to be demonstrated through protocol interaction rather than inferred from configuration. A successful UE-registration sequence can also provide transitive evidence across participating network functions: completion of authentication demonstrates participation by the AUSF and successful retrieval of authentication information from the UDM.
Where CNTC cannot directly demonstrate a required property, it does not convert uncertainty into compliance. The result remains explicit.
A Deterministic Certification Gate
Not every security requirement can be exercised by a normal specification-compliant peer. CNTC therefore separates its certification model into two levels.
| Level | Scope | Tests | Status |
|---|---|---|---|
| Level 1: Conformance & Observable Security | Everything provable with a specification-compliant peer and direct observation | 44 (26 essential) | Available |
| Level 2: Adversarial Robustness & Privileged Interop | Cases requiring a non-compliant or privileged peer: forged, replayed, or malformed protocol state, and registered-NF PKI | 20 | Roadmap |
Level 1 contains 44 implemented tests across the five network functions: AMF 14, SMF 11, NRF 8, AUSF 4, UDM 7. Of these, 26 are classified as essential certification requirements. The certification rule is intentionally strict:
- PASS, all essential requirements pass and a certificate is issued;
- FAIL, one or more essential requirements fail and no certificate is issued; and
- INCOMPLETE, one or more essential requirements cannot be evaluated, and no certificate is issued.
This third state is particularly important. An incomplete verdict is not a softer version of PASS. For example, if a deployment does not provide the behaviour required to evaluate an OAuth2 requirement, CNTC records that requirement as unevaluated rather than silently treating it as compliant. Absence of evidence is not converted into evidence of compliance.
Validation Against a Live 5G Core
CNTC Control Plane Level 1 was validated against a live free5GC deployment in two environments: Docker Compose, and Kubernetes using the official Helm deployment with an in-cluster UE. The same certification methodology and requirement catalog were used across both environments. The results demonstrate why certification should evaluate the running deployment, not merely the software package.
| Network function | Docker | Kubernetes (Helm) |
|---|---|---|
| AMF | PASS (9/9) | PASS (9/9) |
| AUSF | PASS | INCOMPLETE1 |
| UDM | PASS | INCOMPLETE1 |
| SMF | FAIL, SBI not TLS-protected | FAIL2 |
| NRF | FAIL, SBI not TLS-protected | FAIL, serves discovery to an unauthenticated client (HTTP 200); SBI not TLS-protected |
The AMF passed certification in both environments. The complete registration path was exercised, including registration, 5G-AKA authentication, NAS integrity protection, NAS ciphering, and rejection of invalid credentials.
At the same time, CNTC surfaced deployment-specific gaps. In the Kubernetes environment, the NRF successfully responded to an unauthenticated service-discovery request and returned discovery information with HTTP 200. This is exactly why certification must evaluate the deployed system rather than simply assuming that the software implements a capability because the standard requires it. The same certification framework can expose different behaviour across different deployments of the same core.
1 AUSF and UDM pass transitively via registration in Docker; their SBI-authorization case is unevaluated on the default Helm deployment, which does not enforce OAuth2.
2 the in-cluster single-node UPF has no N6 route, so the PDU-session data-path case cannot complete.
Running a Certification
CNTC is designed to operate against a live deployment without requiring certification logic to be rewritten whenever the network is redeployed. Deployment addresses are resolved at runtime. A typical workflow begins with a preflight check:
make cp-doctor CONFIG=configs/free5gc-cp.yamlThe AMF suite can then exercise real registration, 5G-AKA and NAS security behaviour. A typical result looks like:
[PASS] * AMF-REG-01 Initial registration
[PASS] * AMF-AUTH-01 5G-AKA authentication
[PASS] * AMF-SEC-02 NAS ciphering after Security Mode
[PASS] * AMF-SEC-04 Invalid-credential UE rejected
essential gate:
9 passed / 0 failed / 0 na
RESULT: PASSThe resulting scorecard and certification state can then be reviewed through the CNTC dashboard:
make dashboardThe dashboard provides visibility into individual test cases, requirement mappings, essential certification gates, observed results, and the resulting network function verdict.
The Tooling Behind CNTC
- UERANSIM, used for specification-compliant gNB and UE procedures over N1/N2. UERANSIM is fetched and built separately and invoked as an external process, maintaining separation from CNTC's Apache-2.0 licensing.
- A purpose-built SBI client, testing interfaces including Nnrf, Nausf, Nudm, Namf and Nsmf, and supporting the HTTP/2, TLS and OAuth2 mechanisms needed for SBI validation.
- tcpdump and tshark, for packet capture and protocol decoding, giving direct visibility into NAS signalling over N2 and PFCP signalling over N4.
- pfcpsim, used for PFCP session-control testing.
CNTC itself is released under the Apache-2.0 licence, while external drivers and tools retain their respective licences and are obtained separately.
What CNTC Certifies, and What It Does Not
A credible certification framework must define its limits as clearly as its capabilities. CNTC is an open, reproducible conformance and observable-security certification harness. It is not a NESAS-accredited security laboratory.
The current control-plane framework focuses on protocol-facing properties that can be demonstrated through direct interaction and observation, including authentication behaviour, RES* verification, NAS security procedures, NAS ciphering, SBI TLS enforcement, OAuth2 enforcement, protocol conformance, and malformed-input rejection where supported by the applicable test level.
Host operating-system hardening, organizational security processes, lifecycle controls and audit requirements that cannot be demonstrated through available protocol evidence remain outside the current certification scope. Where a property cannot be demonstrated, CNTC reports it as INCOMPLETE or inconclusive rather than making an unsupported compliance claim. That limitation is intentional: a bounded result backed by evidence is more useful than a broad compliance claim that cannot be independently verified.
Where CNTC Goes Next
The 5G Core Control Plane engine is one stage of a broader certification model. CNTC is designed so that additional telecom domains can introduce their own measurement engines and requirement catalogs while retaining the same underlying certification methodology.
Level 2, adversarial robustness. Level 2 moves beyond specification-compliant peers toward adversarial and privileged cases. The roadmap includes forged protocol state, replayed protocol state, malformed protocol exchanges, and registered network function PKI scenarios. The Level 2 requirement catalogs already exist; the corresponding drivers and execution layer remain roadmap work.
Additional 5G Core implementations. The same certification catalog is intended to be exercised against additional open-source 5G Core implementations. Adapters for Open5GS and OAI are part of the roadmap. The objective is not to define a different certification standard for each implementation; it is the opposite, one requirement model exercised consistently across multiple implementations.
Beyond the 5G Core. CNTC is also intended to move further through the telecom stack, with a roadmap covering RAN, SMO and RIC. Each domain can introduce its own measurement engine and requirement catalog while retaining the same certification principle: standard requirement, to measurable evidence, to deterministic gate, to reproducible verdict.
From Telecom Testing to Reproducible Certification
Cloud-native telecom is changing how networks are developed and deployed. Certification needs to evolve with it. When network functions are software and deployments continuously change across containers and Kubernetes environments, verification cannot stop at determining whether the software starts successfully or whether a basic call flow completes. The implementation should be able to demonstrate, through observable behaviour, that the requirements expected from it are actually being satisfied.
That is the direction behind CNTC. Not certification based on assumptions. Not a PASS because an option appears in a configuration file. Not an opaque interpretation of whether the network seems to work. Instead: a transparent chain connecting the 3GPP or SCAS requirement to an automated test, the test to observable protocol evidence, and the evidence to a deterministic certification verdict.
With Control Plane Level 1, CNTC now brings this model to the AMF, SMF, NRF, AUSF and UDM, with 44 automated tests, 26 essential certification requirements, real N1/N2, N4 and SBI observation, per-network-function certification, PASS/FAIL/INCOMPLETE verdicts, and validation against a live 5G Core deployment.
The larger objective is to make certification a repeatable part of how cloud-native telecom software is developed, deployed and evaluated. Telecom software should not only claim standards compliance. It should be able to demonstrate it.
Learn More
- Repository: github.com/TOSSI-Foundation/CNTC
- Documentation: Control-Plane Certification
- Demo: youtu.be/b9Q8BA5wX8g