GSMA Baseline Security Controls (v3.0)

Overview of GSMA BSC v3.0

Released in 2023, Version 3.0 of the GSMA Baseline Security Controls represents a fundamental modernization of the framework to address the paradigm shift brought by 5G Standalone (SA) networks. While v2.0 focused on securing legacy physical infrastructure and traditional network architectures, v3.0 acknowledges that modern telecom networks are essentially cloud-native software platforms running on virtualized hardware. This shift from hardware-based to software-based network functions fundamentally changes security requirements, requiring new approaches to network security, vendor management, and operational practices.

This version integrates critical new domains including virtualization security, containerization (Kubernetes), and zero-trust principles for the Service Based Architecture (SBA) of 5G. The framework recognizes that 5G networks use microservices architectures where network functions communicate via APIs rather than traditional signaling protocols, requiring application-layer security controls that were unnecessary in previous generations. It also significantly expands requirements for supply chain resilience in response to global concerns about high-risk vendors in critical infrastructure, requiring operators to assume vendor equipment could be compromised and implement mitigating controls.

Version 3.0 emerged during a period of rapid 5G deployment worldwide, as operators were transitioning from 4G LTE to 5G Standalone architectures. The framework was developed through extensive collaboration between GSMA member operators, cloud providers, equipment vendors, and security experts, ensuring that controls address real-world 5G deployment challenges. It represents the industry's consensus on minimum security requirements for secure 5G network operations, balancing security needs with operational practicality.

Key Enhancements in Version 3.0

Version 3.0 retains the foundational structure of v2.0 but adds depth and new categories to reflect the "softwarization" of the network.

1. Cloud & Virtualization Security

With Network Functions Virtualization (NFV), telecom functions now run as software on commodity hardware rather than specialized telecom equipment. This shift creates new attack surfaces and security challenges that v3.0 addresses through comprehensive virtualization security controls. The framework recognizes that virtualized network functions are vulnerable to attacks on the virtualization layer itself, requiring security controls that were unnecessary when functions ran on dedicated hardware.

Hypervisor Security: The virtualization layer (hypervisor) that enables multiple virtual machines to run on physical hardware represents a critical security boundary. If compromised, attackers could potentially escape from a virtual machine to access other VMs or the host system—a "VM escape" attack. Version 3.0 mandates hardening of hypervisors through secure configuration, regular patching, access controls limiting who can manage hypervisors, and monitoring for hypervisor-level attacks. Operators must implement hypervisor security baselines, conduct regular security assessments, and maintain separation between different network function VMs to prevent lateral movement.

Container Security: Many 5G network functions run in containers (Docker, Kubernetes) rather than virtual machines, providing lighter-weight virtualization but introducing new security considerations. Version 3.0 requires securing container environments through image signing (ensuring only trusted container images are deployed), runtime protection (monitoring containers for malicious behavior), network policies (controlling container-to-container communication), and secrets management (securely storing credentials used by containers). Operators must implement container security scanning to identify vulnerabilities in container images before deployment, use trusted container registries, and implement least-privilege access controls for container orchestration platforms.

Orchestration Security: The MANO (Management and Orchestration) layer controls the lifecycle of virtual network functions, including deployment, scaling, and termination. Compromise of orchestration systems could allow attackers to deploy malicious network functions or disrupt network operations. Version 3.0 requires securing orchestration platforms through strong authentication, role-based access control, audit logging of all orchestration activities, and network segmentation isolating orchestration traffic. Operators must implement secure APIs for orchestration, monitor orchestration activities for anomalies, and maintain backup and recovery capabilities for orchestration systems.

2. 5G Service Based Architecture (SBA)

5G cores use a Service Based Architecture (SBA) where network functions communicate via RESTful APIs (HTTP/2, JSON) rather than traditional signaling protocols like SS7 or Diameter. This architectural shift enables more flexible network deployments but introduces new security challenges. Version 3.0 introduces comprehensive controls for securing SBA communications, recognizing that API-based architectures require application-layer security controls that were unnecessary in protocol-based architectures.

Security Edge Protection Proxy (SEPP): The SEPP is a critical security component that filters and secures inter-network 5G traffic, similar to signaling firewalls in 4G but operating at the application layer. Version 3.0 mandates deployment of SEPP at all inter-operator boundaries to prevent attacks via roaming and interconnect services. SEPP provides message filtering, rate limiting, and security policy enforcement for inter-network communications. Operators must deploy SEPP at international gateways, configure security policies that block malicious traffic while allowing legitimate roaming services, and monitor SEPP events for attack detection. The framework recognizes that SEPP configuration is complex and requires careful tuning to avoid disrupting legitimate services while blocking attacks.

