NIS2 for Cloud-Native Companies: Containers, Kubernetes, and Serverless When Assets Live for Minutes

Almost two-thirds of Kubernetes containers run for under ten minutes, and about a third finish in under one, according to Datadog’s 2025 telemetry across its customer base [7]. NIS2’s implementing regulation asks entities to maintain a "complete, accurate, up-to-date and consistent inventory" of their assets and to "record changes to the entries in the inventory in a traceable manner" [5]. Read those two sentences together and the obligation looks unsatisfiable.

It isn’t. The clause that resolves it sits one sentence later in the same provision, and almost nobody quotes it. But before the controls matter, a prior question decides how hard the evidence bar is for you specifically: whether your company is a regulated user of cloud infrastructure, or a regulated provider of it.

Are You In Scope — and Does the CIR Bind You Directly?

Two separate tests, and cloud-native companies routinely answer the first and skip the second. Test one decides whether NIS2 applies at all. Test two decides whether Commission Implementing Regulation (EU) 2024/2690 — the document that turns Article 21’s ten one-line measures into 13 chapters of specific technical requirements — is binding law for you or merely a useful reference.

Article 21(5) of Directive (EU) 2022/2555 [1] lists the entity types the implementing act covers: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, CDN providers, managed service providers, managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers. If you are outside that list, the CIR does not bind you and its Annex is an interpretive reference only — a distinction we cover in more depth in our guide to cloud security requirements under Article 21.

Whether a cloud-native software company sits inside that list is genuinely contested. Article 6(30) [2] defines a cloud computing service as "a digital service that enables on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources". Recital 33 [3] then states that the service models "include, inter alia, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) and Network as a Service (NaaS)" — which reads as sweeping in most B2B SaaS. The same recital, however, describes on-demand administration as the customer’s ability to "unilaterally self-provision computing capabilities, such as server time or network storage, without any human interaction by the cloud computing service provider". A CRM that never hands the customer a compute primitive arguably fails that test; a platform where customers spin up their own environments, workers or storage fits it squarely. Recital 33 is a recital — interpretive, not binding — so it indicates how Article 6(30) should be read rather than settling it.

Where you land changes your classification, not just your paperwork. Cloud computing service providers sit in Annex I, and Article 3(1)(b)’s regardless-of-size list covers only qualified trust service providers, TLD registries and DNS providers — cloud is not on it [4]. So the size test governs: a large enterprise is an essential entity, a medium one is important, which is the difference between supervision with no trigger required and supervision that needs an indication of non-compliance first [8]. Our essential vs important comparison works through the thresholds.

Your situation	CIR 2024/2690 status	Practical consequence
You run cloud-native infrastructure, but your sector is Annex I/II non-digital (energy, health, manufacturing…)	Not binding — interpretive reference	Article 21(2) still binds. Use the Annex as the benchmark an auditor will reach for anyway.
You provide IaaS or PaaS, or a platform customers self-provision compute on	Binding	Every Annex point below is a legal requirement, not a good practice.
Pure application SaaS with no customer-controlled compute	Contested	Document the classification reasoning now, before a regulator asks. Do not assume you are out.
You are a managed service provider or MSSP for others	Binding	Listed by name in Article 21(5), irrespective of the cloud question.

The EU’s Own Implementation Guidance Says "Container" Once

ENISA’s Technical Implementation Guidance, version 1.0, June 2025 [5], reprints every CIR Annex requirement verbatim across 170 pages and then adds guidance, evidence examples and tips. Run a keyword count over it — a five-minute job, worth doing before you accept anyone’s claim about what NIS2 "requires" for containers. The word container appears once. Kubernetes, serverless, microservice, ephemeral and infrastructure as code appear zero times each. Virtual machine appears once, as an example of an asset type.

The single container reference is an admission. In footnote 69, under network segmentation, ENISA writes that segmentation methods such as VLANs or physically separate switches should be defined, "however physically separating subnets is not feasible in entirely software-defined environments (container clusters, cloud environments, etc.)".

That silence is not a loophole. Article 21(1) obliges entities to manage risks to the systems "which those entities use", and Article 6(1) defines those systems broadly enough to reach anything that processes digital data. The regulation is deliberately technology-neutral. What the silence does mean is that the translation work — from a control written for durable, ownable machines to a workload that exists for ninety seconds — is yours to do and yours to document. Three problems recur: identity for things that do not persist, change control against continuous deployment, and boundaries without subnets.

