Soffid Solutions for Digital Enterprises:

SSO answers "can this person log in," not "should they still have this access" — it centralizes authentication but says nothing about entitlement scope, dormant permissions, or why a given grant exists in the first place. Governance requires periodic certification, ownership assignment, and policy enforcement across every app in the stack, and most of that stack was adopted outside your SSO provider entirely. An IGA layer sits on top of your existing SSO and IdP, using them as an identity source while adding the review, certification, and lifecycle logic they were never designed to provide. Soffid is built to plug into existing Okta or Azure AD deployments this way rather than replace them.

Shadow SaaS gets adopted through expense reports and free-tier signups rather than IT tickets, so it can't be found by scanning SSO logs alone — you need discovery methods like OAuth grant scanning against Google Workspace or Microsoft 365, expense/card-transaction review, and browser or CASB-based detection. The realistic goal isn't a single clean inventory but a continuously refreshed one, since new signups happen every week regardless of policy. Treating this as an ongoing governance process rather than a one-time cleanup project is what keeps the resulting list actually usable.

The gap exists because deprovisioning usually stops at the identity provider or core directory, while dozens of SaaS apps were never connected to it in the first place. Closing it means mapping every app an employee actually has access to — not just the ones IT provisioned — and triggering deprovisioning the moment HR marks someone as terminated, rather than relying on a ticket reaching every app owner individually. Where an app supports SCIM or an API this can be automated end-to-end; where it doesn't, the access at minimum needs to surface on an owner's revocation checklist so it isn't simply forgotten.

Building this inventory starts with combining three sources: your IdP's app catalog, OAuth-grant data from your core productivity suite, and finance/procurement records for anything paid by card. Each discovered app then needs an assigned business owner — not IT by default — since IT can confirm an app exists but usually can't say whether a given person still needs access to it. The list only stays accurate if it's treated as a living governance artifact reviewed on a recurring cycle, not a spreadsheet built once during an audit and left to rot.

Only the subset of your stack with SCIM or a usable provisioning API can be certified and remediated automatically end-to-end. For the long tail without it, automation still helps by surfacing who has access and routing a certification decision to the right reviewer — the gap is that revoking access on those apps still requires a manual step by an app owner or admin. That's still a meaningfully better position than a fully manual, spreadsheet-driven review, since the review itself and the audit trail are automated even when the last-mile action isn't.

No, but it does mean governance has to happen at the account level rather than the protocol level: someone is designated as the accountable owner, access to that specific tool is captured in the same certification cycle as everything else, and revocation becomes a manual but tracked task instead of an invisible one. The goal for these apps isn't automation parity with your SCIM-enabled stack — it's making sure they aren't simply excluded from the review process because they're inconvenient, which is exactly how orphaned accounts accumulate.

Building this in-house usually starts as a spreadsheet or lightweight internal tool and works fine at a handful of apps — the problem is it doesn't scale past that without ongoing engineering investment lean IT teams rarely have spare capacity for, and it tends to quietly stop being maintained the moment its owner moves to another project. A platform built specifically for access governance also comes with the certification workflows, audit trail, and connector library an internal tool would take years to replicate. For most growth-stage teams the real comparison isn't "tool versus free" — it's ongoing engineering time against a subscription, and the former is usually the more expensive option once maintenance is accounted for.

Non-human identities need the same lifecycle discipline as human ones: an assigned owner, a defined purpose, an expected credential rotation schedule, and inclusion in access certification — an API key or OAuth grant with excess scope is just as exploitable as an over-privileged user account, and often longer-lived since nobody offboards a service account. The practical starting point is inventorying OAuth app-to-app connections and service accounts alongside human identities in the same governance system, rather than treating them as a separate security problem, since access risk doesn't change based on whether a human or a script is holding the credential.