M ManySignal

Use Case: Identity & HR

Offboarding access gaps

IT disabled the Okta account. 14 SaaS apps still had active accounts. The former employee's GitHub access included write permissions to the main production repository. ManySignal found the gaps in 3 minutes.

The offboarding problem

SSO disabled. 14 apps still active.

SCIM-based automated provisioning has improved offboarding for applications that support it — when an Okta account is deactivated, SCIM pushes the deactivation to connected apps. But most enterprise SaaS portfolios include dozens of applications that were set up manually before SCIM was available, or that don't support SCIM, or that have direct API access that bypasses SSO entirely. These apps retain active accounts regardless of what happens to the IdP account.

ManySignal's offboarding verification workflow queries every connected system when an HR departure event fires, identifies remaining access, and either auto-revokes it (for apps with API revocation support) or creates a tracked ticket for manual revocation with a deadline.

workflow: offboarding_verification
trigger: hr_event.status == "terminated"
steps:
  - immediate: disable_primary_sso_account (Okta/Entra)
  - parallel_check:
    - saas_apps: query each connected app for active account
    - cloud_access: aws_iam, gcp_sa, azure_sp active keys
    - active_sessions: oauth_tokens, refresh_tokens, api_keys
    - code_access: github_org_membership, deploy_keys
    - vpn_certificates: revoke client certificates
  - for each gap found:
    - has_api: auto_revoke + log
    - no_api: create_ticket(assignee=it_team, sla=24h)
  - verification_report: send to hr + security within 1h

MITRE ATT&CK mapping

T1078 — Valid AccountsT1550.001 — Application Access Token

Offboarding gaps FAQ

How does ManySignal get notified of employee departures?

ManySignal integrates with Workday, BambooHR, ADP, SAP SuccessFactors, and custom HR APIs via webhook or scheduled sync. When an employee's status changes to 'terminating' or 'terminated', ManySignal immediately begins the offboarding verification workflow — checking each connected system for active accounts and sessions.

What's the typical offboarding gap rate in enterprise organizations?

Internal assessments and IAM audits consistently find that 15-30% of employee accounts in non-primary systems (SaaS apps, cloud projects, shared environments) remain active after departure. The primary SSO account is usually disabled promptly; the connected SaaS apps that weren't provisioned through SCIM are the persistent gap.

Does ManySignal check for active sessions, not just enabled accounts?

Yes. Even after an account is disabled at the IdP level, pre-existing sessions (OAuth tokens, API keys, refresh tokens) may remain valid. ManySignal checks for active session tokens across all connected applications and revokes them as part of the offboarding workflow — this is critical for SaaS apps that have long-lived tokens.

Can ManySignal handle rehire scenarios where an offboarded account needs to be reactivated?

Yes. Rehire workflows are triggered when an HR event shows a returning employee. ManySignal flags any previously offboarded account reactivation for review, comparing the new role and access scope against the previous assignment. This prevents both security gaps (missing access) and security risks (over-provisioning based on historical access).

Close every access gap within 1 hour of departure

HR-triggered offboarding verification across every connected system — with auto-revocation where available.