GSMA NESAS and 3GPP SCAS, explained

NESAS, the Network Equipment Security Assurance Scheme, is the mobile industry's own answer to "how do we know a 5G base station or core network function was actually built and tested securely?" Jointly defined by GSMA (the mobile operator trade body) and 3GPP (the standards body that specifies the networks themselves), NESAS pairs an audit of a vendor's development process with lab evaluation of specific products against 3GPP SCAS (Security Assurance Specifications) — a growing family of technical specifications that, per 3GPP's own description, is now "the basis for Network Equipment & Cyber security certification programs" adopted well beyond 3GPP's own membership, including by the EU's ENISA and Germany's BSI.

Who does what: 3GPP writes the requirements, GSMA runs the scheme

NESAS splits cleanly along organizational lines, and 3GPP's own TR 33.916 (the specification defining SECAM, the underlying methodology) says so directly in its Scope clause: "Some of the tasks described in the SECAM scheme are meant to be performed by 3GPP, while other tasks are meant to be performed by the SECAM Accreditation Body. This accreditation body has been agreed to be the GSMA. 3GPP maintains the overall responsibility for the SECAM scheme and creates the SCASs. The SECAM Accreditation Body is tasked to develop requirements on vendor network product development, the network product lifecycle management process, and SECAM-accreditation for vendors and test laboratories."

In practice:

• 3GPP's Security Working Group (SA3) writes the technical security requirements and test cases — the SCAS specifications — for each class of network function (gNodeB, AMF, UPF, UDM, and so on).
• GSMA governs the scheme itself: it appoints the auditing organizations that assess vendor development processes, accredits the ISO/IEC 17025 test laboratories that run SCAS evaluations against products, and defines the vendor-process security requirements SCAS doesn't cover.

The two-part assessment

Per 3GPP's own technologies page (authored by SA3 Working Group Chair Suresh P. Nair): "A NESAS assessment consists of two parts, the first is an audit of the vendor's development and product lifecycle process; and the second is an evaluation of a specific product release and its related documents against test-cases defined in 3GPP SCAS." A GSMA-authored overview of the scheme breaks this into three practical elements — security assessment of vendor development/lifecycle processes, ISO/IEC 17025 accreditation of test laboratories, and product evaluations by those labs against standardized requirements and test cases.

Step	What happens	Who performs it
1. Vendor self-assessment	Vendor defines security-related development and lifecycle processes, signs a Conformance Claim	Equipment vendor
2. Independent process audit	Audit Team independently audits those processes against NESAS requirements, writes an Audit Report agreed with the vendor	GSMA-appointed Audit Team
3. Test lab accreditation	An ISO/IEC 17025 accreditation body accredits a NESAS Security Test Laboratory, using 3GPP SA3-defined test procedures and GSMA-defined equipment/expertise requirements	Recognized ISO 17025 accreditation body
4. Product compliance declaration	Vendor builds the product following its assessed processes, declares compliance with those processes for the specific release	Equipment vendor
5. Product and evidence evaluation	Test lab evaluates the compliance evidence, then evaluates the network product itself against the applicable SCAS specifications	Accredited NESAS Security Test Laboratory

A product evaluation (step 5) is only meaningful once the vendor's development process has already passed its own audit (step 2) — the scheme is explicit that a passing process audit is a prerequisite for product evaluation, not a parallel, independent check.

SECAM and SCAS: the technical specifications underneath

SECAM (Security Assurance Methodology) is the overall framework; SCAS (Security Assurance Specifications) are the concrete per-network-function requirements and test cases it produces. TR 33.916's Scope states SECAM "will detail the different evaluation tasks (vendor network product development and network product lifecycle management process assessment, Security Compliance Testing, Basic Vulnerability Testing and Enhanced Vulnerability Analysis)," while also noting a real limitation: "Enhanced Vulnerability Analysis is outside the scope of the present release of SECAM" — SCAS testing, as it stands, does not include the kind of open-ended penetration testing that term usually implies.

The specification family has two layers:

• TR 33.926 — "specifies the network product class descriptions, threats and critical assets" common across product classes, per 3GPP's own summary.
• TS 33.117, "Catalogue of general security assurance requirements" — the requirements and test cases shared across most network product classes. Its own Scope states: "Several network product classes share very similar if not identical security requirements for some aspects. Therefore, these are collected in this 'catalogue' document applicable to many network product classes. In addition to this catalogue, requirements specific to different network product classes will be captured in separate documents."
• Network-function-specific SCAS specifications — a long and growing list, including TS 33.511 (gNodeB), 33.512 (AMF), 33.513 (UPF), 33.514 (UDM), 33.515 (SMF), 33.516 (AUSF), 33.517 (SEPP), 33.518 (NRF), 33.519 (NEF), 33.520 (N3IWF), 33.521 (NWDAF), 33.522 (SCP), 33.523 (split gNB), 33.526 (MnF), 33.527 (virtualized network product classes), 33.528 (PCF), 33.529 (SMSF), 33.530 (UDR) and 33.537 (AAnF), alongside legacy pre-5G specifications such as TS 33.116 (MME), TS 33.216 (eNodeB) and TS 33.250 (PGW).

