Hybrid SSE Resilience: Failover and Recovery

Security Service Edge resilience is the ability of SSE enforcement to keep protecting users and data, and keep users working, when components or dependencies fail. Hybrid SSE adds a second enforcement location on premises, which changes what can fail and what can continue. In the Skyhigh architecture, web gateway and private access are enforced on the on-premises gateway, while data protection, isolation, AI controls, CASB, and data posture management are applied in the Skyhigh cloud.

This article is part of the Hybrid Cloud Security guide.

Why SSE resilience matters now

SSE resilience matters because cloud-delivered security concentrates enforcement in shared infrastructure that can fail for everyone at once.

Cloud-delivered security concentrates enforcement in a provider’s infrastructure. That brings scale, but it also means a single provider incident can affect every customer at once.

Two 2025 incidents illustrate the pattern:

• AWS, October 19–20, 2025. A latent defect in DynamoDB’s automated DNS management caused endpoint resolution failures in the us-east-1 region. According to AWS’s post-event summary, the event ran from 11:48 PM PDT on October 19 to 2:20 PM PDT on October 20, with cascading effects on load balancing and new instance launches.
• Cloudflare, November 18, 2025. A database permissions change produced an oversized configuration file that propagated across Cloudflare’s network and caused widespread failures to deliver traffic. Cloudflare’s incident report notes that engineers initially suspected a large-scale DDoS attack.

Neither incident was a security vendor outage specifically, but both show how configuration errors in shared infrastructure cascade. Security and access services that depend on a single provider can fail with it.

Gartner has observed the same concern in the SSE market. Its 2026 SSE research notes that vendors increasingly provide virtual or hardware appliances that extend the SSE data plane on premises, enabling local traffic processing and resilience against unplanned cloud downtime, as cited in Skyhigh Security’s August 2026 announcement.

Failure modes to plan for

Plan for seven failure modes, from a single point of presence to a platform-wide cloud outage.

Fail open vs. fail closed

Every enforcement point needs a defined failure behavior, and the right choice depends on the traffic class:

• Fail closed: If enforcement is unavailable, traffic is blocked. Protection is preserved; work stops.
• Fail open: If enforcement is unavailable, traffic bypasses inspection. Work continues; protection is lost.

Neither should be the default for everything. A common pattern is to fail closed for high-risk categories, regulated data flows, and privileged access, and to fail open (with logging) for low-risk general browsing, for a limited time. Document the choice per traffic class, confirm with your vendor which failure behaviours are configurable per traffic class, and make sure users and the security operations center know when a fail-open state is active.

Hybrid SSE reduces how often this choice matters, because local traffic can keep being enforced when the cloud is unavailable.

Cached policies and local decisions

Local enforcement is only resilient if it can make decisions on its own.

Confirm what each local component caches:

• Policy: Does the gateway keep enforcing the last-known policy if it cannot reach the console?
• URL categorization and reputation: Is there a local database, and how stale can it become before enforcement degrades?
• Authentication: Can sessions continue or new sessions authenticate if the identity provider or cloud authentication service is unreachable?
• DLP classifications and fingerprints: In the Skyhigh deployment described here, data protection is applied in the cloud; it does not continue on the local gateway while the cloud path is unreachable. Treat remote browser isolation, AI security controls, CASB, and DSPM as cloud dependencies as well, and validate the behavior of each service.
• Licensing: Is there a grace period if license validation fails?
• Logs: Are events buffered locally and forwarded when connectivity returns?

Cloud dependencies

List every outbound dependency from local components and assign an owner and an acceptable outage duration.

See Private SSE Deployment: Architecture and Cloud Dependencies for a full dependency checklist.

Failover designs

Resilient hybrid SSE combines local clustering with failover between local and cloud enforcement under one policy.

Local high availability. Deploy gateways in clusters or pairs at each major site, with load balancing and health checks. Containerized or virtual appliances make it easier to add capacity quickly.

Cloud failover for local sites. If a local gateway cluster fails, steer traffic to a cloud point of presence under the same policy. This requires that local and cloud enforcement share one policy engine; otherwise, failover changes the rules users are subject to.

Local fallback for cloud users. For users normally inspected in the cloud who are on site during a cloud outage, route traffic through local gateways. Those users retain local web and private application enforcement; data protection, browser isolation, AI controls, and CASB are applied in the cloud and resume when the path returns.

Multi-PoP failover for remote users. Confirm that agents and tunnels fail over automatically to secondary points of presence, and in which regions, especially where residency rules restrict inspection locations.

Branch continuity. Decide which branches get local enforcement and which rely on regional or cloud enforcement, based on business criticality.

Recovery testing

Resilience that is not tested is an assumption, so build a recurring test schedule:

• Component failure: Take down a gateway node and confirm failover without user impact.
• Cloud unreachability: Block access from a site to the vendor cloud and verify local enforcement, cached policy, and logging behavior.
• Identity outage: Simulate identity provider unavailability and confirm session behavior.
• Fail-open and fail-closed behavior: Verify each traffic class behaves as designed.
• Recovery: Ask your vendor what log buffering capacity and overflow behaviour apply during an outage, then confirm what actually arrives and that policy changes made during the outage propagate afterward.

NIST’s SP 800-34 provides a contingency planning framework that applies to security infrastructure as much as to business systems. For EU financial entities, the Digital Operational Resilience Act, in force since January 17, 2025, requires digital operational resilience testing and management of ICT third-party risk, including exit planning for critical providers.

Operating limits to confirm with vendors

Confirm these operating limits with every SSE vendor before relying on its resilience claims.

• Published SLA for each service, and how availability is measured
• Behavior of each local component when the cloud is unreachable, and for how long
• Maximum age of cached categorization, threat intelligence, and policy before enforcement degrades
• Failover time between points of presence, and between local and cloud enforcement
• Regions available for failover, and whether failover can cross residency boundaries
• Capacity limits per appliance and per cluster with TLS inspection enabled
• Update and change management practices that prevent a bad configuration from reaching all customers at once
• Incident communication process and historical incident reports

How Skyhigh approaches SSE resilience

When the Skyhigh cloud path is unavailable, on-premises gateways continue local web and private application enforcement within validated policy, identity, and licensing limits. Cloud-applied DLP, RBI, AI security controls, CASB, and DSPM are unavailable over that path until connectivity and the services recover.

Skyhigh Hybrid SSE Mesh keeps the SSE data plane on premises where required, so local web inspection and local ZTNA continue on the organization’s own gateways, while cloud points of presence serve remote users. One console and policy engine govern both paths, but available controls depend on the enforcement location and live dependencies. Skyhigh’s March 2026 platform update added a containerized appliance architecture and dynamic traffic routing (Skyhigh Security), and Skyhigh reports 99.999% uptime for its platform.

Sources

1. AWS. “Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region” (October 2025). https://aws.amazon.com/message/101925/
2. Cloudflare. “Cloudflare outage on November 18, 2025.” https://blog.cloudflare.com/18-november-2025-outage/
3. Skyhigh Security. “Skyhigh Security Ranked #1 in Advanced SSE Use Case in 2026 Gartner Critical Capabilities for Security Service Edge” (August 5, 2026). https://www.globenewswire.com/news-release/2026/08/05/3339504/0/en/skyhigh-security-ranked-1-in-advanced-sse-use-case-in-2026-gartner-critical-capabilities-for-security-service-edge.html
4. NIST. SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems. https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
5. European Union. Regulation (EU) 2022/2554 (Digital Operational Resilience Act). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
6. 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