Hybrid identity, fragmented security: How identity estates fuel modern breaches

In this article, I will cover why hybrid identities can lead to fragmented security and reduced visibility when strong security posture practices are not consistently applied. Many organisations place an excessive amount of trust in identity providers and synchronisation features, assuming these features will deliver a consistent security posture across domains. In reality, this over-reliance hides critical security risks most don’t even anticipate.

This article aims to provide a broader overview of the hybrid identity stack, the ‘hidden’ attack surface surrounding it, and strategic security posture recommendations for your environment:

• An overview of a typical hybrid identity stack.
• The 'hidden' attack surface identity silos bring.
• A real-world example of an adversary group leveraging hybrid environments as part of the 'identity kill chain'.
• Strategic recommendations for strengthening hybrid identity security posture.

Throughout, I will mostly refer to Microsoft Entra and general Azure products. 

Introduction

Identity risk is more critical than ever in the evolving threat landscape; according to 2026 Unit 42 Global Incident Response Report - Palo Alto Networks, "Identity has become the most reliable path to attacker success. Identity weaknesses played a material role in almost 90% of our investigations." This is a staggering amount that should continue to be emphasised.

Many of these identity-related tasks are at the hands of attackers exploiting what is known as 'fragmented identity estates', this is effectively where different authentication methods are managed separately across an organisations' infrastructure, leading to a lack of unified identity management. These separate ways of managing authentication methods and systems are known as 'identity silos' as they are separated and, in most cases, have entirely different architecture from one another.

As you can imagine, if security posture is not standardised or kept updated across different systems, then the risk factor massively increases – many companies neglect this and rely heavily on identity provider services (e.g. Entra Cloud Sync) to sync and manage identities across on-premise environments and the cloud.

Although services like this can be effective at reducing fragmentation, they do not eliminate it if the basics are not followed to begin with. Alternatively, hybrid identity stops what is known as 'security drift', not fragmented estates – this is the idea that the system’s configuration deviates from its intended state over time.

In other words, hybrid identity in theory fixes credential fragmentation and the 'single point of failure' (SPOF) aspect but creates architectural fragmentation, as a result this can create credential fragmentation regardless.

The hybrid identity stack: Where fragmentation begins

Hybrid identity brings together systems that were never built to share a unified security model. Even when identities synchronise cleanly between on‑premise Active Directory (AD) and Microsoft Entra ID, each layer continues to enforce its own authentication logic, privileges, and risk evaluation. This is where architectural fragmentation begins.

Active Directory Domain Services (ADDS) – On-premise identity:

• AD access controls – AD still relies on traditional access control mechanisms (UACs, security groups and NTLM authentication) which operate independently from Entra’s conditional access and risk-based policies. Although Entra provides modern services like 'Microsoft Entra Kerberos', it is challenging to directly map this to cloud-based conditional access policies. This is especially the case in cross-tenant environments where Kerberos isn’t supported. The result is more opportunity for misalignment.
• Group memberships – AD group logic is inherently static so if identity synchronisation to Entra isn’t continuous or is deployed incorrectly, then several downstream services in the cloud may inherit privileges unintentionally (e.g. SharePoint access). This privilege drift between AD groups and cloud roles is a common cause of privilege escalation techniques in hybrid environments.
• Microsoft Defender for Identity – This offers strong detection for on‑premise AD attacks, but it does not enforce cloud policy or automatically orchestrate remediation across Entra. Administrators must interpret and act on alerts manually, so without consistent cross-domain monitoring, this creates visibility gaps. However, Microsoft Defender for Identity XDR alerts have helped a lot to allow for maximum visibility across on-prem AD, and new capabilities are constantly added.
  

Cloud identity(Microsoft Entra ID):

• Entra ID protection – Risk based signalling (both risky users and risky sign-ins) can apply to synced AD identities (on-premise activity) which can lead to the user’s cloud sign-in to be blocked if malicious activity were to be detected (e.g. Microsoft 365), which can help prevent lateral movement. However, will not help in blocking on-premises Kerberos/NTLM authentication as it can’t see this by design. Which is where Defender for Identity's on-premise remediation actions come in – without these in place the user blocked in the cloud may still authenticate on-premise without restrictions.
• Conditional access policies – They govern cloud authentication only, meaning the user can be blocked in Entra while still free to authenticate on-premise. Although as an example, Microsoft now encourages extending conditional access to on-premise apps, by publishing them through 'Microsoft Entra Application Proxy', which moves the authentication enforcement point to the cloud – thus reducing dependency on AD legacy authentication stacks.
• Managed identities and service principals – Cloud-native identities that have no equivalent in AD. They follow their own lifecycle, permissions model, and authentication standards.
• Privileged Identity Management (PIM) – PIM can provide just-in-time (JIT) access (time-based authentication) for Entra roles and some AD groups through group writeback, but the enforcement split remains: Any changes made to the user in AD will sync to the cloud and can unintentionally expand the user’s effective permissions if not monitored – it can’t directly override on-prem privilege logic. Important distinction: PIM-eligible groups + Entra Cloud Sync writeback allow Entra to control membership of an on-prem AD group, however PIM does not control how AD enforces that membership.

