Automated SaaS access revocation on employee offboarding eliminates the average 7-day gap between an employee’s last day and full system deprovisioning — a gap that Verizon’s Data Breach Investigations Report consistently cites as the primary access vector in insider threat incidents, and that manual offboarding checklists fail to close because they depend on IT availability on the same day HR processes the termination. Here is the automation architecture. See the Make.com HR Workflow guide for the workflow patterns this system extends.

How Do You Design the Offboarding Trigger for Instant Access Revocation?

The trigger must fire on the termination decision event — not on the employee’s last day. When HR processes the termination in your HRIS, a Make.com™ scenario fires immediately. The scenario receives: employee ID, termination date, termination type (voluntary/involuntary), and last access date. For involuntary terminations, the scenario executes access revocation immediately. For voluntary terminations with a future end date, the scenario schedules the revocation execution for 11:59 PM on the last day. This design handles both immediate-exit and future-dated separations from a single trigger event without manual scheduling.

How Does OAuth Token Revocation Work in Make.com?

For SaaS applications using OAuth 2.0, access revocation requires calling the application’s OAuth token revocation endpoint with the employee’s access token. Make.com™ handles this via the HTTP module: retrieve the employee’s OAuth tokens from your identity provider (Okta, Azure AD, or Google Workspace), call each application’s revocation endpoint with the token as the request parameter, and verify the 200 response confirming revocation. Applications that use SSO via your identity provider (Okta/Azure AD) are deprovisioned through a single identity provider user deactivation call — one Make.com™ module handles all SSO-connected applications simultaneously. Applications with independent credentials require individual API calls.

How Do You Build the SaaS Application Inventory for Complete Coverage?

Complete offboarding coverage requires knowing every SaaS application the employee can access. Build the inventory: export your identity provider’s application list (all SSO-connected apps), cross-reference with your SaaS spend management tool (Zylo, Torii, or similar — covers apps not in SSO), and run a quarterly survey of department heads for shadow IT applications. For each application, document: access revocation method (SSO deactivation, API call, or manual), Make.com™ module or HTTP endpoint for automated revocation, and estimated revocation time. Applications that cannot be automated (those with no API access management) get a Teamwork™ task created automatically on the offboarding scenario trigger, assigned to the application owner with the termination date and a 4-hour completion SLA.

How Do You Audit Offboarding Completeness?

Build a post-offboarding audit scenario that runs 24 hours after each termination’s revocation execution. The scenario queries each application’s user list API and verifies the terminated employee’s account is no longer active. For applications with no user list API, the audit creates a Teamwork™ task for a human access review. The audit result writes to a Google Sheet offboarding completeness log: employee ID, termination date, revocation execution timestamp, applications confirmed revoked, applications requiring manual verification. Review the log weekly for any pattern of revocation failures in specific applications — persistent failures indicate the application’s revocation API has changed and the Make.com™ module needs updating.

Expert Take — Jeff Arnold, 4Spot Consulting™

The risk calculus on offboarding automation is straightforward: the cost of a Make.com™ offboarding scenario build is $3,000–$5,000 once. The average cost of an insider threat incident from unrevoked access is $648,000 (Ponemon Institute). The ROI calculation does not require a spreadsheet. What requires attention is the completeness gap — the shadow IT applications that are not in your SSO and not in your inventory. Your automation is only as good as your application inventory.

Key Takeaways

• Trigger on termination decision, not last day — execute immediately for involuntary, schedule for future-dated voluntary terminations.
• SSO-connected applications: single identity provider deactivation call handles all simultaneously.
• Non-SSO applications: individual OAuth token revocation API calls per application via Make.com™ HTTP module.
• Shadow IT gap: quarterly department survey identifies applications not in SSO or SaaS spend management inventory.
• 24-hour post-revocation audit queries application user lists to verify completeness and flags manual verification tasks for API-less applications.

Frequently Asked Questions

How do you handle shared credentials that a terminated employee knew?

Shared credentials (service accounts, team logins) that a terminated employee knew require immediate credential rotation — not just access revocation. Make.com™ creates a high-priority Teamwork™ task for each known shared credential on the offboarding trigger, with the credential name, the rotation deadline (same business day for involuntary terminations), and the application owner assigned. Shared credentials are your highest-risk offboarding exposure because they survive OAuth token revocation.

What is the legal requirement for access revocation timing?

No US federal law specifies an access revocation timeline, but SOX Section 302/404 compliance requires timely revocation for employees with access to financial systems. State data protection laws (CCPA, NY SHIELD Act) require reasonable security measures including access management. Best practice — and the standard most cyber liability insurers require — is same-day revocation for involuntary terminations and end-of-last-day revocation for voluntary terminations.

How do you handle access revocation for contractors who are not in your HRIS?

Contractors who are not in your HRIS require a separate offboarding trigger: a form submission from the engagement manager when the contract ends. Create a Make.com™ scenario triggered by form submission (Gravity Forms or Typeform) that executes the same access revocation sequence as the HRIS-triggered employee scenario. Maintain a contractor access inventory (Google Sheet updated on contractor onboarding) that the revocation scenario reads to determine which applications to deprovision.