According to the ENISA Threat Landscape 2025 report, ENISA analyzed 4,875 cybersecurity incidents between July 1, 2024, and June 30, 2025. Statistics show that organizations categorized as Essential entities under the NIS2 directive accounted for 53.7% of all affected institutions, with digital infrastructure and services accounting for approximately 27.7% of data breaches. These figures confirm that software supply chain attacks remain a critical threat vector. Under these conditions, implementing NIS2 architectural principles is not just a formal compliance task, but a fundamental requirement for the survival of digital systems.
However, in practice, IT department heads and architects often perceive NIS2 as a bureaucratic process, limiting themselves to updating paper instructions. They ignore the need for deep architectural changes, such as microsegmentation and code integrity control. Attempting to protect legacy monolithic or chaotically integrated systems by "attaching" external security agents leads to excessive complexity, an increased attack surface, and a significant rise in operational costs.
NIS2 as an architectural challenge: why paper compliance will not protect against supply chain compromise
The NIS2 directive requires critical infrastructure enterprises to ensure real network resilience. The traditional security model built around perimeter protection is insufficient. When attackers compromise third-party software, a library, or a service used by an organization, they can gain access to the internal infrastructure, bypassing classic firewalls.
This is confirmed by the Cisco Cybersecurity Readiness Index 2025, based on a survey of 8,000 cybersecurity leaders across 30 markets. According to the data, network resilience and cloud reinforcement are critical priorities, but the infrastructure of many companies lacks sufficient readiness. If the system architecture is monolithic, the compromise of one component allows for unobstructed control over other nodes. This is why the transition to the Zero Trust concept and built-in control mechanisms are key technical goals for NIS2 implementation.
Microsegmentation: how to stop lateral movement in the cloud
To prevent lateral movement of attackers within the network, it is necessary to implement microsegmentation. At the architectural level, this means that isolation should occur not only through network VLANs but also at the level of individual services, applications, and databases.
In a cloud or hybrid environment, this is realized through clear declaration and authorization of every connection between components. A practical example is the implementation of isolation for databases and services processing confidential information from the general network. Even in the event of a successful breach of an external interface, the attacker will not be able to move deeper into the system because network policies and Zero Trust rules will block unauthorized traffic. This reduces the attack surface and localizes the incident within a single segment.
Software supply chain integrity: code integrity control from repository to production
Protecting the software supply chain requires end-to-end control at every stage of the development lifecycle. Attempting to solve this problem solely by installing third-party security agents on every server creates new potential points of failure.
Instead, the architecture should provide for the use of built-in control mechanisms:
- Automated threat modeling at the CI/CD stage to identify vulnerabilities before deployment to the production environment.
- Code signing and artifact verification: every update must be signed, and the runtime environment must verify this signature before execution.
- Third-party dependency control: secure integration with package ecosystems to minimize the risk of importing compromised code.
The economics of security: why built-in platform protection is cheaper than accumulating agents
According to architectural design principles (e.g., Microsoft: Azure Well-Architected — Cost Optimization), modeling solutions and costs at the design stage is more cost-effective than attempting to optimize or fix the architecture post-factum. This principle is key to building secure infrastructure.
When an organization attempts to meet NIS2 requirements by purchasing dozens of third-party solutions (the Add-on Security approach), it faces rising TCO (Total Cost of Ownership). Each agent requires licensing, creates additional load on computing resources, and requires constant administration. Conversely, a platform approach (Security by Design), where security mechanisms are integrated into the core, allows for significantly lower operational costs and optimized performance.
Architectural resilience template: designing systems with security by design
To build systems that meet the architectural goals of NIS2, it is advisable to use a unified platform. An example of such a basis for developing enterprise systems is UnityBase — a full-stack JavaScript low-code platform, which is a joint development of companies within the Intecracy Group (InBase acts as a key, but not the only developer).
UnityBase allows for the implementation of the Security by Design concept at the architectural level, ensuring data isolation without the need to deploy numerous third-party agents.
Built-in platform mechanisms include:
- Row-Level Security (RLS), as well as Access Control Lists (ACL) and attributes in commercial editions (Enterprise/Defence), which ensure deep data isolation at the DBMS level.
- Supply chain integrity verification through secure integration with the npm ecosystem at the build stage.
- Full audit trail for recording security events.
The platform serves as a foundation for well-known enterprise products (e.g., Megapolis.DocNet, Scriptum.DMS), allowing critical infrastructure organizations to implement solutions with ready-made audit and control mechanisms. Of course, no technology covers a significant portion of NIS2 requirements automatically, as compliance also requires organizational processes. However, using a platform as a basis eliminates the need to fix architectural errors post-factum.
| Comparison criterion | Agent-based approach (Add-on Security) | Platform approach (Security by Design / UnityBase) |
|---|---|---|
| Lateral movement control (Zero Trust) | Requires installation and configuration of third-party microsegmentation agents on every virtual machine/container. | Isolation is implemented at the platform architecture level, using built-in access policies (RLS, ACL) and API contracts. |
| Software supply chain integrity | Scanning with third-party tools after deployment; high risk of impact on system performance. | Artifact integrity control at the build stage, code signing, and secure integration with the package ecosystem. |
| Impact on performance and TCO | Rising costs for third-party software licenses; additional infrastructure load due to dozens of agents running. | Minimal overhead; security is part of the system core, reducing infrastructure and support costs. |
FAQ
What specific NIS2 requirements apply to software supply chain security?
NIS2 mandates that organizations assess and control security risks related to their software and service providers. This includes vulnerability scanning, artifact integrity control during updates, and supply chain transparency.
How to implement microsegmentation in a hybrid cloud without expensive third-party software licenses?
Instead of purchasing separate microsegmentation agents, it is advisable to combine cloud tools (Security Groups) with built-in application and database access control (e.g., via platform RLS/ACL mechanisms), isolating data at the logic level.
Why is security by design considered more cost-effective according to the Well-Architected methodology?
According to Well-Architected principles, fixing architecture and integrating security tools after system deployment is significantly more expensive due to the need for process restructuring, license costs, and infrastructure overhead. Modeling security at the design stage optimizes these costs.