Hybrid identity simply means Microsoft Entra ID acts as a bridge, not a unified identity security model. Services like 'Entra Cloud Sync' synchronise identity data, but do not replace on-premise AD security responsibilities. Cloud Sync typically synchronises users from on premises to the cloud, meaning local AD security policies (e.g. GPOs, RDP restrictions) must still be managed with additional security tools like Microsoft Defender for Identity.

This is perfectly demonstrated with Microsoft’s 'shared responsibility model' which emphasises the responsibilities you always retain, regardless of how identities are synchronised – data, endpoints, accounts and access management.

Identity silos: The hidden attack surface

As discussed earlier, hybrid identity deployments naturally introduce silos between on‑prem AD, cloud identity, and additional identity providers, and these silos quickly become blind spots attackers can exploit.

As organisations continue to adopt SaaS workflows that often sit outside centralised governance, which can often lead to careless mistakes – "Unit 42 analysis of more than 680,000 identities across cloud accounts found that 99% of cloud users, roles, and services had excessive permissions, some unused for 60 days or more" – this level of misalignment allows for easy elevated cloud access with minimal resistance in most cases.

Furthermore, along with identity silos often comes the issue of shadow identities (e.g. unapproved SaaS application that employees have signed up for with broad access to corporate data), that again usually authenticate through different identity providers (a common one is Okta), this is basically just a fragmentation multiplier, given that many applications inherently come with elevated permissions making them a desirable target for attackers. If not deployed or managed correctly, every new SaaS integration effectively becomes another mini-identity silo (another token issuer, another privilege set and more blind spots in your environment).

Both points emphasise that identity silos don’t just create visibility gaps in an organisation’s infrastructure, they also widen an organisation's exposure to supply chain attacks. Supply chain attacks occur when the adversary targets and compromises a trusted vendor, instead of compromising the organisation directly. A good example of this would be adversaries injecting malicious code into your trusted third-party applications / software providers in the cloud.

A combination of not knowing what your third-party software does, what permissions they own due to excessive identity stores / federated configurations or in the case of shadow identities where they’re unapproved altogether is what makes your environment susceptible to these attacks.

Anomalous SaaS activity detection can be challenging, especially in environments with fragmented identity controls. There are tools out there such as CrowdStrike Falcon Shield and Microsoft Defender for Cloud Apps which can help in detecting suspicious activity against your SaaS applications, but only when integrated into a broader, unified governance strategy.

The hybrid identity kill chain: A deep dive into Storm-0501's recent campaigns and the cost of fragmented identity deployment

Storm-0501 is a clear example of how attackers exploit fragmented identity estates in real-world hybrid environments. They are known to take advantage of visibility gaps across the compromised environment and frequently pivot from on-prem AD to the cloud.

"In a recent campaign, Storm-0501 compromised a large enterprise composed of multiple subsidiaries, each operating its own AD domain. These domains are interconnected through domain trust relationships, enabling cross-domain authentication and resource access."

"Notably, only one tenant had Microsoft Defender for Endpoint deployed, and devices from multiple Active Directory domains were onboarded to this single tenant’s licence – this fragmented deployment created visibility gaps across the environment. In some cases, a single domain was synced to more than one tenant, further complicating identity management and monitoring."

Source: Microsoft Threat Intelligence

Here lies the problem, if hybrid identity isn’t deployed correctly or consistently these controls can increase the attack surface of an organisation – just because identities are synchronised and the deployment is designed to be efficient, doesn’t mean the security is effective.

Even strong identity practices such as federated trust, SSO, and SCIM provisioning cannot compensate for fragmented architecture (e.g. cross-tenant inconsistencies). These trust related components can only make it easier for the attacker to pivot your environment if there are misaligned baselines, which is exactly what groups like Storm-0501 actively look to exploit.

If you want to look more into Storm-0501's TTPs, to get more of an idea about pivoting techniques in hybrid environments, they can be found here.

Storm‑0501’s behaviour aligns with broader trends in hybrid identity attacks. Attack techniques such as 'DCSync', which allows attackers to impersonate a Domain Controller and extract NTLM hashes/Kerberos secrets, and Golden SAML, where attackers forge cloud authentication tokens using stolen private keys from federated environments (AD FS), demonstrate how identity silos and fragmented trust boundaries can be weaponised.

De-fragmenting the identity estates: Strategic recommendations

1. Strengthening on-premises AD security: 

Visibility and endpoint protection

Visibility is everything when you have large identity estates, so protecting and actively monitoring endpoints is key – tamper protection features can prevent threat actors from stopping Endpoint Detection and Response (EDR) tools (e.g. Microsoft Defender for Endpoint) – an example would be utilising Attack Surface Reduction (ASR) rules.

 Reduce legacy AD 'tech debt'

