Hybrid Identity Management: How to Centralize IGA

It's tempting to centralize identity by buying a platform, but I leave the platform for last. Below is my approach to solutioning centralized identity, followed by an example from a hybrid identity program at a 500-person financial institution.

How do you centralize identity management in a hybrid environment?

Work through five steps, and choose the platform last:

1. Discovery: build an identity inventory of every account store, directory, and identity across cloud, on-prem, and vendor-hosted systems. Interview direct stakeholders (the IAM team, the service desk) and indirect stakeholders (security operations) to capture:
   • today's problems and use cases
   • how they want to operate in the future
   • systems coming down the road
2. Current architecture: map today's components and the connections between them in an architecture diagram.
3. Requirements: turn the problems, the desired future state, and current-architecture gaps into requirements.
4. Target architecture: design the components and connections that meet those requirements.
5. Platform selection: choose the IGA platform that fits the target architecture.

The steps overlap in practice. Architecture work often identifies more requirements, typically non-functional ones, so expect to go back to earlier steps more than once.

An identity architecture breaks down into two parts:

• Components: for example, the identity provider (IdP), the identity governance and administration (IGA) platform, directories such as Active Directory, and targets such as servers, databases, and applications.
• Connections: the links between components, for example a server joined to Active Directory, a database that authenticates against the central directory, or the IdP syncing with the IGA platform.

How does a cloud IGA platform connect to on-prem systems?

A cloud IGA platform reaches on-prem systems through agents, connector servers, or a mix of both:

Examples of connector servers in common IGA platforms:

• SailPoint Identity Security Cloud: a Virtual Appliance (VA) inside your network runs the connectors to on-prem sources.
• ForgeRock Identity Cloud (now PingOne Advanced Identity Cloud): a Remote Connector Server (RCS) inside your network syncs on-prem directories and applications.

The right pattern depends on the systems you have today and the ones you plan to add. Each has pros, cons, and limitations:

• A platform may have no supported integration for some current or planned systems.
• One platform may use agents for one type of system and a connector server for another.

Discovery has to cover both current and planned systems, so these gaps show up before platform selection. More on identity design in mixed environments: on-prem and hybrid GRC guide and SOC 2 access control for on-prem environments.

What are joiner-mover-leaver (JML) requirements in identity governance?

JML requirements define what the IGA platform does at each stage of a person's time at the company. A typical set, for example:

SOC 2 auditors test these stages under CC6.2 user access provisioning and CC6.3 least-privilege role-based access, and the identity architecture itself under CC6.1 logical access security. When the design covers each stage, normal operations produce the evidence for those controls.

What requirements should a centralized identity system meet?

I group identity requirements into three types:

1. Functional: what the system is for. For identity and access management, that means provisioning, JML events, and access reviews.
2. Non-functional: how well the system runs, for example availability, reliability, compatibility, and performance.
3. Threat-functional: which threats the system must mitigate. An identity platform is also a security control, so it needs requirements against the attacks it faces. These usually come from threat modeling.

Start with industry best practices

There's no need to reinvent the wheel. Decades of trial and error have produced well-known best practices for identity security, so start with them. Common frameworks, for example:

• NIST SP 800-63B: authentication and password guidance
• CIS Controls 5 and 6: account management and access control management
• ISO 27001 Annex A: identity and access controls (A.5.15 access control, A.5.16 identity management, A.5.17 authentication information, A.5.18 access rights, and A.8.5 secure authentication)

Examples of baseline requirements from these frameworks:

• MFA for all users, and phishing-resistant MFA for administrators
• Passwords screened against breached and common password lists
• Separate privileged accounts for administrators
• Authentication events logged centrally

Then threat-model what best practices don't cover

Best practices cover the well-known identity attacks. Some newer areas don't have settled best practices yet, for example:

• AI agents and agentic service accounts
• AI-driven attacks against authentication

Threat-model these against your own system. Examples of threat-functional requirements:

Examples of non-functional requirements:

• Availability: 99.9% monthly availability for authentication services.
• Maximum tolerable downtime (MTD): authentication restored within 5 minutes of an outage.
• Redundancy: authentication keeps working if one data center or cloud region is lost.
• Performance: leaver deprovisioning completes in every target system within 1 hour of the HR termination event.
• Compatibility: a supported integration, agent or connector server, for every in-scope current system and every planned system on the roadmap.

More on how requirements fit into security architecture.

What does an identity architecture engagement deliver?

Typical deliverables, for example:

Example: centralized identity for a 500-person financial institution

Summary: choose the identity platform last

• Start with discovery: identity inventory, stakeholder needs, and planned systems.
• Map the current architecture as components and connections.
• Write functional, non-functional, and threat-functional requirements. Start from industry best practices, then threat-model newer risks such as AI agents.
• Design the target architecture to meet the requirements.
• Select the IGA platform last, using the requirements as the vendor checklist.

Buying the platform first usually leaves a tool that automates very little. The same program gap shows up with compliance platforms. For hands-on help, see our enterprise security architecture consulting service.

Frequently Asked Questions

What is identity governance and administration (IGA)?

IGA is the set of processes and tools that manage digital identities and their access across the full lifecycle: provisioning, JML changes, deprovisioning, and recurring access reviews. SailPoint and ForgeRock are common examples of IGA platforms.

What is hybrid identity?

Hybrid identity means managing identities that span cloud and on-prem systems, for example Active Directory on-prem and a cloud identity provider, so each person has one identity across both.

How does a cloud IGA platform connect to on-prem systems?

Through agents installed under a central directory, or through a connector server deployed inside the network, such as the SailPoint Virtual Appliance or the ForgeRock Remote Connector Server. Many environments need a mix of both.

What are threat-functional requirements for identity?

Requirements that define which threats the identity system must mitigate, for example password spraying, credential guessing, and misuse of AI agent accounts. They usually come from a threat model of the identity system, on top of industry best practices.

What is an access review?

A recurring review, also called a recertification campaign, in which system and application owners confirm that each user still holds the right access and remove anything unnecessary. Combined with account discovery, access reviews keep a centralized identity design accurate after go-live.