With the entry into force of strict NIS2 requirements, cybersecurity compliance has ceased to be a mere administrative formality. For the telecommunications industry, which is part of critical infrastructure, this has become a rigid architectural mandate. According to the ENISA Threat Landscape 2025 report, digital infrastructure and service providers account for approximately 27.7% of all organizations affected by data breaches. Essential entities, as classified by NIS2, represent 53.7% of all companies impacted by cyberattacks. In total, between July 1, 2024, and June 30, 2025, ENISA analyzed 4,875 incidents, confirming a rapid increase in the intensity of attacks on critical nodes.
The most vulnerable zone for modern telecom operators is their legacy Operations and Business Support Systems (OSS/BSS). The monolithic architecture of these solutions creates a massive attack surface. Compromising a single public interface often provides attackers with a path to billing systems and the network's signaling core. In this article, we will examine how to break the monolith, isolate critical processes, and ensure compliance without disrupting basic operations.
Why NIS2 changes the game for OSS/BSS: ENISA 2025 threat analysis
Telecom operators have historically built IT landscapes based on an internal security perimeter principle, assuming that everything inside the network is trusted. ENISA statistics refute this approach: phishing remains the leading vector for gaining initial access to systems. This means an attacker can easily bypass perimeter defenses through a compromised employee account.
When a threat penetrates a monolithic OSS/BSS, the lack of internal barriers allows for lateral movement. Attackers gain access to sensitive data or control over network resources. Beyond data breaches, fraud is a critical threat. According to the CFCA Global Fraud Loss Survey 2025, global losses from telecom fraud in 2025 are estimated at approximately $41.82 billion. A significant portion of these losses is linked to unauthorized access to billing systems.
Anatomy of vulnerability: how legacy core monoliths multiply risks
The main problem with legacy OSS/BSS architecture is the lack of decoupling and detailed activity auditing. In a classic monolith, billing modules, subscriber databases, and network provisioning systems are tightly coupled. This creates a series of critical vulnerabilities:
- Excessive attack surface: Integration with external partners or CRM is usually implemented through direct database queries or proprietary interfaces without proper transaction-level authorization.
- Lack of isolation: If a partner portal's web interface is compromised, an attacker may gain the ability to send commands directly to the core network.
- Weak auditing: Logging is performed at the general event level. Determining exactly which user changed a service status or database configuration is virtually impossible, which directly violates NIS2 accountability requirements.
Decoupling strategy: separating billing, CRM, and provisioning via TM Forum ODA principles
Radically replacing the network core and all BSS systems via a "rip-and-replace" approach is risky for large operators, as legacy systems often accumulate the majority of technical debt. Instead, global practice suggests an evolutionary, multi-year path of phased migration.
The TM Forum Open Digital Architecture (ODA) initiative proposes replacing monolithic BSS/OSS with a componentized, API-first architecture to ensure operational autonomy. It is important to note that migrating to ODA or cloud-native technologies does not automatically guarantee NIS2 compliance. These frameworks provide the technical enablers that make compliance possible.
The key principle of modernization is the separation of critical layers:
- Isolation of billing modules from core network signaling to prevent lateral movement in the event of a breach.
- Implementation of API-first gateways to replace proprietary interfaces between CRM and network provisioning systems.
- Application of Role-Based Access Control (RBAC) and centralized logging at the application software level.
This strategy aligns with the evolution of 3GPP standards, where releases define 5G Standalone functionality and the transition to cloud-native service architectures.
Supply chain security: protecting API integrations
Under NIS2, operators are required to manage risks associated with the supply chain. In telecom, this requires strict control over integrations: any partner service interacting with OSS/BSS must pass through a secure gateway using a Security by Design model.
An example of a technological foundation for building such an isolation layer is the use of the UnityBase platform (developed by the Intecracy Group alliance). The platform allows for the deployment of an integration API gateway that separates legacy components from the outside world. Thanks to a unified Domain metadata model, the platform combines data, interface, and security policy descriptions. For critical infrastructure, the Enterprise (EE) or Defence (DE) commercial editions are officially recommended, providing:
- Strict access control: RBAC mechanisms and Row-Level Security (RLS) ensure that a partner system gains access only to authorized data segments.
- End-to-end auditing: The DataHistory module creates a detailed audit trail, recording every action by a user or script, which satisfies NIS2 requirements for incident investigation.
- API protection: Automatically generated REST API endpoints undergo strict authentication (with support for OpenID Connect/OAuth2 and one-time passwords in commercial versions).
The technology alliance's telecom portfolio also includes the carrier-grade VoIP platform DooxSwitch, which provides isolated routing and real-time billing for voice and IoT/M2M traffic. Integrating such highly specialized BSS modules with a secure layer based on UnityBase allows operators to modernize tariffication and prevent fraud without interfering with the legacy network core.
Practical roadmap: phased isolation of legacy components
Transitioning to a secure architecture minimizes the impact on operational activities if performed iteratively. A typical roadmap includes:
- Audit: Identifying interaction points between the legacy monolith and the external environment.
- Creating an integration gateway (Decoupling Layer): Deploying a secure platform as an intermediary that verifies access rights.
- Module migration: Gradually moving functions (e.g., IoT billing) into separate services.
- Monitoring: Integrating application audit logs with a centralized SIEM system.
| Compliance Level | Architecture Description |
|---|---|
| Level 0 (Legacy monolith) | Shared database for billing and provisioning, no isolation, direct access by partner systems to the core. |
| Level 1 (Perimeter defense) | Monolith protected by firewalls, but full trust exists within the network; APIs are not standardized. |
| Level 2 (Hybrid decoupling) | Critical modules (billing, CRM) moved to separate perimeters, interaction via secure API gateways with RBAC. |
| Level 3 (Componentized ODA / NIS2-compliant) | Full layer isolation, zero trust at the transaction level, end-to-end logging of every action. |
Modernizing OSS/BSS to meet NIS2 requirements is a matter of business resilience in the face of growing cyber threats. Architectural separation using reliable platform tools allows for a smooth transition, protecting critical infrastructure without service downtime.
FAQ
How can telecom operators meet NIS2 supply chain security requirements?
It is necessary to eliminate direct access by partner systems to OSS/BSS databases. Interaction must occur through secure API gateways with authentication, traffic encryption, and the application of Role-Based Access Control (RBAC) and Row-Level Security (RLS).
Is it mandatory to perform a full 'rip-and-replace' of legacy BSS to achieve NIS2 compliance?
No, a full replacement carries high operational risks. An effective alternative is a decoupling strategy—building an intermediate integration layer that isolates the legacy core from external systems and ensures control and auditing at the API level.
What are the NIS2 requirements for logging and auditing user actions in billing systems?
NIS2 requires full accountability for incident investigation. The system must maintain an end-to-end audit trail of transactions, recording every change made to user profiles, tariffs, or network provisioning settings.