Hybrid Cloud Security Reference Architecture

A hybrid cloud security reference architecture is a vendor-neutral blueprint that shows how security controls connect across on-premises infrastructure, private cloud, SaaS, and public cloud. It is used to plan deployments, compare vendors, explain security design to auditors, and measure progress toward zero trust.

This article provides a complete reference model: the design principles behind it, logical and deployment diagrams, a component reference, six traffic flows, control boundaries, design considerations for identity, logging, capacity, and resilience, a mapping to CISA and NIST controls, five deployment examples, and a maturity path with validation tests.

This article is part of the Hybrid Cloud Security guide. For the general infrastructure view of hybrid environments, see Hybrid Cloud Architecture: Components and Deployment Models.

Design principles behind the reference model

The reference model rests on four principles drawn from NIST and CISA zero trust guidance.

1. Separate decisions from enforcement. NIST SP 800-207 distinguishes the policy decision point (PDP), which decides whether access is allowed, from the policy enforcement point (PEP), which enables, monitors, or terminates the connection. One PDP, many PEPs.
2. Do not grant trust based on network location. Being on the corporate LAN is not a reason to skip authentication or inspection. NIST SP 800-215 describes the loss of a meaningful perimeter as a defining feature of today’s enterprise networks.
3. Protect data by classification, not location. Controls follow the data class wherever it moves.
4. Assume any single dependency can fail. Identity providers, cloud services, and WAN links all go down. The architecture defines what happens when they do.

NIST’s practice guide SP 1800-35, Implementing a Zero Trust Architecture, published in June 2025 with 24 vendors, demonstrates 19 sample implementations of these principles across on-premises and cloud environments and is a useful companion to this model.

Architecture diagrams

Two views describe the reference architecture: a logical view of its planes and a deployment view of where components run.

Logical architecture

The logical architecture has three planes: a centralized control plane, a distributed enforcement plane, and a shared visibility plane.

The control plane defines policy once. The enforcement plane applies it wherever traffic flows. The visibility plane collects telemetry from every enforcement point and feeds risk signals back into policy.

Deployment topology

The deployment view shows where each enforcement point physically runs across headquarters, branches, cloud regions, and remote users.

Component reference

Each component has a defined role, placement, and set of hybrid-specific requirements.

Traffic flows

Six traffic flows cover most hybrid estates, and each should have one documented enforcement point and one decryption point.

Flow 1: Office user to internet or SaaS

The user authenticates through the identity provider. Traffic goes to the local gateway, which decrypts, inspects for threats, and applies web and access policy, then forwards sessions subject to data protection to the vendor cloud for inspection under the same policy. Document TLS termination and re-encryption across this path and avoid redundant inspection, consistent with NSA guidance on managing TLS inspection risk.

Flow 2: Remote user to SaaS

The endpoint agent or browser controls steer traffic to the nearest approved cloud point of presence. The same policy set applies as in Flow 1. CASB adds SaaS-specific controls such as tenant restrictions and activity-level DLP.

Flow 3: User to private application

Access goes through ZTNA, not a network-level VPN. The access service checks identity, device posture, and policy, then connects the user only to an authorized application. A deployment may use a cloud broker for remote users and a local gateway for supported on-site sessions. Confirm broker placement, application protocols, session visibility, and the actual data path. See On-Premises ZTNA for Private Applications.

Flow 4: Workload to workload

Service-to-service traffic between data center and IaaS workloads uses workload identity, mutual TLS, and segmentation rules. The same policy source defines which services may communicate.

Flow 5: Data at rest in cloud services

CASB API integration and DSPM scan sanctioned cloud storage and SaaS for sensitive data, risky sharing, and excessive permissions, then remediate using the same classification applied inline. See How DSPM and SSE Work Together.

Flow 6: AI agents and service accounts

AI agents and automation often hold user-level access and call internal APIs over long-lived connections, including WebSockets, that originate inside the network. Give each agent its own identity and per-application entitlements, route its traffic through a local enforcement point, and apply DLP to what it sends to external AI services.

Control boundaries

Control boundaries should be drawn around what must be protected, not around where equipment sits.

The jurisdiction boundary is often overlooked. If decrypted traffic, inspection logs, or DLP incident copies leave a jurisdiction, the architecture may break residency commitments even when stored data never moves. See Data Sovereignty in Hybrid Cloud Security.

