NIS2 Zero Trust Architecture: Mapping NIST SP 800-207 to CIR Annex 6 and 11

No article in the NIS2 Directive uses the words ‘zero trust.’ That single fact causes two opposite mistakes: some compliance teams treat zero trust as optional because it is not named as a requirement, while others tell auditors they are ‘doing zero trust’ as if that phrase alone satisfies Article 21. Neither is right. Zero trust is an architecture pattern — formalised by NIST in Special Publication 800-207 — that happens to be the most direct route to satisfying several binding CIR 2024/2690 controls at once, particularly network security, segmentation, and access control. This guide maps NIST’s seven tenets to the exact CIR Annex points they operationalise, then gives you a gap-analysis framework and a six-step rollout plan to get there.

Does NIS2 Actually Require Zero Trust?

No article makes zero trust a named obligation. The only place the term appears is Recital 89, which lists ‘zero-trust principles’ alongside software updates, device configuration, network segmentation, and identity and access management as ‘basic cyber hygiene practices’ entities ‘should adopt.’ [1] A recital is a non-binding interpretive aid — it signals legislative intent, it does not create an enforceable duty the way an Article does. So no competent authority can cite ‘failure to implement zero trust’ as a standalone infringement.

What is binding is Article 21(2)(e) — security in network and information systems acquisition, development and maintenance — and Article 21(2)(i)/(j), which cover access control, asset management, and multi-factor authentication. [7] CIR 2024/2690 unpacks (e) into ten sub-points including network security and network segmentation (Annex 6.7–6.8), and (i)/(j) into access control (Annex 11). Zero trust architecture is simply the design pattern that can support both at a level auditors increasingly expect, especially post-2026 as ‘perimeter plus VPN’ evidence packages draw more scrutiny. One caveat worth stating plainly: CIR 2024/2690 legally binds only the digital-infrastructure entity categories listed in its own scope — DNS and TLD providers, cloud, data centre, CDN, MSP/MSSP, marketplace, search engine, social platform, and trust service providers. [2] For every other NIS2 sector, the Annex is not a direct legal requirement — it is the clearest available interpretive reference for what ‘appropriate technical measures’ under Article 21(2)(e) is generally understood to mean, and most auditors treat it that way in practice.

The practical implications differ sharply by sector. A cloud or MSP/MSSP provider is bound by the full Annex 6 and 11 sub-points directly and should expect an auditor to check for a Policy Engine decision log by name. A manufacturing entity running legacy OT alongside IT has the opposite problem: full dynamic, per-session authentication (tenet 7) is often impossible on a 15-year-old PLC that cannot run a modern agent, so the honest target state is microsegmentation and monitored access at the IT/OT boundary rather than zero trust applied uniformly across the OT floor. A financial entity already subject to DORA usually has the access-control tooling in place from ICT risk-management obligations and mainly needs to extend continuous monitoring (tenet 6) to satisfy the NIS2-specific evidence expectation.

The Seven NIST SP 800-207 Tenets, Mapped to CIR 2024/2690

NIST SP 800-207 defines zero trust through seven tenets rather than a checklist of products. [3] Read individually they sound abstract; matched against CIR Annex sub-points, each one lands on a specific, already-familiar compliance obligation.

NIST Tenet (SP 800-207)	Plain-Language Meaning	CIR 2024/2690 Match
1. All data sources and computing services are resources	Nothing is trusted by default — workstations, APIs, SaaS accounts, IoT sensors are all treated the same	Annex 12 (asset management) — the asset inventory that scoping depends on
2. Secure all communication regardless of network location	Traffic inside the office LAN gets the same scrutiny as traffic from the internet	Annex 6.7 (network security)
3. Grant access per session, least privilege, time-bound	Access expires with the session instead of persisting indefinitely	Annex 11.2 (access rights management)
4. Access decided by dynamic, context-aware policy	Device posture, location, and behaviour feed the access decision in real time	Annex 11.6–11.7 (authentication, MFA/continuous authentication)
5. Continuous identity governance, human and non-human	Service accounts and API keys are governed as rigorously as employee logins	Annex 11.3–11.4 (privileged accounts, administration systems)
6. Continuous monitoring of asset integrity and posture	Devices are re-checked constantly, not just at login	Annex 8 (cyber hygiene) and logging/monitoring controls
7. Dynamic authentication and authorisation enforcement	Every request is re-verified, not inherited from an earlier login	Annex 11.6 (authentication)

Two tenets carry most of the compliance weight for a typical mid-sized entity: dynamic policy (tenet 4) and continuous identity governance (tenet 5). In practice, compliance teams that have already run an Article 21(2)(e) evidence exercise report the identity-governance step as the largest single effort sink — service accounts and legacy integrations rarely have an owner of record, and CIR 11.3–11.4 specifically expects one.

