NIS2 for Microservices and APIs: Every Service Needs Its Own Identity, Owner, and Review Date

The Commission Implementing Regulation that spells out NIS2’s technical requirements never uses the word “API”. Neither does the Directive. ENISA’s 170-page implementation guidance uses it once, inside a non-binding tip about testing external endpoints, and Ireland’s 65-page national guidance for essential and important entities does not use it at all.

That silence is not permission. The binding text regulates communication between distinct systems and identities of network and information systems — abstractions drafted with servers in mind that land, awkwardly but unavoidably, on every service-to-service call you run. This guide does the derivation clause by clause: which requirements actually attach to an API surface, which are unqualified duties, and which come with a documented-reasoning escape hatch.

Does the CIR Bind Your API Surface, or Only Your National Rules?

In plain terms: two different rulebooks can reach your services. If you are one of eleven named digital-infrastructure types, the Implementing Regulation’s Annex binds you directly, clause by clause. If you are not, your obligations come from your member state’s transposition of Article 21 — and national authorities are reproducing the Annex’s language anyway.

Article 1 of Commission Implementing Regulation (EU) 2024/2690 names its addressees exactly: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, of online search engines, of social networking services platforms, and trust service providers [1]. A hospital, a water utility or a food manufacturer running the same microservice estate is not on that list, and is governed instead by national transposition of Article 21(2) of the Directive [2].

The distinction matters less than it appears. Ireland’s NCSC draft Risk Management Measures Guidance applies to all essential and important entities in the state, and its measure RMM013.SA21 reproduces the Annex’s network-security limbs almost word for word — including “establish communication between distinct systems only through trusted channels” [4]. The Annex is becoming the de facto specification whether or not it binds you as regulation.

Your position	What governs the API surface	Practical consequence
One of the 11 CIR Article 1 categories	CIR 2024/2690 Annex, directly applicable	Cite clause numbers in your control register; the Annex is the audit yardstick
Essential or important entity outside those 11	National transposition of Article 21(2)	Check your authority’s guidance first — Ireland, for one, restates the Annex nearly verbatim
Supplier to either of the above	Your customer’s Article 21(2)(d) contract clauses	The requirements arrive as contract terms, not as regulation

For a compliance officer, this changes which document you cite in the control register. For a platform engineer, it changes nothing about the work. Container and Kubernetes scoping — asset granularity for ephemeral workloads, RBAC, immutable infrastructure — is covered separately in our guide to cloud-native architecture compliance; this article stays on the API and service-to-service layer.

The EU Names APIs Once in 235 Pages of Guidance

Search the full text of the Implementing Regulation and “API”, “microservice”, “container”, “interface”, “token”, “orchestration” and “service mesh” all return zero hits [1]. Run the same search over the Directive and “API”, “application programming interface”, “microservice” and “container” return zero as well; its five uses of “interface” refer to CSIRT management interfaces, reporting portals and transport systems, none of them to an application’s API surface [2]. ENISA’s Technical Implementation Guidance returns one, expanding it to “application programming interface” in a TIPS block attached to Annex point 6.5.3 on security testing: “For systems with external integrations (e.g. cloud services) beyond the organization’s control, ensure that all external application programming interface endpoints are thoroughly tested” [3]. That is non-binding, it is about testing, and it is about external endpoints only. Ireland’s guidance returns zero [4].

So the obligations are derived, not stated. Here is where they actually land, and how hard each one binds.

What you run	Clause that reaches it	Binding force
Any service-to-service call	Annex 6.7.2(i) — trusted channels, assured identification of end points	Unqualified “shall”
Each service’s credentials	Annex 11.5.1, 11.5.2(a) and (c) — unique identity per system, plus oversight	Unqualified
A service account shared by several workloads	Annex 11.5.3	Permitted only as a documented, explicitly approved exception
Decommissioning a service	Annex 11.5.4 — deactivate “without delay”	Unqualified
Traffic inside one cluster	Annex 6.8.2(e) — restrict communications between and within zones	Unqualified
Access policy for non-human callers	Annex 11.1.2(b)	Unqualified
Certificate and key rotation	Annex 9.2(c)(ii), (v), (vii), (xi), (xii)	Methods included “where appropriate”
API request and auth logging	Annex 3.2.3(c) and (d)	“Where appropriate”
Third-party APIs you call	Annex 5.2 registry; 5.1.4(d) incident notification	5.2 unqualified; 5.1.4 doubly qualified
MFA on the API surface	Annex 11.7.1	“Where appropriate”, by asset classification

