Deprovisioning: find and close the orphaned accounts you already have

If you run IT for a 50 to 500 person company and an access review or an ISO 27001 audit just turned up active accounts belonging to people who left, this page is for you. If you are looking for the definition of the word, the first section covers it in thirty seconds.

Deprovisioning is the removal of a user's access rights, accounts and permissions when they leave the organisation, change role or finish a contract. An orphaned account is what remains when that removal is incomplete: an active account with no legitimate owner. Fixing your offboarding process stops new orphaned accounts from appearing. It does not close the ones already open, and those sit mostly in applications your identity provider never covered.

What is deprovisioning, and what exactly does it remove?

Deprovisioning is the operational half of identity lifecycle management that runs in reverse. Where provisioning creates an identity, assigns entitlements and grants access, deprovisioning withdraws them: it disables authentication, revokes application entitlements, terminates active sessions, reassigns owned data and retires credentials such as API keys and tokens.

It is triggered by three events, not one. A leaver ends employment. A mover changes role and should lose the entitlements attached to the previous one. A contract or project ends. The second and third triggers are where most companies silently fail, because only the first is usually wired to the HR system.

Is a deprovisioned account disabled or deleted?

The sources that rank on this question do not agree, and the difference has legal consequences. Beyond Identity describes deprovisioning as access withdrawn across systems simultaneously. Delinea describes an asset that is deactivated or deleted. Saviynt adds the removal of credentials and personal data. Fordham University's IT policy defines it as access being suspended or disabled.

The arbitration is not a matter of preference. Under ISO/IEC 27001:2022, Annex A control 5.18, all changes to a user's access rights must be logged, and control 6.5 covers responsibilities that survive the end of employment. You cannot produce that log for an account you have erased. Under the GDPR, Article 5(1)(e) limits how long personal data is kept in an identifiable form, which pushes in the opposite direction.

The workable answer for a mid-market IT team: disable first, delete on a documented schedule. Disable immediately so the account cannot authenticate, keep the record and its access history for the retention period your ISMS and your privacy policy define, then delete. Anyone telling you to delete on day one is optimising for tidiness at the expense of your next audit.

What is an orphaned account?

An orphaned account is an active account with no identifiable owner, usually left behind when deprovisioning was incomplete. It differs from a dormant account, which has an owner but no recent activity, and from a stale account, which is simply unused. Orphaned is the dangerous category, because there is nobody to notice the login. The owner may be a former employee, a former contractor, or nobody at all in the case of a service account whose creator has since left. A fuller definition sits in the Corma orphaned accounts glossary entry, alongside the entry for deprovisioning.

Your offboarding is clean. Your account inventory is not.

Most published advice on this topic treats deprovisioning as a process problem: get the HRIS trigger right, connect the identity provider, run the checklist. That advice is correct and it solves the flow. It does nothing about the stock.

The stock is the set of accounts already open right now, created before your process was tightened, in applications your process never covered. No leaver event will fire for them, because there is no leaver record to fire from. They are found by inventory, not by workflow.

The scale of that gap is visible in Corma's published customer stories. In each case, the company had an inventory it believed to be accurate, and discovery returned a different number.

Satelia is the clearest case, because the consequence was documented. The company could not progress towards ISO 27001 and SOC 2 certification without an auditable view of the SaaS in use, and its own account of the project attributes the unblocking to gaining that view. The full story is published as Satelia's identity governance case study.

Read the table as a ratio rather than a set of absolute numbers. At every size from 30 to 340 employees, the real application estate was materially larger than the tracked one. Every application in that difference can hold accounts that your leaver process never touched.

A warning about the risk figures you will meet while researching this topic. The page currently ranking first on this query, OneLogin's guide to user provisioning and deprovisioning, still quotes an average data breach cost of 148 dollars per record and 7.91 million dollars per breach in the United States, on a page whose metadata shows it was modified on 21 August 2026. That figure is an IBM number from 2018, and IBM stopped leading with cost per record years ago. The 2026 edition of the IBM Cost of a Data Breach Report, published on 29 July 2026, puts the global average at 4.99 million dollars and the United States average at 11.5 million. Check the vintage of any breach statistic before you put it in a board paper.

Where do orphaned accounts actually come from?

They come from four places, and only one of them is the one most articles describe.

Applications your identity provider never covered

Your identity provider is authoritative for the applications connected to it. It is silent about everything else. A team buys a tool on a corporate card, connects it with email and password, and it never appears in the SSO catalogue. When someone leaves, disabling their directory account closes the front door and leaves that tool untouched.

This is not a hypothetical. On r/sysadmin, a practitioner running Okta for SSO described roughly 40 applications that had never been properly integrated with the identity stack, including internal engineering tools. That gap is exactly where orphaned accounts survive, and closing it needs discovery that works inside and outside the SSO perimeter, through the browser and the endpoint rather than through the directory alone.