API Security: In SBA architectures, network functions communicate via APIs, requiring strong authentication and authorization to prevent unauthorized access. Version 3.0 mandates implementation of OAuth 2.0 for API authentication, ensuring that only authorized network functions can access services. The framework requires operators to implement Zero Trust principles for internal network communications, verifying every API request regardless of source. Operators must implement API gateways that provide authentication, authorization, rate limiting, and monitoring capabilities. API security also requires protection against common web application attacks (injection, cross-site scripting) that could compromise network functions through API vulnerabilities.

Network Function Authentication: Version 3.0 requires that all network functions authenticate themselves when communicating with other functions, preventing spoofing attacks where malicious functions impersonate legitimate ones. This requires implementation of mutual TLS (mTLS) or similar authentication mechanisms for network function communications. Operators must maintain inventories of authorized network functions, implement certificate management for network function authentication, and monitor for unauthorized network function deployments or communications.

3. Enhanced Supply Chain Security

Building on v2.0's vendor management requirements, Version 3.0 requires a "Zero Trust" approach to vendors, assuming that vendor equipment could be compromised and implementing mitigating controls to limit the blast radius of a compromised supplier. This shift reflects growing concerns about supply chain attacks targeting critical infrastructure, where attackers compromise vendors to gain access to operator networks.

Operators must implement "clean corridors" for management traffic, isolating vendor management interfaces from other network traffic to prevent lateral movement if vendor equipment is compromised. The framework requires operators to segment vendor equipment into isolated network zones, implement network monitoring for vendor management traffic, and maintain the ability to quickly isolate compromised vendor equipment. Operators must also conduct enhanced security assessments for high-risk vendors, including on-site assessments, source code reviews (where applicable), and continuous monitoring of vendor security postures.

The framework recognizes that operators often have limited visibility into vendor security practices, requiring contract requirements for vendor security certifications, incident notification obligations, and audit rights. Operators must maintain vendor risk registers that categorize vendors by risk level, track vendor security incidents, and implement processes for managing vendor security failures. Version 3.0 also requires operators to verify the integrity of vendor software and hardware updates, ensuring that updates have not been tampered with during delivery.

4. Fraud & Security Operations Integration

Version 3.0 introduces new controls integrating fraud detection with security monitoring, recognizing that fraud schemes (e.g., Wangiri, IRSF) often fund cybercrime and may indicate broader security compromises. The framework encourages sharing of intelligence between fraud teams and Security Operations Centers (SOCs), enabling detection of attacks that might otherwise go unnoticed.

Fraud detection systems can identify anomalous network activity that security monitoring might miss, such as unusual call patterns or SMS routing that could indicate network compromise. Security monitoring systems can detect technical attacks that fraud systems might not identify, such as signaling protocol abuse or API attacks. Version 3.0 requires operators to integrate these capabilities, sharing threat intelligence and coordinating response to incidents that have both fraud and security implications.

The framework requires operators to establish processes for correlating fraud events with security events, enabling detection of sophisticated attacks that combine fraud and technical compromise. Operators must implement shared threat intelligence platforms, conduct joint fraud and security incident response exercises, and maintain relationships with industry information sharing groups that facilitate cross-operator threat intelligence sharing.

Applicability and Adoption

GSMA BSC v3.0 is the current standard for:

• 5G Network Operators: Mandatory for secure 5G deployment.
• Cloud Providers (Hyperscalers): AWS, Azure, and Google Cloud hosting telecom workloads must align with these controls.
• Private 5G Enterprises: Organizations deploying private cellular networks for factories or campuses.

Implementation Strategies and Best Practices

Successfully implementing GSMA BSC v3.0 requires operators to adapt their security programs to address cloud-native architectures, virtualization security, and enhanced supply chain risks. Effective implementation strategies address both the technical and organizational challenges unique to 5G security.

Secure by Design Approach: For 5G rollouts, security must be baked into network design from the beginning rather than added as an afterthought. Operators should use v3.0 controls as requirements in RFPs (Request for Proposals) when procuring new network cores, ensuring that vendors understand security expectations upfront. Security requirements should be included in network architecture decisions, vendor selection criteria, and deployment planning. Operators should conduct security architecture reviews before deploying 5G networks, ensuring that security controls are designed into the network rather than retrofitted later.

