How to Manage Identity Lifecycle in a Hybrid IT Environment

Why Hybrid Environments Add Identity Complexity

Hybrid IT environments — where on-premises infrastructure and cloud services coexist — are the reality for the vast majority of enterprises. The appeal of a fully cloud-native identity model is real, but most organizations carry years or decades of investment in on-premises Active Directory, line-of-business applications that cannot be moved to the cloud, and infrastructure that requires Kerberos or NTLM authentication. Meanwhile, the SaaS ecosystem, Azure, Microsoft 365, and cloud-native development tooling push hard in the other direction. The result is an identity landscape split across two paradigms with different protocols, different management planes, and different security models.

Managing the identity lifecycle — the joiner, mover, and leaver events that govern who has access to what — becomes significantly harder when identities must exist in both worlds simultaneously. A new hire needs to authenticate to both an on-premises file server and an Azure-hosted application. A mover's access must be updated in Active Directory group memberships and in cloud application role assignments. A leaver's account must be disabled in both environments immediately and completely. When these environments are not synchronized properly, lifecycle events create gaps: access that is revoked in one system but not the other, or identities that exist in the cloud but have no corresponding on-premises record, or vice versa.

This article works through the architectural and operational decisions that enable reliable identity lifecycle management in a hybrid environment. The core principle throughout is that hybrid complexity should be managed by establishing clear authority and letting synchronization do the heavy lifting — not by maintaining two separate, manually coordinated identity programs.

Establishing a Single Authoritative Identity Source

The most important architectural decision in hybrid identity management is choosing which system owns the authoritative record for each identity attribute. In most enterprises, the HRIS (Workday, SAP SuccessFactors, BambooHR, or similar) is the authoritative source for workforce data: legal name, employee ID, hire date, job title, department, manager, and departure date. Active Directory is typically the authoritative source for the technical identity: UPN, SamAccountName, group memberships, and password hash. Azure AD / Entra ID derives its identity from Active Directory via synchronization rather than maintaining an independent source of truth.

This HRIS → AD → Entra ID chain is the most common authority model and, when properly implemented, the most maintainable. Changes originate in the HRIS, flow to Active Directory (either via an IGA platform or a direct SCIM/API integration), and then propagate to Entra ID via Azure AD Connect. The key discipline is enforcing this direction: changes to identity attributes should never originate in Active Directory or Entra ID if they should properly be sourced from the HRIS. "Write-back" scenarios — where cloud changes propagate back to on-premises — should be limited to attributes that have no on-premises authority, such as Entra ID-specific settings or cloud-only application role assignments.

Establishing authority also means identifying exceptions: service accounts, shared mailboxes, administrative accounts, and non-employee identities (contractors, vendors, partners) that do not have HRIS records. These identities need their own lifecycle governance — typically through the IGA platform or an identity request workflow — with clear ownership, expiration policies, and periodic review requirements. Treating exceptions as second-class citizens in the identity program is a common failure mode; organizations should invest in a non-employee identity management process that is as rigorous as the employee identity process.

Azure AD Connect: Configuration and Synchronization

Azure AD Connect (now part of Microsoft Entra Connect) is the synchronization engine that bridges on-premises Active Directory and Entra ID for most Microsoft-centric hybrid organizations. Configuring it correctly is foundational to hybrid lifecycle management. The synchronization scope — which OUs and objects are synchronized to the cloud — should be deliberately defined. Not every on-premises account should be cloud-synchronized: service accounts, legacy system accounts, and some administrative accounts may be intentionally on-premises-only. Filtering the synchronization scope prevents on-premises clutter from polluting the cloud directory.

Synchronization latency is a lifecycle concern. The default Azure AD Connect synchronization cycle runs every 30 minutes. For joiner events, this means a new hire's cloud identity may not exist for up to 30 minutes after the on-premises account is created. For leaver events, it means a disabled on-premises account may remain active in Entra ID for up to 30 minutes — long enough for an ongoing session to persist, especially if conditional access token lifetimes are not tuned. Organizations with high sensitivity to leaver timing should either force a manual sync as part of the offboarding workflow or configure delta synchronization triggers that push changes immediately.

Password hash synchronization (PHS) or pass-through authentication (PTA) determines how cloud authentication relates to on-premises credentials. PHS copies a hash of the password hash to Entra ID, allowing cloud authentication to succeed even if the on-premises environment is unavailable. PTA forwards authentication requests to on-premises domain controllers in real time — simpler in some respects but dependent on on-premises availability. For lifecycle management, PHS has an important property: when an on-premises account is disabled, the next PHS synchronization cycle ensures that cloud authentication fails for the same credentials, providing an additional layer of enforcement beyond just disabling the Entra ID account.

Authentication Protocols Across the Hybrid Boundary

