Zero trust and NIS2: what EU businesses need to implement under Article 21

How NIS2 Article 21 and zero trust connect

Zero trust is an architectural principle, not a product. Its core proposition is straightforward: never trust, always verify. Every access request – regardless of where it originates, whether inside or outside the network perimeter – must be authenticated and authorised based on identity, device state and context before it's granted.

NIS2's Article 21 doesn't mention zero trust by name. What it does is mandate a set of security measures that, when you look at them together, describe a zero trust approach. Access control policies, identity verification through MFA, continuous risk assessment, network security controls, supply chain scrutiny – these are zero trust principles expressed in regulatory language.

The connection matters practically. Organisations that approach Article 21 as a checklist – implementing each measure in isolation – spend more, create more complexity and end up with harder-to-evidence compliance. Organisations that implement zero trust as an architecture address multiple Article 21 requirements with a coherent, documented framework. That's a more defensible position when a competent authority comes asking questions, and it tends to produce stronger actual security as well.

For context on the broader NIS2 regulatory landscape – which sectors are in scope, the two-tier structure of Essential and Important Entities, incident reporting timelines and penalties – see our NIS2 Directive practical guide. This article focuses specifically on the security implementation side.

The specific Article 21 requirements that zero trust addresses

Article 21 lists ten categories of required security measures. Five of them have a direct, structural relationship with zero trust principles:

Access control policies and asset management. NIS2 requires documented policies governing who can access what, and a managed inventory of information assets. Zero trust operationalises this through least-privilege access: users and systems receive the minimum permissions required for the specific task, scoped to the specific resource, for the minimum necessary duration. Identity-based access replaces network-location-based access – being on the corporate network grants nothing by itself.

Use of MFA, continuous authentication and secured communications where appropriate. This is the most explicit zero trust requirement in Article 21 – and it's not qualified by "where practical." It's qualified by "where appropriate," which means regulated organisations need to assess where MFA applies and document that assessment. Zero trust treats identity verification as continuous rather than one-time: authentication at login is necessary but not sufficient. Session behaviour, device posture and access context are monitored throughout.

Risk analysis and information system security policies. Zero trust is not a static configuration – it's a continuous risk assessment loop. Access decisions are made dynamically, based on real-time signals about user identity, device health and the sensitivity of the resource being accessed. This aligns directly with NIS2's requirement for documented, risk-based security policies.

Human resources security. The joiners, movers and leavers process is a fundamental zero trust control. When an employee joins, their access is provisioned according to their role – nothing more. When they change roles, permissions are adjusted. When they leave, access is revoked promptly and completely. NIS2 requires this discipline as part of human resources security; zero trust enforces it architecturally through identity providers and automated provisioning.

Security in network and information systems acquisition, development and maintenance. This covers network segmentation and the principle that systems should be designed and maintained with security built in. Zero trust's micro-segmentation approach – dividing the network into small, isolated zones so that a compromised device or account cannot move laterally – directly addresses this requirement. The assumption is that perimeter breaches will happen; micro-segmentation limits the blast radius when they do.

Identity as the foundation: MFA and Conditional Access under NIS2

Identity is the control plane of a zero trust architecture. If you can't reliably verify who is making an access request, everything else falls apart. For NIS2-regulated organisations, identity management is also where the Article 21 MFA requirement becomes concrete.

A compliant implementation typically centres on a cloud identity provider – Microsoft Entra ID and Okta are the most widely deployed – configured to enforce MFA for all users across all applications. That's the baseline. Conditional Access policies then layer additional controls on top: requiring MFA even from managed devices on trusted networks, blocking access from non-compliant devices, enforcing re-authentication for high-sensitivity resources.

Several considerations matter for NIS2 specifically:

• MFA method matters. SMS-based one-time codes are widely used but vulnerable to SIM-swapping and phishing. For regulated environments, authenticator apps, hardware tokens or passkeys provide stronger assurance. Document why you've chosen the methods you have.
• Privileged accounts need stronger controls. Admin accounts – those with elevated permissions over systems, infrastructure or security configurations – warrant privileged access management (PAM) on top of standard MFA. This includes just-in-time access provisioning, session recording and additional approval workflows for sensitive operations.
• Continuous authentication means more than session tokens. Monitor for anomalous behaviour within authenticated sessions – unusual access patterns, data volumes, geographic anomalies. This is where identity protection features in modern identity platforms become relevant to compliance, not just security.

For NIS2 evidence purposes, your identity platform configuration should be documented and auditable. Conditional Access policies, MFA enforcement rates and exceptions (with justification) should all be captured in a form that can be presented to a competent authority.

Network segmentation and micro-segmentation for NIS2 compliance

