Secure Access Service Edge.
One identity-aware fabric for ZTNA, SWG, CASB, DLP, FWaaS, and RBI. Policies say who can reach what, from where, with what data classification — enforced at the edge, not the datacenter.
What Sandworm SASE does.
ZTNA — shipping today
Zero-trust access. Continuous auth, just-in-time provisioning, posture rules, and a WireGuard mesh that routes through the nearest edge — not your datacenter.
SWG — shipping today
Secure Web Gateway. URL category filtering, per-user allow/warn/block/isolate policies, and URL overrides — all enforced inline before the request leaves your fabric.
CASB — shipping today
Cloud Access Security Broker. ~200 SaaS app inventory, sanctioned vs unsanctioned tagging, and shadow-IT detection via DNS and SNI scanning across your tenant.
DLP — shipping today
Inline Data Loss Prevention. Pattern matching for PCI card numbers, PII, secrets, and source code. Log or alert on Platform tier; block inline on Sovereign tier.
FWaaS — shipping today
Cloud-delivered firewall. L3/L4 policy enforcement at the edge, no on-prem appliance required. FWaaS policies compose with your existing ZTNA access rules.
RBI — shipping today
Remote Browser Isolation. Risky or uncategorized URLs open inside a cloud-rendered browser session — nothing executes on the endpoint.
How Sandworm SASE works
- 1
Enroll the device and identity
The Sandworm SASE agent enrolls via your existing IdP (SAML/SCIM). Device posture — OS version, disk encryption, EDR health — is evaluated at enrollment and re-checked on every new session.
- 2
Request hits the edge, not your datacenter
Traffic routes to the nearest Sandworm SASE edge node over WireGuard. ZTNA, SWG, FWaaS, and RBI policy evaluation all happen there — the destination sees a clean, policy-filtered connection.
- 3
CASB and DLP inspect in-line
Uploads and API calls are matched against your DLP patterns (PII, PCI, secrets, source-code fingerprints) and CASB app catalog before they leave the fabric. Sanctioned vs. unsanctioned SaaS determinations happen here.
- 4
Events flow to the Sandworm platform
Every access decision, DLP match, SWG block, and posture failure is emitted as an OCSF event and ingested by the Sandworm correlation engine — giving Truthsayer, CloudGuard, and Sandworm SIEM full visibility into edge activity.
Built for…
Remote-first teams who outgrew the corporate VPN
Sandworm SASE connects users to apps, not networks. SWG and DLP ride the same tunnel — no extra agent, no proxy PAC headaches.
Compliance teams replacing legacy VPN for audit
Per-app access policies, device posture checks, CASB SaaS inventory, and inline DLP evidence — structured OCSF logs, not just a tunnel log.
Platform teams enforcing posture and data policy together
If the disk isn't encrypted, the ZTNA tunnel doesn't open. If the upload matches a DLP rule, it doesn't leave. Policy, not hope.
Security teams hunting shadow IT across SaaS
The CASB layer continuously discovers unsanctioned SaaS apps from DNS and SNI data — so you know what employees are actually using before data moves to the wrong place.
Integrations
- IdP via SAML/SCIM
- SaaS apps
- device posture
- Okta / Entra ID
- CrowdStrike Falcon (posture)
- Google Workspace
- Microsoft 365
- Slack
- GitHub
- Salesforce
- Jira
- Zoom
Frequently asked questions
- How do I roll out the Sandworm SASE agent across my fleet?
The Sandworm SASE agent is a lightweight daemon for Windows, macOS, and Linux. It enrolls against your existing IdP using SAML — no additional PKI setup required. MDM-based silent deployment via Intune or Jamf is supported so rollout follows the same workflow as any other managed application.
- Does Sandworm SASE inspect encrypted HTTPS traffic?
Yes — SWG and DLP both require TLS inspection to evaluate request content inline. The agent installs a local CA certificate and forwards decrypted sessions to the nearest edge node for policy evaluation. Apps that use certificate pinning (banking clients, OS update services) can be individually excluded from inspection via policy rules.
- What happens to my network traffic inside the Sandworm SASE fabric?
Traffic is processed at the edge node for policy evaluation and then discarded. Sandworm SASE does not buffer or store full session payloads. When a DLP rule matches, the matched snippet — not the full document — is logged to your tenant and retained for your configured window. Traffic data is never used to train models and never shared across tenants.
- Which features require which bundle?
ZTNA, SWG, and CASB are available on the Platform bundle. DLP inline blocking, FWaaS advanced policy, and Remote Browser Isolation are Sovereign-tier features. Full pricing and a feature comparison table are at /pricing. A 7-day trial covers the full Platform feature set.
- Why replace a VPN with Sandworm SASE rather than keeping the tunnel?
A VPN grants network-level access: once the tunnel is up, users can reach anything on that segment. Sandworm SASE grants per-application access and continuously re-evaluates device posture — if posture degrades mid-session, access can be revoked without terminating other sessions. SWG, DLP, and CASB all ride the same WireGuard tunnel, so you get the policy enforcement of a full security stack without a separate proxy PAC or extra agent.
- What Sandworm SASE features are still in development?
Three capabilities are actively being built: browser-native ZTNA that grants agent-less access for unmanaged or contractor devices via a browser extension; CASB app control actions that block specific API operations (not just alert on them); and automatic URL recategorization fed by the Sandworm Sight threat-intel feed. None of these are shipped yet.
Also in Sandworm.
Sandworm SIEM
Security information and event management with real-time correlation.
See Sandworm SIEM →Replace the VPN. Bring SWG, CASB, and DLP with you.
We'll run Sandworm SASE on your team's devices and show you the full access fabric — ZTNA tunnels, SWG policies, CASB shadow-IT dashboard — live.