Fragmented Trust in Hybrid Identity Estates: Unifying Control Across AD, Cloud and SaaS
Table of Contents
- 0. Document Intent and Audience
- 1. Executive Abstract
- 2. The Reality of Hybrid Identity Fragmentation
- 3. Structural Failure Modes in Hybrid Identity
- 4. The Identity Mesh: A Reference Architecture
- 5. Federated Trust Modelling
- 6. Policy Convergence Patterns
- 7. Detection Engineering Across Domains
- 8. Governance Integration
- 9. Implementation Roadmap
- 10. Common Objections
- 11. IdentityFirst Position
- 12. Conclusion
0. Document Intent and Audience
This paper is written for:
- IAM and security architects
- Cloud platform engineers
- Enterprise architecture leads
- Identity and access management programme directors
- Hybrid and multi-cloud security teams
It examines the structural risk introduced by fragmented identity estates — where organisations operate across Active Directory, Microsoft Entra ID, AWS IAM, GCP IAM, and hundreds of SaaS platforms — without unified trust modelling, policy consistency, or coordinated governance.
1. Executive Abstract
Modern enterprises no longer operate from a single identity directory.
A typical organisation runs:
- Active Directory for on-premises authentication and group policy
- Microsoft Entra ID for Microsoft cloud and hybrid identity
- AWS IAM for Amazon Web Services identity and access
- GCP IAM for Google Cloud Platform identity
- Okta, Auth0, or other IdPs for SaaS application federation
- Direct SaaS identity stores for applications with independent user directories
This fragmentation creates:
- Inconsistent policy enforcement — a user may be restricted in AD but unrestricted in AWS
- Invisible trust relationships — OAuth grants, cross-account roles, and federation trusts are not visible across domains
- Privilege asymmetry — a compromised identity in one domain may grant access to resources in another
- Detection blindness — identity events in one domain may not correlate with behaviour in another
- Governance gaps — access reviews rarely span all identity domains simultaneously
2. The Reality of Hybrid Identity Fragmentation
2.1 What Fragmentation Looks Like
| Identity Domain | Primary Use Case | Authentication | Authorisation |
|---|---|---|---|
| Active Directory | On-prem apps, endpoints | Kerberos, NTLM | Group-based |
| Microsoft Entra ID | Microsoft 365, cloud apps | OAuth, OIDC, SAML | Role-based, claims |
| AWS IAM | Cloud infrastructure | Access keys, roles | IAM policies, SCPs |
| GCP IAM | Google Cloud | Service accounts, WIF | IAM policies |
2.2 Why Fragmentation Exists
Organisations do not choose fragmentation — it emerges from:
- Merger and acquisition — acquired companies bring their own IdPs
- Shadow IT — business units adopt SaaS without IT governance
- Multi-cloud strategy — business requirement for AWS, Azure, GCP
- Legacy on-prem — AD cannot be replaced overnight
- Vendor lock-in — SaaS platforms with proprietary identity models
2.3 The Security Consequence
3. Structural Failure Modes in Hybrid Identity
3.1 Policy Inconsistency
Scenario: An organisation enforces MFA in Entra ID but not in AWS IAM.
Risk: An attacker who obtains AWS credentials can bypass MFA requirements entirely.
3.2 Cross-Domain Trust Exploitation
Scenario: AWS role trust policy permits assumption from any principal in the organisations Entra ID tenant.
Risk: If Entra ID is compromised, the attacker can assume any AWS role with that trust relationship.
3.3 Privilege Accumulation Across Domains
Scenario: A user has standard user in AD, Global Administrator in Entra ID, Read-only in AWS, Admin in SaaS.
Risk: No single identity review captures the aggregate privilege.
4. The Identity Mesh: A Reference Architecture
4.1 Core Principles
- Federated Governance, Not Consolidation — Each identity domain maintains its native architecture. The mesh provides a governance overlay.
- Unified Inventory — All identity subjects across all domains are inventoried with unique correlation.
- Policy Harmonisation — Define a baseline policy that maps to each domain's native enforcement mechanism.
- Telemetry Normalisation — Collect, normalise, and correlate identity events from all domains.
- Coordinated Response — Enable coordinated containment actions across domains.
4.2 Architectural Layers
Identity Mesh Layer
Unified Inventory · Policy Harmoniser · Centralised Telemetry
Policy Orchestration
AD Connector · Cloud IAM Connectors · SaaS / Federation Connectors
Identity Domains
AD · Entra ID · AWS IAM · GCP IAM · Okta · SaaS Native
5. Federated Trust Modelling
5.1 The Identity Graph Across Domains
Build a graph that represents trust relationships across all identity domains:
- Nodes: Identities (human, service, workload), resources, applications
- Edges: Membership, role assignment, OAuth grant, federation trust, cross-account role assumption
From this graph, compute:
- Effective privilege — aggregate permissions across all domains
- Attack paths — paths from a compromised identity to crown-jewel resources
- Trust chain risk — transitive trust that creates unexpected access
5.2 Cross-Domain Trust Risks
| Trust Pattern | Risk | Mitigation |
|---|---|---|
| Entra ID → AWS (role federation) | Compromised Entra ID grants AWS access | Enforce conditional access on role assumption |
| AWS → Entra ID (SAML federation) | Compromised AWS can access Entra ID | Restrict SAML audience, monitor attributes |
| SaaS → Entra ID (OAuth) | Token theft provides SaaS access | Short token lifetimes, monitor usage |
6. Policy Convergence Patterns
6.1 Authentication Baseline
Define a unified authentication standard:
- MFA required for all human identities with access to sensitive resources
- MFA required for all privileged identities regardless of resource
- Session lifetime limits enforced consistently
- Re-authentication required for high-risk operations
6.2 Authorisation Baseline
- Least privilege by default
- Role assignments require business justification
- Privileged access is time-bound (JIT)
- Access reviews conducted at defined frequency
7. Detection Engineering Across Domains
7.1 Unified Detection Requirements
Detection must correlate events across domains to identify attacks that span identity boundaries.
| Stage | Cross-Domain Signal |
|---|---|
| Initial access | Login in AD followed by login in Entra ID from same session |
| Privilege discovery | Enumeration in AD followed by role query in AWS |
| Privilege escalation | Admin role granted in Entra ID followed by AWS key creation |
| Lateral movement | Access to SaaS via Entra ID token followed by API call to AWS |
8. Governance Integration
8.1 Unified Access Review
Access certification must span all identity domains:
- Identify identity
- Retrieve all entitlements across domains
- Present aggregate view to reviewer
- Capture review decision (approve, revoke, modify)
- Execute domain-specific revocation where approved
8.2 SoD Conflict Detection Across Domains
Segregation of duties violations often span domains:
- Finance system access in SaaS + Database access in AWS
- HR system access in Entra ID + Payroll modification in on-prem
9. Implementation Roadmap
| Phase | Timeline | Key Activities |
|---|---|---|
| Phase 1: Discovery and Inventory | 0–3 months | Deploy connectors, build unified inventory, map trusts |
| Phase 2: Policy Harmonisation | 3–6 months | Define global policy, map to domain enforcement |
| Phase 3: Unified Detection | 6–9 months | Deploy telemetry pipeline, implement correlation rules |
| Phase 4: Governance Unification | 9–12 months | Implement unified access review, deploy SoD detection |
10. Common Objections
"We already have a directory."
Having a directory does not provide cross-domain visibility. Entra ID does not see AWS IAM permissions.
"Each domain has its own security team."
Security teams may own domains, but the organisation needs unified governance.
"Consolidation is the answer."
Consolidation is one option, but often impractical. Most enterprises will remain hybrid for years.
11. IdentityFirst Position
Fragmentation is the default state of modern enterprise identity.
Organisations do not choose hybrid identity — they inherit it through business requirements, M&A, cloud adoption, and SaaS proliferation.
IdentityFirst architecture addresses this reality through:
- Federated governance overlay (not replacement)
- Unified identity inventory
- Policy harmonisation across domains
- Normalised telemetry and correlation
- Coordinated response capability
12. Conclusion
Hybrid identity fragmentation is not a problem to be solved — it is a condition to be managed.
The security consequence is real:
- Inconsistent security controls
- Invisible attack paths
- Undetected privilege abuse
- Fragmented governance
The identity mesh provides a practical path:
- Visibility without consolidation
- Governance without disruption
- Detection without duplication
- Response without complexity