The qualified rows are not free passes. Article 2(2) of the Regulation states that where a requirement applies “where appropriate”, “where applicable” or “to the extent feasible” and an entity considers it inapplicable, “the relevant entity shall in a comprehensible manner document its reasoning to that effect” [1]. Deciding that MFA does not translate to a machine caller is defensible. Deciding it silently is not.

Read 6.7.2(i) as Three Separate Requirements

The clause that does the most work reads: entities shall “establish communication between distinct systems 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 and protection of the channel data from modification or disclosure” [1].

Three cumulative requirements sit in that sentence, and they are usually collapsed into one. The channel must be isolated. It must provide assured identification of their end points — plural, both of them. And it must protect the channel data from modification or disclosure.

Ordinary server-side TLS delivers the first and the third cleanly, and delivers half of the second. The certificate proves the server’s identity; the caller stays anonymous at the transport layer. Whatever identifies the calling service — a bearer token, an API key, a source IP range — travels inside the channel rather than establishing it, which means the channel itself was set up with one end unidentified. Mutual TLS closes that gap because both parties present certificates during the handshake, which is why service mesh implementations converge on it. NIST’s guidance on microservice architecture presents the service mesh as a way to specify these requirements uniformly across services, enforced in proxy infrastructure rather than in each microservice’s own code [5]. No EU instrument mandates mTLS or a mesh — but if you satisfy the second requirement another way, be ready to explain how the calling end is assured.

Then there is the harder question: what counts as a distinct system? Article 6(1)(b) of the Directive defines a network and information system as “any device or group of interconnected or related devices, one or more of which, pursuant to a programme, carry out automatic processing of digital data” [2]. That definition counts devices. Forty services on one cluster could be read as one system or as forty, and neither the Directive nor the Regulation resolves it. The boundary is yours to draw, in the risk assessment under Annex point 2.1 and the asset classification under 12.1, and to record in the network architecture documentation that 6.7.2(a) requires you to keep “comprehensible and up to date” [1]. Draw it deliberately and write down why. An auditor cannot invent a count either — and neither can a vendor selling per-service enforcement.

Every Service Needs Its Own Identity Record, With Four Fields

In plain terms: the Annex treats a service’s credentials as an identity with a lifecycle, in the same section that governs staff accounts. ENISA is specific about what the record has to contain.

Annex 11.5.1 requires entities to “manage the full life cycle of identities of network and information systems and their users”, and 11.5.2 requires them to “set up unique identities for network and information systems and their users” and to “ensure oversight of identities of network and information systems” [1]. Point 11.5.4 closes the loop: review identities regularly and, if no longer needed, “deactivate them without delay”.

ENISA’s guidance on 11.5.1 is where this becomes concrete, and it is the single most quotable sentence in 170 pages for anyone running distributed systems: the identity inventory “should also include all service identities and have these identity records as a minimum including department owner, review date, purpose and the level of privileges for each service identity” [3]. Four fields, per workload identity. ENISA adds two controls that platform teams rarely have: identities assigned to non-human users should be “subject to appropriately segregated approval and independent ongoing oversight”, and active identities should be reviewed “as a minimum quarterly”, relaxed to annually only for micro-sized entities [3]. Ireland’s NCSC states the same expectation in four words — “Provide human oversight of system identities” — inside a measure that explicitly covers “both human and non-human identities” [4].

Segregated approval is the control that bites. A developer opening a pull request that adds a service account is creating an identity and approving it in the same act. Meeting 11.5.2 means someone outside that path signs off and keeps looking.

There is a real asymmetry in the text worth naming. The identity limbs (11.5) explicitly cover systems; the authentication limbs (11.6) are written for people, in the vocabulary of log-in attempts, inactive sessions and personnel [1]. ENISA restates 11.1.2(b) as access by “network and information system processes” and glosses it as “e.g. a machine, device or a service”, and Ireland’s guidance uses the same framing — policies addressing access by “processes — e.g. one network and information system connecting to another”. The text published in the Official Journal reads “address access by network and information systems”, with no mention of processes [1][3][4]. Every reading puts non-human callers in scope; only the Official Journal text binds. Translating the human-shaped clauses is left to you:

