The Manager Who Approved 200 Certifications in Three Minutes
It happens in every organization that runs access reviews. The certification campaign launches — quarterly, semi-annual, whatever the compliance cycle demands — and managers get a list of employees and their entitlements to review. Confirm that each person still needs each access. Simple enough concept.
Then reality: a manager has 47 direct reports. Each has 15 to 30 entitlements to certify. That's somewhere between 700 and 1,400 approval decisions they're supposed to make thoughtfully, on top of their actual job. The deadline is two weeks away. The reminders start on day one. By day ten, the security team is sending escalation emails. By day thirteen, managers are hitting approve on everything just to clear the queue.
Three minutes. 200 certifications. Approved. Campaign complete. Compliance satisfied. Audit evidence collected. And 340 orphaned accounts for former employees, contractors, and rotated service accounts stay active for another quarter because nobody actually looked at what they were reviewing.
This is access review as security theater. And the uncomfortable fact is that most Identity Governance and Administration programs — SailPoint, Saviynt, One Identity, IBM ISIM, whatever platform you're running — are being used to generate this theater at enterprise scale. The tool works perfectly. It's just producing the wrong outcome efficiently.
What IGA Is Supposed to Do
Identity Governance and Administration, when it works, handles the full Joiner-Mover-Leaver (JML) lifecycle with enforcement rather than aspiration. Someone joins the company — they get role-based access provisioned automatically based on their role and department, through integration with your HR system. Someone moves to a different team — their old access is revoked and new access is provisioned, automatically or through a clean approval workflow. Someone leaves — all access is terminated, full stop, with no manual intervention required.
The access certification process in a functioning IGA program is a cleanup pass for things that fell through the cracks and for drift from the baseline that has accumulated. It shouldn't be the primary mechanism for enforcing least privilege. It should be catching the exceptions that the automated JML process missed.
When access certification is your primary access control mechanism — when you're relying on managers looking at a list every 90 days to determine who has what — you've already lost. The control runs quarterly at best, managers don't have context to make meaningful decisions, and the tooling is optimized for throughput rather than accuracy.
The real function of IGA should be continuous, automated, and exception-driven. Humans should only be in the loop for decisions that actually require human judgment — non-standard access requests, sensitive system provisioning, access that doesn't fit any defined role. Everything else should be handled by policy.
Role Explosion and Why Your Role Model Is Meaningless
Every IGA implementation hits the role explosion problem eventually. You start with the intention of building a clean, manageable set of roles — maybe 100 roles to cover your organization's functional needs. Two years later, you have 2,400 roles, many of which differ by one entitlement, most of which were created because someone's access request didn't fit any existing role and the path of least resistance was creating a new one.
Role explosion happens for predictable reasons:
Access requests drive role creation. When a user needs access that doesn't map to an existing role, someone creates a new role for them. This should be an exception that triggers a review of whether the role model needs adjustment. Instead it becomes the default provisioning path.
Roles are created per-project rather than per-function. Project-based roles make sense during a project's active life. They become orphaned clutter when the project ends, but nobody deprecates them because doing so requires figuring out whether anyone still depends on the entitlements included.
Business roles and technical roles are conflated. A business role like "Sales Representative" should map to a set of application entitlements. When technical entitlements bleed directly into the role catalog — when you have a role called "ReadOnly-Salesforce-Opportunity-West-Region-Q3" — the role model has collapsed into an entitlement list with extra steps.
The SailPoint IdentityIQ role mining capability can help identify consolidation opportunities by clustering similar entitlement sets. Saviynt has equivalent analytics. But role rationalization is fundamentally a governance project, not a technology project. It requires someone with authority to retire roles, update job codes, and force conversations with application owners about what access actually means. The tooling surfaces the problem. Fixing it requires organizational will.
The Orphaned Account Problem Is an HR System Integration Problem
Orphaned accounts — active accounts belonging to people who no longer work at the organization — are almost always a symptom of a broken or absent HR system integration. If your IGA platform doesn't have a reliable, real-time feed from your authoritative identity source (HRMS, HCM, Active Directory), it doesn't know when someone's employment status changes.
The classic failure pattern: an employee's last day is recorded in Workday. The Workday-to-IGA sync runs overnight. The IT service desk has a manual offboarding checklist. The manager didn't submit a separation ticket. The IGA platform never got the termination event. Three months later, the former employee's AD account is still active, their M365 license is still assigned, and their VPN certificate hasn't expired. They can still log in.
This is not a CSPM problem. It's not an EDR problem. It's an identity plumbing problem that most organizations have and most organizations underestimate the security significance of. The Verizon DBIR consistently shows credential compromise as a leading attack vector. Orphaned accounts with valid credentials — credentials the former employee might still remember or share — are an attacker's easiest path to persistence.
The fix requires: a reliable HR integration that triggers on status changes in real-time or near-real-time, a defined authoritative source hierarchy, and an automated deprovisioning workflow that doesn't require human initiation. Disable the account in Active Directory. Revoke SSO sessions in Okta or Azure AD. Remove group memberships. Archive mailbox. This should happen automatically within hours of a termination event being recorded, not as a manual checklist item that may or may not get done.
Rubber-Stamp Reviews and How to Detect Them
If you're running access certifications and not analyzing the review behavior, you're missing one of the most valuable data sets your IGA platform produces. Review analytics tell you whether your certification campaigns are producing meaningful decisions or just generating audit evidence.
Metrics worth tracking:
Approval rate by manager. If a manager consistently approves 99% of certifications, they're not reviewing. 99% approval is not a realistic outcome of thoughtful access review. Compare rates across your manager population — significant outliers in either direction are worth investigating.
Time per decision. SailPoint and Saviynt both log timestamps at the certification decision level. If a manager is approving entitlements at a rate of one per second, they're not reading them. Reasonable review time varies, but sub-2-second approval rates on complex entitlement descriptions are a red flag.
Revocation rate trend over time. If your certification campaigns are producing close to zero revocations quarter after quarter, either your access model is pristine (unlikely) or managers are rubber-stamping. A healthy certification campaign should surface some meaningful revocations each cycle, particularly for Mover cases where role changes should have triggered access adjustments.
Use this data to intervene. High rubber-stamp rates in a particular manager's team might mean they have too many certifications to review, the entitlement descriptions are too technical for them to interpret, or they need explicit guidance on what "review" actually means. Fix the process rather than just logging the behavior.
Segregation of Duties: The Control Nobody Can Actually Explain
Segregation of Duties (SoD) is the principle that no single person should have the combined access to both initiate and approve a sensitive transaction — the classic example being someone who can both create and approve vendor payments, which enables straightforward fraud.
SoD controls in IGA platforms work by defining conflicting entitlement pairs — if a user has Entitlement A and requests Entitlement B, a conflict is flagged. SailPoint has a SoD policy engine. Saviynt has SoD matrix management. Saviynt in particular has good coverage of common ERP SoD conflicts for SAP and Oracle environments.
The problem with SoD in practice: the SoD matrix is often defined once during implementation and never maintained. New applications are added. New entitlements are created. The SoD matrix doesn't expand to cover them. Within 18 months, there are combinations of entitlements that should be flagged as conflicting that aren't, because the entitlements didn't exist when the matrix was built.
Additionally, SoD violations that have been granted exceptions accumulate over time. Exceptions should require documented business justification, compensating control evidence, and a defined review period. Instead, many organizations grant SoD exceptions indefinitely because cleaning up the exception backlog is painful and there's always something more urgent to work on.
If your SoD exception count has been climbing for three years and nobody has closed an exception in the last six months, your SoD program has the same problem as your access reviews: it's generating audit evidence without producing meaningful risk reduction.
Service Accounts and the Access Review Gap
Most IGA access certification campaigns are designed around human identities. Service accounts — non-human identities used by applications, scripts, automation, and integrations — are frequently out of scope for certification campaigns or included as an afterthought.
This is a significant gap. Service accounts often carry high privilege because they were provisioned by someone who was trying to make something work and chose the path of least resistance. A service account with Domain Admin rights because someone needed it to do one thing during a project in 2019 and it was never scoped down. A shared application account with database admin access because separating read and write roles seemed too complex at the time.
Service accounts don't leave the organization, so the orphaned account concern feels less relevant. But service accounts with excessive privilege are high-value lateral movement targets. If an attacker compromises an application that uses a service account with excessive rights, those rights become the attacker's rights.
IGA programs need to include service account inventory and certification in scope. Who owns this service account? What does it need access to? Is it still in use? When was the password last rotated? Some of these controls belong in a PAM platform (CyberArk, BeyondTrust) rather than IGA, but the discovery and ownership assignment work lives in IGA.
What a Functioning IGA Program Actually Looks Like
A functioning IGA program has a few properties that distinguish it from compliance theater.
The HR integration is real and current. Terminations trigger automated deprovisioning within a defined SLA. Movers trigger automated access adjustments aligned to role changes. The IGA platform's identity data reflects reality, not a 48-hour-old batch sync.
The role model is maintained, not just created. There's an ongoing process for role rationalization, role deprecation, and role entitlement review. Someone owns the role catalog and is accountable for its accuracy.
Certification campaigns are scoped appropriately and include review analytics. Managers receive only what they can meaningfully review. Rubber-stamp behavior is detected and addressed. Revocations happen and are tracked.
SoD policies are maintained as the application landscape evolves. Exception management has teeth — time-bound approvals, documented justifications, active closure processes.
And critically: access request workflows make it easier to do the right thing than the wrong thing. When a manager needs to give someone temporary access, the tool guides them to time-limited entitlement grants rather than permanent access. When a request doesn't fit an existing role, the default is a structured exception, not a new role that will never be cleaned up.
The 340 orphaned accounts aren't a technology failure. They're the outcome of an IGA program that went live, got certified by an auditor, and then stopped being actively managed. Identity governance isn't a project. It's an operational discipline that requires continuous attention or it produces the exact outcome it was supposed to prevent.
