Most growing tech companies have solid authentication — Okta, SSO, MFA — and genuinely believe identity is covered. It isn’t. Strong authentication answers exactly one question: who can log in? It says nothing about whether those users should still have the access they’re holding, or whether that access was ever revoked when their role changed.
The gap is governance. When HR onboarding, IT access management, and customer-facing identity all run as disconnected silos, that gap compounds fast. The result is entitlement sprawl, privilege creep, orphaned accounts, and a Zero Trust posture that looks great on paper but can’t be enforced in practice.
Identity assurance architecture is the end-to-end framework that connects proofing signals, entitlement governance, and access control across all three identity domains. This article gives you the architectural decision framework for a company growing from 50 to 500 employees. For the broader proofing context, see the identity proofing stack overview that situates these layers in the full architecture.
Why do isolated IAM controls fail when identity spans HR, IT and customer systems?
IAM platforms — Okta, Azure AD, Auth0 — authenticate users and control login. What they don’t govern is what happens after authentication: which entitlements a user holds, whether those entitlements are still appropriate, or whether they were properly revoked when a role changed. That’s an entirely separate problem.
Three identity domains generate disconnected identity states:
- HR onboarding via HRIS (Workday, ADP, SuccessFactors) creates an employee record with role and department attributes — the authoritative identity source, but one that rarely propagates automatically to all downstream systems.
- IT access provisioning via IAM grants system-level entitlements — often manually, inconsistently, and almost never with automated revocation when attributes change.
- Customer-facing systems (CIAM) manage external user identity independently — a separate silo with its own provisioning and access lifecycle that rarely connects to workforce identity governance at all.
When these three domains are siloed, a termination event in the HRIS may not propagate to all IT systems or CIAM accounts — leaving orphaned accounts active long after the user has left.
The failure mode concentrates in the Joiner-Mover-Leaver (JML) lifecycle. Joiners wait days for access. Movers accumulate old entitlements on top of new ones. Leavers retain active accounts in systems the offboarding process missed. These are governance failures. IAM was never designed to solve them.
At SMB scale, the risk is concentrated: a single compromised admin account can access everything because identity governance was never layered on top of authentication.
What is the difference between IAM and IGA — and why do you need both?
“We have Okta, so identity is covered” is the most common and most consequential assumption in this space.
IAM (Identity and Access Management) is the authentication and access control layer — login, SSO, MFA, federation via SAML and OIDC. IAM answers: who can log in?
IGA (Identity Governance and Administration) is the entitlement lifecycle governance layer — who has access to what, whether they still should, who approved it, and when it should be revoked. IGA answers: what can they do, and should they still be able to do it?
Both are required. Neither is sufficient alone.
IGA provides capabilities IAM simply can’t deliver:
- Access certification campaigns: periodic or continuous review of all entitlements, with full audit trails and automatic revocation for non-responses.
- Separation of Duties (SoD) enforcement: no single user should hold a combination of access rights that could enable fraudulent actions undetected. SoD requires analysing entitlement combinations across systems — IAM cannot do this.
- Least privilege enforcement: IAM grants access; IGA governs whether that access is still justified.
- Audit trails for compliance: IGA maintains the governance record that compliance frameworks require.
Traditional IGA operates on periodic certification cycles — quarterly or annual — rather than real-time risk signals. Permissions change daily; the certification campaign runs quarterly. That gap is exactly what entitlement sprawl exploits.
For a deeper look at identity lifecycle management as the operational model, see the continuous verification guide.
What is entitlement sprawl and how does it become a critical identity risk?
Entitlement sprawl is the proliferation of permissions across cloud, SaaS, and on-premises systems — accumulated through role changes and manual access grants that are never revoked.
The mechanism is relentless. Every role change adds new entitlements without revoking old ones. Every project grants temporary access that quietly becomes permanent. Every SaaS tool onboarded adds a new permission surface no one maps back to existing roles.
At SMB scale, this is invisible without IGA tooling. A developer who joined as a backend engineer accumulates infrastructure admin access after a role change, then SIEM access after joining a security task force — all without previous entitlements being revoked. Within eighteen months, one user holds access far exceeding their current role. No alarm fires, because authentication was never the problem.
Birthright access is where governance should start — baseline entitlements automatically assigned from HRIS attributes when a user is provisioned. All engineering staff receive access to GitHub, Jira, and the CI/CD pipeline. Anything beyond birthright access requires explicit approval and periodic review.
Without a clean entitlement baseline, there’s no ground truth against which to verify access. Which brings us to Zero Trust.
How does Zero Trust architecture make identity assurance modernisation mandatory?
Zero Trust is premised on “never trust, always verify.” Every access request requires continuous verification of identity, device posture, and context — regardless of network location. And there’s a structural requirement that often gets overlooked: continuous verification is impossible without clean entitlement governance. If the system doesn’t know what entitlements a user should have, it can’t tell whether a given request is legitimate or anomalous. Without IGA, that ground truth simply doesn’t exist.
The connection chain: proofing signals — liveness detection, behavioural biometrics, device intelligence — feed into the Identity Risk Orchestration layer, routing decisions into two downstream layers:
- The IAM layer receives step-up authentication triggers — an unusual login context triggers additional MFA.
- The IGA layer receives entitlement review triggers — an anomalous access pattern triggers a targeted review instead of waiting for the next quarterly campaign.
ABAC (Attribute-Based Access Control) extends this further — incorporating risk signals from the proofing layer into access decisions. Same entitlement, different decision because the context changed.
Zero Trust is also the board-level justification for identity governance investment. “We need IGA for entitlement hygiene” is hard to justify. “Zero Trust requires continuous entitlement verification” is a different conversation entirely. For context on proofing signal integration into the architecture, see the four-signal identity stack guide.
What does a cross-system identity assurance architecture actually look like?
A mature identity assurance architecture spans six layers. Each has a distinct function; the architecture fails when any layer is missing or when the connections between them are broken.
Layer 1 — HRIS (Workday, ADP, SuccessFactors): The authoritative identity source. Joiner, mover, and leaver events originate here. Nothing downstream is authoritative unless it reflects the current HRIS state.
Layer 2 — CIAM: The customer-facing identity domain. Must be integrated into the governance framework — not left as a silo — so customer identity events reach the orchestration layer.
Layer 3 — IAM (Okta or equivalent IDP): The authentication enforcement layer. Handles login, SSO, MFA, and federation — the enforcement point for “can this user log in?” Not for “should they still have this access?”
Layer 4 — IGA: The entitlement governance layer. Provisions birthright access from HRIS attributes, runs access certification, enforces SoD, detects entitlement sprawl. SailPoint at enterprise scale; light-IGA at SMB scale.
Layer 5 — Proofing Signal Layer: Continuous identity verification — liveness, behavioural biometrics, device intelligence — feeding real-time risk context into the orchestration layer.
Layer 6 — Identity Risk Orchestration: The architectural connective tissue. Consumes proofing signals and feeds risk-based decisions into both the IAM and IGA layers. Strata.io‘s Maverics is a reference implementation.
PAM alongside Layer 3 — CyberArk or equivalent: Manages the highest-risk identity tier — admin credentials, service accounts, API keys — with just-in-time access and credential vaulting.
The HRIS connects to IAM and IGA via SCIM. Joiner events trigger birthright access provisioning. Mover events trigger entitlement adjustment. Leaver events trigger deprovisioning across all connected systems. The gap occurs when SCIM integrations are incomplete — orphaned accounts in the systems that were missed.
For the full architectural context, the complete guide to identity stack modernisation covers how these layers fit together at each growth stage.
Light-IGA versus full IGA: which is right for a company at your scale?
Light-IGA delivers the foundational capabilities without a full platform deployment: automated provisioning and deprovisioning from HRIS events, basic access certification, and role-based entitlement management. Operational in weeks with existing IT staff.
Full IGA (SailPoint-class platform) adds a policy engine, SoD enforcement, advanced certification campaigns, entitlement analytics, and compliance reporting. Implementation takes six to eighteen months and requires dedicated identity engineering staff.
The scale thresholds:
- At 50 employees: Light-IGA is appropriate. A cloud IDP with SCIM-based automated provisioning from the HRIS, quarterly access reviews, and a documented birthright access policy covers the governance baseline.
- At 200+ employees with multiple SaaS applications and regulatory requirements: the case for full IGA becomes compelling. Access review volume exceeds what manual processes can handle.
- At 500 employees: Full IGA is likely necessary. The entitlement surface and compliance requirements exceed what light-IGA can govern.
The decision signals — regardless of headcount:
- Access reviews are failing — managers rubber-stamping certifications without meaningful review.
- Entitlement sprawl is detected in audit.
- SoD violations are discovered.
- Regulatory requirements demand formal certification campaigns and audit trails.
Opti represents the emerging category between these two tiers — fine-tuned LLMs and graph-based normalisation to detect sprawl and recommend access revocations. For companies at 100–300 employees who need deeper entitlement analytics than light-IGA provides but aren’t ready for full platform deployment, AI-native entitlement intelligence is a viable middle path.
For vendor-level evaluation at each scale point, vendor evaluation for your identity architecture covers the detailed comparison.
How do you choose between building a multi-signal identity stack and buying an integrated solution?
The build-vs-buy decision isn’t about cost. It’s about extensibility, vendor dependency, and team capacity — and it’s most consequential at the orchestration layer.
Build (orchestration approach): Integrate best-of-breed vendors — Okta for IAM, SailPoint or light-IGA for governance, CyberArk for PAM, Opti for entitlement intelligence — connected via an Identity Risk Orchestration layer. Vendor-agnostic; sits on top of existing solutions rather than replacing them.
Buy (integrated platform approach): A single vendor stack covering IAM, IGA, and orchestration. Reduces integration complexity but creates vendor lock-in.
The decision criteria:
- Existing investment: If you already have Okta and are adding IGA, an orchestration approach preserves that investment. Okta Identity Governance is a natural first step.
- Team capacity: An orchestration approach requires integration engineering. A platform approach requires less custom development. Smaller IT teams favour platforms.
- Vendor trajectory: Is your IAM vendor expanding into IGA? If yes, extend the existing platform rather than add a separate one.
Before deciding, audit three areas:
- Access review quality: Are managers reviewing meaningfully or rubber-stamping quarterly certifications?
- Entitlement hygiene: Can you produce a complete report of who has access to what across all SaaS, cloud, and on-premises systems?
- Cross-system propagation: Does an HRIS termination event trigger deprovisioning in every connected application within 24 hours?
For companies at 50–200 employees: start with your IAM provider’s governance add-ons, supplement with light-IGA or Opti, and plan the orchestration layer as the next investment. For detailed vendor comparison, vendor evaluation for your identity architecture provides the neutral evaluation framework.
Frequently Asked Questions
Is Okta an IGA platform or an IAM platform?
Okta is an IAM platform — authentication, SSO, federation via SAML and OIDC. Okta Identity Governance adds basic governance capability, but for full entitlement lifecycle governance — access certification, SoD enforcement, entitlement analytics — a dedicated IGA solution is still required.
Do I need IGA if I already have a good IAM setup?
Yes. IAM controls who can log in; IGA governs what they can do and whether they should still have that access. Without IGA, entitlements accumulate unchecked — every role change adds permissions that are never revoked, creating privilege creep IAM cannot detect.
What is the minimum viable identity assurance architecture for a 50-person company?
A cloud IDP for authentication and SSO, SCIM-based automated provisioning from the HRIS, quarterly access reviews, and a documented birthright access policy. This is light-IGA without a dedicated IGA platform — manageable provided the HRIS-to-IAM connection is clean.
What is birthright access and why does it matter for identity governance?
Birthright access is the baseline entitlements automatically assigned from HRIS attributes when a user is provisioned — all engineering staff receive access to GitHub, Jira, and the CI/CD pipeline. It defines the governance baseline: any entitlements beyond birthright access require explicit approval and periodic review.
How does the HRIS connect to the IAM and IGA layers in practice?
The HRIS publishes joiner, mover, and leaver events via SCIM or API integrations. A joiner triggers birthright access provisioning. A mover triggers entitlement adjustment and SoD checks. A leaver triggers deprovisioning across all connected systems. The gap occurs when events do not propagate everywhere — creating orphaned accounts in the systems that were missed.
What is identity orchestration and how is it different from SSO?
SSO allows a user to authenticate once and access multiple applications. Identity orchestration mediates between heterogeneous IAM systems, IDPs, and governance tools — routing signals, enforcing policy, enabling integration without platform consolidation. Where SSO eliminates repeated login prompts, orchestration eliminates the need to re-architect applications when the underlying identity infrastructure changes.
What does privilege creep look like at a 200-person SaaS company?
A developer joins with access to production databases. They move to a platform role and gain infrastructure admin access — previous access is not revoked. They join a security task force and receive SIEM access. Within eighteen months, one user holds access far exceeding their current role. No review flagged it, because authentication was never the problem.
How do I assess whether my current IAM controls are still sufficient?
Audit three areas: access review quality (meaningful reviews or rubber-stamping?), entitlement hygiene (can you produce a complete report of who has access to what across all systems?), and cross-system propagation (does an HRIS termination trigger deprovisioning everywhere within 24 hours?). A gap in any of these means you need IGA.
What is separation of duties and why is it an IGA concern rather than an IAM concern?
SoD ensures no single user holds access rights that could enable fraudulent actions undetected — one user should not be able to both create and approve payments. It’s an IGA concern because it requires analysis of entitlement combinations across systems. IAM authenticates individual sessions; it cannot evaluate whether those entitlements violate a SoD policy.
When should a growing company move from light-IGA to a full IGA platform?
Move when access reviews are failing, SoD violations appear in audit, regulatory requirements demand formal certification campaigns, or entitlement sprawl is detected at scale. The threshold is typically 200–300 employees with 50 or more SaaS applications — but the decision signals matter more than the headcount.
What role does AI play in modern identity governance?
AI-native platforms like Opti use fine-tuned LLMs and graph-based normalisation to detect sprawl, recommend access revocations, and normalise permissions across heterogeneous platforms — closing the gap between light-IGA and full-IGA without a SailPoint-class deployment.
Can I implement Zero Trust without IGA?
Not meaningfully. Zero Trust requires continuous verification of whether a user’s access is appropriate — knowing what access exists and whether it is still valid. Without IGA, there is no entitlement baseline to verify against. Authentication tells you the user is who they claim to be; governance tells you whether what they are trying to do is appropriate.
Part of a series on identity proofing and identity stack modernisation for growing technology companies. For the complete architectural framework, see the complete guide to identity stack modernisation. For the vendor evaluation guide, see vendor evaluation for your identity architecture.