Hybrid environments must support multiple authentication protocols simultaneously, each with different security characteristics and lifecycle implications. On-premises resources typically rely on Kerberos for Windows-integrated authentication and NTLM as a fallback. These protocols are tied to Active Directory and do not extend naturally to the cloud — they require either Active Directory Federation Services (AD FS) or Entra ID's hybrid join capabilities to bridge the boundary. Kerberos tickets and NTLM sessions can persist after an account is disabled if the client has a cached token, which is why account disablement alone is not sufficient for high-risk leaver scenarios: force-signing out active sessions and revoking cached credentials requires additional steps.

Cloud-native applications use SAML 2.0 or OpenID Connect (OIDC) for authentication, with OAuth 2.0 for authorization. These protocols are token-based: when a user authenticates, they receive a token with a defined lifetime. Access tokens typically have short lifetimes (one hour or less), but refresh tokens can persist for days or weeks. When a leaver's account is disabled in Entra ID, existing access tokens remain valid until they expire — the application will only see the account as disabled when the token is refreshed. Organizations that need immediate access termination for high-sensitivity applications must implement continuous access evaluation (CAE), a feature in Entra ID that allows applications to be notified of account state changes in near real time and revoke sessions accordingly.

Application proxies and legacy authentication protocols present a specific challenge. Applications that use basic authentication, LDAP bind, or other legacy protocols do not participate in token-based authentication and cannot enforce modern conditional access policies. These applications authenticate directly against the directory with a password, meaning that session termination requires disabling the account — there is no token to revoke. Identifying which applications in the environment rely on legacy authentication is a critical audit step for hybrid lifecycle management, and migrating them to modern protocols should be a priority roadmap item.

Managing Devices Across On-Premises and Cloud

Device identity is a dimension of the lifecycle that is easy to overlook but increasingly important. In a hybrid environment, devices may be domain-joined (managed by Group Policy), Entra ID-joined (managed by Intune), or hybrid-joined (both). The device management approach affects how lifecycle events play out: a domain-joined device can enforce on-premises policies and certificate-based authentication but may not be visible to cloud conditional access policies unless it is also hybrid-joined. A device that is only Entra ID-joined cannot authenticate to on-premises resources using Kerberos without additional configuration.

When an employee leaves, their assigned device must be handled as part of the offboarding workflow. If the device is in the field — with a remote worker, on loan, or unrecovered — it must be remotely wiped or at minimum have its management certificate revoked. Conditional access policies that require compliant or hybrid-joined devices provide a layer of defense: if the device falls out of compliance after the account is disabled, it will be blocked from accessing cloud resources even if somehow the credentials are still functional. BitLocker key escrow ensures that the device's data can be recovered or confirmed destroyed even if the device is not physically returned.

Group Policy vs. Intune for device management in hybrid fleets is a longstanding tension. Group Policy is mature, powerful, and deeply integrated with Active Directory, but it requires line-of-sight to a domain controller to apply policies — meaning remote or cloud-only scenarios are underserved. Intune provides cloud-native device management that works anywhere with internet access, supporting both Windows and non-Windows platforms. The pragmatic hybrid approach is to maintain GPO for on-premises resources that require it while progressively migrating device management to Intune, with the goal of eventually managing all devices from the cloud plane so that lifecycle events propagate to device policy without dependency on VPN or on-premises connectivity.

Identity Lifecycle Events in the Hybrid Context

Each lifecycle event — joiner, mover, leaver — has hybrid-specific considerations that pure cloud or pure on-premises environments do not face. For joiners, the provisioning workflow must create both an on-premises Active Directory account and ensure it synchronizes to Entra ID before the employee's start date. The timing window matters: if the on-premises account is created one day before the start date but Azure AD Connect has not run, the employee will not be able to authenticate to cloud applications on day one. Workflows should build in a sync trigger or a wait-and-verify step after account creation.

For movers, access changes may need to be made in both environments: group membership changes in Active Directory affect on-premises resource access, while Entra ID application role assignments and license changes affect cloud access. If the IGA platform has connectors to both environments, it can orchestrate the full mover workflow from a single trigger. Without an IGA platform, mover workflows require coordination between the AD team and the cloud team — a manual handoff that is slow and error-prone. The mover event is also the most common source of hybrid synchronization inconsistency: changes made on one side without corresponding changes on the other.

The leaver event is where hybrid complexity poses the most risk. The safest approach is to disable the account in Active Directory first — which triggers propagation to Entra ID via Azure AD Connect — and then also directly disable the Entra ID account to eliminate the synchronization latency window. Revoke refresh tokens in Entra ID explicitly using PowerShell or the Entra ID portal. Remove the user from all Exchange distribution groups and Teams memberships. Disable any active VPN certificates or device management enrollments. Each of these steps addresses a different access vector, and only completing all of them provides full offboarding assurance in a hybrid environment.

Planning for Cloud Consolidation

Most hybrid environments are hybrid by necessity rather than by design — the on-premises infrastructure exists because of legacy applications, compliance requirements, or prior investment, not because the organization prefers managing two identity planes. The strategic direction for most organizations is toward cloud-native identity, with on-premises systems either decommissioned or relegated to a supporting role. Identity lifecycle programs should be designed with this trajectory in mind: investments in IGA integrations, SSO federation, and device management should favor the cloud-native path. Where some workloads will stay on-premises for good, a deliberate hybrid cloud strategy decides which ones and why.

