For Ukrainian product companies exporting software or integrating systems with European counterparts, the rules for operating in the EU market have changed fundamentally. The NIS2 (Network and Information Security Directive) shifts the focus of cybersecurity from protecting an organization's own perimeter to securing the entire supply chain. This means any API connecting your product to a European client's system is viewed by auditors as a critical point of potential infrastructure compromise.
For CEOs and CFOs of Ukrainian tech companies, API security is no longer just an internal technical matter for developers. Today, it is a direct business risk: non-compliance with new requirements can lead to the cancellation of export contracts and loss of margin. While previously filling out a standardized security questionnaire was enough to close a deal, clients now demand architectural proof that integration channels are securely protected and controlled.
The new NIS2 reality: why your APIs are under the microscope of European clients
Architects and developers often view integration merely as a technical communication channel, ignoring the fact that every API represents trust in external code and data. According to the ENISA Threat Landscape 2025 report, "essential entities" under NIS2 classification accounted for 53.7% of all cyberattack victims, with the digital infrastructure sector accounting for about 27.7% of data breaches. These figures justify the strict stance of European regulators on controlling every vulnerable link.
Under NIS2, any software provider automatically becomes part of the client's overall security perimeter. Compromising your interface could grant attackers access to critical systems of a European bank, logistics operator, or energy provider, exposing the client to significant financial penalties. Under these conditions, clients will not hesitate to drop suppliers whose architecture creates risks for their business.
The point-to-point trap: how chaotic integrations destroy supply chain security
Many product companies historically use point-to-point integration architectures. In this model, a direct connection is created between two systems using a static access key. As the number of such connections grows, the infrastructure turns into a chaotic web where security cannot be guaranteed.
Formalizing integration patterns helps avoid the risks of unmanaged point-to-point connections. The main vulnerabilities of the point-to-point approach include:
- Decentralized access: It is impossible to quickly revoke compromised access or update security policies for a single partner without interfering with the code of various services.
- Static API keys: Using immutable tokens creates a risk of interception or leakage.
- Lack of load control: Direct connections without intermediate buffers allow technical failures or DDoS attacks from a partner to be transmitted directly into the internal system.
Moving to a unified integration layer significantly reduces the attack surface and is a necessary condition for implementing a Zero Trust model.
Anatomy of a secure interface: from dynamic tokens to Schema Registry
Compliance with NIS2 supply chain security requirements necessitates the implementation of API-contract security. This involves creating architectural barriers between external partners and internal organizational services.
The first such barrier is an API Gateway. This is a mandatory tool in microservice architectures for centralizing security policies. The API Gateway handles dynamic authentication (e.g., via OAuth2/JWT) instead of using static keys transmitted in plain text. Additionally, it provides traffic management (rate limiting), restricting the number of requests from an external partner to protect internal infrastructure from overloads.
The second layer of protection for asynchronous integrations (e.g., based on event streaming via Apache Kafka) is data validation. Using Schema Registry and Change Data Capture (CDC) technologies makes integration controllable through strict data contracts. Schema Registry automatically validates the structure of incoming messages at the integration layer, ensuring that no unforeseen requests or malicious payloads reach the database.
Audit trail: how to prove compliance to regulators in minutes, not weeks
For European clients and auditors, traceability is a key requirement. If a cyber incident occurs, the company must be able to immediately localize its source and assess the scale of the compromise.
Implementing automated integration auditing allows for reducing the investigation time of unauthorized access from weeks to minutes. End-to-end logging of all API calls creates an immutable audit trail containing:
- Identification of the subject initiating the request (via JWT or other tokens);
- Exact transaction time;
- Content of the operation and volume of requested data.
Without such a trail, it will be impossible to prove your non-involvement in a data breach to a regulator or partner or to quickly block a compromised channel.
Architectural foundation: why integration security must be built at the platform level
Implementing an API Gateway or Kafka does not automatically make a system NIS2-compliant—these are just technical implementation tools that require a systematic approach. However, choosing the right base platform for development can significantly simplify meeting these requirements if the necessary protection mechanisms are built into the system core.
For complex enterprise solutions and integrations, it is advisable to use platforms that provide a unified access and data management model. An example of such a tool is the low-code platform UnityBase (a joint development by companies of the Intecracy Group, an alliance of independent companies linked by partner agreements and share exchanges, where InBase is a key, but not the only, developer). Products of the ecosystem, such as Megapolis.DocNet or Scriptum.DMS, are built on it.
UnityBase uses the Domain metadata concept, which combines a data model with automatically generated REST API. The platform handles detailed audit trails, Role-Based Access Control (RBAC), and Row-Level Security (RLS) directly in its core. For projects with high security requirements or high-load, the official platform documentation recommends using Enterprise or Defence editions. They expand dynamic authentication capabilities (OpenID Connect/OAuth2) and provide additional traffic encryption, allowing product companies to focus on business logic while using reliable platform-level security mechanisms.
| NIS2 Requirement | Technical implementation mechanism | Impact on business risks and capital |
|---|---|---|
| Authentication and authorization | Replacing static API keys with dynamic OAuth2/JWT tokens with limited lifespan and Role-Based Access Control (RBAC). | Prevents the use of stolen keys; reduces the risk of unauthorized access to client data. |
| Traffic management (Rate Limiting) | Implementing request limits at the API Gateway level to protect against overloads and DDoS attacks from integrated systems. | Prevents technical downtime of internal systems; maintains service availability for key clients. |
| Data contract validation | Using Schema Registry for automatic verification of incoming message structures before processing by internal services. | Protects the database from malicious injections; reduces costs for fixing errors in corrupted registries. |
| Traceability (Audit Trail) | End-to-end logging of all API calls, recording the subject, time, and nature of the operation for rapid cyber incident investigation. | Reduces leak detection time from weeks to minutes; provides an evidentiary basis to avoid regulatory sanctions. |
Reviewing integration architectures is a mandatory step for those planning to continue working in the European market. Transitioning to a controlled integration layer instead of point-to-point connections is a strategic investment in customer trust and the preservation of long-term contracts.
FAQ
How do NIS2 directive requirements affect Ukrainian software developers who do not have offices in the EU?
European clients (who fall under NIS2 requirements) are obligated to control the security of the entire supply chain, including their contractors. Accordingly, they will require Ukrainian partners, regardless of their location, to provide proof of the security of their systems and integration APIs under the threat of contract termination.
What technical requirements do European companies impose on the API security of their suppliers?
Basic architectural requirements include: moving away from unmanaged point-to-point integrations, using dynamic authentication (OAuth2/JWT), implementing request limits via API Gateway to protect against overloads, data schema validation, and maintaining a strict audit trail for all transactions.
Why are static API keys considered non-compliant with NIS2 security standards and what should replace them?
Static keys transmitted in plain text have an unlimited lifespan, making them vulnerable to leaks or interception. Modern API-contract security standards require the use of dynamic tokens (e.g., JWT) with a limited lifespan that are managed centrally.