The NIS2 directive requires telecom operators to fundamentally rethink software supply chain security. Protecting integrations with external contractors has become a priority, as the ENISA Threat Landscape 2025 report indicates that digital infrastructure and services accounted for approximately 27.7% of all recorded data breaches. During the reporting period from July 1, 2024, to June 30, 2025, ENISA analyzed 4,875 incidents, confirming the systemic nature of attacks on telecom operators and their partners.
For technical leaders in telecom companies, this presents a significant challenge. Most critical business processes are still tied to legacy Business Support Systems and Operations Support Systems (BSS/OSS). These monolithic solutions were created in an era when supply chain threats were not considered critical. Today, connecting dozens of external service providers to a legacy core without proper isolation creates risks of compromising the entire network.
Why NIS2 focuses on the supply chain: threat analysis for telecom infrastructure
Telecom operators are the backbone of the digital society. According to ITU data, as of 2025, approximately two-thirds of the world's population uses the internet. Any disruption in an operator's operations has a cascading effect on the financial sector, logistics, and government services, which explains the stringent requirements of European regulators.
Beyond the threat to service availability, financial fraud is a critical factor. According to the CFCA Global Fraud Loss Survey 2025, global losses from telecom fraud are estimated at approximately $41.82 billion. A significant portion of these incidents is linked to the compromise of BSS/OSS integration nodes, through which attackers gain unauthorized access to billing or routing systems.
Complying with NIS2 requirements regarding supply chain security means that every API integration or request from a third-party service must pass through strict filters. However, legacy systems are architecturally incapable of providing such a level of verification.
Anatomy of vulnerability: why legacy BSS/OSS are not ready for direct integrations
A typical legacy BSS/OSS system is an on-premises monolith that uses a shared database for many modules. Attempts to integrate it with modern external services encounter three architectural problems:
- Lack of flexible access control. External partners are often granted excessive rights (e.g., database-level access) or use hardcoded accounts that cannot be revoked promptly.
- Weak authentication mechanisms. Legacy components generally do not support modern standards like OAuth2 or OpenID Connect (OIDC) for API requests.
- Fragmented audit trail. Event logs are often stored in text files on application servers where they are easily modified or deleted, making it impossible to conduct investigations in the event of an incident.
In such conditions, the compromise of even a secondary partner (e.g., an SMS messaging service) opens a direct path for attackers to billing information.
TM Forum ODA architectural pattern as a basis for isolating critical systems
To avoid a complete replacement of the core, architects are turning to modern modernization concepts. TM Forum ODA (Open Digital Architecture) proposes a transition from monolithic BSS/OSS to a componentized, API-first architecture. It is important to understand that ODA is not a security standard — it is an architectural reference model. However, its principles are ideal for isolating vulnerable nodes.
ODA involves creating clearly defined service boundaries. All interactions occur through standardized Open APIs. This allows for the construction of a secure integration layer that assumes the functions of protection and traffic filtering, leaving the legacy core isolated from direct external access.
Implementing a secure integration layer: API isolation and end-to-end audit trail
In practice, creating such a layer is based on three technical solutions:
- API isolation for legacy systems. External partners never access legacy components directly. An intermediate layer converts modern calls (e.g., REST with JWT) into internal BSS/OSS protocols.
- Request filtering via API Gateway. The gateway checks the structure of requests for compliance with data schemas, blocking unauthorized access attempts or injections before they reach critical nodes.
- Centralized audit trail. The intermediate layer logs every API request, recording who, when, from which IP address, and exactly what data was requested. Logs are recorded in an immutable storage (e.g., DataHistory), which complies with NIS2 requirements for traceability.
Practical implementation: modernizing the telecom core without interrupting processes
Building a secure integration layer requires an appropriate technological foundation. An example of a tool for deploying such architectures is the full-stack JavaScript low-code platform UnityBase (a joint development by companies within the Intecracy Group; an alliance of independent companies linked by partner agreements and share exchanges, not a single holding company; InBase acts as a key, but not the sole, developer of the platform).
Thanks to the Domain metadata concept, the platform allows for the design of a domain model, based on which REST APIs are automatically generated. For telecom infrastructures with high loads and strict security requirements, official documentation recommends commercial Enterprise (EE) or Defence (DE) editions. They provide critical NIS2-compliant protection mechanisms at the layer level:
- Support for modern authentication methods: OpenID Connect/OAuth2 and one-time passwords.
- Row-Level Security (RLS) and Access Control Lists (ACL), which allow for limiting data visibility for a specific partner-provider.
- Built-in immutable audit trail for all transactions.
In cases where modernization requires updating specific telecom modules (e.g., routing or billing), this integration approach can be combined with operator solutions, such as the DooxSwitch VoIP platform (with built-in real-time billing and LCR routing). Integrating DooxSwitch with a secure layer allows for managing IoT services or traffic routing without creating new vulnerabilities.
Disclaimer: The use of integration platforms or API gateways is a necessary technical step, but it does not automatically make an operator's infrastructure NIS2-compliant. Full compliance requires a comprehensive audit of processes and regular testing of supply chain security.
| NIS2 Requirement | Legacy Problem | Architectural Solution (Integration Layer) |
|---|---|---|
| Supplier access control | Hardcoded accounts in legacy, excessive partner privileges. | Implementation of an API Gateway with dynamic authentication (OAuth2/OIDC) and authorization based on RLS/ACL. |
| Traceability of actions (Audit Trail) | Logs are missing, fragmented, or stored in unprotected text files. | Centralized immutable logging of all transactions and API requests at the integration layer level. |
| Attack surface minimization | Direct partner access to databases and internal network interfaces. | Complete isolation of the legacy core using an API-first architecture (according to TM Forum ODA principles). |
FAQ
How to meet NIS2 supply chain security requirements without fully replacing legacy BSS/OSS?
Instead of replacing the core, a secure integration layer (API Gateway) is deployed. It handles authentication, request filtering, and logging, fully isolating the legacy system from direct external integrations with contractors.
What is the role of TM Forum ODA in ensuring telecom operator integration security?
TM Forum ODA is a reference architectural model that proposes a transition to a componentized architecture based on Open APIs. Its use allows for clearly defined service boundaries and control over all external traffic through a single secure layer.
How to organize a reliable audit trail for legacy billing systems?
A reliable audit is implemented at the integration layer level, which partners access. All incoming API requests are recorded in an immutable, secure log storage (detailing the initiator, time, and data volume) before the call is forwarded to the internal legacy billing system.