Containers as Assets: The Granularity Clause Nobody Quotes

Asset management sits under Article 21(2), point (i), and the CIR Annex confirms it: chapter 12 opens "for the purpose of Article 21(2), point (i)" [5]. Point 12.4.1 is the demanding one — the complete, accurate, up-to-date, consistent, traceably-changed inventory. Then 12.4.2 hands the decision back:

"The granularity of the inventory of the assets shall be at a level appropriate for the needs of the relevant entities. The inventory shall include the following: (a) the list of operations and services and their description, (b) the list of network and information systems and other associated assets supporting the relevant entities’ operations and services."

Two things follow that resolve most of the panic. First, the entity sets the granularity — there is no pod-level mandate anywhere in the text. Second, the mandatory list leads with operations and services, and only then reaches the systems supporting them. An inventory built around services and workloads, not instances, satisfies the wording as written.

The attribute list people quote at you — asset owner and contact, asset location, date of last update or patch, asset end of life — is ENISA guidance, introduced with "consider adding one or more of the following (indicative, non-exhaustive list)". It is not a required schema, which matters because half of it is meaningless for a pod and all of it is meaningful for the workload that pod belongs to. A three-layer model maps cleanly:

Layer	Inventory unit	System of record	Traceability evidence (12.4.1)
Durable	Clusters, node pools, registries, managed databases, cloud accounts	Cloud asset inventory / CMDB	Provisioning logs, IaC state history
Declared	Deployments, services, functions, container images by digest	Git — the manifests are the register	Commit history: who changed what, when, approved by whom
Ephemeral	Individual pods, tasks, function invocations	Runtime telemetry, retained per your logging policy	Orchestrator events, admission-controller decisions

The declared layer is where the compliance argument lives, and it is a stronger position than a hand-maintained spreadsheet: a Git-backed manifest set gives an auditor an inventory that is accurate by construction and whose change history is traceable by default — exactly what 12.4.1’s second sentence asks for. ENISA’s own tips endorse the direction, recommending tools for "automated discovery and asset tracking to continuously discover, categorize, and monitor both on-premises and cloud assets". Classification under 12.1 then attaches to the workload — see our NIS2 asset management guide for the mechanics.

Kubernetes RBAC as Article 21(2)(i) Evidence

Access control is the other half of Article 21(2), point (i), and the CIR devotes chapter 11 to it. Germany’s BSI — the national competent authority, and a source ENISA itself cites in the guidance — goes further than any EU-level text by publishing a dedicated Kubernetes building block, APP.4.4, in its IT-Grundschutz Compendium [6]. Its basic requirement APP.4.4.A3 reads: Kubernetes and all other control-plane applications MUST authenticate and authorise each action taken by a user "or, in automated mode, corresponding software"; administrative actions MUST NOT be performed anonymously; each user MUST only be granted the permissions they absolutely require.

Properly scoped RBAC — namespaced Roles over ClusterRoles, no wildcard verbs, service accounts bound to single workloads, audit logging on the API server — can support an access-control claim under point (i) and can be cited as evidence for it. It does not by itself satisfy Article 21(2)(i), which also covers human resources security and asset management, and no single technical control makes an entity compliant.

The sharper consequence is in a line most engineering teams have never read. BSI’s containerisation module, SYS.1.6.A2, states that "the creator of a container is to be considered like an administrator due to the effects they have on parts of the operation". Take that seriously and your privileged-access regime changes shape: the CI/CD service account that pushes images, and every engineer who can merge to a branch that deploys, are administrators for access-control purposes. They belong in the privileged-account register under CIR 11.3, and they fall inside the human-resources security duties of chapter 10 — including termination procedures that revoke pipeline credentials, not just SSO. Most cloud-native companies run a rigorous joiner-mover-leaver process against their identity provider and none at all against their registry tokens. Our access control requirements guide covers the register itself.

Immutable Infrastructure Meets Change Management

CIR 6.4.2 is the clause that reads as incompatible with continuous deployment. Change management procedures "shall be applied for releases, modifications and emergency changes of any software and hardware in operation and changes to the configuration", and those changes must be documented and, based on the risk assessment under point 2.1, "tested and assessed in view of the potential impact before being implemented" [5]. Fifty deployments a day against a change advisory board is not a workable combination.