Contractors who never entered the HRIS

Freelancers, agency staff and interim specialists are frequently onboarded outside HR. They get accounts, they finish the engagement, and no termination record is ever created, so no trigger fires. The regulatory framing is explicit here: Regulation (EU) 2024/2690 requires access rights for third parties such as suppliers and service providers to be limited in scope and in duration, which presupposes you know they exist.

Movers, the leavers nobody declares

An internal transfer is a partial leaver event. The person keeps their identity and should lose a set of entitlements. In practice they accumulate. After two or three moves, an employee holds a permission set that reflects a career rather than a job, and each abandoned entitlement is an orphaned permission attached to a live account.

What if the vendor charges extra for SSO?

This objection comes up constantly and almost nobody writes about it. As one IT manager put it on r/ITManagers, when the vendor either does not support SSO or prices it into a higher tier, the team cannot do anything about it at the identity layer. That is a budget constraint, not a security decision, and it produces a permanent population of accounts outside the perimeter.

The workaround is not to fight the pricing. It is to treat those applications as a named exception list with a manual or agent-driven offboarding step attached, and to keep that list short deliberately. Corma covers the technical options in its guide to managing offboarding for apps without SCIM, SAML or SSO.

The accounts that have no leaving date

Service accounts, API tokens, OAuth integrations and AI agents are identities. They authenticate, they hold permissions, and they move data. They also have no employment record, no manager and no last day, which means no HR-driven process will ever deprovision them.

Nikolai Fomm, COO and co-founder of Corma, put the problem directly in an article published on 17 August 2026: these identities were never provisioned through your identity provider, they do not appear in your leaver checklist, and most of them have no owner. The full argument is in Corma's guide to non-human identity security, with a definition in the non-human identity glossary entry.

The volume is the part that surprises IT teams. Obsidian Security reports that its customers typically arrive with around 900 OAuth integrations connected to Google, 750 to Microsoft and 150 to Salesforce, and that over 70 percent of those integrations have been inactive for 90 days or more while retaining their granted permissions. An API key created in 2022 for a one-off migration, pasted into a spreadsheet and never revoked, is functionally a permanent credential with no expiry.

This category is where most competing content stops short. It is also where the regulation is clearest, as the next sections show.

How to find the orphaned accounts you already have

Discovery is a reconciliation exercise. You are looking for accounts that exist in an application but have no matching active person in your source of truth. Five steps, in this order.

1. Fix a source of truth. Export the current active roster from the HRIS, plus a separate list of active contractors and service providers. Without this list, everything downstream is guesswork.
2. Export every account from every connected application. Start with the identity provider, then go application by application through your SSO catalogue. This gives you the easy half.
3. Find the applications that are not in the catalogue. Cross-reference expense reports and card statements, the OAuth grant lists in Google Workspace and Microsoft 365, DNS or proxy logs, and browser or endpoint telemetry. This step is what turns 30 known applications into 160, and it is the step manual audits skip.
4. Reconcile and classify. Match every account against the roster. Anything unmatched falls into one of four buckets: leaver, contractor whose engagement ended, mover with residual entitlements, or non-human identity with no owner. Assign an owner to each non-human identity or mark it for retirement.
5. Record the finding before you act. Capture the account, the application, the last login and the date you found it. This record is your audit evidence and your baseline for the next review.

Step 3 is where a manual approach breaks down, because you cannot inventory applications you do not know exist, and the list changes every month. Running this as a recurring control rather than a one-off project is the difference between a clean audit and a repeat finding. Corma's automated access reviews surface unowned accounts on a schedule and produce the reviewer decisions as evidence, which is the same artefact an assessor will ask for.

How to close them without breaking anything

Deleting an account that owns a shared drive, a billing relationship or a production integration causes an outage. Work in this order.

1. Disable authentication first. Suspend the account and terminate active sessions. This stops the risk immediately and is reversible if you have misclassified something.
2. Check what the account owns. Documents, calendars, repositories, billing seats, integrations and automations. Reassign ownership before going further.
3. Revoke credentials separately. Disabling a user account does not always kill the API tokens, personal access tokens or OAuth grants that account created. Revoke them explicitly.
4. Reclaim the licence. An orphaned account is usually a paid seat. This is the part of the exercise that funds itself.
5. Delete on schedule, not on impulse. Apply the retention period defined in your policy, then delete and log the deletion.

The time saving is real but modest per event, which is why the stock matters more than the flow. A 30 person e-commerce company using Corma reports gaining between 20 and 30 percent of the time previously spent on each onboarding and offboarding. Applied to a backlog of several hundred unmatched accounts, that ratio is what makes the clean-up finishable at all.

What ISO 27001, NIS2 and GDPR expect once you have found them

Finding orphaned accounts creates an obligation. Auditors do not grade the discovery, they grade what you did next and whether you can show it. The three frameworks below treat the same two risks differently: unauthorised access by someone who should no longer have it, and the inability to demonstrate that access was removed at all.

