You're confident your team can revoke a departing employee's access within 24 hours. Yet, more than one-third of organizations in a FIDO Alliance and HID survey shared that confidence, only to admit they'd failed to meet that deadline.
This isn't about policy. It's about architecture. The decision isn't whether to revoke access quickly, but how to structure your identity governance so you actually can.
The Decision You Are Facing
Your organization needs a reliable process for complete access revocation within 24 hours of an employee's departure. The gap between intent and execution typically stems from one of three architectural patterns:
- Centralized identity governance with full connector coverage
- Federated systems with partial automation
- Fragmented point solutions with manual handoffs
Each path has different requirements, costs, and failure modes. Your choice depends on factors you can measure today.
Key Factors That Affect Your Choice
System coverage: Count how many identity repositories exist in your environment. Include Active Directory, cloud directories, SaaS applications, privileged access management (PAM) vaults, physical access control systems, and any shadow IT that HR or department heads manage directly.
Connector maturity: For each repository, determine whether your Identity Governance and Administration (IGA) platform has a certified connector, a custom integration, or no automated link. Systems without connectors require manual steps, which means they'll miss your 24-hour window during nights, weekends, or when the responsible person is unavailable.
Reconciliation frequency: Your IGA system can only revoke what it knows about. If reconciliation runs weekly, you're blind to access granted between cycles. Daily reconciliation is essential for 24-hour revocation; hourly reconciliation catches just-in-time elevation that wasn't de-provisioned.
Termination workflow ownership: Who initiates the revocation? If HR updates a system of record and your IGA platform monitors that source, you've got clean automation. If termination requires a ticket, email, or verbal handoff, you've introduced human latency and error.
Physical-digital integration: Many organizations fail their 24-hour target due to physical access issues, like badge systems and server room locks, that operate separately from digital identity infrastructure.
Path A: Full IGA Integration
Choose this path if:
- You have fewer than 50 identity-bearing systems
- Your IGA platform has certified connectors for 90% of those systems
- You can enforce a policy requiring all new systems to integrate before going live
- HR or Workday serves as your authoritative source of record
- You're willing to invest in custom connectors for the remaining 10%
What you're committing to:
Deploy an IGA platform (SailPoint, Saviynt, Omada, or similar) with automated provisioning and de-provisioning workflows. Configure it to monitor your HR system for termination events. Build reconciliation jobs that run at least daily for all connected systems. This represents the target state, but gaps in connector coverage create the failures organizations admit to.
Write custom connectors for legacy systems, physical access platforms, or niche applications that lack vendor support. A single unconnected system, like a privileged account in a PAM vault, breaks your 24-hour commitment.
Implement automated certification campaigns to catch entitlement drift. Even with full automation, access granted outside your IGA workflow won't be revoked unless reconciliation discovers it.
The failure mode:
You'll hit your 24-hour target for 95% of users, but the remaining 5% will involve edge cases: contractors with access across multiple legal entities, employees who transferred before terminating, or access granted through an unknown system. Post-incident reviews will focus on expanding connector coverage and tightening your "no integration, no deployment" policy.
Path B: Federated Hybrid Model
Choose this path if:
- You have 50-200 identity-bearing systems
- You can't achieve full connector coverage (budget, legacy systems, or third-party constraints)
- Your organization uses federated identity for most SaaS applications
- You're willing to accept manual steps for a defined set of low-risk systems
What you're committing to:
Segment your environment into tiers. Tier 1 includes your directory services (Active Directory, Azure AD), PAM vaults, and any system with access to production data or financial systems. These get full IGA automation with daily reconciliation.
Tier 2 includes federated SaaS applications. Revoke the user's session at the Identity Provider (IdP), and federation handles the rest. This works if you've implemented WS-Federation or OAuth 2.0 properly, but many organizations discover they've granted direct credentials to SaaS platforms, bypassing federation entirely.
Tier 3 includes physical access and low-risk systems that lack connectors. These require manual revocation workflows with documented owners and SLA tracking. You won't hit 24 hours consistently for Tier 3, but you've contained the blast radius.
The failure mode:
Your manual Tier 3 processes will slip. The badge system admin is on vacation. The department-specific application has three people who know the admin password, and none of them check the termination queue daily. You'll meet your 24-hour target for critical systems but fail for the long tail.
Path C: Manual Coordination with Checklist Enforcement
Choose this path if:
- You have more than 200 systems or lack an IGA platform
- You're in the middle of a broader identity modernization program
- You need an interim solution that works today
- You can enforce checklist completion before final paycheck or severance
What you're committing to:
Build a termination checklist that covers every system category: directory services, email, VPN, PAM, physical access, SaaS applications, cloud infrastructure, and department-specific tools. Assign an owner to each category with a documented backup.
Integrate the checklist into your HR offboarding workflow. The employee's final paycheck or separation paperwork doesn't process until every checkbox is marked complete. This creates accountability, but it also means you're explicitly accepting that revocation happens on a human timeline, not an automated one.
Implement a 72-hour verification cycle. Three days after termination, a separate team (ideally your security operations or IAM team) audits a sample of terminated accounts to confirm revocation actually happened. Failures trigger immediate remediation and a review of why the checklist didn't catch it.
The failure mode:
You won't meet the 24-hour target. You're choosing deliberate, verified revocation over speed. This path makes sense if you're addressing fragmented identity governance, but you need executive acknowledgment that you're trading speed for coverage until you can fund a proper IGA implementation.
Summary Matrix
| Factor | Path A: Full IGA | Path B: Federated Hybrid | Path C: Manual Checklist |
|---|---|---|---|
| System count | <50 | 50-200 | >200 or unknown |
| Connector coverage | >90% | 60-80% (Tier 1/2) | <60% |
| Typical revocation time | <24 hours | <24 hours (Tier 1/2), 48-72 hours (Tier 3) | 48-96 hours |
| Upfront investment | High (IGA platform + connectors) | Medium (tiered approach) | Low (process + tooling) |
| Ongoing maintenance | Moderate (connector updates) | Moderate (manual Tier 3 tracking) | High (checklist sprawl) |
| Audit confidence | High (automated logs) | Medium (mixed automation) | Low (relies on attestation) |
The survey's finding that more than one-third of organizations fail to revoke access within 24 hours isn't surprising. It's a symptom of choosing Path C when your risk profile demands Path A or B. If you're still discovering systems during post-termination audits, you haven't solved identity governance. You've just documented the problem more thoroughly.
Which path matches your current connector coverage and risk tolerance? That's the decision you're actually making.