Implement Compliance as Code: Because v3.0 deals with virtualized, dynamic environments where network functions are constantly deployed, scaled, and terminated, manual auditing is impossible. Operators should implement "Compliance as Code" tools that automatically check configuration against BSC baselines, ensuring that security controls are maintained even as networks change. These tools can validate container image security, check API security configurations, verify network segmentation, and monitor for policy violations. Automated compliance checking enables operators to maintain security in dynamic environments where manual processes would be overwhelmed.

Prioritize Interconnect Defense: The roaming edge remains the most common attack vector, requiring prioritized deployment of SEPP (for 5G) and Diameter Firewalls (for 4G) to secure inter-operator boundaries. Operators should deploy these security controls before enabling new roaming agreements, ensuring that interconnects are secured from day one. Firewall rules must be carefully tuned to block malicious traffic while allowing legitimate services, requiring ongoing monitoring and adjustment. Operators should implement automated threat intelligence feeds that update firewall rules based on emerging threats, enabling rapid response to new attack patterns.

Develop Cloud Security Expertise: Version 3.0 requires expertise in cloud security, containerization, and API security that many telecom operators lack. Operators should invest in training existing staff, hiring cloud security specialists, or partnering with managed security service providers (MSSPs) that have cloud security capabilities. The framework recognizes that securing cloud-native networks requires different skills than securing traditional networks, requiring operators to develop or acquire new capabilities. Operators should establish cloud security centers of excellence that provide expertise across the organization, ensuring consistent security practices.

Implement Zero Trust Architecture: The SBA security requirements in v3.0 are based on Zero Trust principles, requiring operators to verify every network function communication regardless of source. Operators should implement Zero Trust architectures that authenticate and authorize all network communications, segment networks to limit lateral movement, and monitor all network activity for anomalies. Zero Trust requires operators to assume that network functions could be compromised and implement controls that limit the impact of compromises.

Establish Vendor Security Programs: Enhanced supply chain security requirements require robust vendor management programs. Operators should categorize vendors by risk level, conduct comprehensive security assessments for high-risk vendors, implement network segmentation for vendor equipment, and maintain processes for managing vendor security incidents. Operators should require vendors to provide security certifications, maintain security incident notification obligations, and grant audit rights. Contract requirements should mandate vendor security practices, ensuring that vendors maintain adequate security postures.

Relationship to Other Frameworks

• GSMA BSC v2.0: The predecessor. v3.0 includes all v2.0 controls but adds the cloud/5G layer.
• NIST Zero Trust Architecture: The principles of SBA security in v3.0 are directly derived from Zero Trust concepts.
• 3GPP SA3 Standards: The BSC provides operational guidance on how to implement the technical security standards defined by 3GPP.

Common Challenges and Solutions

Operators implementing GSMA BSC v3.0 encounter predictable challenges related to skill gaps, architectural complexity, vendor dependencies, and resource constraints. Understanding these challenges and proven solutions helps operators build effective 5G security programs.

Skill Gap Convergence: Telecom engineers often lack cloud security skills, while cloud security experts lack telecom knowledge. Version 3.0 requires a convergence of these skill sets, creating a "DevSecOps" culture that combines development, security, and operations expertise. This skill gap makes it difficult for operators to find qualified staff who understand both telecom networks and cloud security.

Solution: Operators address skill gaps through comprehensive training programs that teach telecom engineers cloud security concepts and cloud security experts telecom fundamentals. Cross-functional teams that combine telecom and cloud expertise enable knowledge sharing and skill development. Operators should invest in certification programs (like cloud security certifications) for existing staff, hire specialists with hybrid expertise, or partner with MSSPs that have both telecom and cloud security capabilities. Some operators establish internal training programs or send staff to industry training courses to develop required skills.

Architectural Complexity: Securing thousands of ephemeral microservices in a 5G core is significantly more complex than securing a few dozen hardware boxes in a 4G core. The dynamic nature of cloud-native architectures means that network functions are constantly being deployed, scaled, and terminated, making it difficult to maintain security visibility and control. The complexity of SBA architectures, with numerous network functions communicating via APIs, creates a large attack surface that must be secured.

Solution: Operators address complexity through automation, standardized security baselines, and centralized security management. Automated security scanning, configuration management, and compliance checking enable operators to maintain security in dynamic environments. Operators should implement security orchestration platforms that automate security processes, reducing manual effort and ensuring consistency. Standardized security baselines for containers, APIs, and network functions enable operators to apply security controls uniformly across diverse environments. Centralized security management through SIEM and security analytics platforms provides visibility into complex architectures.