Network security for hybrid cloud

Network security in a hybrid environment shifts from protecting a perimeter to protecting individual connections.

• Replace flat site-to-site trust with segmentation and per-application access.
• Keep encrypted tunnels (IPsec, GRE, or private interconnects) between sites and cloud regions, but do not treat tunnel membership as authorization.
• Steer traffic deliberately: explicit proxy or PAC files for managed office networks, agents or browser controls for roaming users, tunnels for branches.
• Decide which component decrypts each flow, so no flow is decrypted twice.
• Log at every enforcement point and correlate centrally.

NIST SP 800-215 reviews these options, including ZTNA, microsegmentation, software-defined perimeters, and secure access service edge (SASE) models that combine networking and security services.

Design considerations

Four design areas decide whether the architecture works in practice: identity, logging, capacity, and failure behavior.

Identity architecture

Identity is the first input to every access decision, so the reference architecture treats four kinds of identity as first-class subjects.

• Workforce users. One authoritative identity provider, federated to every cloud provider and SaaS application, with phishing-resistant MFA and conditional access. Group and role data should come from one source so entitlements do not diverge between environments.
• Devices. Device identity and posture (managed status, patch level, disk encryption, endpoint protection) should be evaluated for on-site users as well as remote ones.
• Workloads and services. Applications and services authenticate to each other with workload identities and mutual TLS rather than shared secrets or network location.
• AI agents and automation. Each agent receives its own identity, scoped entitlements, and an accountable human owner, so its actions can be authorized, logged, and revoked independently.

Two design details are easy to miss. First, sessions should be re-evaluated when context changes, such as a device falling out of compliance, rather than trusted until they expire. Second, define break-glass access for administrators that works when the identity provider is unavailable, with strong controls and alerting on its use.

Logging and telemetry

Logging in a hybrid architecture has to serve detection, investigation, and compliance while respecting where data is allowed to go.

• What to collect. Every enforcement point should log the user, device, application or destination, policy decision, rule matched, and data classification involved. Use common correlation keys (user ID, device ID, session ID) so events from local and cloud enforcement can be joined.
• Where to collect it. Local collectors at each major site store events first, then forward to the central SIEM. This preserves logs during WAN outages and allows selective forwarding.
• What to forward. Forward metadata needed for detection. Keep full DLP evidence and content excerpts in the jurisdiction where they were captured, with access restricted to authorized investigators.
• Retention. Align retention with regulatory requirements per data class and jurisdiction, and document it.
• Integrity. Protect logs from tampering and alert on gaps, which can signal both failures and attacks.

Capacity and sizing

Local enforcement points must be sized for decrypted traffic at peak, which is the most common source of performance problems in hybrid deployments.

• Measure peak throughput and connection rates per site, and the share of traffic that will be decrypted. TLS decryption is compute-intensive.
• Size clusters with headroom for failover, so the loss of one node does not overload the rest.
• Account for growth in encrypted traffic, larger file transfers, and long-lived AI and collaboration sessions.
• Plan how capacity is added. Virtual and containerized appliances can scale faster than dedicated hardware.
• For cloud points of presence, confirm regional capacity and failover options with the provider, especially where residency limits the regions you can use.

Resilience and failure behavior

A reference architecture is incomplete until it defines what happens when each dependency fails.

• Vendor cloud unavailable: local enforcement of web and private application policy continues with cached policy, while services delivered from the cloud, including data protection, remote browser isolation, AI security controls, CASB, and data security posture management, are not applied until the path recovers; remote users fail over to other points of presence.
• Identity provider unavailable: define whether existing sessions continue and whether any local fallback exists.
• Site WAN or internet link down: local ZTNA keeps on-site access to local applications working.
• Local gateway failure: a cluster peer or a cloud point of presence takes over under the same policy.
• Fail-open or fail-closed: decide per traffic class, and make the state visible to operations.

See Hybrid SSE Resilience: Failover and Recovery for a testing plan.

Control mapping to CISA and NIST

Mapping each component to recognized frameworks turns the reference architecture into evidence for auditors and a checklist for implementers.

The table maps components to the pillars of CISA’s Zero Trust Maturity Model and to representative control families in NIST SP 800-53 Rev. 5.

This mapping is a starting point. Each organization should confirm control applicability against its own baseline and regulatory scope.

