NIS2 Network Architecture: Implementing Zero Trust Segmentation for Regulated Entities

NIS2 Article 21 requires "security in network and information systems" — but doesn't prescribe specific architectures. That's both liberating and dangerous. Liberating because you can design for your context. Dangerous because regulators expect "appropriate and proportionate" measures, and what's appropriate for critical infrastructure is significantly more rigorous than traditional perimeter security.

Why Perimeter Security Fails NIS2

Traditional castle-and-moat architecture — firewalls at the edge, flat networks inside — fails three NIS2 requirements simultaneously. It doesn't limit blast radius (incident handling), it doesn't prevent lateral movement (risk management), and it doesn't protect against supply chain compromise (supply chain security). If an attacker breaches one system, they have access to everything on the same network segment.

Zero Trust Architecture for NIS2

Zero trust assumes breach and verifies every access request regardless of source location. For NIS2-regulated entities, this translates into:

Microsegmentation

Segment your network at the workload level, not the subnet level. In Kubernetes environments, this means network policies that default-deny all traffic and explicitly allow only required connections. Use Cilium or Calico for L3/L4 policies, and service mesh (Istio, Linkerd) for L7 policies with mutual TLS.

Identity-Based Access

Replace IP-based access controls with identity-based ones. Every service authenticates with a cryptographic identity (SPIFFE/SPIRE). Every human access goes through an identity provider with MFA. Privileged access uses just-in-time provisioning with session recording.

Encrypted Everything

NIS2 Article 21(2)(h) explicitly mentions cryptography and encryption. Enforce TLS 1.3 for all service-to-service communication. Use WireGuard or IPsec for cross-cluster traffic. Encrypt data at rest with customer-managed keys. Implement certificate automation with cert-manager.

Continuous Monitoring

Zero trust requires continuous verification. Deploy network detection and response (NDR) for anomaly detection. Monitor east-west traffic patterns. Alert on unexpected connections between segments. Use eBPF-based observability (Cilium Hubble, Pixie) for deep network visibility without performance overhead.

Kubernetes Network Policies: A Practical Example

For an AI platform with separate namespaces for data ingestion, model training, model serving, and monitoring:

• Data ingestion can access object storage and message queues — nothing else
• Model training can access data ingestion outputs and GPU nodes — not the serving layer
• Model serving can access the model registry and receive external traffic — not training infrastructure
• Monitoring can read metrics from all namespaces — but cannot write to any workload

Each policy is codified, version-controlled, and auditable. When NIS2 auditors ask how you prevent lateral movement, you show them the Git history.

What Open Empower Delivers

We design and implement zero trust network architecture for AI platforms in regulated industries. From Kubernetes network policies to service mesh configuration to certificate automation — infrastructure that's secure by default and auditable by design.