NIS2 won’t secure your systems. But it will expose them.

Much has been written about what NIS2 is and who it affects. Far less attention is given to what it actually changes in practice. At first glance, the directive looks like what many expected: another regulatory framework, another set of requirements – ultimately another compliance exercise to be managed alongside existing obligations. Policies need to be updated, processes documented, responsibilities defined. For many organizations, the initial reaction is therefore very predictable – to approach it as a structured checklist and work through it step by step.

However, this interpretation misses the deeper implication of NIS2.

Because unlike many other regulations, NIS2 does not merely ask whether security measures exist. It implicitly asks whether these measures actually hold up under real-world conditions. In doing so, it shifts cybersecurity from a largely declarative discipline, based on policies and assumptions, towards one that increasingly demands evidence and validation. 

And that is where things become significantly more challenging.

Anyway: Who is actually affected by NIS2? 

Before exploring the implications of NIS2, it is worth understanding who it actually applies to. The overview below illustrates which sectors are affected – and how significantly this scope has expanded compared to NIS1. 

From identifying critical infrastructure to enforcing accountability

Under NIS1, the regulatory focus was relatively contained. The directive primarily addressed operators of essential services. Organizations whose disruption would have an immediate and visible impact on society, such as energy providers, financial institutions, or healthcare systems. The scope was limited, and so was the level of scrutiny applied to many other sectors. NIS2 expands both dimensions. 

The number of relevant sectors has grown substantially, with industrial domains, manufacturing, and digital service ecosystems now clearly within scope. At the same time, NIS2 makes inclusion far more explicit: instead of relying primarily on national identification processes, it generally applies to medium-sized and large entities in the covered sectors.

What this means in practice can be summarized quite simply: 

• More industries are affected, especially in industrial and manufacturing environments 
• Scope becomes more clearly defined, based on sector and organization size 
• More responsibility is assigned, with direct management liability 
• Faster reaction is required, with incident reporting within 24 hours 

Perhaps more importantly, these changes indicate a move away from broad classification towards operational responsibility. 

In other words, while NIS1 already aimed to ensure that critical organizations are prepared to handle cyber threats, NIS2 makes these expectations more explicit, more enforceable, and applicable to a broader set of organizations. As a result, the implications extend further into supply chains, making it increasingly important for suppliers to engage with NIS-related requirements. This is reflected in the types of measures organizations are expected to implement across products, development processes, and supply chains:

Where service and product security converge 

What is often overlooked in this context is that NIS2, while formally targeting operators and service providers, does not stop at them. Its requirements extend beyond organizational boundaries and propagate through supply chains, effectively turning regulatory obligations into market expectations. 

Operators of critical infrastructure are required to ensure the security of their systems – including the components and services they rely on. As a result, these expectations are passed on to suppliers and product manufacturers. What begins as a service-oriented regulation becomes, in practice, a condition for participating in these ecosystems. 

For manufacturers of connected systems, this creates a fundamental shift. Even if they are not directly in scope of NIS2, they are increasingly expected to demonstrate compliance in order to remain viable partners. Security requirements are no longer defined solely by product-specific regulation, but also by the expectations of their customers. In this sense, NIS2 introduces an indirect market access requirement: those who cannot demonstrate sufficient security may find themselves excluded from critical supply chains. 

The broader convergence of service- and product-focused cybersecurity requirements is discussed in more detail in a previous article.

From compliance to real-world exposure 

Even in this expanded context, many organizations continue to approach NIS2 through a familiar lens: compliance as documentation. 

Risk management frameworks are defined, controls are mapped, and policies are written. Audits are conducted, processes aligned, and on paper, the system appears structured and under control. However, this perspective remains largely theoretical. Compliance frameworks ensure consistency, but they do not inherently verify effectiveness. A documented control may still fail under pressure, and a completed audit does not prove resilience against adversarial behavior. As a result, organizations can meet regulatory requirements while remaining vulnerable in practice. 

This gap becomes particularly visible in industrial environments. 

Unlike traditional IT systems, industrial environments combine long lifecycles with increasing connectivity. Many systems were not designed for today’s threat landscape, yet are now integrated into complex, interconnected infrastructures – often without a corresponding evolution in their security architecture. Several factors amplify this challenge: 

• Legacy systems that were never designed for connectivity 
• IT/OT convergence, creating new and often poorly understood attack surfaces 
• Limited testing options, as production environments cannot easily be disrupted 
• Complex supply chains, where responsibility is distributed across multiple actors 

In this context, the limitations of a purely compliance-driven approach become clear: policies describe intent, audits confirm structure, and controls may exist without ever being tested under realistic conditions. Attackers, however, operate differently – they identify and exploit weaknesses regardless of how well systems are documented. 

This is reflected in real-world incidents. Attacks such as TRITON (2017), which targeted industrial safety systems, or Industroyer (2016–2022), designed to disrupt power infrastructure, demonstrate that industrial environments themselves have become viable attack targets. 

Where Compliance meets Reality

This is where the implications of NIS2 become tangible. It does not introduce entirely new security principles, but it makes it increasingly difficult to treat them as purely theoretical – even for companies that are not directly in scope. Organizations are no longer only expected to define controls; they are expected to demonstrate how those controls behave under real conditions, across complex, interconnected systems, as these expectations are increasingly driven by customers and supply chain requirements. 

For many, this is precisely where the gap becomes operational: knowing what is required is one thing; being able to validate it continuously and realistically is another. This gap cannot be closed through documentation alone. Approaches like HydraVision address it directly by turning abstract requirements into observable system behavior through continuous validation.  

In that sense, NIS2 is less about adding another layer of compliance, and more about forcing a shift from assumed security to demonstrated resilience.