Hybrid Cloud Security: On Premises to Cloud Trust Links

In a hybrid estate the weakest trust link between on premises and cloud decides the security of both, and attackers now move deliberately across that link. Directory synchronisation servers, federation trusts, site to site VPNs and private circuits, cloud management agents on local servers and cloud provider hardware in your own data centre all create paths where a compromise on one side becomes control of the other. This guide covers the risks that are specific to hybrid: identity synchronisation and federation, network connectivity, extending cloud control planes to on premises machines, cloud hardware on site, consistent policy and monitoring across both sides. It is written for cloud and infrastructure architects, identity teams and security leaders. Cloud native controls such as landing zones and guardrails are covered in the Cloud Security Guide; this page focuses on what changes when the estate spans both. Where provider services are named they are listed alphabetically (AWS, Google Cloud, Microsoft); order is never a ranking.

Key takeaways

Identity sync servers are Tier 0. Microsoft documents that the Entra Connect server must be treated as a Tier 0 (control plane) component, with the same protection as domain controllers.
Separate cloud administration from on premises administration. Cloud only administrator accounts with phishing-resistant MFA stop a domain compromise from becoming a tenant compromise.
Network links carry trust both ways. Treat VPNs and private circuits as boundaries with filtering and monitoring on both ends, not as an extension of a flat internal network.
Cloud agents on local servers inherit cloud permissions. Whoever administers the cloud subscription or project that manages a hybrid server can change that server, so scope those roles as tightly as local admin.
One policy, two enforcement points. Define security baselines once and enforce them on both sides, with logs from both feeding one detection platform.

How hybrid attack paths work

Hybrid incidents often follow the same shape: compromise on premises, reach the systems that bridge to the cloud, then use the trust they hold. The Storm-0501 Hybrid Cloud Attacks 2024 page describes a group that gained domain admin rights, extracted the credentials of Entra Connect Sync accounts, took over a cloud Global Administrator account that had no MFA by resetting its on premises password, and then added a federated domain to the tenant so it could sign in as any user. The cloud did not need to be breached directly.

Bridge	What it trusts	Abuse pattern (MITRE ATT&CK)	Primary control
Directory sync server and its accounts	Writes identities and password hashes to the cloud directory	T1003 OS Credential Dumping, T1078.004 Cloud Accounts	Tier 0 server, monitored sync accounts, cloud only admins
Federation trust (AD FS or other IdP)	Issues tokens the cloud accepts	T1606.002 SAML Tokens, T1484.002 Trust Modification	Protect signing keys, alert on federation changes, consider cloud native authentication
Site to site VPN or private circuit	Routes traffic between networks	Lateral movement over trusted routes	Segmentation, filtering both ends, flow logging
Cloud management agent on local servers	Runs commands and extensions sent from the cloud control plane	T1021.007 Cloud Services	Scoped RBAC, local agent restrictions, dedicated subscriptions for Tier 0
Managed service provider access	Administers both sides	T1199 Trusted Relationship	Separate, monitored, time bound access

See the Storm-0501 Threat Actor Profile Guide and the Golden SAML and Federation Trust Abuse Defence Guide.

Where identity fits: directory sync and federation

Hybrid identity is the centre of hybrid security. The examples below use Microsoft's Entra Connect prerequisites page, which sets out hardening for the sync server; the same controls apply to any directory sync agent or federation server.

Tier 0 handling: Restrict administration to domain administrators or tightly controlled groups, use dedicated privileged accounts that are never used for email or browsing, and administer from privileged access workstations. See the Privileged Access Workstations Guide.
Local credentials: Unique local administrator passwords through Windows LAPS, and NTLM denied on the sync server.
Sync settings: Turn off soft matching if not needed (the blocksoftmatch feature) and turn off hard match takeover, both described by Microsoft as carrying security risk because they let on premises objects overwrite cloud identities.
Federation monitoring: Alert on changes to the trust between your identity provider and Entra ID, including new federated domains.
Sync accounts are non-human identities: Inventory the on premises and cloud sync accounts, alert on their use from anywhere but the sync server, and rotate them after any domain compromise.
Keep the software current: Microsoft Learn states, as checked in November 2026, that Entra Connect must be upgraded to version 2.6.84.0 or later and configured for application based authentication by 7 April 2027, after which synchronisation services stop working for servers that do not meet the requirement. Plan the upgrade now.

Two architectural choices reduce the bridge's power. First, cloud only administrator accounts, never synchronised from on premises, with phishing-resistant MFA and Conditional Access. Second, where federation is not needed, moving authentication to the cloud directory removes the federation signing keys as a target. See the Microsoft Entra Connect and Cloud Sync Hardening Guide and the AD FS to Entra ID Migration guide. Workloads that call cloud APIs from on premises should use short lived federated credentials rather than stored keys; see the Workload Identity Federation Guide.

