Zero Trust Beyond the Buzzword: Why Microsegmentation Is the Control Swiss Enterprises Keep Skipping

Earlier this year, the US National Security Agency published phase one and phase two Zero Trust recommendations covering what the Department of Defense defines as target-level zero trust maturity. The guidance runs to 368 pages. It covers identity, devices, applications, data, network, automation, and orchestration. Most security teams will skim the identity section, nod at the MFA requirements, and move on. Alexandre Blanc, ISO/IEC 27001 Lead Implementer and one of LinkedIn's most followed cybersecurity voices, noted the pattern directly when the guidance dropped: "The NSA just dropped 368 pages on Zero Trust. Buried inside? The one control most orgs still ignore. Microsegmentation. The guidance is explicit." He is right. And for Swiss organisations — particularly those subject to DORA, the Information Security Act, and FINMA's operational resilience circular — the gap between Zero Trust as a stated strategy and microsegmentation as an operational reality is a risk that cannot be deferred much longer.

What Zero Trust Actually Requires — and Where Most Implementations Stop

Zero Trust is not a product. It is an architecture, built on a single foundational assumption: no user, device, or network segment should be trusted by default, regardless of whether it sits inside or outside the corporate perimeter. The NSA's 2026 guidance describes zero trust as an operating model that should persist throughout an entire user or system session — not just at the authentication boundary. The framework encompasses seven pillars: users, devices, applications and workloads, data, networks, automation and orchestration, and visibility and analytics.

In practice, most enterprise Zero Trust deployments focus heavily on the first two pillars — identity verification and device posture — because the tooling is mature, the vendor ecosystem is large, and the compliance narrative is easier to communicate to boards. Multi-factor authentication, conditional access policies, device health attestation, and phishing-resistant credentials are all valuable controls and relatively straightforward to implement at scale. But they address only one phase of the attack lifecycle: initial access. Once an attacker has valid credentials — obtained through phishing, credential stuffing, or session hijacking — a flat network gives them unrestricted east-west movement. The controls that stop this are in the network pillar, specifically microsegmentation.

The Attack Surface Problem: Why Connectivity Itself Is a Risk

Alexandre Blanc has spent years making a related point with characteristic directness: connected = hacked. The formulation is deliberately stark, but the underlying observation is empirically grounded. Every additional connection point — every SaaS integration, every API endpoint, every OT device brought online, every remote access gateway — extends the attack surface. Organisations that have undergone digital transformation, cloud migration, and hybrid work adoption without corresponding investment in network segmentation have systematically expanded what attackers can reach once they obtain a foothold.

The Interlock ransomware campaign documented three weeks ago in this publication — where the group exploited CVE-2026-20131 in Cisco Secure Firewall Management Center for 36 days before the patch existed — illustrates the consequence precisely. Once inside the management plane, Interlock's post-exploitation toolkit systematically enumerated the entire connected environment: virtual machine inventories, backup infrastructure, stored credentials, lateral movement paths. A microsegmented network would not have prevented the initial compromise of FMC, but it would have constrained what the attacker could reach from that beachhead.

What Microsegmentation Actually Means in Practice

Microsegmentation is the practice of dividing a network into isolated zones — not at the subnet level, but at the workload, application, or identity level — and applying policy that explicitly permits only the traffic flows that are operationally required. Traffic that is not explicitly permitted is denied by default. The result is that a compromised system in one segment cannot communicate with systems in other segments without passing through a policy enforcement point that validates the connection against defined rules.

In concrete terms for a Swiss financial institution: the payment processing workload should not be able to initiate connections to the HR system. The core banking application should not be reachable from the email server. The trading platform should not communicate with the legacy document archive. None of these connections are needed for normal operations, but in a flat network, they are all possible — and in a ransomware event, they are all exploited. Microsegmentation eliminates the implicit permission.

The Three Implementation Models

Microsegmentation can be implemented through three primary approaches, which are not mutually exclusive. The first is network-based segmentation using next-generation firewalls, SDN policies, or VLANs with strict inter-VLAN routing controls — effective for traditional on-premises environments but increasingly difficult to maintain as workloads move to cloud. The second is host-based segmentation using software agents deployed on individual servers and workloads, which enforces policy at the operating system level regardless of network topology — better suited to hybrid and multi-cloud environments. The third is identity-based segmentation, where policy is enforced based on authenticated workload identity rather than IP address — the most architecturally mature approach and the direction the NSA guidance points toward.

The Swiss Regulatory Case for Microsegmentation

