The NIS2 directive is now in full force across the EU. Senior executives face personal liability for cybersecurity failures, and enforcement is tightening. Most compliance discussions have focused on governance frameworks, network segmentation, and access controls, all of which are necessary, but incomplete.
There's a significant blind spot that most organisations are only now confronting: the container images running in production. If your workloads are built on unvetted base images pulled from public registries, you may already be failing multiple Article 21 requirements before writing a single policy document.
This guide maps NIS2 requirements directly to container security controls. It's written for platform and DevSecOps engineers, to help you understand what compliance looks like at the infrastructure layer and what to actually do about it.
Article 21 is the operational core of the NIS2 directive. It mandates that all covered essential and important entities implement "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risk. There are ten specific NIS2 requirement areas defined under Article 21(2):
For container-based workloads, the clauses that bite hardest are (d), (e), (f), (g), and (i). These cover software supply chain security, vulnerability management, effectiveness assurance, cyber hygiene, and asset inventory, all areas where container infrastructure is directly in scope and frequently under-addressed.
Container images are software supply chain inputs. When your platform engineers run docker pull nginx or reference python:3.11 in a Dockerfile, they're introducing a third-party software component and all its included packages, dependencies, and CVEs into the core of your production infrastructure.
This matters for NIS2 compliance in several concrete ways:
Public registry images like node:latest or ubuntu:22.04 routinely contain hundreds of known CVEs. Most are inherited from underlying OS packages that have nothing to do with your application; but they're present, they're scannable, and under NIS2 Article 21(e), you're responsible for them.
If your base image has a critical vulnerability, every service, microservice, and job that extends that image inherits the same risk. A single unpatched base can be a lateral movement vector across your entire container estate, which is precisely the kind of systemic supply chain risk NIS2 is designed to address.
Containerised workloads are part of your "network and information systems" as defined by the directive. They process data, expose services, and form part of your ICT infrastructure. There's no container exemption, and regulators are increasingly sophisticated about what modern production environments look like. Running unpatched container images is not a defensible position under audit.
The table below maps the most relevant Article 21 clauses to specific container security controls. This is the framework for understanding where your container posture either supports or undermines your NIS2 compliance position.
The following sections expand on each of these requirements and what "done" actually looks like in practice.
Article 21(d) requires organisations to manage security risks arising from direct suppliers and service providers. For container workloads, the question is simple: do you know exactly what software is inside your images?
A Software Bill of Materials (SBOM) is the mechanism for answering that question. An SBOM is a machine-readable inventory of every package, library, and component inside an image, along with version information and provenance data. Under NIS2, SBOMs are the audit artefact that proves you understand what's in your software supply chain and that you can identify and respond to vulnerabilities within it.
SBOMs also enable the downstream requirement: when a new CVE drops, you need to know which of your images are affected and whether any of those CVEs are under active exploit. Without an SBOM, that triage is manual and slow. With one, it's automated.
NIS2 requires policies and procedures to identify, assess, and remediate vulnerabilities in your systems. For containers, this breaks into two complementary strategies:
"Appropriate measures" under NIS2 aren't self-certifying; you must be able to demonstrate them to auditors and national competent authorities. For container security, demonstrable compliance means:
This is where many teams struggle. They may have done the right things technically, but they can't produce evidence quickly when an audit arrives. Compliance dashboards that report against CIS and NIST standards in real time close that gap.
Basic cyber hygiene for containers means running only what you need. Public registry images violate this principle routinely; they're built for developer convenience, not production security. A typical node:20 image includes a full Debian/Ubuntu base, a package manager, build tools, and often shells. None of that belongs in a production container.
Minimal images enforce hygiene by default. Without a shell, an attacker who achieves container escape has significantly fewer post-exploitation options. Without a package manager, installing additional malicious tooling becomes much harder. This is attack surface reduction in its most literal form, and it's a direct implementation of Article 21(g).
NIS2 requires organisations to maintain an overview of all relevant assets and ensure they're properly handled. In a containerised environment, your images and their constituent packages are assets.
SBOMs provide a precise, machine-readable inventory of exactly what's running, including which images, which packages, and which versions, at a level of granularity that traditional IT asset management tools don't reach.
When a new vulnerability disclosure hits, an SBOM-backed inventory means you can answer "are we affected?" in seconds rather than days.
National Competent Authorities (NCAs) responsible for NIS2 directive enforcement have broad audit powers, including on-site inspections, targeted security assessments, and requests for documented evidence of controls. For container security specifically, expect scrutiny on:
The common thread: compliance requires evidence, not just intent. Automated, continuously maintained compliance artefacts, such as SBOMs, benchmark reports, and CVE dashboards are what turn good security practices into defensible compliance positions.
Minimus is built specifically to solve the container security compliance problem. Its core capabilities map directly to the NIS2 requirements covered in this guide, delivering compliance artefacts and security controls that work by default.
Minimus provides hundreds of hardened, minimal container images built from source with the latest security patches. By stripping out everything unnecessary, such as shells, package managers, debug tools, and unused OS packages, Minimus images address NIS2 requirements at the foundation. Customers consistently achieve over a 97% reduction in CVEs compared to standard public registry alternatives.
Every Minimus image comes with an automatically generated, cryptographically signed SBOM. You don't have to add an SBOM generation step to your pipeline; it's produced as a standard output for every image. This gives you the package-level inventory required for NIS2 Article 21(d) and 21(i) by default, with artefacts that are immediately usable as audit evidence.
Minimus images are built and validated against CIS Controls and NIST standards. Compliance posture is visible directly in the Minimus web console, with native reporting that lets you demonstrate benchmark alignment without manual evidence collection. For NIS2 compliance, this is the difference between telling an auditor "we follow best practices" and showing them a real-time compliance dashboard.
Minimus images are rebuilt from source automatically whenever an upstream package changes: not on a weekly schedule, not when a scan happens to catch something, but continuously. This means your images are always current against the latest patches, eliminating the CVE drift that accumulates when images are built once and left running. For the vulnerability patching cadence that NIS2 Article 21(e) expects, this is the operationally correct answer.
Minimus maintains a real-time feed of CVEs and automatically alerts you when a new vulnerability affects one of your images. CVEs are prioritised by exploitability, not just CVSS score, so your team focuses remediation effort where it actually matters. For NIS2's vulnerability handling requirements, this closes the loop between disclosure and response, and provides the documented response timeline that auditors ask for.
If your container security posture needs work, here's a practical sequence to follow:
NIS2 Article 21 compliance isn't just a governance exercise; it reaches into the infrastructure layer. For organisations running containerised workloads, the container image is where compliance starts. CVE-laden images inherited from public registries are a direct Article 21 liability, and the absence of SBOMs, benchmark reporting, and a continuous patching process are the specific gaps that audits will expose.
The regulatory stakes are real: essential entities face fines of up to €10 million or 2% of global revenue, and senior executives bear personal liability for cybersecurity failures. The good news is that the container security layer is one of the most addressable parts of a NIS2 compliance programme. Hardened images, automated SBOMs, and continuous CVE intelligence close the gaps that matter most, and produce the audit artefacts that make compliance demonstrable rather than merely asserted.
Minimus provides hardened, minimal container images built from source, with signed SBOMs, CIS and NIST benchmark attestations, and real-time CVE intelligence generated automatically for every image. Organisations using Minimus achieve a 97% reduction in container CVEs on average compared to standard public registry images. Schedule a demo to see how Minimus addresses NIS2's container security requirements in practice.
.svg)
.svg)
.svg)
.svg)
