Security Without Borders: Building A Hybrid Cloud Architecture That Works

Most enterprises didn’t wake up one morning and decide to build a complicated hybrid cloud environment. It usually happened gradually. A team moved one application to the cloud. Another kept a legacy system on-premises because replacing it would’ve cost a fortune. An acquisition brought in another platform. 

Someone needed lower latency. Someone else had a regulatory requirement. And somewhere along the way, “our infrastructure” became several very different environments connected together. That approach can work perfectly well for infrastructure. Security is where it gets harder. Each environment can be secure on its own and the organisation can still have gaps between them. 

Identity policies may behave differently. Logging may stop at a platform boundary. Security teams may use different tools, while responsibility for an application changes depending on where it runs. A good hybrid cloud security architecture has to account for those differences without pretending they don’t exist. 

The goal isn’t to make every environment identical. It’s to make sure the organisation gets consistent security outcomes wherever its users, applications and data happen to be.

Hybrid Cloud Changes Where Security Has To Work

Hybrid infrastructure is already the normal operating environment for many enterprises. Flexera’s 2026 State of the Cloud Report, based on 753 cloud decision-makers and practitioners, found that 73 per cent of organisations now operate hybrid cloud estates. That doesn’t mean all those environments were designed from scratch as one neat architecture. 

Flexera points out that multicloud and hybrid estates can also emerge through mergers, siloed applications and other business decisions. Security teams may therefore inherit an environment long after the decisions that created it were made. The problem is that attackers don’t care where one environment ends and another begins. 

Neither do data flows, user sessions, applications or business processes. A customer-facing service might depend on an on-premises database, a public-cloud application and several software-as-a-service platforms before it can complete one transaction. So hybrid cloud security can’t stop at the edge of each platform. 

NIST’s August 2026 draft report on multicloud architecture offers a useful picture of the problem. Although the report focuses specifically on multicloud environments, NIST identified 23 security and compliance challenges created or amplified when organisations try to coordinate controls across autonomous cloud environments. 

The most significant problems came from differences between cloud-native services, organisational complexity and the difficulty of creating centralised security capabilities across provider boundaries. Those same tensions appear in hybrid environments, where public cloud infrastructure also has to connect with privately operated systems. 

Which means the architecture has to account for difference from the beginning.

Consistency Doesn't Mean Making Every Environment The Same

It would be convenient if every system supported the same identity model, generated the same logs and enforced security policies in exactly the same way. Most enterprises don’t work like that. Legacy applications may have been built before modern authentication existed. Public-cloud providers have their own security services and configuration models. 

On-premises systems may rely on completely different network controls. Even two cloud platforms designed for similar purposes can implement the same security principle differently. Trying to remove every difference can create almost as much complexity as leaving everything disconnected. 

A better cloud security architecture starts with the outcomes that need to remain consistent:

• Who should have access?
• What needs protecting?
• Which activity must be recorded?
• How quickly should suspicious behaviour be detected?
• What happens when a system or account is compromised?

Those requirements can stay the same even when the technologies enforcing them change. The familiar cloud security basics still apply. Organisations need strong access controls, encryption, secure configurations, monitoring and incident response. 

Hybrid architecture simply adds another question: can those controls still achieve the same result when a workload crosses into a different environment? That distinction gives security teams some flexibility without lowering the standard.

Identity And Policy Need To Cross The Boundary

Identity is one of the clearest places to see this problem. A person doesn’t become a different employee when they access an on-premises application instead of a cloud service. Their role, permissions and level of trust shouldn’t suddenly change because the infrastructure underneath the application did. 

Yet the systems making those decisions often do change. The Cloud Security Alliance’s State of Multi-Cloud Identity Survey found that 75 per cent of organisations manage two or more identity providers. It also found that 57 per cent experience moderate or high difficulty onboarding on-premises applications to cloud identity providers, with legacy compatibility among the major barriers. 

That makes cloud identity security partly an integration problem. An organisation may have a strong identity strategy on paper while older applications, separate directories and provider-specific controls create different versions of it in practice. A Zero Trust approach can help by shifting the decision away from network location.

Access is based on identity, context and policy rather than assuming something is trustworthy because it sits inside a particular network. But even good policy becomes fragile when nobody can see how consistently it’s being enforced. 

CSA’s August 2026 research found that 92 per cent of respondents had at least some difficulty getting one accurate view of security policies across hybrid and multicloud environments. Almost half said policy changes were mostly or completely manual, while only nine per cent had fully integrated policy management into development and deployment workflows. 

So identity and security policy management need to work above individual platforms wherever possible. The technologies underneath can differ. The decision logic shouldn’t.

Data And Workloads Need Protection Wherever They Move

Infrastructure used to give organisations a fairly easy way to think about data security. Sensitive information lived inside systems they controlled, usually in places they could physically point to. Cloud changed that. Hybrid cloud makes the picture more complicated again. 

A workload may process data locally, send part of it into a cloud service, write results somewhere else and use a third-party platform along the way. If protection depends primarily on where the data currently sits, security can weaken every time that location changes. That’s why data classification needs to come before location. 