For Swiss organisations operating under existing regulatory frameworks, microsegmentation is not merely a security best practice — it is increasingly a compliance expectation expressed in operational terms.

DORA — Digital Operational Resilience Act

DORA's ICT risk management requirements, applicable to financial entities with EU operations since January 2025, explicitly require the identification, classification, and protection of critical network infrastructure and information assets. Article 9 of DORA requires that entities identify all sources of ICT risk, implement protection and prevention controls, and design network security that limits the impact of ICT incidents. The ability to contain a breach to a single segment — rather than allowing it to propagate across the entire ICT estate — is a direct expression of the containment requirement. DORA's operational resilience testing obligations also presuppose that organisations understand their segmentation boundaries sufficiently to model attack paths and validate containment.

Swiss Information Security Act (ISA)

The ISA's mandatory incident reporting obligation for critical infrastructure operators, in force since April 2025, creates an indirect regulatory incentive for microsegmentation. An organisation that can demonstrate that a confirmed breach was contained to a defined segment — that the blast radius was architecturally limited — is in a substantially better position both in terms of mandatory reporting scope and regulatory credibility. An organisation that cannot segment cannot bound the scope of an incident, which complicates both the 24-hour notification and the 14-day detailed follow-up.

FINMA Operational Resilience Circular

FINMA's circular on operational resilience, effective January 2024, requires supervised institutions to identify critical services and implement controls that maintain those services during and after an operational disruption. Microsegmentation supports critical service isolation: by ensuring that a compromise of one part of the infrastructure cannot cascade to the systems supporting critical banking functions, the organisation can maintain regulatory service obligations even while an incident is being contained and remediated.

A Practical Roadmap for Swiss Security Teams

• Map your data flows before drawing any policy. The single most common failure in microsegmentation projects is applying policy to traffic flows that have not been fully mapped. Applications communicate in ways that were never documented — legacy integrations, undiscovered service dependencies, vendor management connections. Before defining any deny-by-default rule, conduct a comprehensive data flow mapping exercise, ideally using network monitoring tools that can observe and visualise actual traffic patterns over a period of two to four weeks.
• Define your protect surfaces, not your attack surfaces. The Zero Trust methodology introduced by Palo Alto Networks co-founder John Kindervag inverts the traditional perimeter model: instead of trying to protect everything, identify the four to six most critical data, applications, assets, and services (DAAS) and build segment policy around protecting those first. For a Swiss bank, the protect surface is likely to include core banking, payment rails, customer data stores, and trading infrastructure. Start there.
• Implement segmentation in monitoring-only mode first. The fastest way to kill a microsegmentation project is to create a deny rule that breaks a critical business process. Deploy your chosen technology in a visibility-only or allow-with-logging mode for a minimum of four weeks before enforcing deny policies. Analyse the logged traffic to identify flows you did not know existed, validate your data flow map, and build confidence in your policy before enforcement.
• Integrate with your SIEM and SOAR. Microsegmentation generates policy violation events that are operationally valuable — they indicate traffic attempting to cross segment boundaries, which may represent lateral movement. Ensure that your segmentation platform feeds events to your SIEM and that your SOC playbooks include response procedures for segment boundary violations.
• Apply Zero Trust Segmentation to remote access and vendor connections. Third-party vendor access is consistently identified as one of the highest-risk lateral movement paths in Swiss incidents. Vendor connections should never land on a flat network. Implement just-in-time, session-level access with microsegmented connectivity that limits each vendor to the specific systems they need — and nothing else.
• Document your segmentation architecture for regulatory purposes. Under DORA, ISA, and FINMA, you will be asked to demonstrate your network security controls during audits and in incident reports. Maintain current documentation of your segmentation boundaries, enforce change control processes for policy modifications, and ensure your segmentation policy is reviewed at least annually.

The Window Is Narrowing

Gartner projected that by 2026, 60% of enterprises working toward Zero Trust architecture would use more than one deployment form of microsegmentation, up from less than 5% in 2023. Whether that projection holds, the direction of travel is clear. As attackers continue to acquire zero-day capabilities in perimeter devices — as Interlock demonstrated with Cisco FMC — the implicit assumption that the perimeter will hold is no longer sustainable as an architectural stance. Swiss organisations that continue to invest exclusively in identity controls while deferring network segmentation are accepting an architectural risk that no amount of MFA can compensate for. The NSA's guidance is explicit. The regulatory direction is clear. The operational case is well-established. What remains is execution.