TS 33.117's Clause 4.1 sets ground rules for how any of this testing happens: the target network product must already be "installed correctly," "powered on," and communicating "over all standardized interfaces and OAM interfaces" before testing starts, and the specification is explicit about scope: "SCAS testing is not about security in operations and deployments. So, in particular, SCAS testing is independent of any operator guidelines or considerations on specific deployment scenarios." On tooling, Clause 4.1.2 prefers "Commercial-off-the-shelf (COTS) and Free-Open-Source-Software (FOSS) tools that are available for other testers that may want to repeat the test," allowing vendor-proprietary tools only "as long the test tool is controlled under a suitable quality management system (QMS)."

Clause 4.4, "Basic vulnerability testing requirements," gives the clearest worked example of what a SCAS test case actually looks like. It covers four testing aspects — port scanning, vulnerability scanning, robustness/fuzz testing, and endpoint scanning — and spells one out concretely: the Port Scanning requirement states "it shall be ensured that on all network interfaces, only documented ports on the transport layer respond to requests from outside the system," backed by test case TC_BVT_PORT_SCANNING, which requires the vendor to document, in advance, "all interfaces providing IP-based protocols," "the available transport layer protocols on these interfaces," "their open ports and associated services," and "a free-form description of their purposes" — so the lab has a concrete baseline to scan against rather than guessing what "normal" looks like for that product.

NESAS's reach: EU certification and national schemes

NESAS did not stay a purely industry-internal exercise. Per a GSMA-authored deck on NESAS hosted by ENISA, GSMA formally proposed NESAS as a candidate certification scheme under the EU Cybersecurity Act: on 22 February 2021, "GSMA Director General" wrote to "ENISA Executive Director," noting the European Commission's request to ENISA to develop a 5G network equipment certification scheme, and submitting "a formal proposal, developed in conjunction with Germany's Bundesamt für Sicherheit in der Informationstechnik (BSI)," offering NESAS as "an existing scheme that can be adopted and adapted to meet the EU needs." 3GPP's own technologies page confirms the broad outcome: "EU ENISA has adopted 3GPP and GSMA into the certification framework" for network products.

At the national level, Germany's BSI operates the clearest public example of NESAS feeding into a binding regulatory requirement. BSI's own program page states it "has been operating a national product certification program for highly specialized components in the 5G core network, based on the NESAS evaluation scheme of the GSMA: BSI NESAS, formerly NESAS CCS-GI" since July 2022, and that BSI's Technical Guideline TR-03163 designates BSI-NESAS as "the only permitted certification program" for components implementing certain 3GPP core-network and NFV-MANO functions sold into the German telecom market. BSI also confirms that GSMA's own scheme has continued to evolve past the version covered in the 2021 deck: BSI's current scheme version "implements Version 3.0 of the underlying NESAS scheme of the GSMA." Separately, 3GPP's technologies page notes that India's Telecommunication Security Assurance Requirements (ITSAR) "use the generic SCAS requirements (TS 33.117) and Network Function specific SCASs as the basis for its scheme" — a second national example of SCAS being reused wholesale rather than reinvented.

A workable starting point

1. If you build or buy 3GPP network functions, start with TS 33.117, not the function-specific SCAS. The generic catalogue covers the security baseline — authentication, logging, hardening, basic vulnerability testing — that every network product class inherits; function-specific specifications (33.511, 33.512, etc.) only add what's unique to that function.
2. Treat the vendor-process audit as a gate, not a parallel track. NESAS's product evaluation step assumes the vendor's development and lifecycle process has already passed its own independent audit — a product can't be meaningfully NESAS-evaluated on top of an unaudited or failed process.
3. Don't confuse SCAS testing with a full penetration test. TR 33.916 is explicit that Enhanced Vulnerability Analysis sits outside SECAM's current scope — SCAS's Basic Vulnerability Testing (port scanning, vulnerability scanning, fuzzing, endpoint scanning) is a defined, repeatable baseline, not open-ended red-teaming.
4. Check whether a national scheme has made NESAS mandatory for your market, as Germany's BSI has for specific 3GPP-core and NFV-MANO product classes under TR-03163 — "built on NESAS" and "legally required for this market" are two different claims, and only the second changes your go-to-market timeline.
5. Go to gsma.com/nesas for the current FS.xx documents and conformance lists. This guide is built on 3GPP's own specifications plus GSMA content as quoted or hosted by ENISA and BSI, because GSMA's own resource pages were not independently fetchable during research (see the FAQ above) — treat vendor/lab/product counts and the exact current FS.xx version numbers as needing a direct check against GSMA's own site before relying on them.

SoftWSP's firmware and device security assessments can test network-adjacent embedded products against SCAS-style baselines — documented ports, authentication hardening, logging, basic vulnerability scanning — even where a full NESAS evaluation isn't in scope: see Device & Firmware Security.

This guide quotes 3GPP's own published TR 33.916 and TS 33.117 text, 3GPP's official technologies-page article on SCAS, a GSMA-authored NESAS overview deck as hosted on ENISA's website, and Germany's BSI official NESAS certification program page. GSMA's own gsma.com/security resource pages and FS.13-FS.51 documents were not independently fetchable during research (requests returned HTTP 403/redirect responses); readers should confirm current scheme versions, conformance lists and document text directly at gsma.com/nesas before relying on them. This guide is not a substitute for the full SECAM/SCAS specifications or NESAS scheme documents, and does not constitute compliance or certification advice.