SaaS identity governance tools like Lumos, Zluri, and AccessOwl solve access review for the systems that expose clean APIs and SSO integration — which covers most of a typical SaaS stack. The gap shows up the moment a company has homegrown internal tools, direct database access, or AWS IAM structures the off-the-shelf connector was never built to understand.
Where SaaS IGA Tools Reach — and Where They Stop
Most identity governance platforms are built around SCIM and OAuth-connected SaaS applications: Salesforce, Google Workspace, Slack, Snowflake, and similar tools with mature, well-documented APIs. For that layer, buying a SaaS IGA product is almost always the right call — building a custom replacement for what these tools already do well is wasted engineering effort.
The gap opens up in a specific, recurring set of places:
- Internal applications with no SCIM support — a homegrown admin panel, an internal ops tool, or a legacy system with its own user table and role model that no connector was ever built for
- Database-level access — direct SQL grants, read replicas accessed via connection strings shared outside any identity provider's visibility
- AWS IAM structures with role chaining — cross-account assume-role patterns and resource-based policies that a generic cloud connector often flattens into an incomplete picture
- Legacy on-prem or self-hosted systems — internal wikis, ticketing systems, or infrastructure tools running outside the SaaS ecosystem entirely
The Custom Layer We Build
Rather than positioning this as "cheaper than [IGA product]," the honest framing is: it's the ~30% of your access surface that SaaS IGA tools structurally can't reach, built as a companion layer that feeds evidence into whatever platform you already run.
Direct entitlement ingest for non-standard systems. For an internal app with its own database-backed permission model, we build a scheduled extraction job that pulls the current role/permission state directly from the source of truth:
def ingest_internal_app_roles(db_conn) -> list[Entitlement]:
query = """
SELECT u.email, r.role_name, r.granted_at, r.granted_by
FROM user_roles r
JOIN users u ON u.id = r.user_id
WHERE u.deactivated_at IS NULL
"""
rows = db_conn.execute(query).fetchall()
return [
Entitlement(principal=row.email, source_system="internal-app",
role=row.role_name, granted_at=row.granted_at)
for row in rows
]
A unified review surface across standard and non-standard systems. The value isn't just closing the gap for the hard 30% — it's presenting reviewers with one coherent view spanning both the SaaS-IGA-covered systems and the custom-covered ones, so a reviewer isn't juggling two disconnected review processes for the same team's total access footprint.
AWS IAM role-chain resolution. For cross-account access patterns, we resolve the full effective permission set — not just the directly attached policy, but the chain of assumed roles and resource policies that actually determine what a principal can reach — since a generic connector reviewing only the first-hop role misses the real risk.
When to Build vs. When to Just Buy More IGA Coverage
Not every gap justifies custom engineering. If a SaaS IGA vendor has a roadmap item that will cover your specific internal system within a reasonable timeframe, waiting may be the more cost-effective path. Custom integration makes sense when: the system is genuinely unlikely to ever get vendor-native support (proprietary internal tooling), the system holds sensitive data an auditor specifically wants reviewed, or the volume of access changes is high enough that manual bridging (exporting to a spreadsheet quarterly) creates real audit risk.
Frequently Asked Questions
Should we cancel our SaaS IGA subscription if we build a custom layer?
No — the custom layer is designed to complement, not replace, your existing IGA tool. It extends coverage to systems the tool can't reach while your IGA platform continues handling the SCIM-connected SaaS layer it's built for.
How do you handle systems with no API at all?
For systems with no API, we typically build direct database-level extraction (read-only, scoped credentials) or, where neither is feasible, a structured manual export process with automated normalization and evidence capture on the ingest side.
Can this integrate with our existing GRC platform's evidence collection?
Yes — the goal is to push normalized entitlement and review evidence into whatever GRC platform you already run (Vanta, Drata, Secureframe) rather than creating a parallel, disconnected evidence trail.
How long does a typical non-standard system integration take?
It depends heavily on the system's data model and access patterns, but a single well-defined internal application integration typically takes one to two weeks from discovery to a working entitlement feed.
Does this help with AWS-specific access review challenges?
Yes — resolving effective permissions across IAM role chains and cross-account access is one of the most common gaps we close, since generic connectors often miss the real effective permission set in multi-account AWS organizations.
See what an Access & Credential Governance Diagnostic finds in your environment → rutagon.com/contact or call 907-841-8407.