↓ Skip to main content
Le Site de François
  1. Index/

3GPP SCAS

Compliance Telecom 5g 3gpp Security-Testing
Table of Contents

3GPP Security Assurance Specifications (SCAS) are technical specifications developed by 3GPP’s SA3 working group (Security) that define security requirements and associated test cases for specific network product classes — each 3GPP-defined network function (AMF, SMF, UPF, gNB, MME, etc.) has its own SCAS document. 3GPP is the international standards body responsible for mobile telecommunications standards (comprising seven organizational partners covering Europe, US, China, Japan, Korea, India), making SCAS a globally recognized specification set rather than a national or regional scheme. Each SCAS document follows a structured approach: it identifies the assets of the network product class that require protection, performs a threat analysis describing how those assets can be exploited, defines security requirements (objectives) that mitigate the identified threats, and specifies concrete test cases to verify that a product implementation meets those requirements. SCAS specifications serve as the technical foundation for the GSMA NESAS scheme — when a vendor submits a network product for NESAS evaluation, accredited test laboratories evaluate it against the applicable SCAS test cases. Compliance is voluntary (there is no legal mandate to pass SCAS tests), but SCAS/NESAS evaluation results are increasingly used as a procurement requirement by telecom operators and are referenced by the EU 5G Security Toolbox and national security assessments. The list of adopted SCAS documents is maintained by the GSMA in FS.63 and continues to expand as 3GPP defines new network functions.

Red Hat’s relevance to SCAS is indirect but technically significant. Red Hat does not itself develop 3GPP network functions — that is the domain of telecom equipment vendors (Ericsson, Nokia, Samsung, Mavenir, etc.) — but it provides the platform on which those network functions execute and against which SCAS test cases are ultimately run. When a SCAS test case verifies, for example, that a network function uses TLS 1.3 for its service-based interfaces, that TLS implementation is provided by the OpenSSL libraries in RHEL. When a test case checks that unauthorized access to the network function’s data is prevented, the enforcement mechanism is SELinux, Kubernetes RBAC, and network policies on OpenShift. When a test case evaluates the network function’s resilience to known CVEs, the vendor relies on Red Hat’s vulnerability management (CSAF advisories, rapid backporting, Insights-driven patching). Red Hat’s telco-specific platform hardening — including the restricted kernel (reduced attack surface for real-time workloads), FIPS 140-3 mode, seccomp profiles for containerized NFs, and the Compliance Operator’s CIS/STIG enforcement on telco clusters — directly contributes to positive SCAS evaluation outcomes. As 3GPP expands SCAS coverage to cloud-native network functions (where the boundary between the NF and its platform becomes increasingly relevant), Red Hat’s security properties will feature more prominently in SCAS evaluations.

Additional Information
#

Related

EU5G Certification Scheme

Compliance Eu 5g Certification Telecom
The EU5G cybersecurity certification scheme is a certification framework being developed under the EU Cybersecurity Act (Regulation 2019/881), intended to provide harmonized security assurance for 5G network products and components across the European Union. ENISA established an Ad Hoc Working Group (AHWG) on EU5G in Q4 2021 following a European Commission request. As of mid-2026, the scheme has not been formally adopted and no complete public draft is available — making it the least mature of the three schemes requested under the CSA (after EUCC, adopted in January 2024, and EUCS, still stalled). Current work has focused on specific components: in June 2024, ENISA launched a public consultation on technical specifications for eUICC (embedded Universal Integrated Circuit Card) certification, which will be handled under the existing EUCC framework rather than a new standalone scheme. A broader EU NESAS scheme for 5G network products is under development, leveraging the existing GSMA NESAS/3GPP SCAS methodology. The scheme is expected to be voluntary once adopted, with assurance levels aligned to the CSA’s basic/substantial/high structure. Its practical significance will be shaped by the revised Cybersecurity Act (CSA2), proposed in January 2026, which strengthens ENISA’s mandate and may provide additional impetus for adoption.

GSMA NESAS

Compliance Telecom 5g Gsma International
The GSMA Network Equipment Security Assurance Scheme (NESAS) is a voluntary, global security assurance framework jointly led by the GSMA and 3GPP. It was established to provide a universal, industry-driven security evaluation for mobile network equipment — primarily targeting 4G/LTE and 5G infrastructure — that avoids the fragmentation of country-specific security requirements. NESAS operates through two complementary components: first, an audit of the vendor’s development and product lifecycle processes (covering secure design, implementation, testing, and vulnerability handling), conducted by GSMA-appointed auditing organizations; second, a product evaluation against 3GPP-defined Security Assurance Specifications (SCAS), performed by ISO/IEC 17025 accredited security test laboratories. The GSMA manages scheme governance (accreditation, dispute resolution, publication of results), while 3GPP’s SA3 working group defines the technical security requirements and test cases in SCAS documents. The scheme is currently at NESAS v3.0 (specifications published early 2025), which introduces revised security requirements and expands coverage to include virtualized network functions. NESAS is voluntary — no government mandates it — but it is increasingly referenced by national 5G security reviews and procurement requirements (including the EU 5G Toolbox), and major operators use NESAS assessment results as a procurement criterion. Evaluated vendors and their results are publicly listed on the GSMA website.

5G Core (5GC)

Telco 5g 5gc Core-Network Service-Based-Architecture Nfv Cloud-Native Network-Slicing Upf Amf Smf Standards 3gpp
The 5G Core (5GC) is the packet core network architecture defined by 3GPP from Release 15 onward as the control and user-plane backbone of standalone 5G deployments. It replaces the Evolved Packet Core (EPC) of 4G LTE not through incremental evolution but through a deliberate architectural break: where the EPC was built around monolithic, hardware-bound network functions interconnected by point-to-point interfaces, the 5GC is designed from the ground up around a Service-Based Architecture (SBA) — every network function exposes its capabilities as a set of services over a common HTTP/2 bus (the Service-Based Interface, SBI), and any authorised consumer NF can discover and invoke those services through the NRF (Network Repository Function) without bilateral peering agreements or proprietary protocols. This shift reflects two structural requirements of 5G that EPC could not satisfy: network slicing — the ability to run logically independent end-to-end networks (each with its own QoS, isolation, and lifecycle) on shared physical infrastructure — and cloud-native deployment, where NFs run as containerised microservices on commodity compute, can be horizontally scaled, and are managed by standard Kubernetes-compatible orchestration rather than vendor-specific element managers. The 5GC also enforces a hard separation between Control Plane (CP) and User Plane (UP) — the CUPS principle inherited from 3GPP Release 14 and fully operationalised here — so that the UPF (User Plane Function) handling packet forwarding, QoS enforcement, and traffic anchoring can be distributed to the edge independently of the control logic, enabling ultra-low-latency and MEC scenarios without redesigning the control plane. The architecture is access-agnostic: the same 5GC serves NR (New Radio), eLTE, Wi-Fi (untrusted/trusted non-3GPP access), and fixed-wireless access through a unified N2/N3 reference point toward the access network and a common UE context model in the AMF.