NIS2 doesn’t care how many CVEs you have. It cares about what breaks in production

As NIS2 has become law in Sweden, we continue to explore the impact it will have on software engineering teams.

NIS2 is not just a compliance exercise

The NIS2 directive is frequently framed as a governance or legal obligation. In practice, it is an operational requirement. For organizations operating in regulated environments such as healthtech, fintech, and HRtech, NIS2 fundamentally changes expectations around how systems behave in production.

The directive emphasizes risk management, incident impact reduction, and operational resilience. None of these live in policy documents alone. They live in running systems.

Why engineering teams are now in scope

NIS2 makes senior management accountable, but engineering teams are responsible for implementation. This creates a direct link between regulation and production workloads.

Auditors and regulators are increasingly interested in how systems fail safely. Not whether vulnerabilities exist, but whether their exploitation would meaningfully impact availability, integrity, or confidentiality.

From vulnerability volume to real exploitability

Traditional vulnerability management treats CVEs as equal units of risk. In containerized environments, this leads to alert fatigue. A single image can contain hundreds of vulnerabilities, many of which are never exercised at runtime.

NIS2 implicitly challenges this model. It pushes organizations to understand contextual risk: whether vulnerable code is reachable, executable, or capable of causing harm given real runtime constraints.

What actually changes in production environments

Meeting NIS2 expectations requires changes in how systems run. This includes:

• Enforcing which binaries and processes may execute

• Restricting file system and network access to known‑good paths

• Containing behavior when something deviates from the norm

These controls shift security from detection to prevention and containment.

Allow‑listing as a practical NIS2 control

Allow‑listing defines what a workload is expected to do and blocks everything else. When enforced at runtime, it reduces the attack surface by default. From a NIS2 perspective, this creates tangible benefits: reduced blast radius, fewer incident escalation paths, and clear evidence that risk is actively managed.

Runtime evidence becomes audit evidence

NIS2 increases the need for proof. Runtime enforcement provides concrete artifacts: enforced policies, prevented execution paths, and logs showing abnormal behavior being blocked. For regulated sectors, this bridges the gap between compliance language and technical reality.

How bifrost supports engineering‑led compliance

bifrost focuses on runtime allow‑listing for containerized workloads. By learning normal behavior and enforcing it at the kernel level, bifrost helps teams understand which vulnerabilities are actually exploitable in their environment. Even when a CVE exists, bifrost can limit what an attacker can do, reducing both impact and remediation noise. This aligns closely with the intent of NIS2: reducing real‑world risk, not just reporting it.

What engineering leaders should do now

NIS2 does not require perfect security. It requires demonstrable control over operational risk. Engineering leaders should:

• Reassess how vulnerability risk is prioritized

• Shift focus from detection‑only tooling to runtime control

• Ensure production environments fail safely by design

NIS2 compliance is not achieved in spreadsheets. It is achieved in production.