Traditional network security was built around a trusted interior and an untrusted exterior. Zero trust rejects that model because it doesn't match how modern organisations actually work: cloud services, remote access, third-party integrations and mobile devices mean the perimeter effectively no longer exists as a meaningful security boundary.

Micro-segmentation replaces the perimeter model with granular, policy-driven isolation. Rather than one large trusted network, systems are grouped into small segments with strict controls on what can communicate with what. A compromised endpoint in the marketing VLAN cannot reach the finance system or the production servers – not because there's a firewall at the perimeter, but because the policy explicitly disallows it.

For NIS2 Article 21 compliance, network segmentation serves two purposes. It directly addresses the requirement for security in network and information systems maintenance – segmentation is a documented, auditable technical control. It also limits incident impact: if a breach occurs (and Article 21's incident handling requirements assume it will), segmentation constrains how far an attacker can move, which directly affects whether that incident reaches the threshold of "significant" for reporting purposes.

Implementation priorities for NIS2-regulated environments typically include:

• Separating operational technology (OT) and IT networks where both exist, particularly in energy, manufacturing and transport sectors
• Isolating systems that handle sensitive or regulated data from general corporate infrastructure
• Restricting lateral movement between segments through explicit allow-list policies rather than implicit trust
• Monitoring east-west traffic (within the network, between segments) not just north-south (in and out of the perimeter)

Supply chain security: applying zero trust to third-party access

NIS2 places specific obligations on regulated organisations to assess and manage cybersecurity risks arising from their supply chain relationships. This isn't an abstract policy requirement – it means actively evaluating how your suppliers and service providers handle security, and what risk their access to your systems creates.

Zero trust supply chain security starts from the same principle as everything else: don't trust third-party access by default. When a supplier or vendor needs access to your systems, that access should be granted on the same identity-verified, least-privilege basis as internal access – not through shared credentials, not through VPN access that opens more than intended, and not on the assumption that a long-standing vendor relationship implies trustworthiness.

Practical controls for NIS2 supply chain compliance:

• Require MFA for all supplier access. This is a direct Article 21 requirement and a basic zero trust control. No exceptions for legacy integrations or "low-risk" suppliers without documented risk assessment.
• Scope third-party permissions tightly. A supplier managing your email infrastructure doesn't need access to your finance systems. Permissions should be defined by function, reviewed regularly and revoked when the relationship ends.
• Monitor third-party activity. Log what supplier accounts access, when and from where. Anomalous supplier activity is a common indicator of compromise – either of the supplier's own systems or of credential theft.
• Assess suppliers' security posture. NIS2 requires this. In practice it means questionnaires, certifications (ISO 27001, Cyber Essentials Plus) and contractual security requirements. Your zero trust framework provides a useful baseline: do your suppliers apply the same principles to their own operations?

The supply chain provision in NIS2 also flows downstream. If you're a supplier to a regulated entity, expect your customers to ask harder questions about your security controls. Zero trust implementation is increasingly a supplier qualification criterion, not just a compliance requirement.

Documenting your zero trust implementation for NIS2 evidence

NIS2 places personal liability on senior management for compliance failures. That shifts the burden of proof: it's not enough to have implemented reasonable controls – you need to be able to demonstrate that you have, to an authority that may not take your word for it.

Zero trust architecture is well-suited to this requirement because it produces documented, auditable controls rather than implicit security assumptions. But that documentation doesn't happen automatically – it needs to be built into the implementation from the start.

For each Article 21 requirement, your NIS2 evidence pack should include:

• Policy documentation. Written policies for access control, MFA requirements, privileged access, network segmentation and supplier security – approved by senior management and reviewed on a defined schedule.
• Technical configuration records. Screenshots or exports of Conditional Access policies, MFA enforcement settings, network segmentation rules, PAM configurations. These demonstrate that policies are actually implemented, not just written down.
• Access reviews. Periodic reviews of who has access to what, with evidence that least-privilege principles are being maintained. Most identity platforms can generate these reports; the key is running them on a schedule and acting on the results.
• Incident and exception logs. Any deviations from policy – MFA exceptions, temporary access grants, segmentation rule changes – should be logged with justification and approval. Exceptions that aren't documented become compliance gaps.
• Supplier security assessments. Records of supplier evaluations, including what was assessed, when, by whom and what the outcome was. Contractual security requirements should be retained alongside these assessments.

ENISA – the EU Agency for Cybersecurity – has published guidance on network and information system security that aligns closely with zero trust principles. Referencing ENISA guidance in your policy documentation strengthens the evidential position: you're demonstrating alignment with EU-recognised security standards, not just asserting that your controls are adequate.

The most common gap we see in NIS2 readiness assessments isn't the absence of security controls – it's the absence of documentation that proves those controls exist and are working. Zero trust gives you the architecture; the documentation work is what makes it auditable.