Reference Architecture: IdP + IGA + PAM

Overview

Most enterprises run multiple IAM products simultaneously: an IdP (Okta, Entra ID, Ping), an IGA platform (SailPoint), and a PAM platform (CyberArk). Each vendor claims to be the "center" of your identity architecture. The reality is that each has a role, and the architecture decision is how to split responsibilities so the combined system is reliable, auditable, and supportable.

The core problem: Without clear boundaries, you get overlapping capabilities that create drift, audit confusion, and operational chaos. If both the IdP and IGA provision users, which is authoritative? If both IGA and PAM govern privileged access, which certifies it? These conflicts aren't edge cases—they're the primary failure mode of multi-product IAM deployments.

The core principle: One owner per control plane.

IdP owns: Authentication, federation, session policy, sign-in risk
IGA owns: Lifecycle governance, access requests, certifications, audit evidence
PAM owns: Privileged workflows, credential vaulting, session recording

When you violate this principle—when two systems both approve, both provision, or both "own" identity—you get drift, outages, and audit pain.

Key Decisions

Decision	Options	Recommendation	Notes / Gotchas
Who provisions the IdP?	IGA / IdP self-managed / Directory sync	IGA provisions IdP accounts and group memberships	IdP as a target, not a source
Who provisions SaaS apps?	IGA / IdP / Both (tiered)	IGA for Tier-0/Tier-1; bounded IdP for Tier-2	Document boundary; avoid overlap
Where do approvals live?	IGA / IdP / ITSM / Multiple	IGA for all access approvals	Single approval system for audit
Canonical identifier	email / UPN / employeeID / GUID	employeeID for workforce; stable GUID for externals	Correlation key must be immutable
Deprovisioning semantics	Disable only / Disable + revoke	Disable + session revoke (risk-tiered SLA)	"Disable" ≠ "logout"
Privileged access governance	IGA only / PAM only / IGA + PAM	IGA certifies privileged access; PAM enforces	Both have a role
SIEM correlation	IdP only / All three / Unified	Unified: IdP + IGA + PAM logs correlated	Enterprise identity as correlation key

Function	IdP	IGA	PAM	Notes
Identity creation	Receives	✓ Primary	Receives	IGA provisions from HR
Standard access provisioning	Receives (or bounded T2)	✓ Primary	-	IGA governs; IdP may execute
Privileged access provisioning	-	✓ Governs	✓ Enforces	IGA certifies; PAM controls
Authentication	✓ Primary	-	Receives SSO	IdP authenticates all users
MFA policy	✓ Primary	-	Receives	IdP enforces authn strength
Session management	✓ Primary	Triggers revoke	✓ Privileged sessions	IdP for standard; PAM for privileged
Access requests	-	✓ Primary	Receives assignments	Single request system
Approvals	-	✓ Primary	May have workflow	IGA is audit record
Certifications	-	✓ Primary	Subject to cert	IGA certifies all access
Credential vaulting	-	-	✓ Primary	PAM owns credentials
Session recording	-	-	✓ Primary	PAM records privileged sessions

Document current-state control planes (who does what today)
Identify boundary violations (duplicate provisioning, approval conflicts)
Inventory privileged access paths
Map audit requirements by compliance framework
Assess integration capabilities between products

Outputs: Current-state architecture, boundary violation analysis, integration assessment

Phase 1: Architecture Design (3-4 weeks)

Inputs: Discovery outputs, business requirements, risk appetite Activities:

Define target-state control-plane boundaries
Define canonical identifier strategy
Define provisioning and deprovisioning SLAs by tier
Design integration architecture (IdP ↔ IGA ↔ PAM)
Design SIEM correlation strategy
Document boundary exceptions with rationale

Outputs: Reference architecture document, decision log, integration design

Phase 2: Integration Build (8-12 weeks)

Inputs: Architecture design, API/connector access Activities:

Configure IGA → IdP provisioning (SCIM/API)
Configure IGA → PAM integration (safe membership)
Configure IdP → PAM SSO (SAML/OIDC)
Configure SIEM integration for all three
Build deprovisioning workflow with session revocation
Migrate provisioning ownership per boundary design

Outputs: Integrated platforms, operational workflows

Phase 3: Validation & Rollout (4-6 weeks)

Inputs: Integrated platforms, test scenarios Activities:

Test full lifecycle (hire → access request → privileged access → termination)
Test deprovisioning and session revocation timing
Validate SIEM correlation end-to-end
Validate audit evidence completeness
Pilot with limited population

Outputs: Validated architecture, audit evidence package

Phase 4: Operate (Ongoing)

Activities:

Monitor integration health
Review boundary exceptions quarterly
Update integrations as products evolve
Periodic architecture reviews
Audit evidence generation for compliance

Deliverables

Target-state reference architecture — control-plane diagram with boundaries
Integration boundary document — who owns what, with decision rationale
Identifier strategy — canonical ID, attribute precedence, correlation rules
Provisioning/deprovisioning SLAs — time-to-provision, time-to-revoke by tier
SIEM correlation design — log sources, correlation rules, dashboards
Runbooks — break-glass, incident response, integration failure recovery

Risks & Failure Modes

Risk	Likelihood	Impact	Early Signals	Mitigation
Dueling provisioning engines	H	H	Drift; duplicate accounts; conflicting access	Clear ownership; technical enforcement
"Disabled" user still has access	H	H	Terminated users active in SaaS	Session revocation + verification drills
Identity correlation failure	M	H	Orphan accounts; audit gaps	Canonical ID; reconciliation; monitoring
PAM not integrated with IdP	M	M	Privileged users bypass enterprise authn	SAML SSO for PVWA; break-glass only exception
SIEM correlation gaps	M	M	Can't trace access to identity	Consistent identifiers; correlation testing
Boundary creep	M	M	Exceptions become the norm	Quarterly boundary review; governance

KPIs / Outcomes

Time-to-provision (p95): By system tier (target: Tier-0 fewer than 4 hrs, Tier-1 fewer than 24 hrs)
Time-to-revoke (p95): By system tier (target: Tier-0 fewer than 15 min, Tier-1 fewer than 1 hr)
Provisioning failure rate: % of provisioning requests that fail (target: fewer than 1%)
Boundary compliance: % of apps following defined ownership (target: 100%)
Audit evidence completeness: % of access traceable request → approval → provision → usage → revoke (target: 100%)
Session revocation coverage: % of terminated users with verified session revocation (target: 100% for Tier-0)