Clause, as written for people	The service-to-service equivalent
11.6.2(c) — change credentials initially, at predefined intervals, and on suspicion of compromise	A documented secret and certificate rotation interval, plus a break-glass rotation path you have actually exercised
11.6.2(e) — terminate inactive sessions after a predefined period	Bounded token lifetimes; short-lived credentials in place of static keys
11.6.2(d) — block after a predefined number of failed log-in attempts	Rate limiting and lockout at the authorisation service, not only at the human login page
11.6.2(f) — separate credentials for privileged or administrative access	A distinct identity for a service’s control-plane calls, separate from its data-path identity
11.7.1 — multi-factor authentication for users	Does not translate. Record the asset classification and document the reasoning under Article 2(2)

One more consequence, easy to miss: a service account shared by twelve deployments is a shared identity under 11.5.3, which permits it only “where necessary for business or operational reasons” and “subject to an explicit approval process and documentation”, with the risk carried into the risk management framework [1]. A Kubernetes manifest is not that approval. ENISA’s suggested compensating controls for shared identities include credential vaulting with automatic rotation and time-bound access [3]. Our guide to NIS2 access control requirements covers the human side of the same section.

What “Within Zones” Means on a Shared Cluster

Annex 6.8.2(e) requires entities to “restrict access and communications between and within zones to those necessary for the operation of the relevant entities or for safety” [1]. The three words that matter are and within. A flat pod network where any workload can open a connection to any other satisfies “between” — there is a perimeter, and it holds — and fails “within” outright.

Ireland’s guidance adds a limb the Regulation does not contain, and it is the one with a budget attached: “Application of the same security measures to all systems co-located in the same zone” [4]. Put a low-criticality reporting service in the same zone as a payment service and you have not saved money; you have raised the control floor for both. Zone boundaries are cost boundaries, which is the strongest practical argument for drawing them along criticality lines rather than along team org charts.

Two adjacent limbs get missed routinely. Point 6.8.2(h) requires production systems to be separated from those used in development and testing, “including backups” — restoring a production dataset into a staging namespace breaches it, and so does one shared artefact registry with write access from both. Point 6.8.1 requires segmentation “from third parties’ systems and networks”, which is a live question on any managed platform.

Calibrate the claim honestly: nothing in the Annex requires per-service microsegmentation. Point 6.8.1 ties the segmentation design to the results of your risk assessment, so a coarse but justified zoning model is compliant and a fine-grained but undocumented one is not. Our guide to NIS2 network security requirements works through the zoning model in more depth.

The Third-Party APIs You Call Are Suppliers

A payment API, an identity provider, a geocoding endpoint, an email delivery service — each is an ICT service supplied by a direct service provider, which puts it squarely inside Article 21(2)(d) and its “relationships between each entity and its direct suppliers or service providers” [2].

Annex 5.2 is the clause that catches teams out, because it is short and unqualified: maintain an up-to-date registry of direct suppliers and service providers including “contact points for each direct supplier and service provider” and “a list of ICT products, ICT services, and ICT processes provided” [1]. A dependency manifest is not that registry. It has no contact point, no named internal owner, and it usually cannot distinguish a library you vendored from a live third-party API in your request path.

Annex 5.1.4(d) then expects contracts to oblige suppliers to notify you of incidents “without undue delay”, alongside a right to audit or receive audit reports (e) and vulnerability handling (f) [1]. A free tier accepted by clickthrough rarely carries any of that — which is a procurement decision, not an engineering one. Note the limit honestly: Article 21(2)(d) reaches direct suppliers. Your provider’s own upstreams are addressed through subcontracting requirements under 5.1.4(g), by contract rather than directly. See our guide to NIS2 supply chain security for the full classification process, and API breach reporting obligations for what happens once one of those integrations fails.

Where Zero-Trust Actually Sits in the Regulation

“Zero-trust” appears twice in the whole Implementing Regulation: once in a recital about basic cyber hygiene, and once in the Annex at 6.2.2(b), which requires entities to “apply principles for engineering secure systems and secure coding principles to any information system development activities such as promoting cybersecurity-by-design, zero-trust architectures” [1]. That clause sits in the secure development life cycle section, under Article 21(2)(e). It is a design-time engineering duty, not a network procurement mandate.