ENISA’s guidance under the same point defuses it: change management procedures "may allow different workflows depending on the criticality of the system, the scope of the change and the urgency". Nothing requires one workflow for every change. The defensible reading — interpretation, not settled law — is that the pipeline is the change management procedure for standard changes: the pull request is the request for change, required reviewers are the approval, the test suite and staging deploy are the pre-implementation assessment, and the merge commit is the documentation. What you owe on top is the written procedure saying so, the criticality criteria deciding which changes escape the standard path, and a separate emergency workflow — CIR 6.4.3 requires a record of the result and an explanation of why the normal procedure could not be followed.

Patching under 6.6 inverts in the same way. You do not patch a running container; you rebuild the image and replace the workload. That sounds like a compliance gap until you read ENISA’s guidance under 6.6.1, which names the acceptable strategies outright: blue/green, rolling deployment (canary given as the example in footnote 59), feature toggles, shadow deployment and hotfix deployments. The EU’s own implementation guidance already contemplates replace-don’t-patch, though as recommendation rather than binding text. What survives unchanged is 6.6.1(c) — patches must "come from trusted sources and are checked for integrity", meaning signature verification and digest pinning for images — and BSI SYS.1.6.A6, which requires image creators to be clearly identifiable, base image versions not to be deprecated, and unique version numbers to be provided. A base image pinned to a version that no longer receives updates is the container-era unpatched server, and 6.6.2 offers an escape only if you "duly document and substantiate" why the disadvantages of updating outweigh the benefits. See our guides to vulnerability and patch management and SBOM requirements for the supply-chain half.

Configuration management under 6.3 lands most comfortably of the three. Point 6.3.2(b) requires enforcing secure configurations "for newly installed systems as well as for systems in operation over their lifetime", and ENISA’s guidance asks entities to "detect and respond to unauthorised changes to defined configuration settings". A GitOps controller reconciling live state against a declared repository does precisely that, automatically, with a log of every correction.

Segmentation Without Subnets

CIR 6.8.2(h) is short, unqualified by any "where appropriate", and the one most shared clusters fail: entities shall "separate the production systems for the relevant entities’ services from systems used in development and testing, including backups" [5]. Kubernetes namespaces are a scoping mechanism, not a security boundary — they share a kernel, a control plane and, unless configured otherwise, a flat pod network. BSI is more explicit than the CIR here: APP.4.4.A1 states that each application SHOULD run in its own namespace, and that "only applications with similar protection needs and similar possible attack vectors SHOULD share a Kubernetes cluster" [6]. Dev and prod do not have similar protection needs. Separate clusters, or at minimum separate node pools with enforced network policy and distinct credentials, is the position that survives scrutiny.

Two further sub-points catch the control plane. 6.8.2(f) requires separating the dedicated administration network from the operational network, and (g) requires segregating administration channels from other traffic. Applied to Kubernetes that is the API server: private endpoints, administrative access through a bastion or identity-aware proxy, and no route from a workload pod to the control plane it runs on. BSI SYS.1.6.A16 reaches the same conclusion from the other side, treating access from a container to its host as remote administrative access that should not be established.

The clause worth putting in front of your platform team is 6.7.2(i), also unqualified: communication between distinct systems shall be established "only through trusted channels that are isolated using logical, cryptographic or physical separation from other communication channels and provide assured identification of their end points" [5]. Read literally, that is mutual TLS with workload identity for east-west traffic. Assured endpoint identification is not satisfied by a network policy that trusts an IP address. And 6.7.2(a) requires network architecture documented "in a comprehensible and up to date manner", which in a mesh whose topology changes hourly means generating the diagram from live state rather than drawing it once a year.

Serverless: A Smaller Surface, Not a Smaller Duty

Neither the CIR Annex nor ENISA’s guidance mentions serverless once, so everything here is reasoned application rather than sourced requirement. Removing the host removes some duties in substance: there is no operating system for you to patch under 6.6 and no node network for you to segment under 6.8. Those obligations transfer to your provider, and Article 21(2)(d) supply chain security is where you then evidence them.

What intensifies is everything else. Runtime deprecation becomes a patch decision under 6.6, on a deadline the provider sets rather than you. Function dependencies and shared layers become the supply chain, so SBOM discipline matters more, not less, without a container to scan. Per-function execution roles become the access-control surface under chapter 11, and over-broad roles are the most common finding. Logging survives intact: BSI SYS.1.6.A7 requires container logging data to be stored outside the container itself, and the principle applies with more force to a function that leaves nothing behind. Our logging and monitoring guide covers retention.

