The European NIS2 directive and national cybersecurity regulations for critical infrastructure impose strict requirements on telecom operators. According to the ENISA Threat Landscape 2025 report, digital infrastructure and services account for approximately 27.7% of all data breaches. This presents a significant challenge for the telecom industry: most operators still rely on legacy Business Support Systems (BSS) that were not designed with modern threats in mind, yet must now integrate with dozens of third-party services, payment gateways, and AI agents.
Why legacy BSS is the primary telecom vulnerability in the NIS2 era
Legacy BSS often function as "black boxes." While they reliably handle service billing, they lack modern architectural security features such as detailed logging, granular Role-Based Access Control (RBAC), and end-to-end encryption. Consequently, connecting any third-party service becomes a security risk for the entire supply chain.
Under NIS2 requirements, operators, as essential entities, are obligated to manage risks associated with partners and suppliers. If a third-party service is compromised, attackers could gain unauthorized access to the billing core. The situation is further complicated by the fact that legacy systems often fail to track who initiated a request, as they frequently use a single shared system account for all external integrations.
The API facade concept: isolating the legacy core instead of risky refactoring
Attempting to modify the closed legacy code of a monolithic system is a path toward high costs and technological risks. Any intervention in code written many years ago threatens billing stability, financial losses, and prolonged service downtime.
The solution lies in the architectural isolation of the legacy core. Instead of rewriting code, architects deploy a secure API facade (an API gateway or integration layer). This intermediate layer handles security, authentication, authorization, and auditing, transforming risky direct requests into controlled transactions. The API facade does not eliminate internal vulnerabilities within the legacy code itself (it merely isolates it), but it reliably protects the system from the outside world by creating a single point of control.
Architectural requirements of TM Forum ODA for supply chain security
Modern telecom evolution is based on TM Forum Open Digital Architecture (ODA) standards. ODA proposes replacing monolithic BSS/OSS with a componentized, API-first architecture where services interact via standardized Open APIs. This brings telecom closer to cloud-native operations, similar to the 5G core architecture standardized by 3GPP.
To ensure trust in identifiers across networks, modern cryptographic methods are used. For instance, technical standards like STIR/SHAKEN rely on public keys to verify identifiers. In the context of BSS integrations, this means that every request from a third-party service must be authenticated, authorized, and logged at the API facade level before reaching the internal network.
Implementing access control and auditing at the integration layer
Building such a secure API facade requires a high-performance tool capable of processing large volumes of transactions. An example of creating such an integration layer is the use of solutions based on the UnityBase platform (developed by the Intecracy Group alliance, with InBase as a key developer).
The UnityBase platform functions as a full-stack JavaScript low-code framework. Through the Domain metadata concept, the platform allows for the rapid generation of secure REST APIs and the utilization of built-in security mechanisms critical for BSS:
- RBAC and RLS (Row-Level Security): Access differentiation not only at the API method level but also at the level of specific rows in databases.
- Detailed Audit Trail: End-to-end logging of every request and access attempt, which is a key NIS2 requirement for auditing and incident investigation.
- Modern authentication protocols: Support for OpenID Connect, OAuth2, JWT, and in the Defence edition, authorization via public and private keys.
This approach allows for the deployment of a secure gateway on-premises, integrating it with legacy databases and modern components, such as the operator-grade VoIP platform DooxSwitch (part of the Intecracy Group technology alliance), which provides real-time billing and routing.
Practical scenarios: secure connection of AI agents and payment gateways
- Forced authentication of third-party AI agents: Telecom operators are increasingly integrating external AI services. Instead of granting AI direct access to the DooxSwitch billing system or legacy databases, an API gateway on UnityBase is deployed in front of them, performing forced authentication for every request (e.g., verifying a JWT token) and limiting access speed.
- Logging requests to legacy databases without built-in auditing: Legacy databases often lack tools for detailed logging of SELECT queries. The integration layer intercepts all external requests, records the user ID, IP address, and parameters in a secure Audit Trail, ensuring action traceability.
- Access differentiation (RBAC) for external payment gateways: When connecting a payment partner, they only require access to specific functions (e.g., balance checks). Through the API facade, the partner receives strictly limited access. Attempts to access other functions are automatically blocked at the gateway level.
Comparison of BSS security modernization approaches
| Comparison criteria | Direct legacy code modification | Implementing a secure API facade (UnityBase) |
|---|---|---|
| Implementation speed | Low (months/years of analyzing old code) | High (weeks, without core intervention) |
| Risk to billing stability | Critical (potential transaction failures) | Zero (core operates in standard mode) |
| NIS2 audit compliance | Limited (difficult to implement end-to-end logging) | Full (centralized audit of all API requests) |
| Third-party connection flexibility | Extremely low (each integration developed separately) | High (standardized API contracts and RBAC) |
While implementing an API gateway does not guarantee full NIS2 compliance (as the directive also requires comprehensive risk management and organizational measures), building a secure API facade is the most rational engineering step for isolating vulnerable legacy telecom systems.
FAQ
How can NIS2 compliance be ensured for telecom systems without a full replacement of legacy BSS?
The most effective engineering step is to build a secure API facade (integration layer) in front of the legacy system. This allows for centralized authentication, access control (RBAC), and request auditing without interfering with sensitive billing code.
What requirements does the NIS2 directive impose on API and supply chain security in telecom?
The NIS2 directive obligates operators, as essential entities, to control cyber risks associated with partners. This requires the implementation of strict access control and mandatory Audit Trail logging for all external integrations with critical systems.
How can a secure API facade be built in front of a legacy billing system?
Specialized low-code integration platforms, such as UnityBase, are used for this purpose. This allows for the definition of a metadata model, the automatic generation of secure REST APIs, and the configuration of flexible logging and authorization rules to isolate the legacy core from direct external requests.