If information has the same sensitivity and business value, its protection requirements should travel with it. Encryption, access restrictions, retention rules and monitoring may be implemented differently across environments, but the organisation shouldn’t lose control simply because the workload has moved. 

This becomes especially clear when looking at cloud security in healthcare. Healthcare organisations often have legitimate reasons to maintain mixed infrastructure. Clinical systems, connected devices, older applications, patient data and newer digital services don’t all carry the same technical or regulatory requirements. 

The US Department of Health and Human Services’ healthcare cybersecurity goals specifically call for organisations to identify known, unknown and unmanaged assets, while also considering system placement and data classification. That principle extends well beyond healthcare. Workload placement should reflect what the system actually needs. 

Security architecture then has to preserve the appropriate controls wherever that decision places it.

Visibility Has To Follow The Same Architecture

Prevention only gets you so far. Eventually, something behaves strangely. A credential is compromised. An application is exploited. Data starts moving somewhere it shouldn’t. At that point, the organisation needs to understand what happened across the entire path, not only inside one platform. That’s where fragmented telemetry becomes a real problem. 

Logs from an on-premises system may sit in one tool while cloud events live somewhere else. Identity activity might be recorded separately again. Each team can technically have visibility and still miss the relationship between those events. Current threat activity shows why that relationship is important.

Google Cloud’s H1 2026 Threat Horizons Report found that identity issues were used for initial access in 83 per cent of the major cloud and SaaS incidents it analysed from the second half of 2025. The report also describes attackers moving from compromised endpoints or development environments into cloud infrastructure. 

Google also highlighted Storm-0501 activity involving hybrid environments where attackers exfiltrated data and deleted Microsoft Azure data and backups. An incident like that can’t be understood properly as one cloud event plus one network event plus one identity event. Security visibility needs enough shared context to connect them. 

That doesn’t require every platform to produce identical logs. It does require the architecture to preserve the information security teams need to follow an attack wherever it goes.

Shared Responsibility Gets Harder In Hybrid Environments

There’s another boundary hybrid environments create, and this one is organisational rather than technical. Cloud providers operate under shared-responsibility models. The provider protects some parts of the service, while the customer remains responsible for others. Most enterprise teams understand that principle by now. 

Hybrid services make the dividing line more interesting. Take AWS security in the cloud as an example. Under AWS’s standard shared-responsibility model, AWS protects the infrastructure running its cloud while customers remain responsible for areas such as their data, identities, applications and configurations. 

With AWS Outposts, AWS infrastructure can also run inside a customer’s own facility. AWS still operates and manages the Outposts equipment, but the customer takes on additional responsibilities for areas such as physical security, power, cooling and network connectivity. The provider hasn’t disappeared. Neither has the customer. The boundary has simply moved. 

A coherent hybrid architecture therefore needs responsibility to be as clearly designed as the technical controls themselves. Someone needs to know who owns each security decision, who receives the alert, who changes the policy and who responds when something fails. Otherwise, the weakest point may be the assumption that somebody else was handling it.

Test The Architecture At The Boundaries

One of the easiest ways to review a hybrid environment is to inspect each platform individually. Check its identity controls. Review its configuration. Look at its monitoring. Confirm that someone owns it. That can tell you whether each environment is reasonably secure. It won’t necessarily tell you whether the architecture works. 

The more useful questions appear where one part of the estate connects with another:

• Does the same identity receive appropriate access when it moves between environments?
• Can security policies produce equivalent outcomes even when different technologies enforce them?
• Does sensitive data retain the right protection when its location changes?
• Can security teams follow one incident across identity, network, cloud and on-premises systems?
• Is responsibility still clear when provider-managed technology runs inside customer-managed infrastructure?
• Can the organisation explain which control takes over when another one stops applying?

These are architectural questions rather than product questions. They also expose a different kind of security gap. A business can own excellent individual tools and still struggle if the hand-off between those tools, teams or environments isn’t understood. That’s where a security architecture review can become more useful than another inventory of controls. 

Instead of asking whether security exists everywhere, it asks whether protection remains coherent when something crosses a boundary.

Final Thoughts: Secure The Connections, Not Just The Environments

Hybrid cloud doesn’t create security problems simply because an organisation has more than one type of infrastructure. The harder problem appears when those environments have to behave like one enterprise. Users move between them. Applications depend on each other. Data travels across them. 

Security teams investigate incidents that refuse to stay politely inside the system where they began. A strong hybrid cloud security architecture accepts that the underlying environments will remain different. It doesn’t try to flatten every platform into one technical model. 

Instead, it defines the security outcomes the organisation expects and makes sure those outcomes survive the journey between systems. That changes what leaders need to look for. The architecture isn’t working simply because every environment has security controls. It’s working when identity, policy, protection, visibility and ownership remain intact as workloads cross the boundaries between them. 

And those boundaries are only likely to become more complicated as enterprises add new cloud services, AI workloads, sovereign infrastructure and whatever comes after that. EM360Tech will continue following how those changes reshape the decisions technology and security leaders make about cloud architecture, cyber resilience and the infrastructure their organisations depend on.