Vendor Dependence: Operators remain heavily dependent on vendors for 5G network equipment, cloud platforms, and security tools. Vendor security failures can directly impact operator security, creating risks that operators cannot fully control. The complexity of vendor ecosystems makes it difficult to assess and monitor vendor security postures effectively.

Solution: Operators address vendor dependence through diversification, enhanced vendor management, and network segmentation. Diversifying vendor ecosystems reduces reliance on single vendors, enabling operators to isolate compromised vendors without disrupting operations. Enhanced vendor management programs include comprehensive security assessments, contract requirements mandating security practices, and ongoing monitoring of vendor security postures. Network segmentation isolates vendor equipment, limiting the impact of vendor security failures. Operators should maintain contingency plans for vendor failures, including alternative vendors and rapid isolation capabilities.

Resource Constraints: Implementing comprehensive v3.0 controls requires significant investment in technology, personnel, and processes. Small operators or those in developing markets may lack resources for comprehensive implementations. The specialized nature of 5G security requires expertise that may be difficult to recruit or expensive to acquire.

Solution: Operators address resource constraints through prioritized implementations, managed services, and industry partnerships. Prioritizing high-risk areas (like interconnect security) enables operators to focus limited resources where they provide the most value. Managed security services enable operators to leverage external expertise without hiring full-time staff. Industry partnerships and information sharing groups provide access to security expertise and threat intelligence that individual operators might not be able to develop independently. Cloud-based security tools reduce infrastructure costs while providing advanced capabilities.

Frequently Asked Questions

Do I need to upgrade to v3.0 if I don't have 5G?

It is highly recommended, even for operators without 5G deployments. Version 3.0 includes updated guidance on virtualization and supply chain security that applies to modern 4G LTE networks. Many 4G operators are deploying Network Functions Virtualization (NFV) and cloud-native architectures that benefit from v3.0 controls. The enhanced supply chain security requirements address risks that exist regardless of network generation. Operators planning 5G deployments should implement v3.0 as part of their 5G readiness activities, ensuring that security is designed into 5G networks from the beginning.

Is this framework relevant for Private 5G?

Yes, absolutely. Enterprises deploying Private 5G networks act as "mini-operators" and face similar risks to public network operators. Implementing BSC v3.0 ensures that private networks are not weak points for enterprise IT networks. Private 5G networks often connect to enterprise IT systems, creating potential attack paths if private networks are not properly secured. Version 3.0 provides comprehensive guidance for securing private 5G deployments, including virtualization security, API security, and supply chain management. Enterprises should adapt v3.0 controls to their specific risk profiles and operational requirements.

What is the relationship between GSMA BSC and NESAS?

NESAS (Network Equipment Security Assurance Scheme) audits the equipment vendors who supply network infrastructure, while GSMA BSC audits the operators who deploy that equipment. They are complementary parts of the GSMA security ecosystem. NESAS ensures that vendor equipment meets security standards, while BSC ensures that operators deploy and operate equipment securely. Operators should require vendors to obtain NESAS certification, demonstrating that vendor equipment meets security requirements. Operators must then implement BSC controls to ensure secure deployment and operation of that equipment. The relationship ensures security throughout the supply chain, from vendor development through operator deployment.

How does v3.0 address cloud provider security?

Version 3.0 recognizes that many operators deploy 5G networks on cloud platforms (AWS, Azure, Google Cloud) and includes controls for securing cloud-hosted network functions. The framework requires operators to implement cloud security controls including identity and access management, network segmentation, encryption, and monitoring. Operators must ensure that cloud providers implement adequate security controls, requiring cloud provider security certifications and contract requirements. The framework addresses shared responsibility models, clarifying which security controls are the operator's responsibility versus the cloud provider's responsibility.

Can operators implement v3.0 incrementally?

Yes, operators can and should implement v3.0 controls incrementally, prioritizing high-risk areas first. Operators should begin with foundational controls like security governance and risk management, then implement technical controls based on risk priorities. Interconnect security (SEPP, Diameter Firewalls) should be prioritized as it addresses the most common attack vector. Virtualization and cloud security controls can be implemented as operators deploy cloud-native architectures. The framework is designed to support incremental implementation, enabling operators to improve security progressively rather than requiring comprehensive implementation immediately.