Skip to main content

Stormshield ZTNA

NAC/ZTNAZTNA

Overview​

Stormshield's ZTNA story is "ZTNA built into the SNS firewall and SSL VPN stack" rather than a separate clous service", with posture checks, identity-aware access and micro-segmentation all driven from the firewall OS.

Stormshield implements Zero Trust Network Access as a feature set of its Stormshield Network Security (SNS) next-gen firewalls, using SSL VPN plus granular filtering to give remote and mobile users least-privilege access to internal apps and segments. The focus is on securing remote and BYOD use cases (mobility, contractors, business app access) by authenticating users, verifying device health and then only exposing the specific applications or network slices they need.

ZTNA capabilities are included in SNS at no extra cost and are backed by European certifications and qualifications (e.g. ANSII), which is a big differentiation in EU public sector and critical-infra accounts. Firmware v5 (and 4.8+ for some functions) brings strengthened IAM with single sign-on, TOTP-based MFA and enhanced host compliance checks for SSL VPN clients.

How to position​

Ideal/target customers​

  • Organizations already running SNS firewalls that still use "fat" SSL VPN or IPsec VPN for remote access; ZTNA is a logic upgrade path with minimal change
  • EU-based customers who care about sovereignty and certifications (public sector, healthcare, OT/industrial, defense suppliers), where ANSSI qualification and other European certifications carry real weight.
  • Hybrid on-prem/private-cloud environments that want Zero Trust principles (identity, least privilege, micro-segmentation) delivered from an on-prem firewall instead of a fully cloud-native ZTNA/SASE stack.

Easy entry-points​

  • "Secure your existing SSL VPN": turn on client workstation verification and granular filtering on SNS 4.8+ or 5, so only compliant devices can establish tunnels and only to the apps they're entitled to
  • BYOD and contractors: use posture checks (AV, firewall, SES present, no local admin) to reduce risk from unmanaged or semi-managed endpoints while still giving them controlled access to line-of-business apps
  • VPN performance refresh: Stormshield highlights improved performance and user experience vs traditional VPN, which resonates with users frustrated by slow remote access

Core Features​

  • Identity-and MFA-based access: Users authenticate via SNS with support for multifactor methods (Stormshield TOTP or third-party MFA via RADIUS), forming the identity root for ZTNA
  • Client workstation verification ("Host Check"): The firewall evaluates endpoint posture before allowing an SSL VPN tunnel: AV status, Windows firewall status, SES agent presence, and whether the user has local admin rights
  • Granular, least-privilege policies: Filter/NAT rules and VPN profiles restrict users to specific apps or subnets, implementing least privilege and micro-segmentation instead of full-network VPN access
  • Integrated into SNS NGFW: ZTNA is delivered by the same NGFW platform that already provides segmentation, usage control and TLS inspection, with all features included in the base product
  • Certified, hardened platform: SNS firmware is certified and qualified by multiple European agencies (including ANSSI), which Stormshield explicitly frames as "enhanced ZTNA" for regulated environments.

Feature Overview​

  • Where it lives: ZTNA is configured on the SNS firewall under SSL VPN and authentication policies, and enforced on compatible Stormshield SSL VPN clients; generic OpenVPN clients are not compatible with posture checks
  • Authentication & ZTNA linkage: Authentication policies in SNS combine LDAP/RADIUS with MFA (TOTP or push via RADIUS) and are explicitly referenced as the identity layer for Zero Trust network access
  • Posture criteria options: Admins can require active AV, an enabled Windows firewall, installed SES EVolution agent, and can block users with local admin rights from bringing up tunnels
  • Policy behavior: If any criterion fails, compliant SSL VPN clients are blocked from establishing the tunnel; incompatible clients can be optionally allowed in a "permissive mode", which is useful during phased roll-out