Network connectivity: VPNs, private circuits and private endpoints

Hybrid networks join a data centre to one or more cloud networks through site to site IPsec VPNs, dedicated private circuits from the provider, and private endpoints that expose cloud services on private addresses. Each choice affects both availability and the blast radius of a compromise.

Option	Strengths	Security considerations
Site to site IPsec VPN over the internet	Quick to deploy, encrypted by design	Strong IKE and cipher settings, certificate based authentication, gateways patched and monitored
Dedicated private circuit	Predictable bandwidth and latency	Private does not mean encrypted: add MACsec or IPsec over the circuit where data sensitivity requires it
Private endpoints for cloud services	Keeps service traffic off the internet	DNS design across both sides; policies that deny public access once private access works
Hub and spoke with central inspection	One place to filter and log	Hub becomes critical: redundancy and change control

Filter both directions: Allow only the flows each application needs between on premises and cloud segments. A cloud workload compromise should not reach domain controllers, and an on premises compromise should not reach cloud management endpoints.
Do not extend flat networks: Avoid routing the whole data centre range into the cloud. Map application flows and route only those.
Log flows on both sides: Cloud flow logs and on premises firewall logs together show cross boundary movement.

The CISA and NSA cloud security information sheets released in March 2024 include one on network segmentation and encryption in cloud environments and one on secure cloud identity and access management. See the Cloud Network Security Guide.

Cloud control planes on local servers and cloud hardware on site

Providers now extend their control planes and hardware into customer locations. These services change who can administer what, and they shift physical security responsibility back to the customer. Each provider describes its model in its own documentation; the summaries below are customer side settings to apply.

AWS: Outposts

AWS Outposts places AWS infrastructure in your facility, under the AWS shared responsibility model. AWS documents that all Outposts data is encrypted at rest, with key material wrapped to an external key on a removable Nitro Security Key that is required to decrypt data on the rack, and that destroying the Nitro Security Key cryptographically shreds the data. Traffic between the Outpost and its AWS Region over the service link is encrypted by AWS; for local gateway traffic to your network, AWS recommends using an encryption protocol such as TLS. Customer side actions: control physical access to the rack and the Nitro Security Key, use Amazon EBS encryption with KMS keys where required, apply the same IAM guardrails as in the Region, and segment the local gateway. See the AWS Security Guide.

Google Cloud: Google Distributed Cloud

Google Distributed Cloud extends Google Cloud infrastructure and Kubernetes to customer data centres and edge sites, in connected (Google managed hardware linked to Google Cloud) and air gapped forms. For connected deployments, Google documents that the customer is responsible for physical security, that a physical intrusion sensor notifies the customer and Google, that the TPM is the root of trust for encryption keys, that drives are self encrypting with LUKS on logical volumes, and that customer managed encryption keys in Cloud KMS can wrap the disk keys. Traffic to Google Cloud uses MASQUE tunnels or TLS with per machine certificates. Customer side actions: restrict physical access, decide on customer managed keys and protect the Cloud KMS role binding (revoking it removes access to the data), and allow inbound traffic only to load balancer address pools, blocking it to management layers and local control plane endpoints, as Google recommends. See the Google Cloud Security Guide.

Microsoft: Azure Arc

Azure Arc projects on premises and other cloud servers into Azure through the Azure Connected Machine agent, which provides a managed identity for authenticating to Azure. Microsoft documents that the customer manages RBAC on Arc enabled resources and protects onboarding credentials, and that local agent settings take precedence over cloud requests: an extension allowlist, disabling guest configuration, and disabling incoming remote connections with azcmagent config. For Tier 0 servers such as domain controllers, Microsoft advises treating subscription and management group administrators as equivalent to local administrators and considering a dedicated subscription with few persistent admins. Customer side actions: apply those local restrictions on sensitive servers, scope roles at the narrowest level, and review policy inherited from parent management groups. See the Azure Arc Security Guide.

Consistent policy across both sides

Hybrid estates drift because two teams apply two baselines with two toolsets. The aim is one set of security requirements with an enforcement point on each side.

Policy area	On premises enforcement	Cloud enforcement	Shared evidence
Server hardening baseline	Group Policy, configuration management	Policy engines, guest configuration through hybrid agents	One compliance report per baseline
Privileged access	Tiered admin model, PAWs	Cloud only admin accounts, just in time roles	Single privileged account inventory
Encryption and keys	HSM or on premises key management	Cloud key management with customer managed keys	Key inventory with owners and rotation dates
Network access	Firewalls, segmentation	Security groups, firewall policies, private endpoints	Approved flow register across the boundary
Logging	Windows, Linux and network logs	Cloud audit, flow and directory logs	One SIEM with common time and identity fields

