For Ukrainian IT product companies developing solutions for the telecom sector and targeting the European Union market, cybersecurity has finally transformed from a formal checklist into an architectural standard. The NIS2 directive is forcing European telecom operators, recognized as critical infrastructure, to review the reliability of their supply chains. Any software vendor whose OSS/BSS system fails to isolate processes from legacy cores risks losing access to European tenders.
For owners and CEOs of Ukrainian technology businesses, this represents a direct threat to export revenue. Modernizing product architecture through decoupling and a Security by Design approach is a necessary investment to maintain market share and the status of a reliable supplier for EU operators.
NIS2 as a new barrier to entry: why European telecom is changing the rules
European telecom operators function under strict regulatory oversight. According to NIS2 criteria, they are classified as "essential entities." Incidents within their networks lead not only to operational losses but also to severe fines and potential personal liability for management.
Statistics prove the reality of these risks. According to the European Union Agency for Cybersecurity (ENISA), 4,875 incidents were analyzed in the 2024-2025 reporting period, and 53.7% of all affected organizations were identified as "essential entities." Furthermore, approximately 27.7% of all recorded data breaches occurred in the digital infrastructure and services sector. Under these conditions, operators no longer risk integrating third-party software without a deep architectural audit.
Anatomy of the threat: why monolithic OSS/BSS no longer meet compliance
Historically, Operations and Business Support Systems (OSS/BSS) were built as monoliths, where client services, billing transactions, and network resource management were tightly coupled. In such environments, the compromise of a single module can mean gaining control over the network core.
This model has become unacceptable due to a number of critical vulnerabilities:
- Lack of process isolation: an attack on a less secure external interface (e.g., a self-service portal) provides direct access to the billing database.
- Legacy protocol vector: signaling interfaces like SS7 and Diameter in legacy cores, which ENISA consistently identifies as potential points of vulnerability, remain open to unauthorized internal requests from the monolithic system.
- Financial losses: architectural flaws in BSS translate directly into losses. According to the CFCA Global Fraud Loss Survey 2025 report, global losses from telecom fraud reached approximately $41.82 billion.
Decoupling strategy: how to isolate critical business processes from the legacy core
Transitioning to NIS2 requirements does not necessarily require an immediate rewrite of all legacy code. The key approach is architectural decoupling—separating business logic and client modules from the sensitive telecom core to limit the blast radius in the event of an incident.
In practice, this process includes:
- Isolating billing systems: breaking direct database connections and transitioning to interaction via secure API Gateways.
- Implementing microservice control: using Role-Based Access Control (RBAC) at the component level, which ensures that processes only have access to the minimum data required.
- Auditing and protecting signaling traffic: replacing uncontrolled requests to SS7/Diameter with standardized service calls using encryption.
Security by design in practice: the role of platform approach and TM Forum ODA standards
The Open Digital Architecture (ODA) from the international association TM Forum serves as the benchmark for modernizing vendor systems. ODA involves replacing monolithic BSS/OSS with a componentized, API-first architecture that is compatible with the evolution of mobile networks to 5G Standalone and service-based architectures (according to 3GPP standards).
However, creating such a secure ecosystem from scratch requires vast resources. Many developers optimize this path by migrating development to ready-made platform foundations that already contain built-in security mechanisms.
An example of such a foundation is the UnityBase platform (a joint development by the companies of the Intecracy Group alliance, where InBase acts as a key, but not the only, developer). It is a full-stack JavaScript low-code platform for enterprise applications that, thanks to a unified domain metadata model, allows for the automatic generation of REST API and ensures strict access control.
For telecom solutions that must comply with NIS2, the capabilities of the commercial editions of the platform (Enterprise or Defence) are critical:
- Access control and data isolation: support for RBAC and Row-Level Security (RLS), which prevents the horizontal spread of threats between client or operational segments.
- Audit trail: detailed logging of all system processes and user actions, necessary for forensics and compliance.
- Cryptographic protection: integration with certificate authorities (CRL/OCSP) and integrity control of server modules in the Defence edition.
Specialized solutions for operators are created on such technological foundations. A notable example is the operator VoIP platform DooxSwitch (developed by the company DooxSwitch, which is part of the Intecracy Group technology alliance). The platform combines a softswitch, LCR routing, and real-time billing. Using a secure architectural foundation allows such specialized systems to meet the strict requirements of operators for reliability and pass European audits faster.
Supply chain risks: what European operators will demand from your code
Beyond pure architecture, NIS2 expands requirements for the development process itself. To remain in the pool of suppliers, product companies will have to ensure transparency in the following processes:
- Software Bill of Materials (SBOM): providing a comprehensive list of all libraries, open-source dependencies, and product components with proof of the absence of non-compliant vulnerabilities.
- CI/CD pipeline protection: automated security testing (SAST/DAST) for every release and isolation of build environments.
- Incident management: the existence of documented procedures for the rapid detection and remediation of vulnerabilities (Vulnerability Disclosure Policy).
Modernizing OSS/BSS to an API-first and Security by Design level does not guarantee automatic certification—procedural auditing remains the operator's responsibility. However, without architectural readiness, a telecom product will simply not be admitted for evaluation. Moving from a monolith to a componentized architecture is currently the only strategy for maintaining expansion into the European market.
Readiness levels of telecom products (OSS/BSS) for NIS2 requirements
| Readiness Level | Architectural Features | Impact on Risks and Compliance |
|---|---|---|
| Level 0 (Legacy Monolith) | Direct module access to DB, lack of signaling and business circuit isolation, high risk of supply chain attacks. | Critical non-compliance. Risk of rapid exclusion from the pool of European operator suppliers. |
| Level 1 (Hybrid API-first) | Initial implementation of API gateways, basic RBAC, but critical processes (e.g., billing) are tightly coupled with the core. | Partial risk reduction. Vulnerability to horizontal threat propagation remains. |
| Level 2 (ODA-aligned) | Componentized architecture according to TM Forum ODA standards, microservice isolation, traffic encryption. | Significant reduction in attack surface. Meets most basic architectural requirements of technical audits. |
| Level 3 (NIS2-ready / Security by Design) | Full decoupling, end-to-end action auditing, data isolation (RLS) at the platform level, automated code integrity control, and SBOM. | High readiness. Minimization of risks for the operator, readiness for integration into critical EU supply chains. |
FAQ
What specific sanctions and risks does NIS2 impose on software vendors for European operators?
The direct penalties of the NIS2 directive are aimed at the operators themselves (essential entities). However, to maintain compliance, operators are forced to stop working with vendors who cannot provide proof of architectural security (Security by Design), process isolation, and component transparency (SBOM), which automatically deprives the vendor of the market.
How does the TM Forum ODA architecture help meet process isolation requirements in telecom?
The ODA model conceptually shifts monolithic BSS/OSS to an API-first approach, breaking the system into isolated components (microservices). Their interaction occurs through standardized open APIs. This allows for limiting the blast radius in the event of an incident, preventing an attacker from moving from one module to other critical subsystems.
Is it mandatory to completely rewrite legacy OSS/BSS to obtain a certificate of compliance in the EU?
A complete rewrite is not always necessary or cost-effective. Most companies apply a decoupling strategy—separating critical processes, migrating them to secure enterprise platforms (for example, using UnityBase mechanisms for RLS and auditing), and closing off legacy systems with secure API gateways.