Zero Trust and SOC: from principle to effective detection
Zero Trust is an architecture principle, not a product category. No network, device or account is trusted implicitly, and every request is continuously authenticated and authorised. For the principle to work you need a SOC that correlates identity, device and network signals and detects violations of the defined policies. Without detection Zero Trust stays a diagram; without a Zero Trust foundation the SOC runs in circles. Frame and operating model in detail on [SOC as a Service Switzerland](/en/soc/soc-as-a-service-switzerland).
Scope: Zero Trust vs SASE vs perimeter
Zero Trust is a security principle with seven tenets (see NIST SP 800-207): no implicit trust zones, least privilege, continuous verification. SASE is a delivery model for network and security functions (SWG, CASB, ZTNA, FWaaS) from the cloud. It can make Zero Trust operational without replacing it. Classical perimeter architecture trusts everything inside the network; this is obsolete with cloud, remote work and SaaS. This page treats Zero Trust as the foundation for SOC detection.
Zero Trust defines the rules. SASE delivers the technology. The SOC verifies that the rules hold in reality.
Which signals the SOC gets from a Zero Trust architecture
| Layer | Source | Detection example |
|---|---|---|
| Identity | Entra ID, Okta, Ping: sign-ins, Conditional Access, risk events | Impossible travel, MFA bypass, unusual OAuth grants; see ITDR. |
| Device | EDR, MDM: posture, compliance state, process tree | Access from a non compliant device to a sensitive app; see SOC EDR vs MDR. |
| Network | ZTNA broker, firewall, NDR | East-west traffic that should no longer exist after segmentation; see NDR. |
| Application / data | SaaS audit logs, DLP, data access governance | Access to customer data outside approved roles and times. |
Why this matters especially in Switzerland
- revFADP (revised Federal Act on Data Protection): Zero Trust puts purpose limitation and data minimisation into practice through fine-grained access control. If an incident is likely to result in a high risk to the persons concerned, the FDPIC must be notified as soon as possible. See revFADP and SOC.
- FINMA: institutions report material cyber attacks under Art. 29 para. 2 FINMASA (Guidance 05/2020, refined by Guidance 03/2024): initial notification within 24 hours of discovery, full report within 72 hours. FINMA Circular 2023/1 expects layered controls; Zero Trust telemetry delivers evidence for supervisory questions. See SOC and FINMA.
- ISG: operators of critical infrastructures notify cyber incidents to the National Cyber Security Centre (NCSC) within 24 hours; segmented architectures limit impact and speed up assessment. See ISG reporting duty.
- ISO 27001: least privilege and continuous verification address controls such as A.5.15 (Access control), A.5.18 (Access rights) and A.8.2 (Privileged access rights). See ISO 27001 and SOC.
Pragmatic roadmap for the Swiss mid-market
- Identity as the new perimeter: mandatory MFA, Conditional Access, privileged access management. Feed ITDR into the SOC.
- Enforce device posture: EDR with compliance signals, ZTNA instead of legacy VPN, unmanaged devices into their own enclaves.
- Segment the network step by step: crown-jewel applications first, monitor east-west with NDR, close dead legacy paths.
- Data access by classification: sensitive data behind just-in-time access, audit logs centrally in the SIEM, maintain DLP rules.
- Anchor detection and response: SOC playbooks for policy violations, threat hunting against bypassed controls. See Threat hunting Switzerland.
Zero Trust projects rarely fail on technology. They fail on exceptions: legacy applications that cannot do modern authentication; admin accounts that stay MFA free by exception; remote maintenance that bypasses the broker. The SOC must know and monitor those exceptions, otherwise every exception hollows out the principle.
Legal basis and sources
- FINMA Guidance 05/2020 on reporting cyber attacks (Art. 29 para. 2 FINMASA): finma.ch
- FINMA Guidance 03/2024 refining the reporting duty: finma.ch
- ISG (SR 128), Art. 74a-74f: Fedlex
- ISG reporting duty at the National Cyber Security Centre (NCSC) including routing: bacs.admin.ch
- Reporting data security breaches to the FDPIC: edoeb.admin.ch
Frequently asked questions
Does Zero Trust necessarily require SASE or ZTNA products?
No. Zero Trust is a principle that can be implemented with different stacks. ZTNA and SASE speed up implementation, but Conditional Access, EDR, good segmentation and a SOC are equally valid building blocks.
How does Zero Trust relate to legacy OT and industrial plants?
OT systems rarely speak Zero Trust themselves. The pragmatic path is strict segmentation, broker or jump-host access, passive SOC monitoring and explicit exception lists with expiry dates.
Which metrics show progress?
Useful metrics are the share of applications behind Conditional Access and the share of devices with enforced posture. Add the number of open exceptions, time to detect policy violations (MTTD) and time to respond (MTTR). See [MTTD and MTTR](/en/soc/soc-mttd-mttr).
What is the role of the SIEM in a Zero Trust world?
The SIEM aggregates signals from identity, device, network and application, correlates policy context and delivers cases to analysts. Without that correlation the signals stay isolated. See [SIEM](/en/glossary/siem).
How long does a serious Zero Trust rollout realistically take?
A mid-sized company is typically on the road for 12 to 24 months when identity, EDR, segmentation and data classification run in parallel. Value materialises much earlier once identity and EDR are married with the SOC.
Related terms
- Zero Trust Zero Trust is a security model in which no access is automatically considered trustworthy.
- ZTNA Zero Trust Network Access (ZTNA) connects users securely to specific applications without exposing the entire network.
- Conditional Access Conditional Access is a form of policy-based access control for user sign-ins and sessions.
- SASE SASE (Secure Access Service Edge) combines network and security functions into a single, cloud-delivered service.
- MFA Multi-Factor Authentication requires a second form of verification in addition to a password during login.