Why "identity is the new perimeter" is easy to say and hard to enforce — and what most access review programs are getting wrong about their own scope
Every security leader has said it — "identity is the new perimeter." But knowing the principle and being able to enforce it are two different things. The gap between them is where most breaches actually happen.
Your IdP is configured correctly. MFA is enforced. Provisioning workflows exist. SCIM is running. On paper, the identity program looks solid.
And yet — a departing engineer's service account still holds write access to a production database six weeks after their last day. A contractor's OAuth token for a third-party data pipeline is still active. Nobody revoked it because nobody knew it existed. An AI writing tool an employee authorized eight months ago still has a persistent session connected to their inbox.
This isn't a policy failure. The policies are fine. It's a visibility failure.
Most enterprise environments have three layers of identity activity. Governance tools typically see one of them clearly.
The managed layer — your SSO-connected apps, directory-provisioned accounts, and core SaaS platforms — is well-lit. You can audit it, review it, and certify it.
Everything else is in the dark. The OAuth grants to tools nobody formally approved. The service accounts created by engineers who have since left. The AI integrations with workspace-level permissions. The 30–40% of your tech stack that doesn't support SCIM and therefore falls entirely outside automated provisioning and review workflows.
The overlap between what your IdP misses and what attackers look for isn't a coincidence. It's the attack surface that visibility-first security is designed to close.
Access Reviews Are Where Visibility Failures Become Compliance Failures
User access reviews are the mechanism that's supposed to surface and close this gap on a recurring basis. In most organizations, they don't — because they're built on the same incomplete data that created the gap in the first place.
Reviews that only cover accounts the IGA tool knows about are certifying 60–70% of actual access. The result is a process that consumes significant reviewer time, creates a documented record of assurance, and systematically misses the access paths that present the most risk.
Three failure modes show up consistently:
Unreviewed non-human identities. Service accounts, API keys, and deployment tokens are rarely included in access certifications. They're also rarely subject to MFA, frequently over-scoped, and don't get offboarded when the human who created them leaves the organization.
Manual reviews on incomplete data. Reviewers are asked to certify access they can't fully see. Approving a user's access to GitHub doesn't tell you whether they have write permissions to a production repository. Access reviews need to operate at the inside-app permission level — not just at the account level.
Shadow IT outside the review scope. SOC 2, SOX ITGC, and ISO 27001 auditors increasingly ask for evidence of access control across all systems handling sensitive data. If 30–40% of your SaaS stack isn't in scope for reviews, that's a gap your next audit will find — even if your reviewers didn't.
What Actually Needs to Change
Effective access reviews depend on complete discovery upstream. This sounds obvious, but most IGA implementations skip it — they start with the known account list and build review workflows on top of that. The inventory problem never gets solved; it just gets certified annually.
A few numbers that put the scope of the problem in context:
82:1 is the ratio of non-human to human identities in modern cloud environments. Most access review programs cover a fraction of this.
30–40% of the average enterprise tech stack lacks SCIM support, falling entirely outside automated provisioning and review workflows.
70% of CISOs will deploy an Identity Visibility and Intelligence Platform by 2028, per Gartner — precisely because current tools leave these gaps unaddressed.
A review program built on complete visibility looks meaningfully different from what most teams run today. Four things have to be true.
1. Discover Before You Certify
Run multi-channel discovery across IdP logs, expense systems, OAuth catalogs, browser telemetry, and network egress data before scoping reviews. The goal is an unedited inventory — including shadow SaaS, unmanaged service accounts, and third-party integrations with persistent access tokens that no one actively manages.
2. Review Effective Permissions, Not Just Account Existence
A user "has access to Salesforce" is not enough information. What can they actually do inside Salesforce? Which reports can they export? Which data objects can they modify? Access reviews need to operate at the inside-app permission level — specific channels, repositories, folders, and export rights — to mean anything in a least-privilege context.
3. Build a Certification Track for Non-Human Identities
Service accounts, API keys, and integration tokens need their own review cadence, separate from human identity reviews. Every entry should include scope, owning team, last-used date, and expiry. Machine identities that predate current security policy are high-value targets and are almost never reviewed systematically — until something goes wrong.
4. Close the Loop Without a Ticket Queue
A review that identifies over-provisioned access and then opens a helpdesk ticket leaves a remediation window open — sometimes for weeks. The decision to revoke should trigger the revocation directly, automatically, across every affected system. The access is either closed or it isn't.
How Zluri Approaches This
Zluri's IGA platform starts at the discovery layer — not the directory. Instead of mapping reviews to a static list of known accounts, Zluri builds a real-time identity graph across eight discovery channels: IdP logs, HRIS data, financial and expense systems, cloud infrastructure (AWS, GCP, Azure), a 240,000+ app catalog via direct API connectors, browser extension telemetry for SSO bypass detection, network gateway egress data, and custom SDK connectors for in-house legacy systems.
The identity graph is maintained continuously by IRIS (Identity Risk Intelligence System) — Zluri's intelligence layer — which correlates identity entities, application contexts, and effective permission chains in real time. This means when a software engineer leaves and their primary IdP account is suspended, IRIS can surface a secondary service account they created months earlier, with a persistent API token still active in a production environment. That's the correlation a quarterly access review working from a static directory would never find.
Access certifications in Zluri run against this complete picture. Reviewers see human identities, non-human identities, shadow SaaS, and inside-app permissions — not just the accounts that made it into the managed directory. When a reviewer revokes access, Zluri executes the remediation directly via native API integrations across 1,500+ applications. No ticket. No queue. The access is closed at the moment the decision is made.
Zluri customers report access reviews completing 10x faster with 70% less reviewer effort — not because the reviews are less thorough, but because data quality and direct remediation remove the overhead that makes reviews slow and inconsistent in the first place.
Frequently Asked Questions
What does "identity is the new perimeter" actually mean for security teams?
It means the boundary you're defending is no longer the network edge — it's every identity that can access your systems. Firewalls and VPNs secured a physical perimeter. In a cloud-first, SaaS-heavy environment, that perimeter doesn't exist anymore. Every user account, service account, API key, and OAuth token is now a potential entry point. Defending the perimeter means governing those identities — all of them, not just the ones in your IdP.
Why do traditional IGA tools miss so much of the identity surface?
Traditional IGA tools are built around the "happy path" — applications with documented APIs, SCIM connectors, and enterprise-grade directory integrations. That covers 60–70% of a typical enterprise stack. The remaining 30–40% — shadow SaaS, legacy systems, team-specific tools, non-human identities — don't fit neatly into that model. Most IGA tools have no discovery mechanism for this layer, so it stays unmanaged by default.
What are non-human identities, and why do they matter for access reviews?
Non-human identities are any system-level accounts that operate without direct human interaction — service accounts, API keys, OAuth tokens, deployment credentials, bot accounts, and integration tokens. In modern cloud environments, they outnumber human users by more than 80 to 1. They're high-value targets precisely because they're under-governed: rarely subject to MFA, frequently over-scoped, and almost never included in standard access certification programs.
How often should access reviews be conducted?
Frequency should match the risk profile of what's being reviewed. Privileged access to production systems and sensitive data warrants quarterly or even continuous review. Standard SaaS access for typical users is commonly reviewed annually or semi-annually for compliance purposes. Non-human identities — given how rarely they're reviewed at all — benefit from a dedicated cadence, separate from human identity reviews, with automated expiry policies where possible.
What's the difference between an access review and an access certification?
The terms are often used interchangeably, but there's a useful distinction. An access review is the process of examining what access exists and whether it's appropriate. An access certification is the formal attestation — a reviewer signing off that specific access has been reviewed and approved or revoked. Certifications are what auditors look for as evidence of control. The quality of a certification is only as good as the completeness of the review that preceded it.
What's the biggest reason access review programs fail in practice?
Incomplete scope is the most common failure — reviews that certify the accounts the IGA tool knows about while leaving the unmanaged layer untouched. The second most common failure is slow remediation: reviews that correctly identify over-provisioned access but route revocation through a helpdesk ticket queue, leaving the access active for days or weeks while the ticket sits in a backlog. Both failures come back to the same root cause — discovery and automation gaps that the review process was never designed to compensate for.
.svg)
