In 2026, compliance with the European NIS2 directive became a strict reality for operators of essential services. The main challenge facing CIOs and CISOs is not nominal policy declaration, but the actual protection of systems from sophisticated targeted attacks without creating operational bottlenecks for the business.
According to the ENISA Threat Landscape 2025 report, critical infrastructure entities accounted for 53.7% of all analyzed cyber incidents between July 2024 and June 2025 (4,875 incidents in total). This clearly demonstrates that energy, transport, healthcare, and financial sector enterprises are primary targets for attackers. The traditional approach, based solely on network perimeter protection, can no longer guarantee the resilience of such infrastructures.
Why network segmentation no longer protects critical infrastructure on its own
Classic segmentation at the network port and IP address level (L3/L4) creates an illusion of security. The practice of dividing a network into zones using firewalls and organizing access via VPN tunnels has a critical flaw: it does not protect against lateral movement once attackers have breached the external barrier.
If an attacker gains access to a specific network segment, they usually gain direct visibility into all databases, APIs, and services located within it. Attempts to solve this problem through stricter isolation at the routing level lead to operational downtime, disruption of integration buses, and increased administrative complexity, which directly contradicts the basic requirements for business continuity in critical infrastructure.
NIS2 requirements and CISA CPG: shifting from perimeter to Zero Trust
The NIS2 directive and CISA CPG (Cross-Sector Cybersecurity Performance Goals) guidelines require organizations to fundamentally change their approaches. The new version of the NIST Cybersecurity Framework (CSF) 2.0 introduces the "Govern" function, which emphasizes cyber risks as an integral part of overall corporate governance. Security can no longer be localized solely at the network infrastructure level.
According to Microsoft's Zero Trust concept, user identity and the context of their request become the new security perimeter. Instead of trusting a session based solely on the fact of a VPN connection, the system must continuously verify credentials with every access request to a specific data object.
Application-level segmentation: how RBAC and Row-Level Security (RLS) work
Real-world operation of critical systems proves the danger of excessive trust in network connections. Specialists at CERT-UA, while analyzing incidents involving the UAC-0145 group, detail scenarios of VPN access compromise through social engineering during the hiring process. Having obtained legitimate credentials, the attacker bypasses network barriers without hindrance and begins harvesting confidential information.
To prevent such threats, security must be embedded in the application architecture (L7 level) through two key mechanisms:
- Role-Based Access Control (RBAC): The role model strictly defines which actions are permitted for a specific user or system interface. Even if an attacker gains access to the network, their actions will be limited by the rights of the compromised account.
- Row-Level Security (RLS): Security at the database row level ensures contextual filtering. If an account belongs to an operator of a specific zone, RLS ensures they only see records (table rows) that directly pertain to their area. Attempts to access neighboring records are blocked at the ORM layer of the application, even if network access to the DBMS is completely open.
Such data-level segmentation makes lateral movement virtually impossible without re-authorization and privilege escalation, which is immediately recorded by the audit system.
Ensuring business process continuity when isolating critical systems
The biggest barrier to implementing strict security requirements is the risk of halting operations. ERP must exchange data with registries, and electronic document management (DMS) systems must integrate with external client portals. Blocking these connections at the port level paralyzes company operations.
The solution lies in logical process isolation using detailed audit trails instead of physical traffic blocking. Application-level logging captures the semantics of business operations: which document was opened, what changes were made, and who initiated the process. This allows the Security Operations Center team to instantly detect anomalies without disrupting service availability for legitimate system processes.
Architectural approach: building secure systems on UnityBase without operational downtime
To implement NIS2 requirements for access control without creating downtime, a flexible technological foundation is required. One example of tools that ensure such architectural resilience is the high-performance full-stack low-code platform UnityBase (a joint development of companies within the Intecracy Group technology alliance, where InBase acts as a key, but not the only, developer).
UnityBase is not an off-the-shelf program that automatically guarantees compliance without configuring internal organizational processes; however, it provides architects with powerful built-in tools for implementing Zero Trust principles:
- Domain metadata: A unified domain metadata model combines descriptions of data structures, interfaces, and APIs, allowing for centralized definition of security rules at the highest level of abstraction.
- Built-in RBAC and RLS: Access control mechanisms are integrated directly into the platform's ORM layer. They operate independently of the chosen DBMS, ensuring that no request bypasses permission checks.
- Detailed audit trail: The platform automatically maintains a security log and data change history (DataHistory), tracking the lifecycle of every record.
Enterprise solutions such as the Megapolis.DocNet electronic document management system and Scriptum.DMS already operate on UnityBase. For high-load systems or infrastructures with increased security requirements, the platform's official page recommends using commercial Enterprise (EE) or Defence (DE) editions. They support advanced authentication methods (including digital signatures and Active Directory integration) and additional integrity control for server modules.
By combining basic network hygiene with deep application-level (L7) segmentation, critical infrastructure enterprises can build a resilient architecture that meets strict NIS2 standards while maintaining the continuity of business operations.
Comparison of approaches to critical system segmentation
| Comparison parameter | Network segmentation (L3/L4) | Application architectural segmentation (L7 / Zero Trust) |
|---|---|---|
| Access control point | IP addresses, ports, subnets, VPN tunnels | User identity, request context, specific data objects |
| Resistance to credential compromise | Low (attacker in VPN gains access to the entire segment) | High (access is limited at the individual record level via RLS) |
| Impact on business processes | High risk of downtime when changing network rules | Zero impact on availability (changes are made at the application policy level) |
| Audit detail | Only network transactions (who connected to where) | Full operation context (what specific action was performed on which data) |
FAQ
How to meet NIS2 segmentation requirements without stopping critical business processes?
Instead of rigid physical network isolation, implement logical segmentation at the application level (L7) using RBAC and RLS tools. This allows data access control at the individual record level without changing network configurations or stopping integrations.
Why do traditional VPNs and firewalls not provide a sufficient level of security according to CISA CPG standards?
Traditional perimeter defense tools are powerless against credential compromise (e.g., via social engineering, as in UAC-0145 campaigns). If an attacker gains access to a VPN, they can move freely within the network segment (lateral movement).
What is the role of Row-Level Security (RLS) in protecting critical infrastructure databases?
RLS restricts user access to specific rows in database tables based on their context and identity. Even if an account is compromised, the attacker will not be able to access the entire database, but only the permitted narrow segment of information.