The Zero Trust Policy Engine Is CIR Annex Point 11 Access Control, Operationalised

NIST SP 800-207 describes three logical components that do the actual work of zero trust: the Policy Engine, which evaluates identity, device posture, and context to decide allow, deny, or revoke; the Policy Administrator, which executes that decision by creating, modifying, or terminating the session; and the Policy Enforcement Point, which sits at the resource boundary, enforces the decision, and can kill the session mid-flight. [3]

That three-part model is not a new concept bolted onto NIS2 — it is a direct operational build-out of CIR Annex point 11, access control. The policy on access rights (11.2) becomes the rules the Policy Engine evaluates. Privileged account management (11.3) becomes a stricter policy tier the Engine applies to admin sessions specifically. Authentication and MFA (11.6–11.7) become the enforcement the Policy Enforcement Point demands before any session opens. The reason this matters for audit evidence: a static access control policy document proves intent, but a Policy Engine’s decision log proves the policy was actually enforced, session by session — which is precisely the evidence gap auditors flag most often in Article 21(2)(i) reviews.

Microsegmentation Is CIR Annex 6.7–6.8 Network Segmentation, Taken Further

If your organisation has already implemented the four-zone segmentation model — internet, DMZ, internal, and critical/OT — described in our network segmentation guide, you have already addressed the macro-level intent of CIR 6.8. Microsegmentation is the next granularity level down: instead of trusting everything inside the ‘internal’ zone equally, it enforces policy between individual workloads, applications, or even processes within that zone.

The mechanism is what makes this worth the extra effort. Flat internal segmentation stops an attacker at the DMZ boundary but does nothing once they are inside — a compromised laptop on the internal VLAN can typically reach every other device on that VLAN by default. Microsegmentation enforces a deny-by-default policy between workloads regardless of which zone they sit in, so lateral movement requires defeating a policy check at every hop, not just the perimeter. CIR Annex point 6.7 explicitly requires entities to ‘configure controls to prevent accesses and network communication not required for the operation of the relevant entities’ [6] — microsegmentation is the most literal implementation of that clause available. For most mid-sized entities, the pragmatic sequence is: finish zone-level segmentation first (addresses the 6.8 baseline), then apply microsegmentation to the critical/OT zone and any system holding CIR-relevant data, rather than attempting it network-wide on day one.

Gap Analysis: Current State vs. Zero Trust Target State

Before scoping a project, map each control domain against where your organisation actually sits today. This is the framework we use when a perimeter-based environment needs a realistic, CIR-referenced effort estimate rather than a vendor’s generic maturity score.

Control Domain	Typical Perimeter-Based State	Zero Trust Target State	CIR Reference	Effort
Network access	VPN grants broad internal network access after one login	Per-application access, re-verified per session	6.7, 11.6	High
Segmentation	Flat VLANs inside the perimeter	Workload-level microsegmentation, deny-by-default	6.8	High
Authentication	Password plus occasional MFA prompt	MFA or continuous authentication on every session	11.7	Medium
Privileged accounts	Standing admin rights, rarely reviewed	Just-in-time elevation, logged and time-bound	11.2–11.3	Medium
Service accounts/APIs	Static credentials, no defined owner	Governed identities with rotation and ownership	11.4–11.5	High
Device posture	Assumed trusted once inside the network	Continuously checked before and during access	8, 12	Medium

Read across the rows and a pattern emerges: the two ‘High’ efforts — segmentation and service-account governance — are also the two domains where CIR evidence gaps show up most often in practice, because they require inventory work no vendor tool does automatically. Authentication and privileged-account changes score lower effort mainly because most organisations already own the MFA and PAM tooling; the gap is usually policy and enforcement scope, not procurement.

Implementation Roadmap: Six Steps, Effort Level, and Owner

Step	What It Involves	Effort	Primary Owner
1. Asset and identity inventory	Catalogue every resource (tenet 1) and every identity, including service accounts	Medium	IT / CISO
2. Define protect surfaces	Group critical data, assets, applications, and services by sensitivity, not by network zone	Low	CISO
3. Map transaction flows	Document how traffic actually moves between the resources identified in Step 2	Medium	IT
4. Deploy the Policy Engine/PEP	Stand up the enforcement layer that evaluates and applies access decisions per session	High	IT
5. Apply microsegmentation to the highest-risk protect surface first	Start with critical/OT or the system holding CIR-relevant data — not the whole network	High	IT / CISO
6. Formalise the access control policy and evidence trail	Document the policy, retain Policy Engine decision logs, schedule periodic access reviews	Low	Compliance Officer

