The security and compliance risks unique to hybrid cloud come from the seams between environments: two identity systems, network paths that cross the boundary, data that moves between jurisdictions, inconsistent policies and logs, and a shared-responsibility model that differs on each side. You mitigate them by unifying identity with short-lived credentials, encrypting and authenticating every cross-boundary connection with mTLS and private links, mapping data residency per location, enforcing one policy set as code, and centralizing audit logs into a single timeline.
Disclosure: Control Plane publishes this guide.
TL;DR
Each hybrid-specific risk and its mitigation:
- Identity sprawl. Federate through one identity provider and use short-lived credentials.
- Long-lived keys. Replace them with workload identity federation.
- Flat VPNs. Replace them with scoped private links and deny-by-default firewalls.
- Unencrypted east-west traffic. Enforce mTLS on every service-to-service call.
- Data residency drift. Map residency per location and enforce placement in deployment policy.
- Inconsistent policy baselines. Keep one policy set as code, applied everywhere.
- Fragmented audit logs. Centralize logs and sync clocks to one redundant time hierarchy.
- Shared-responsibility gaps. Assign an owner to every control.
- Inconsistent patching and image provenance. Use one image pipeline with signed artifacts.
- Duplicated secrets. Use one secrets store with envelope encryption.
- Where Control Plane fits. Control Plane closes many of these gaps with Universal Cloud Identity instead of long-lived keys, Cloud Wormhole private connectivity into on-premises networks, mTLS behind deny-by-default firewalls, and location control through its Global Virtual Cloud (GVC).
What security and compliance risks are unique to hybrid cloud?
A single-cloud deployment has one identity plane, one network perimeter, one set of provider-managed controls, and one shared-responsibility model. Hybrid cloud has at least two of each, and every connection, credential, policy, and log entry that crosses the boundary between on premises and the public cloud adds risk that neither environment carries alone. The Cloud Security Alliance notes that interconnecting disparate cloud infrastructures increases “the challenge to consistently apply and maintain cloud security and compliance controls.” The boundary creates gaps that neither side’s native tooling fully covers.
| Risk | Where it occurs | Compliance control at stake | Mitigation | How to verify |
|---|---|---|---|---|
| Identity sprawl between on-premises directory and cloud IAM | The federation boundary between Active Directory or LDAP and cloud identity providers | SOC 2 logical access, HIPAA access controls | Federate identity through a single identity provider; enforce MFA on both sides; deprovision in one place | Audit federated login events; confirm no orphaned accounts in either directory each quarter |
| Long-lived keys used to reach cloud services from on premises (and the reverse) | CI/CD pipelines, config files, and environment variables that store static API keys or service-account JSON | SOC 2 logical access, PCI DSS credential management | Replace static keys with workload identity federation and short-lived tokens | Scan repos and config stores for static credentials; report key age from cloud IAM and alert when it exceeds policy |
| Flat or VPN-based connectivity that bridges networks | Site-to-site VPN tunnels and peered VPCs that allow broad lateral movement | PCI DSS scope and segmentation, SOC 2 system boundaries | Replace flat VPNs with scoped private connectivity; segment by workload so each service reaches only its declared dependencies | Run network-path analysis to confirm workloads can reach only their declared dependencies |
| Unencrypted or unauthenticated east-west traffic across the boundary | Service-to-service calls between on-premises applications and cloud workloads | PCI DSS Requirement 4 where cardholder data crosses open, public networks, HIPAA transmission security | Enforce mTLS with a unique certificate per workload and a deny-by-default internal firewall | Capture traffic samples at the boundary; verify TLS version and certificate chain |
| Data residency drift when data or backups move between sites and regions | Backup replication, database failover, and object-storage sync jobs | GDPR international transfer rules (Chapter V), HIPAA business associate coverage for every location that stores ePHI | Map data residency per location; enforce placement in deployment policy; restrict replication targets | Review backup and replication configs monthly; alert on data appearing in unapproved regions |
| Inconsistent policy and configuration baselines | Separate policy engines for on-premises firewalls, cloud security groups, and IAM policies | SOC 2 change management, PCI DSS configuration standards | Define one policy set as code and apply it to both environments through a single pipeline | Diff deployed policy against the canonical source on every change; fail deployments on drift |
| Fragmented audit logs and time sources | On-premises syslog, cloud-native audit trails, and separate NTP servers | SOC 2 monitoring, HIPAA audit controls, PCI DSS log management | Centralize logs into one SIEM or log store; sync all hosts to the same redundant NTP hierarchy | Trace a known event across both environments; check clock skew |
| Shared-responsibility gaps between your data center and the provider | The boundary between provider-managed infrastructure and your self-managed on-premises stack | Every framework that requires defined control ownership | Build an explicit shared-responsibility matrix and assign an owner to every control | Review the matrix in each audit cycle; confirm no control is unowned |
| Inconsistent patching and image provenance across environments | On-premises VMs built from local templates and cloud instances built from marketplace images | SOC 2 vulnerability management, PCI DSS patch management | Use a single image pipeline; sign artifacts; enforce provenance checks at deploy time | Compare deployed image digests against the signed artifact registry; alert on unsigned images |
| Secrets duplicated across two secret stores | An on-premises vault and a cloud secret manager holding copies of the same credentials | SOC 2 logical access, PCI DSS credential management | Use one secrets store or a single source of truth with envelope encryption and HSM-backed keys | Enumerate secrets in both stores; flag duplicates; rotate and consolidate |
Who is responsible for what in hybrid cloud?
The shared-responsibility model is well documented for public cloud IaaS; AWS, Azure, and Google Cloud each publish theirs. In hybrid cloud the model changes on each side of the boundary, and the seam itself is often nobody’s explicit responsibility. On premises, you own everything. For on-premises servers or your own Kubernetes clusters joined to a managed platform, physical security, hardware, and host operating systems stay with you.
| Layer | On premises (you) | Public cloud IaaS | Managed platform |
|---|---|---|---|
| Physical security | You | Provider | Provider for provider-hosted locations; you or your cloud provider, for servers or clusters you bring |
| Hardware and hypervisor | You | Provider | Provider for provider-hosted locations; you or your cloud provider, for servers or clusters you bring |
| Network fabric | You | Provider (VPC fabric); you configure security groups and routes | Platform manages workload networking; you choose locations and endpoints |
| Host OS patching | You | You for VMs; provider for managed services | Provider for provider-hosted locations; you, for nodes in your own cloud accounts or data centers |
| Container runtime and orchestration | You | You for self-managed Kubernetes; provider for the managed Kubernetes control plane | Platform schedules workloads in every location; on Control Plane, the platform runs the Kubernetes control plane for its managed locations and for servers joined through Control Plane’s Managed Kubernetes (MK8s); you, for Kubernetes clusters you bring |
| Workload identity and access policy | You | Shared: provider supplies IAM primitives, you configure policies | Platform supplies identity and a policy engine; you define the policies |
| Encryption of data at rest | You | Shared: provider encrypts most services by default; you manage customer-managed keys if you use them | Varies by platform; Control Plane encrypts all volumes by default |
| Encryption in transit between services | You | You configure TLS or mTLS | Varies by platform; Control Plane enforces mTLS between workloads by default |
| Audit logging of platform actions | You | Shared: provider logs management API calls by default; you enable data-access logging and configure retention | Platform logs its own actions (Control Plane’s audit trail is tamper-proof and queryable by resource, subject, and time); you analyze it alongside your other logs |
| Application code and data classification | You | You | You |
How do you mitigate hybrid cloud security risks?
Each step targets one or more risks from the register.
- Unify identity and remove long-lived keys. Federate human and workload identities through a single identity provider, and replace every static API key and service-account JSON with short-lived tokens issued through workload identity federation. This follows NIST SP 800-207 zero-trust tenets: access is granted per session, and authentication and authorization are dynamic and strictly enforced before access is allowed.
- Replace flat VPNs with scoped private connectivity. A site-to-site VPN that bridges your data center to a cloud VPC can give every host on both sides a path to every other host. Connect specific workloads to specific endpoints instead, with Control Plane’s Cloud Wormhole or with cloud-native private endpoint services such as AWS PrivateLink or Google Cloud Private Service Connect, which expose only specific services. On-premises access to those endpoints still rides Direct Connect, Interconnect, or a VPN, but it is scoped to the endpoint instead of the whole network.
- Enforce mTLS and a deny-by-default internal firewall. Every service-to-service call, within each environment and across the boundary, should be encrypted and mutually authenticated. A deny-by-default firewall ensures that a service accepts calls only from the workloads explicitly allowed to reach it.
- Map data residency per location and enforce it in deployment. Build a data-flow map that records where every dataset, backup, and replica lives, and encode residency rules into the deployment pipeline so that, if your policy keeps EU personal data in the EU, a workload processing it cannot be scheduled to a US region.
- Define one policy set as code for both environments. Keep security policies, network rules, IAM policies, configuration baselines, and deployment constraints in a version-controlled repository, apply them through one pipeline to both environments, and fail deployments on drift. The policy as code guide covers rule design.
- Centralize audit logs and sync time. Ship on-premises syslog, cloud audit trails, and application telemetry to one SIEM or log store, and sync every host to the same redundant NTP hierarchy so event timestamps correlate. The Cloud Security Alliance’s hybrid cloud mitigation guidance lists integrated security management and centralized identity and access lifecycle management among its countermeasures.
- Use one secrets store or a single source of truth. Duplicating secrets across an on-premises vault and a cloud secret manager widens the attack surface and makes rotation error-prone. Consolidate into one store with envelope encryption backed by hardware security modules (secrets management best practices).
- Establish consistent image provenance and patching. Build all container images and VM templates from one pipeline, sign every artifact, verify signatures at deploy time in both environments, and patch on one cadence.
- Assign ownership and test across the boundary. Assign an owner to every control in a shared-responsibility matrix, then run incident-response exercises that span both environments, such as a credential compromise that starts on premises and moves to the cloud.
Which compliance frameworks are hardest in hybrid cloud?
Major compliance frameworks expect consistent controls across every system in scope, and the hybrid seam makes that harder in framework-specific ways. This section is general guidance; confirm specific obligations with your assessor or legal counsel.
PCI DSS recommends segmenting the cardholder data environment (CDE) from everything else to reduce scope, and when you rely on segmentation to reduce scope, you must confirm it with penetration testing under Requirement 11.4.5. Requirement 4 requires strong cryptography for cardholder data sent over open, public networks. In a hybrid setup, the VPN or private link that connects on premises to the cloud is in PCI DSS scope if it transmits cardholder data, and systems connected to the CDE can be in scope too. If you use segmentation to limit scope, the segmentation tests must cover the boundary as well as each side.
HIPAA requires access controls, audit controls, and transmission security for every system that touches electronic protected health information (ePHI). If ePHI moves from an on-premises EHR to a cloud analytics workload, both environments and the connection between them must satisfy the Security Rule, and each cloud or platform vendor that handles ePHI needs a business associate agreement. Fragmented audit logs make it hard to produce a complete access history for one patient record.
SOC 2 is an attestation report issued by an independent CPA firm. A Type II report covers the design and operating effectiveness of controls within the system boundary defined in your system description, evaluated against the AICPA Trust Services Criteria. If that boundary spans on premises and cloud, the auditor tests controls in both, and inconsistent policy baselines and unclear control ownership across the boundary produce exceptions.
GDPR restricts transfers of personal data outside the European Economic Area (EEA) unless a transfer mechanism applies, such as an adequacy decision (including the EU-US Data Privacy Framework for certified recipients) or Standard Contractual Clauses. Hybrid setups where backups replicate to a US cloud region, or where failover shifts processing outside the EEA, can create unplanned transfers without a valid mechanism, and these often go unnoticed until an audit or a data subject request. Running regulated apps in the cloud with SOC 2, HIPAA, PCI, and data residency covers these frameworks in more depth.
How Control Plane reduces hybrid cloud risk
Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI), VM workloads on locations joined through Control Plane’s Managed Kubernetes (MK8s), and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds. Several mitigations from the plan map to Control Plane capabilities.
Identity without long-lived keys. Control Plane’s Universal Cloud Identity gives each workload access to services on AWS, GCP, and Azure through an IAM role or service-account grant instead of long-lived keys in your code, with short-lived, least-privilege credentials at runtime.
Scoped private connectivity. Control Plane’s Cloud Wormhole connects workloads to TCP or UDP endpoints in VPCs and other private networks, including on-premises data centers, by running a Control Plane agent inside the private network. Control Plane’s native networking, configured on a workload’s identity, also gives workloads private connectivity to AWS PrivateLink and Google Cloud Private Service Connect resources without traversing the public internet.
mTLS and deny-by-default firewalls. Workload-to-workload traffic uses mTLS with a unique client certificate per workload, rotated every hour. Internal and external traffic is off by default: a workload accepts calls from other workloads only when its internal firewall allows them (same GVC, same org, or a named list of workloads), and external inbound and outbound access stays closed until you allow specific addresses or hostnames.
Data residency through location choice. A workload deployed to a GVC, Control Plane’s named set of locations across one or more clouds, runs in every location of that GVC from one definition. Locations can be Control Plane-managed regions on AWS, GCP, Azure, and Oracle Cloud, Kubernetes clusters you already run joined through Control Plane’s Bring Your Own Kubernetes (BYOK), or your own servers through MK8s, including on premises. You choose the locations, which is how you keep data in the places your residency rules allow. The hybrid cloud deployment guide walks through the setup.
Least-privilege policies. Inside a Control Plane org, nothing is permitted until a policy grants it. Policies grant permissions to users, groups, service accounts, and workload identities, and can be as narrow as one service account holding edit on one workload. A workload reads a secret’s value only when a policy grants its identity reveal on that secret. Policies are org-wide, so the same grants apply in every location, and you can manage them as code through Terraform, Pulumi, or the CLI.
Tamper-proof audit trail. Control Plane provides a tamper-proof audit trail that records every action from the console, CLI, Terraform, Pulumi, the Kubernetes operator, and the MCP server, and workloads can write their own events to it through an audit context. Every platform change across all locations lands in one trail; logs from your on-premises systems still belong in your central SIEM.
Encrypted secrets and volumes. Org secrets use envelope encryption with keys held in cloud hardware security modules. Control Plane encrypts all volumes by default, and on AWS locations a volume set can use your own AWS KMS key.
Workload isolation. Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Sandboxes run in dedicated Kata Containers microVMs. The multi-tenant isolation guide covers isolation in depth.
Day 2 operations and compliance. Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.
What remains your responsibility. Control Plane secures the workloads and connections it runs. Your on-premises hardware and physical security, the servers or clusters you join as locations, your directory, and the data your applications store remain your responsibility, and using Control Plane does not make your own systems compliant by itself. The cost trade-offs are covered in cloud vs on premises vs hybrid cost.
FAQ
Short answers to common questions about securing hybrid cloud.
What security and compliance risks are unique to hybrid cloud, and how can I mitigate them?
They come from the boundary between on premises and the public cloud: identity sprawl, long-lived cross-boundary keys, flat VPNs, unencrypted east-west traffic, residency drift, inconsistent policy, fragmented logs, unowned controls, uneven patching, and duplicated secrets. The risk register in this guide pairs each with a mitigation and a verification step.
Is hybrid cloud less secure than public cloud?
Hybrid cloud has a different risk profile because the boundary between environments adds risks a single-cloud deployment lacks. Teams that control the boundary with unified identity, scoped connectivity, consistent policy, and centralized logging can reach a comparable security posture while keeping control over where data lives.
How do you secure connectivity between on premises and the cloud?
Replace site-to-site VPNs that bridge entire networks with scoped private connectivity that connects specific workloads to specific endpoints. Encrypt and mutually authenticate every connection with mTLS, and apply deny-by-default firewall rules so that no traffic flows until a rule explicitly allows it.
How do you manage identity across on premises and cloud?
Federate all identities through a single identity provider and enforce MFA on both sides. Replace long-lived API keys and service-account credentials with short-lived tokens issued through workload identity federation.
How do you keep data residency compliant in hybrid cloud?
Build a data-flow map that records where every dataset, backup, and replica lives, and encode residency rules into your deployment pipeline so regulated data runs only in approved locations. Restrict replication targets and audit them monthly.
What is the shared responsibility model in hybrid cloud?
It changes depending on which side of the boundary you are on, and each provider publishes its own version for public cloud. The seam between environments is often nobody’s explicit responsibility unless you build a responsibility matrix that covers it.
How do you audit a hybrid cloud environment?
Ship on-premises, cloud, and platform audit logs to one SIEM on a shared time source, then verify completeness by tracing a known event across both environments. Retain logs as long as your frameworks require, in tamper-evident storage.
How does Control Plane secure hybrid workloads?
Control Plane runs your cloud and on-premises workloads as one environment, so identity, mTLS, firewall rules, access policies, and the audit trail work the same way in every location instead of differing on each side of the seam. Universal Cloud Identity replaces long-lived keys, Cloud Wormhole and native networking replace flat VPNs, and org-wide policies and one tamper-proof audit trail cover every location.
Do I need separate compliance audits for on premises and cloud?
Usually not. A SOC 2 report covers the system boundary in your system description, and a PCI DSS assessment covers every system that stores, processes, or transmits cardholder data or connects to the cardholder data environment. If that scope spans on premises and cloud, the assessor tests controls in both and at the boundary, and you receive one report covering the whole scope. Controls your cloud or platform provider operates are usually carved out of a SOC 2 report and covered by that provider’s own report, and for PCI DSS they are covered by the provider’s attestation of compliance.
Talk to the Control Plane team or sign up free to deploy hybrid workloads with these controls in place.
Originally published on the Control Plane blog.