Practically, this means identifying the on-premises dependencies that are blocking cloud consolidation. Legacy applications that require Kerberos authentication are candidates for application modernization or legacy app proxying. File servers and print servers can often be replaced with SharePoint, OneDrive, and cloud print services. Domain controllers can be progressively decommissioned during a migration from on-premises Active Directory to Entra ID as the last Kerberos-dependent workloads are migrated. The identity lifecycle program should track these dependencies explicitly and update the hybrid architecture as they are resolved, moving toward a state where the synchronization layer is no longer needed and Entra ID stands alone as the authoritative identity store.

Conclusion

Managing identity lifecycle in a hybrid environment requires more deliberate architecture than either a pure on-premises or pure cloud program. The key principles — single authority, synchronization discipline, protocol awareness, and event-driven automation — apply regardless of the specific technology stack, but the implementation details matter enormously. Organizations that invest in getting the HRIS-to-AD-to-Entra ID chain right, configuring synchronization for minimal latency, and building leaver workflows that address both environments simultaneously will find that their hybrid identity program is resilient rather than brittle. Monitoring that surfaces synchronization failures before they become security gaps belongs in that foundation too.

The hybrid state is temporary for most organizations. Every cloud migration, every legacy application decommissioning, and every device management modernization project moves the needle toward the simpler, more maintainable cloud-native model. The identity lifecycle program should be a driver of that consolidation, not an obstacle to it — using lifecycle events as opportunities to migrate users and workloads toward the cloud-native path rather than simply replicating the on-premises pattern in the cloud. The discipline built during the hybrid period, from reliable HRIS integration to comprehensive deprovisioning, carries directly into the cloud-native environment that follows.

Bridging Hybrid Identity with ezOnboard

Hybrid environments multiply the complexity of identity lifecycle events—a single new hire may require an account in on-premises Active Directory, a synchronized identity and licenses in Microsoft Entra ID, and an Exchange mailbox, all of which need to be provisioned consistently and in the right sequence. ezOnboard handles this by syncing your HR system to Active Directory, Entra ID, and Exchange, applying the right provisioning actions in each based on the employee’s role and location. Your hybrid directory stays consistent with HR.

Frequently Asked Questions

What is hybrid identity and how is it different from cloud-only identity?

Hybrid identity refers to an architecture where user identities exist in both on-premises directory services (typically Active Directory) and cloud-based identity platforms (typically Microsoft Entra ID), synchronized between the two. Cloud-only identity eliminates the on-premises directory entirely, managing all identities natively in the cloud. Most enterprises in 2026 operate in a hybrid state during their cloud transition, while organizations that never built on-premises infrastructure often deploy cloud-only from the start.

What are the biggest identity lifecycle challenges specific to hybrid environments?

The primary challenges are synchronization latency (changes in one directory take time to propagate to the other), conflicting policies (on-premises and cloud access controls that don't align), duplicate provisioning steps (new hires require account creation in multiple systems rather than one), and incomplete deprovisioning (disabling an Entra ID account without disabling the synchronized on-premises AD account, or vice versa). Each of these failure modes creates either access gaps for new employees or residual access risk for departed ones.

How does Microsoft Entra Connect affect identity lifecycle management?

Entra Connect (formerly Azure AD Connect) synchronizes identities from on-premises Active Directory to Microsoft Entra ID on a configured schedule, typically every 30 minutes. This synchronization latency means that lifecycle changes made in on-premises AD don't immediately appear in Entra ID—a consideration for time-sensitive events like emergency access revocation. Entra Connect also defines the authoritative source for each attribute: changes made directly in Entra ID for synchronized attributes may be overwritten on the next sync cycle, which causes confusion when administrators aren't aware of the synchronization direction.

Should hybrid organizations use their HRIS or their directory as the authoritative source for identity data?

The HRIS should be the system of record for workforce data—hire dates, job titles, department assignments, and reporting relationships. The directory should derive its identity data from the HRIS rather than maintaining parallel records that can diverge. When the HRIS is authoritative, a new hire record in the HRIS triggers directory account creation, and a termination in the HRIS triggers account deactivation—ensuring the directory reflects employment reality rather than requiring separate HR and IT processes that can fall out of sync.

What is the best approach for deprovisioning in a hybrid environment?

Deprovisioning in hybrid environments should be comprehensive and sequenced: disable the on-premises AD account first (which propagates to Entra ID via synchronization), then revoke active sessions in Entra ID immediately (don't wait for the sync cycle for time-sensitive departures), then work through SaaS application deprovisioning. Automating this sequence through a defined offboarding workflow prevents the partial deprovisioning that leaves active credentials in some systems while others are disabled—the most common hybrid deprovisioning failure mode.