What an Auditor Actually Asks For

Essential entities face security scans and audits with no trigger required under Article 32; important entities face the same toolkit only once there is an indication of non-compliance under Article 33 [8]. Either way the request is for artefacts, and cloud-native teams usually have better artefacts than they realise — they have never mapped them.

What you already have	CIR anchor	What to add so it counts
IaC repository and manifests	12.4 inventory, 6.3 configuration	A written statement that the repo is the asset register, with defined granularity
Pull requests, reviews, merge history	6.4 change management	The procedure document naming PR review as the standard-change workflow, plus emergency-change criteria
Image signing and admission policy	6.6.1(c), 5.1 supply chain	Signed exceptions register and base-image currency review
RBAC bindings and API audit logs	11.2, 11.3 access control	Privileged-account register that includes pipeline service accounts
Network policies and mesh configuration	6.7.2(i), 6.8.2	Generated topology diagram and the risk assessment justifying the zones
etcd and volume backups	4.2 backup	Backups of control-plane configuration and image registries too — BSI APP.4.4.A5 is explicit that snapshots MUST NOT be treated as a substitute for backups

Ownership splits predictably: the platform lead owns the technical evidence, the CISO owns the risk assessment justifying the segmentation and granularity decisions, the compliance officer owns the written procedures that turn pipeline behaviour into documented process, and the board owns the classification decision from the first section — getting that one wrong is a registration and supervision failure, not a technical one. Our audit readiness guide covers the evidence pack format.

Frequently Asked Questions

Do we have to list every pod in our asset inventory?
No provision requires it. CIR 12.4.2 states that inventory granularity "shall be at a level appropriate for the needs of the relevant entities", and the mandatory content list starts with operations and services. An inventory at workload and service level, with the durable infrastructure beneath it, meets the wording — provided you document the granularity decision and can show traceable change history.

Is our SaaS product a "cloud computing service" under NIS2?
It depends on whether customers can self-provision computing resources. Recital 33 names SaaS among the cloud service models, but it also describes on-demand administration as unilateral self-provisioning of capabilities such as server time or storage without human interaction from the provider. Platforms that hand customers compute or storage primitives fit; pure application software with no customer-controlled compute is arguable both ways. Document your reasoning — and note that the recital is interpretive, not binding.

Does a Kubernetes namespace satisfy the dev/production separation requirement?
On its own, unlikely. CIR 6.8.2(h) requires separating production systems from development and testing systems, including backups, with no proportionality qualifier attached. Namespaces share a kernel and a control plane. BSI’s position — that only applications with similar protection needs should share a cluster — is the safer benchmark.

Does deploying fifty times a day breach change management?
Not if the pipeline is your documented procedure. ENISA’s guidance under CIR 6.4 permits different workflows by criticality, scope and urgency. What breaches it is having no written procedure at all, or having one that describes a change advisory board your engineers demonstrably bypass.

Do we need a service mesh?
Not by name. CIR 6.7.2(i) requires trusted, isolated channels with assured identification of endpoints for communication between distinct systems, and it carries no "where appropriate" qualifier. Mutual TLS with workload identity is the common way to meet it; any mechanism that cryptographically identifies both endpoints would also do.

Sources

1. "Article 21, Cybersecurity risk-management measures" — Directive (EU) 2022/2555 (NIS 2 Directive) [1]
2. "Article 6, Definitions" — Directive (EU) 2022/2555 [2]
3. "Recital 33" (Preamble 31 to 40) — Directive (EU) 2022/2555 [3]
4. "Article 3, Essential and important entities" — Directive (EU) 2022/2555 [4]
5. "Technical Implementation Guidance on Cybersecurity Risk-Management Measures", version 1.0, June 2025 — ENISA (reproducing the Annex to Commission Implementing Regulation (EU) 2024/2690 verbatim) [5]
6. "IT-Grundschutz Compendium", English edition 2022, modules SYS.1.6 Containerisation and APP.4.4 Kubernetes — Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de) [6]
7. "State of Containers and Serverless" (2025) — Datadog [7]
8. "Article 32, Supervisory and enforcement measures in relation to essential entities" — Directive (EU) 2022/2555 [8]

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.