Which makes ENISA’s own reference model a poor fit for the architecture this article is about. Its definition footnote lists the components of zero trust as identity and access management with MFA, device security and EDR, “network microsegmentation supported by logical segmentation, Next Generation Firewalls”, ZTNA platforms replacing VPNs, CASB and DLP, and SIEM with user behaviour analytics [3]. Every item addresses a person or a device connecting to a corporate network. Nothing addresses how service A proves its identity to service B. Buying a ZTNA platform is real evidence for employee and service-provider access; it evidences nothing about your east-west surface. Our guides to zero-trust implementation and secure development requirements cover both halves.

Closing the Gap: Current State to Required State

The work below is ordered by how often it is missing rather than by clause number, with an effort estimate and an owner. Effort levels are a practical planning heuristic, not a figure from any regulation.

Typical current state	Required state	Owner / effort
Service accounts created in pull requests, no central list	Identity inventory covering service identities with owner, purpose, review date and privilege level (11.5.1)	Platform lead / Medium
Server-side TLS between services, callers identified by token only	Assured identification of both end points, or documented reasoning for the alternative (6.7.2(i))	Platform lead / High
Flat internal network, perimeter-enforced	Communications restricted within zones as well as between them (6.8.2(e))	Network owner / High
One shared service account across several workloads	Unique identities, or an explicitly approved and documented exception (11.5.2(a), 11.5.3)	Platform lead / Low to Medium
Third-party APIs tracked in code only	Supplier registry with contact point and ICT service list per provider (5.2)	Compliance officer / Low
No scheduled identity review	Quarterly review of active identities, annually for micro entities (11.5.4)	Compliance officer / Low

The split of work is unusual in this area. Four of the six rows are engineering changes a compliance officer cannot make, while the registry and the review cadence are documentation tasks a platform team will not prioritise. Article 21(4) is worth reading in that light: an entity that finds it does not comply must take corrective measures “without undue delay” [2] — so a gap you have identified and scheduled is materially better than one nobody has written down.

Frequently Asked Questions

Does NIS2 require mutual TLS between microservices?
No instrument names mTLS. Annex 6.7.2(i) requires trusted channels providing “assured identification of their end points”, and mutual TLS is the common way to assure the calling end because ordinary TLS identifies only the server [1]. Another mechanism that authenticates both ends at channel establishment can satisfy the clause — document which one you use and why.

Is each microservice a separate “network and information system”?
The Directive does not say. Article 6(1)(b) defines the term by reference to devices, not software services [2]. In practice you set the boundary through your risk assessment and asset classification, and record it in the network architecture documentation required by 6.7.2(a).

Do service accounts need multi-factor authentication?
Annex 11.7.1 applies MFA or continuous authentication to “users”, “where appropriate, in accordance with the classification of the asset” [1]. It does not translate cleanly to a machine caller. Because the limb is qualified, Article 2(2) requires you to document the reasoning where you conclude it does not apply — and to show the compensating controls, typically short-lived credentials and rotation.

How often must service identities be reviewed?
Annex 11.5.4 says “regularly” without a number. ENISA’s guidance sets the expectation at quarterly as a minimum, or annually for micro-sized entities [3]. That is guidance rather than binding text, but it is the yardstick an auditor is most likely to reach for.

Does the Implementing Regulation apply to us if we are not a cloud or digital infrastructure provider?
Not directly — Article 1 lists eleven categories [1]. Your obligations run through national transposition of Article 21(2). Check your competent authority’s guidance before assuming the Annex is irrelevant, because authorities are reusing its language for all essential and important entities [4].

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.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex, Official Journal (Article 1, Article 2(2), and Annex points 3.2.3, 5.1.4, 5.2, 6.2.2, 6.7.2, 6.8.1, 6.8.2, 9.2, 11.1.2, 11.5, 11.6.2, 11.7.1, 12.1, 12.4)
2. Directive (EU) 2022/2555 (NIS2) — EUR-Lex, Official Journal (Article 6(1), Article 21)
3. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 — ENISA, June 2025
4. NIS 2 Risk Management Measures Guidance (draft) — National Cyber Security Centre, Ireland, June 2025
5. Building Secure Microservices-based Applications Using Service-Mesh Architecture (SP 800-204A) — NIST, May 2020