See the Cloud Security Posture Management (CSPM) Guide for the cloud side of posture checks and the Multi-Cloud Identity Guide where more than one provider is in use.

Implementing hybrid security

Map the bridges (weeks 1 to 4): List every sync server, federation server, VPN gateway, private circuit, hybrid management agent, on site cloud hardware and third-party access path. Record who administers each.
Protect identity first (weeks 2 to 8): Classify sync and federation servers as Tier 0, create cloud only admin accounts with phishing-resistant MFA, remove synchronised accounts from privileged cloud roles, and enable federation change alerts. Test sign in for break glass accounts before removing old paths.
Restrict hybrid agents (months 2 to 3): Apply local agent restrictions on Tier 0 servers, narrow cloud roles that can act on hybrid machines, and pilot on a non critical server group before wider rollout.
Segment connectivity (months 2 to 6): Replace broad route advertisements with application flows, add filtering on both sides, and enable flow logs. Roll out per application with a documented rollback (the previous rule set) for each change.
Unify baselines and logging (months 4 to 9): Publish one baseline per platform, enforce on both sides, and bring both log sets into one detection platform.
Exercise (yearly): Run a scenario in which the domain is compromised and confirm that the cloud tenant stays under control.

Decision guidance: A small organisation with a single directory and few servers gains most from cloud only admins, Entra Connect hardening and a single VPN with tight filtering. A large enterprise with multiple providers, private circuits and on site cloud hardware needs a formal Tier 0 boundary that includes hybrid bridges, a central hub for inspection, and a single owner for cross boundary policy. Where regulation or latency keeps workloads on premises, prefer hybrid management through scoped agents over opening inbound management ports.

Detection and measurement

Identity signals: sign ins by sync accounts from hosts other than the sync server, new federated domains or federation setting changes, privileged role assignment to synchronised accounts, password resets on accounts with cloud admin roles.
Agent signals: extensions installed on hybrid servers, run command use, role assignments at subscription or project level that cover Tier 0 servers.
Network signals: new flows across the boundary, traffic to management endpoints from unexpected sources, changes to route tables and VPN configuration.

Metric	Target
Privileged cloud roles held by synchronised accounts	Zero
Cloud admin accounts with phishing-resistant MFA	100%
Hybrid bridges (sync, federation, agents on Tier 0) managed under Tier 0 controls	100%
Cross boundary flows covered by an approved flow register entry	Above 95%, rising
Servers on both sides reporting compliance against the common baseline	Above 95%

Framework mapping

Hybrid control	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ATT&CK addressed
Sync and federation hardening, cloud only admins	PR.AA-01, PR.AA-05	AC-2, AC-6, IA-2	T1078.004, T1606.002, T1484.002
Boundary filtering and encryption of links	PR.IR-01, PR.DS-02	SC-7, SC-8	T1199
Hybrid agent scoping and baselines	PR.PS-01	CM-2, CM-6	T1021.007
Key management across sides	PR.DS-02	SC-12	T1003
Unified monitoring	DE.CM-03, DE.CM-09	AU-6	All of the above
Inventory of bridges	ID.AM-02	CM-8	All of the above

Common failure patterns

Sync server treated as an ordinary member server: Patched and administered like any application server, so domain compromise reaches it quickly.
Domain admins with cloud Global Administrator roles: One synchronised account controls both sides, often without MFA on the cloud side, as in the Storm-0501 intrusions.
Federation changes go unnoticed: A new federated domain or token signing change is not alerted, giving an attacker a sign in path that bypasses MFA.
Full mesh routing: The entire on premises range is advertised to the cloud and the reverse, so a single compromised VM can reach domain controllers.
Broad subscription or project roles over hybrid servers: Contributors who were never meant to administer domain controllers can run commands on them through the hybrid agent.
Two logging silos: On premises and cloud logs land in different tools, so a cross boundary attack is never correlated.

Practitioner checklist

Inventory every hybrid bridge (sync, federation, VPN, private circuit, hybrid agent, on site cloud hardware, MSP access) with an owner.
Classify directory sync and federation servers as Tier 0 and apply PAW, LAPS, NTLM restriction and restricted admin groups.
Use cloud only administrator accounts with phishing-resistant MFA and remove privileged cloud roles from synchronised accounts.
Turn off soft matching and hard match takeover where not needed, and alert on federation configuration changes.
Plan the Entra Connect upgrade and application based authentication before the April 2027 date Microsoft has published.
Apply local agent restrictions on Tier 0 hybrid servers and scope cloud roles that can act on them.
Route only approved application flows across the boundary, filter both sides and log flows.
Enforce one security baseline per platform on both sides and send both log sets to one SIEM.
Exercise a domain compromise scenario and confirm the cloud tenant remains under control.

Hybrid Cloud Security: Secure the Links Between On Premises and Cloud