Two details in the NIS2 implementing regulation are worth reading closely, because almost no vendor content covers them. First, Annex point 11.5.1 requires entities to manage the full life cycle of identities of network and information systems and their users, which brings service accounts and machine identities inside the obligation rather than leaving them as a best practice. Second, Annex point 12.5 requires that where an asset cannot be returned or deleted at the end of employment, the entity must ensure it can no longer access its systems. That is a direct instruction about the residual access this article is concerned with.

One scope caveat that matters and is often glossed over: Regulation (EU) 2024/2690 sets these technical requirements for a defined list of entity types, including cloud computing service providers, data centre providers, managed service providers, online marketplaces and trust service providers. Article 21(2) of the directive applies more broadly, but the granular annex points above are binding for those categories. Check which applies to you before quoting a paragraph number to your board.

Corma itself is ISO/IEC 27001:2022 certified and audited annually by an independent third party, and hosts customer data in the EU.

The deprovisioning checklist that stops new orphaned accounts

Once the backlog is cleared, the job is to stop rebuilding it. This checklist covers the leaver event itself.

• The HRIS termination record is the single trigger, and it fires automatically.
• Directory account suspended and all sessions terminated on the last working day, not the following week.
• Access revoked in every connected application, with the non-SSO exception list handled explicitly rather than forgotten.
• Document, calendar and repository ownership transferred to a named person.
• API tokens, personal access tokens, OAuth grants and shared credentials created by the account revoked or rotated.
• Licences reclaimed and the saving recorded.
• Contractor and project end dates treated as termination events with the same workflow.
• A per-leaver record produced automatically, so the evidence exists before anyone asks for it.

The full mechanics of building this, including the HRIS to identity provider wiring and the SCIM and SAML foundations, are covered in Corma's guide to automating IT onboarding and offboarding. That guide handles the flow. This page handles the stock, and the two are meant to be run together.

Why Corma

Corma is a European platform that combines SaaS management with identity and access management (IAM) in one product, which is what makes the stock problem tractable. Most IAM tools govern what is already connected to them, so their view of your estate is exactly as complete as your integrations are. Corma starts by finding what is not connected, then governs it, which is why the compliance reporting reflects the real estate rather than the catalogued one.

• Discovery inside and outside SSO, through the browser and the endpoint as well as through API connectors, which is what surfaces the applications a directory export cannot see.
• Automated access reviews that flag unowned and unmatched accounts on a recurring schedule and capture reviewer decisions as evidence.
• Zero-touch joiner, mover and leaver workflows built on native connectors to Google Workspace, Microsoft Entra ID, Okta and JumpCloud, so Corma governs on top of your identity provider instead of replacing it. See automated user provisioning and clean offboarding.
• Non-human identity and shadow AI detection, covering the OAuth grants, service accounts and agents that no leaver process reaches.
• EU hosting and ISO/IEC 27001:2022 certification, with GDPR and NIS2 framing built into the reporting rather than bolted on.

Frequently asked questions

What is the difference between deprovisioning and deleting an account?

Deprovisioning removes access: it disables authentication, revokes entitlements and terminates sessions. Deleting removes the account record itself, along with its access history. Deprovisioning should happen immediately. Deletion should happen later, on a documented retention schedule, because the record is the evidence an ISO 27001 or SOC 2 assessor asks for.

What does it mean to be deprovisioned?

Being deprovisioned means an account's access rights, permissions and application entitlements have been withdrawn because the person or system no longer needs them. It normally follows a departure, a role change or the end of a contract, and it should cover every application the account touched, not only the directory.

How do I find orphaned accounts in apps that are not connected to SSO?

Reconcile from outside the identity provider. Cross-reference expense and card data to find purchased tools, review OAuth grant lists in Google Workspace and Microsoft 365, check DNS or proxy logs, and use browser or endpoint discovery. Then compare each application's user list against your active roster. Accounts with no matching active person are your candidates.

What do I do when a vendor charges extra for SSO?

Treat those applications as a named exception list rather than pretending they are covered. Assign each one an owner, add an explicit manual or automated offboarding step to the leaver workflow, and review the list quarterly. Keeping the list short and visible is more effective than paying for every SSO upgrade.

How long can an orphaned account stay open before it becomes an audit finding?

There is no universal grace period, and assessors judge against your own documented policy. For entities covered by Regulation (EU) 2024/2690, identities that are no longer needed must be deactivated without delay. In practice, privileged accounts are expected to be revoked the same day, and a standing population of unmatched accounts is a finding regardless of the age of any single one.

Are service accounts and API tokens orphaned accounts?

They become orphaned accounts as soon as nobody owns them, which is common because they have no leaving date to trigger a review. Regulation (EU) 2024/2690 explicitly covers the life cycle of identities of network and information systems as well as their users, so these are in scope for governance, not optional extras.