Private SSE Deployment: Architecture and Cloud Dependencies
- Private SSE runs web gateway and private application enforcement on infrastructure the customer controls, while data services such as data protection may still be applied by the vendor cloud. Map which is which.
- Evaluate the data plane, control plane, and supporting services separately, because each can be private or cloud.
- Most self-hosted SSE still depends on the vendor cloud for something, so map every outbound dependency.
- Telemetry is data; decide which logs, samples, and metadata leave your environment and where they go.
- Private and cloud SSE can run together, with private enforcement reserved for sites that need it.
Private SSE is a deployment model in which Security Service Edge capabilities, such as secure web gateway (SWG), zero trust network access (ZTNA), and data loss prevention (DLP), run on customer-hosted infrastructure. It is used by organizations that must keep traffic inspection, keys, or logs inside their own facilities or jurisdictions, or that need security to keep working without dependence on an external cloud.
Gartner’s definition of SSE describes it as primarily cloud-delivered but notes that it may include on-premises or agent-based components. Private SSE puts those components at the center.
This article is part of the Hybrid Cloud Security guide.
Three planes of an SSE architecture
Every SSE deployment, cloud or private, has three logical layers.
NIST’s zero trust model in SP 800-207 makes the same distinction between policy decisions and policy enforcement.
Data plane. The components that sit in the traffic path and inspect or broker connections: web proxies, ZTNA gateways, TLS inspection, DLP scanning, and malware analysis. This is where plaintext exists.
Control plane. Where administrators define policy, manage identities and groups, and push configuration to enforcement points. It may be a console on premises, in the vendor cloud, or both.
Supporting services. The things enforcement points call on to make decisions: URL categorization, threat intelligence, file reputation, sandboxing, software and signature updates, licensing, and analytics.
A deployment is only as private as its least private plane.
Private SSE deployment models
Private SSE ranges from a private data plane with cloud management to fully private deployments with no external dependencies. These are evaluation models; availability and operating limits depend on the selected product.
| Model | Data plane | Control plane | Supporting services | Typical fit |
|---|---|---|---|---|
| Cloud SSE | Vendor cloud | Vendor cloud | Vendor cloud | Remote-first organizations |
| Hybrid SSE | Customer and vendor cloud | Vendor cloud or unified console | Vendor cloud, with local caches | Regulated enterprises with remote workforces |
| Private data plane | Customer infrastructure | Vendor cloud | Vendor cloud | Local inspection required, cloud management acceptable |
| Fully private | Customer infrastructure | Customer infrastructure | Customer-hosted or offline updates | Air-gapped, classified, or sovereign environments |
The private data plane model is the most common. It keeps decryption and inspection local while using a cloud console for policy and analytics. Fully private deployments are rarer and demand more from the customer’s operations team.
Customer-hosted components
In a private or hybrid SSE deployment, the customer hosts and operates the enforcement and key components, typically including:
- Web gateway appliances, physical, virtual, or containerized, for local TLS inspection and web policy
- ZTNA gateways or connectors that broker access to private applications
- DLP scanning, where a vendor offers it locally; Skyhigh applies data protection through its cloud on traffic the gateway forwards
- Sandboxing, on premises for sensitive files
- Inspection CA and key storage, with hardware-backed custody only where supported and verified
- Log collectors that store events locally and forward selected data
The customer is responsible for capacity, availability, patching, and physical security of these components.
Cloud dependencies to map
Most private SSE deployments still depend on the vendor cloud for something, so list each dependency and its failure behavior.
Before evaluating any private SSE architecture, ask the vendor to list every outbound connection from customer-hosted components, and what happens when each is unavailable:
| Dependency | Question to ask | What to look for |
|---|---|---|
| Policy and configuration | Does enforcement continue with last-known policy if the console is unreachable? | Cached policy with defined behavior |
| URL categorization and reputation | Are lookups local, cloud, or hybrid? | Local database with cloud refresh |
| Threat intelligence and signatures | How are updates delivered, and can they be staged or delivered offline? | Staged updates; offline option for disconnected sites |
| Sandboxing | Are files sent to a cloud sandbox? | On-premises sandbox option |
| Authentication | Does access depend on a cloud identity service? | Local identity fallback or cached tokens |
| Licensing | Does enforcement stop if license checks fail? | Grace period |
| Logging and analytics | What is sent, where is it stored, and can it be disabled? | Configurable fields and regions |
| Support access | Can vendor staff reach customer-hosted components? | Customer-controlled, audited access |
For each dependency, decide whether the default behavior is acceptable or whether a local alternative is required.
Telemetry flows
Telemetry from private enforcement points is data in its own right, and it can include:
- Access logs: user, device, URL, category, action
- DLP incidents, sometimes with content excerpts or full copies
- File hashes or samples for threat analysis
- Performance and health metrics
- Usage data for licensing
Some of this is harmless. Some of it is regulated data. Build a telemetry map that records each flow, its content, its destination, and its retention. This is often the difference between a sovereignty review that passes and one that stalls. See Data Sovereignty in Hybrid Cloud Security.
A useful pattern is fingerprinting sensitive data inside the customer environment and sending only hashes to the service, so the protected content itself never leaves. Ask each vendor where fingerprints for exact data matching and document matching are generated and what is transmitted. Skyhigh generates and applies data protection matching in its cloud.
When private SSE makes sense
Private SSE makes sense when regulation, connectivity, operational technology, traffic volume, or legacy replacement requires local enforcement.
- Regulations or contracts require decrypted traffic, keys, or logs to remain in-country or on-premises
- Networks are air-gapped, classified, or intermittently connected
- Operational technology or critical infrastructure must keep running during external outages
- Internal traffic volume makes cloud inspection costly or slow
- The organization is replacing an on-premises proxy and wants to modernize without a forced cloud move
When none of these apply, cloud SSE usually has lower operating effort.
Operating tradeoffs
Private SSE returns responsibility to the customer: sizing, redundancy, patching, update staging, and troubleshooting.
The gains are control over plaintext, keys, and logs, and continuity when the vendor cloud is unreachable. Hybrid designs let organizations limit private enforcement to the sites and traffic that need it.
How Skyhigh supports private and hybrid SSE
Skyhigh supports private and hybrid SSE with an on-premises data plane governed by the same console as its cloud services.
Skyhigh Hybrid SSE Mesh enforces secure web gateway and Zero Trust Access policy on the customer’s own on-premises gateway, with local TLS inspection and a containerized appliance architecture introduced in March 2026, and applies data protection, CASB, and the other data services in the Skyhigh cloud on traffic the gateway forwards, all under one policy authored in one console. The control plane is cloud delivered, so policy authoring, reporting, and log delivery depend on cloud reachability, while local enforcement of web and private application policy continues at the site if that path is interrupted. Skyhigh holds FedRAMP High authorization.
Sources
- Gartner. Security Service Edge (SSE), Information Technology Glossary. https://www.gartner.com/en/information-technology/glossary/security-service-edge-sse
- NIST. SP 800-207: Zero Trust Architecture (August 2020). https://csrc.nist.gov/pubs/sp/800/207/final
- Skyhigh Security. “Skyhigh Security Announces New Solutions to Strengthen Disruptive Universal SSE Platform” (March 24, 2026). https://www.skyhighsecurity.com/about/newsroom/newswire/skyhigh-security-announces-new-solutions-to-strengthen-disruptive-universal-sse-platform.html
- Skyhigh Security. “Modernizing Your Symantec Edge Secure Web Gateway With Skyhigh Hybrid SSE Mesh” (July 15, 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
- Skyhigh Security. “Adopting Hybrid Just Got Easier With Skyhigh SSE Platform” (October 3, 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html