What Changes for CISOs, Compliance Officers, and the Board

A CISO reads this article for the Policy Engine and microsegmentation detail — that is the technical build. A compliance officer needs a different translation: zero trust does not replace your existing Article 21(2)(e) and (i) documentation, it changes what counts as sufficient evidence inside it. A static ‘access is role-based’ statement stops being enough once auditors expect session-level logs showing the policy was actually enforced, not just written down.

For the board, the framing is budget and liability, not architecture. Zero trust is not a single line item — it is a multi-year programme, and management personal liability under NIS2 attaches to the adequacy of the risk-management measures actually in place, not to the existence of a roadmap document. The board’s practical question is not ‘are we doing zero trust’ but ‘does our current network access evidence hold up against Article 21(2)(e) and (i) as CIR compliance matrices are currently interpreted’ — and the gap-analysis table above is the honest starting answer.

Where Zero Trust Projects Actually Fail

Germany’s BSI, in its own zero trust guidance, is unusually direct about this: zero trust is ‘ein langfäristiges Vorhaben’ — a long-term undertaking requiring sustained budget and staffing, not a one-time purchase. [4] BSI also flags a specific, underestimated barrier: a lack of product interoperability standardisation, which makes cross-vendor Policy Engine and Policy Enforcement Point deployments harder to integrate than vendor marketing suggests. For organisations that share infrastructure or data flows with partners — supply chain integrations, shared service providers — zero trust policy also has to be coordinated across the boundary, not just internally, which is routinely the step project timelines skip.

Supply chain integrations make this concrete: if a supplier’s system authenticates directly into your internal network under the old perimeter model, moving to zero trust means renegotiating that access as a scoped, monitored, per-session connection rather than a standing trust relationship — a contractual and technical change that has to be agreed with the supplier, not just configured internally. Entities that skip this step end up with a Policy Engine that governs employee access tightly while leaving supplier access exactly as trusted as before, which auditors reviewing Article 21(2)(d) supply chain security increasingly catch.

The most common practical failure is not technical — it is sequencing. Teams that attempt network-wide microsegmentation in one project stall for months without shipping anything auditable. The roadmap above sequences deliberately: inventory and policy engine first, microsegmentation on the single highest-risk protect surface second, and only then wider rollout. Each step produces its own evidence, so an audit mid-project still has something concrete to show.

Documentation Checklist for Audit Evidence

• Network architecture diagram showing current zones and planned microsegmentation boundaries
• Access control policy referencing CIR Annex 11.2–11.7 sub-points by number
• Policy Engine/Policy Enforcement Point configuration record and decision-log retention setting
• Privileged account inventory with named owners and review cadence
• Service account and API key register, including rotation schedule
• Microsegmentation policy for the highest-risk protect surface, with the deny-by-default ruleset documented
• Record of the periodic access review (who reviewed, when, what changed)

FAQ

Is zero trust legally mandatory under NIS2?
No. It appears only in Recital 89, which is non-binding. What is mandatory are Article 21(2)(e) network security and Article 21(2)(i)/(j) access control and MFA — zero trust is the architecture pattern most auditors accept as satisfying them well.

Does CIR 2024/2690 apply to my organisation?
Directly, only if you fall into its listed digital-infrastructure categories (DNS/TLD, cloud, data centre, CDN, MSP/MSSP, marketplace, search engine, social platform, trust service). [2] For every other sector, treat the Annex as the clearest available interpretive reference for Article 21(2)(e), not a binding checklist.

How long does a zero trust rollout actually take?
Multi-year for most mid-sized entities, per BSI’s own framing. [4] The six-step roadmap above is sequenced so each step ships auditable evidence rather than requiring the whole programme to finish before anything counts.

Do I need to replace my existing perimeter and VPN?
Not immediately. The pragmatic sequence keeps perimeter controls in place while adding the Policy Engine/PEP layer and microsegmentation to the highest-risk protect surface first — full VPN retirement is typically a later-stage step, not a prerequisite.

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. NIS 2 Directive, Preamble 81-90 (Recital 89) — nis-2-directive.com
2. CIR 2024/2690 — NIS2 Technical Measures — nisd2.eu
3. NIST Special Publication 800-207, Zero Trust Architecture — csrc.nist.gov
4. Zero Trust — Bundesamt für Sicherheit in der Informationstechnik (BSI)
5. Directive (EU) 2022/2555 (NIS2) — EUR-Lex
6. CIR 2024/2690 Annex 1: Technical and methodological requirements — advisera.com
7. NIS 2 Directive, Article 21 — Cybersecurity Risk-Management Measures — nis-2-directive.com