Deployment examples

The same reference model adapts to different industries by moving enforcement points, not by redesigning policy.

Example 1: Regional bank

Headquarters and data centers run local SWG and ZTNA gateways so that customer data is decrypted and inspected only on bank-controlled infrastructure. Branch traffic uses local appliances or tunnels to the nearest data center. Remote staff use cloud points of presence restricted to in-region locations. Inspection logs stay in-country. This pattern supports DORA ICT risk and third-party requirements for EU institutions while still allowing cloud CASB for SaaS.

Example 2: Manufacturer with OT networks

A segmentation firewall separates plant OT networks from corporate IT. OT systems reach only approved update and telemetry destinations through a local SWG. Engineers reach plant systems through local ZTNA with device posture checks. If the WAN or a cloud service fails, plant access and inspection continue locally.

Example 3: Public sector agency

Classified or disconnected networks require components explicitly supported for operation without external services. Unclassified networks may use appropriately authorized cloud services for remote workers. Document policy synchronization, identity, update, and licensing dependencies, and keep environment-specific exceptions under change control.

Example 4: Regional health system

The electronic health record and imaging systems run in the health system’s data centers. Clinical workstations in hospitals use local gateways, so patient data in web and SaaS traffic is inspected on premises. Medical devices sit in segmented zones with tightly restricted outbound access. Clinicians working remotely reach the EHR through the cloud ZTNA broker with managed-device requirements, and DLP rules for protected health information apply identically in both paths, supporting HIPAA Security Rule safeguards.

Example 5: Global retailer

Stores use small branch gateways or tunnels to regional hubs, with point-of-sale systems in a segmented cardholder data environment that reaches only payment processors. Corporate and store staff browsing is inspected at regional hubs or cloud points of presence, with European traffic restricted to EU regions and logs stored in-region. Store systems keep operating during WAN outages because local segmentation and access rules do not depend on the cloud. This supports PCI DSS segmentation and logging requirements.

Maturity path and validation

Use CISA’s maturity stages to phase the rollout, and repeatable tests to prove each stage works.

Maturity path

Organizations rarely implement the full reference architecture at once; CISA’s model describes four stages (Traditional, Initial, Advanced, and Optimal) that make a useful roadmap.

Use the gap between the current stage and the next as the basis for a phased plan.

Validating the architecture

An architecture is only as good as its tested behavior, so validate each flow and boundary with repeatable tests.

• Send a known-bad URL, a test malware file, and a DLP test document through every enforcement point and confirm identical results with the cloud path available. Record the expected behaviour for cloud-applied controls when that path is interrupted.
• Confirm each flow is decrypted exactly once.
• Attempt access to a private application from on site, remote, and an unmanaged device, and confirm the expected outcomes.
• Block access from a site to the vendor cloud and confirm local enforcement continues.
• Verify that logs from every enforcement point reach the SIEM and that residency rules are honored.

How Skyhigh maps to the reference architecture

Skyhigh Hybrid SSE Mesh covers the control plane (one console and policy engine with policy pushed as code), local enforcement (on-premises SWG appliances with local TLS inspection and local ZTNA), cloud enforcement (cloud SWG, CASB, ZTNA, and RBI), browser-level controls, and DSPM (Skyhigh Security).

For inspection-key protection and on-premises sandboxing, confirm the supported integrations, product versions, and deployment requirements with Skyhigh. Do not assume HSM support for the chosen gateway or service.

Sources

1. NIST. SP 800-207: Zero Trust Architecture (August 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST. SP 800-215: Guide to a Secure Enterprise Network Landscape (November 2022). https://csrc.nist.gov/pubs/sp/800/215/final
3. NIST NCCoE. SP 1800-35: Implementing a Zero Trust Architecture (June 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
4. NIST. SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
5. CISA. Zero Trust Maturity Model, Version 2.0. https://www.cisa.gov/zero-trust-maturity-model
6. NSA. Managing Risk from Transport Layer Security Inspection (November 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
7. European Union. Regulation (EU) 2022/2554 (Digital Operational Resilience Act). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
8. U.S. HHS. HIPAA Security Rule. https://www.hhs.gov/hipaa/for-professionals/security/index.html
9. PCI Security Standards Council. PCI DSS v4.0.1 (document library). https://www.pcisecuritystandards.org/document_library/
10. 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
11. 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