Ensure full transition from what is known as 'legacy AD tech debt' (e.g. outdated domain controllers and protocols) which in short emphasises that on premises must be kept up-to-date even if using hybrid identities managed via the cloud. Typically, companies will prioritise new features and identity providers (e.g. Entra ID) over fixing legacy (old) identity controls – the detection and mitigation capabilities are undoubtably better with the modern providers; however, this does NOT mean that the attack surface will reduce just because the legacy environment is being ‘managed’ from elsewhere.

Examples of AD hardening include:

• • • Migrating away from NTLM authentication – From NTLM to Kerberos.
    • Deprecating unsupported/old forest and domain functional levels (these are effectively the supporting features for each OS/version release of domain controllers (DCs)) – if not supported/updated they can create hidden vulnerabilities.
    • Hardening vulnerable AD CS (certificate services admin role within AD) deployments to mitigate several attack vectors.
      

2. Securing cloud identity and access:

Decoupling cloud privilege from AD risk

Global admin and privileged groups should be cloud-native accounts – "if your on-premise account is compromised, it can compromise your Microsoft Entra resources as well."

Utilise authentication strengths

Organisations should utilise 'conditional access authentication strengths' which specifies which combinations of authentication methods users can use to access a resource. A good example to use this would be if a user takes a sensitive action within an application; you could prompt them to use only phishing-resistant authentication methods which enforces zero-trust principles. FIDO2-based authentication is a strong option because it uses public-key cryptography rather than shared secrets like passwords. The service stores only a public key, whilst the corresponding private key is generated on the user's device, kept within a hardware-backed secure enclave, and never transmitted. This eliminates server-side credential theft and, because credentials are cryptographically bound to a specific origin, makes the authentication process inherently resistant to phishing.

Mitigate the 'valid accounts' gap

A common lateral movement and privilege escalation technique utilised by adversaries is 'valid accounts' which comes from weak password policies and legacy authentication (which does not support MFA). Passwords should be long, complex, and unique for all accounts, MFA should be enforced and the principle of ‘least privilege’ should be applied across the identity estate.

3. Preventing identity drift across hybrid environments

Across both environments, a critical concern is 'identity drift' which is where access controls and policies gradually erode in effectiveness over time – this drift quietly accumulates security gaps and quickly leads to misalignments between:

• • AD GPOs (Group Policy Objects) and Entra roles.
  • Conditional access and on-prem authentication. (Modern solutions such as 'Microsoft Entra Kerberos' as discussed earlier can help).
  • Multi-tenant or multi-domain monitoring boundaries.
  • Cloud-only account/hybrid account permissions.

The idea of this emphasises the importance of a unified approach to compliance and cyber security – "by implementing integrated compliance frameworks to ensure resilience, data integrity and sustainability".

Conclusive thoughts

The organisations that will thrive in hybrid identity ecosystems are those that treat identity as a unified security surface, not a collection of disconnected services.

Hybrid identity is no longer a transitional state; it is the default architecture for modern enterprises. But as this article has shown, combining on‑premise Active Directory, Microsoft Entra ID, SaaS ecosystems, and multi‑cloud environments creates two parallel identity worlds that rarely behave as one. Even when identities synchronise seamlessly, their authentication paths, privilege models, policy engines, and risk signals remain fundamentally separate.

The truth is that hybrid identity only works when hybrid security is intentional. Technologies such as conditional access, privileged identity management, Defender for Identity, Entra ID Protection, and hybrid-joined devices are enormously valuable in the context of the Entra ID provider, but they are not substitutes for governance. They are only effective when deployed consistently, monitored continuously, and aligned across every identity ecosystem rather than applied in isolation. Attackers don’t need you to misconfigure Entra or AD, they just need the gap between the two systems.

The future of hybrid identity security

Recently, we have already started to see a shift in hybrid identity and federation security, with Microsoft announcing that compromised users in AWS (both federated and IAM users) can be automatically disrupted in Microsoft Sentinel, along with Proofpoint and Okta – effectively allowing for the revoking of sessions by default and thus minimising business impact whilst lowering operational complexity.

This marks a major shift towards cross-provider detection and remediation all in one place, which is something hybrid environments have historically lacked. With this, organisations can begin to close the security gaps created by isolated identity estates.

Key takeaways:

• Hybrid identities and synchronisation features unify accounts (e.g. reduce credential fragmentation), but not security models (e.g. authentication logic or risk evaluation). Remember the 'shared responsibility model' – you are responsible for securing users, accounts and access.
• Attackers increasingly hunt and exploit architectural 'blind spots' in hybrid environments, often resulting in privileged lateral movement capabilities.
• Shadow identities in the cloud are arguably the biggest threat to your environment, they create 'identity silos' by nature.
• Identity security is almost always a 'posture' problem, not a tooling or provider problem – synchronised features are only useful when consistently deployed and monitored.
• Continuous cross-domain checks are essential for ensuring consistent 'least privilege' (e.g. checking SaaS applications have correct permissions in a federated environment). If a user needs elevated permissions for something, apply just-in-time (JIT) access, always.