Provisioning and Deprovisioning: Turning Access Decisions Into Real Accounts

A token that outlived its owner

Daniel left a software company in February. His last day went by the book: HR closed his record, the identity provider disabled his account within minutes, and his laptop went back to IT that afternoon. In October, during an investigation into an unexpected clone of a private repository, the security team finds the request came from a personal access token Daniel had created two years earlier for a build script. Nobody had revoked it, because the code repository doesn’t ask the identity provider before accepting a token. Daniel hadn’t done anything with it; someone had found it in an old script on a shared drive. For eight months, a person who no longer worked there had a working key to the company’s source code, and every dashboard said his access was gone.

Where decisions meet systems

Everything in this module so far has been about decisions. A request is approved. A certification revokes something. A role changes. A policy matches a new hire’s attributes. None of that changes anything in the world until a target system is told about it: an account created in the ERP, a group membership added in the directory, a user removed from the CRM. That last step is provisioning, and its reverse is deprovisioning.

It’s tempting to treat this as plumbing, something the platform does once the interesting governance decisions are made. In practice it’s where a large share of real IGA failures happen. Access that was approved never arrives, so people borrow a colleague’s login. Access that was revoked stays in place because a connector failed quietly at 2 a.m. A leaver’s identity provider account is disabled on time, but their personal API token for the code repository keeps working for another eight months, which is exactly Daniel’s story. Auditors know this, which is why they rarely stop at the approval record and almost always ask for proof that the change happened in the system itself.

The JML article made the case that a workflow reporting success is a claim, not a fact, and that reconciliation is what turns it into evidence. This article goes one level down, into how provisioning actually reaches systems, where it breaks, and what a program does about it.

What provisioning actually does

Provisioning someone into a system is usually more than one operation. The platform has to make sure an account exists, which means finding an existing account that belongs to the person or creating a new one. It sets the account’s attributes: name, email, department, manager, sometimes a cost center or a location that the application uses for its own rules. It adds the entitlements the person should hold, which might be group memberships, application roles, permission sets, or license assignments. And for some systems it has to deliver a first credential, though in most modern setups the account is federated and the person signs in through single sign-on instead.

Each of these steps can go wrong independently. The account is created but the group addition fails. The groups are added but the attribute that the application uses to scope data is wrong, so the person sees another region’s records. The account already existed from a previous job, nobody correlated it, and now the person has two. Thinking of provisioning as a sequence of separate, checkable operations rather than a single “grant access” action is the first step toward getting it right.

Changes during a person’s time in the organization follow the same pattern in smaller pieces. A mover gets entitlements added and removed, attributes updated, sometimes an account in a new system. A name change updates attributes everywhere and ideally nothing else. Those updates matter more than they look: an application that scopes access by department will keep showing a mover their old department’s data until the attribute in that application is updated, even if every group membership was changed correctly.

Before the first create: find what already exists

The most avoidable provisioning mistake is creating an account the person already has. A rehire, a contractor who became an employee, or someone who used a system years ago in another role may already have an account in the target, and creating a second one splits their history and leaves the old account active and unowned. Before creating anything, the platform should try to match existing accounts to the identity using the same correlation rules the identity data model article described, and send uncertain matches to a person instead of guessing.

Naming deserves a decision too. Usernames and email addresses need a convention that handles collisions (the second Sara López in the company), and a policy on reuse. Reassigning a former employee’s email address to a new person is a quiet way to deliver the old person’s password resets, vendor notifications, and occasionally sensitive replies to someone else. Many organizations never reuse addresses for that reason, or wait years before they do.

Order and dependencies

Provisioning across systems has an order, and getting it wrong produces failures that look random. The directory account usually has to exist before anything that reads from it. A SaaS application federated through the identity provider may need the user assigned to the application in the identity provider before SCIM will push them. A mailbox needs a license before it can be created. Group memberships that drive access in downstream applications need to land before those applications sync.

Good provisioning designs make these dependencies explicit, so an operation waits for what it needs instead of failing and being retried until it happens to succeed. The same dependencies run in reverse for removal: an application that pulls its users from a directory group will only see the person disappear after the group membership is removed and the application has synchronized, which may be hours later unless the connector removes them directly.

The ways an IGA platform reaches a system

Every target system is reached through some kind of connector, and the type of connector decides how fast, how reliable, and how verifiable provisioning to that system will be.

SCIM is the closest thing to a universal standard. An application that supports SCIM exposes a REST API with a common schema for users and groups, and any IGA platform or identity provider that speaks SCIM can create, update, disable, and read accounts without custom code. Most modern SaaS applications support it, though often only in their higher-priced tiers, and support varies: some handle users but not groups, some ignore custom attributes, some accept a “deactivate” but can’t be read back to confirm it.

Directory and LDAP connectors cover Active Directory, Entra ID, and other directories. They’re mature and fast, and for many organizations the directory is the single most important target, because so many applications decide access from directory group membership.

Application APIs cover systems with their own REST or SOAP interfaces but no SCIM. These need a connector written for that specific API, either shipped by the IGA vendor or built by the program. They work well and break when the vendor changes the API.

Database connectors write directly into an application’s user and permission tables. They’re common for older, in-house applications. They’re also risky, because they bypass the application’s own logic, so a direct insert can create a user the application considers invalid or skip an audit record the application would normally write.

File-based exchanges send a CSV or similar file to the application, which imports it on a schedule, and read back an export for reconciliation. They’re slow and fragile but sometimes the only option for older systems.

Manual fulfillment, finally, means there is no connector at all. The platform creates a task for a person, usually the system’s administrator, who makes the change by hand and marks the task complete.

flowchart LR
  accTitle: Connector types from the IGA platform to target systems
  accDescr: The IGA platform provisions access through several kinds of connector. SCIM connectors reach modern SaaS applications. Directory connectors reach Active Directory and Entra ID. Custom API connectors reach applications with their own interfaces. Database and file-based connectors reach older in-house systems. Systems with no interface receive manual tasks for an administrator. Reconciliation reads access back from every system, including through exports for the manual ones.
  IGA[IGA platform] --> S[SCIM<br/>modern SaaS]
  IGA --> D[Directory<br/>AD, Entra ID]
  IGA --> A[Custom API<br/>connectors]
  IGA --> F[Database or file<br/>legacy systems]
  IGA --> M[Manual task<br/>no interface]

Disconnected applications

Most organizations have far more applications than connectors. A mid-sized company might run 200 applications and have automated connectors for 40 of them. The rest are disconnected: provisioning to them means a ticket or a task for a human, and nobody knows for sure what access exists in them unless someone exports it.

It’s tempting to treat disconnected applications as out of scope. They’re usually where the risk is. Old finance tools, vendor portals, niche clinical systems, and departmental SaaS bought on a credit card all tend to sit outside the connector list, and they’re exactly the places where a leaver keeps access for months.

A realistic approach ranks disconnected applications by risk and works down the list. For the highest-risk ones, building a connector, or paying for the SaaS tier that includes SCIM, is usually worth it. For the next tier, a scheduled export of users and permissions, loaded into the IGA platform, gives reconciliation something to compare against even if provisioning stays manual. For the rest, manual tasks with a service level and a monthly check are often enough. What doesn’t work is leaving an application entirely outside the program because it has no API; the absence of a connector says nothing about the absence of access.

Manual tasks need the same discipline as any other provisioning path. They should carry exactly what was approved, not a free-text summary. They should have a due date, and overdue tasks should escalate. And the administrator closing the task should not be the only evidence that it was done; the next export or reconciliation should confirm it.

Deprovisioning is harder than provisioning

When provisioning fails, someone notices quickly, because they can’t do their job and they say so. When deprovisioning fails, nobody notices, because the person who still has access usually has no reason to complain. That asymmetry is why most of the attention in a provisioning design should go to removal.

The first decision is what “removal” means. Removing a single entitlement, for a mover or after a certification, is usually straightforward. Removing a whole person, for a leaver, is a sequence with choices in it. Disabling an account immediately stops its use but keeps its data and history. Deleting it frees the license and the namespace but can destroy mailboxes, files, and audit records the organization still needs. Most programs disable immediately on the termination date, or the moment HR records an involuntary termination, and delete later after a defined retention period, once ownership of the person’s files, shared mailboxes, and scheduled jobs has been moved to someone else.

That transfer step is easy to forget. A leaver may own a shared drive folder the whole team uses, a scheduled report that finance depends on, an integration running under their credentials, or the admin account of a SaaS tool the department bought. Deleting their account breaks those things; leaving it active leaves the access open. The answer is a handover task, usually for the manager, with a deadline that comes before deletion.

Single sign-on is not deprovisioning

Disabling a person’s account in the identity provider is the fastest and most important leaver step, and it stops new single sign-on logins to every federated application at once. It’s not the end of the job. Many applications keep sessions alive for hours or days after the last SSO login. Many still have local accounts with their own passwords, created before SSO was set up or kept as a fallback. Developers create personal access tokens and API keys in code repositories and cloud consoles that work without any SSO at all. Mobile apps keep refresh tokens.

So a complete leaver process disables the identity provider account first, then reaches into each high-risk application to disable the local account, revoke sessions, and revoke tokens, through its connector where one exists and by task where it doesn’t. The session management article covered why sessions outlive logins; this is where that becomes a deprovisioning problem.

When operations fail

Connectors fail all the time, and a program that assumes they won’t will slowly accumulate access nobody intended. Target systems go down for maintenance. APIs rate-limit. Passwords for service accounts expire. A field validation rejects a value. A vendor changes an endpoint without notice.

A well-built provisioning engine treats each operation as something that can fail and be retried. Operations go into a queue. Temporary failures are retried with increasing delays, and permanent failures, like a rejected value, are sent to a person instead of being retried forever. Operations are written so that running them twice does no harm, which matters because a retry after a timeout might repeat an operation that actually succeeded the first time. And partial results are recorded honestly: if the account was created but two of five groups failed, the record should say exactly that, not “failed” or “succeeded.”

Removals deserve the most care. A failed grant shows up as a complaint. A failed removal shows up as nothing at all, so failed deprovisioning operations should alert someone and stay visible on a dashboard until they’re resolved, with a tighter service level for privileged access and leavers.

End dates only work if something acts on them

The access request article argued that most access should carry an end date, and the policies article added lifecycle rules for contractors and seasonal staff. Both depend on provisioning to do something when the date arrives. That sounds automatic, and it fails in a few predictable ways.

The expiry job runs at midnight in the platform’s time zone, which is the middle of the working day for a team on the other side of the world, so access disappears while someone is using it, or lingers a full day longer than intended in the other direction. The connector to the target is down on the day of expiry, the removal fails, and nothing retries it because the expiry job only looks at access that expires today. Access with an end date is removed from the role assignment in the IGA platform but the target system is never told, so the platform’s view says the access is gone while the system still has it.

The fixes are unglamorous. Expiry should create removal operations that go through the same retrying queue as any other deprovisioning, rather than a one-shot job. The expiry time should be defined in the person’s own time zone, or set to the end of their working day. Reminders to renew should go out several days ahead, so legitimate renewals don’t depend on someone noticing the access vanish. And reconciliation should specifically look for access that is past its end date but still present in the target, since that’s exactly the gap a failed expiry leaves.

Reconciliation and drift

Reconciliation, introduced in the JML article, is the periodic process of reading the actual accounts and entitlements in each target system, usually called aggregation, and comparing them with what the IGA platform believes should be there. The differences are called drift, and they come in a few recognizable kinds.

Some drift is provisioning that didn’t happen: an approved grant missing from the system, or a revoked entitlement still present. That points to a failed operation or a manual task closed without being done, and the fix is to retry or escalate.

Some is access that appeared without going through the program: someone added a user to a group directly in the directory, or an application admin granted a permission in the console. This is the “side door” from the access request article, and it needs a decision. The access can be revoked, if nobody can justify it. It can be adopted, if it turns out to be legitimate, in which case it should be recorded as an approved assignment with an owner rather than silently accepted. Or it can be flagged for investigation, if it’s privileged or looks suspicious.

And some drift is accounts that don’t correlate to any identity at all: orphan accounts left by people who left before the program existed, test accounts, accounts created for a vendor years ago. Each of these needs an owner found or needs to be disabled.

flowchart TD
  accTitle: Deciding what to do with drift found by reconciliation
  accDescr: Reconciliation compares the access the IGA platform expects with the access found in each target system. If expected access is missing or revoked access is still present, the provisioning operation is retried or escalated. If access exists that the platform never granted, its owner decides whether to revoke it, adopt it as an approved assignment, or investigate it. If an account matches no identity, it is treated as an orphan: an owner is found or the account is disabled.
  R[Reconciliation finds a difference] --> Q{What kind?}
  Q -->|Expected change<br/>not in system| RT[Retry or escalate<br/>the operation]
  Q -->|Access the platform<br/>never granted| DEC{Owner decides}
  DEC --> RV[Revoke]
  DEC --> AD[Adopt as an<br/>approved assignment]
  DEC --> IN[Investigate]
  Q -->|Account with<br/>no identity| OR[Orphan: find an owner<br/>or disable]

How often to reconcile depends on risk and on what the system allows. Directories and core SaaS can usually be aggregated daily or even more often. Large ERPs are sometimes aggregated weekly because a full read is expensive. Disconnected applications are reconciled whenever their export arrives, often monthly. The important thing is that high-risk systems are reconciled often enough that a failed removal or a side-door grant is found in days, not at the next audit.

Some programs go further and let the platform correct drift automatically, removing any access it didn’t grant as soon as it sees it. That’s effective and also blunt; it will remove an emergency fix an administrator made during an outage. Automatic correction works best for well-understood, high-risk entitlements, like membership in privileged directory groups, where any unexplained member should go immediately, with an alert to explain why.

Licenses: the part finance cares about

Most SaaS applications charge per account, so deprovisioning has a cost side that’s easy to use as an argument for the work. An account that stays active after its user leaves keeps consuming a license, and so does an account whose user simply stopped using the application. Reconciliation data, combined with each application’s last-login information, shows both.

Programs that report reclaimed licenses alongside security metrics tend to get budget for connectors more easily. A connector for a SaaS application with a few hundred paid seats often pays for itself in the first year just by removing leavers promptly and reclaiming seats that haven’t been used in 90 days. It also gives application owners a reason to care about deprovisioning that has nothing to do with audits.

Keeping connectors healthy

A connector is software that depends on someone else’s system, and it degrades without anyone touching it. The vendor deprecates an API version. The service account the connector uses has its password expire or its permissions reduced. A new mandatory field appears in the application and every create starts failing. A target system is migrated to a new URL.

The symptoms are often quiet. The most useful single signal is the time since each connector’s last successful aggregation: a connector that hasn’t read its target in four days is a connector whose provisioning is probably failing too. Alongside that, error rates per connector and the size of each retry queue tell you where to look first.

Changes to connectors deserve testing against a non-production copy of the target, with test identities that cover the awkward cases (a rehire, a name change, a mover with a conflicting role). And the connector’s own credentials need the same care as any other privileged account, because an IGA connector usually has rights to create and remove users in the system it manages. A compromised connector account is a direct route to granting access anywhere the program reaches.

Non-human accounts

Service accounts, integration users, and API clients are provisioned too, often outside any process. A developer creates a service account in the cloud console for a new integration, gives it broad permissions to get things working, and moves on. Nobody provisioned it through IGA and nobody will deprovision it when the integration is retired.

Bringing these into the program starts with reconciliation, which finds them as accounts with no human identity. Each one needs an owner, a purpose, and ideally a narrowly scoped technical role, as the role engineering article suggested. New ones should be requested through the same process as human access, with an owner and a review date. And when an application is retired, its service accounts need explicit deprovisioning, because no HR event will ever trigger it.

Worked example: offboarding at a SaaS company

A software company with 900 employees uses about 130 applications. Its identity provider handles SSO for 95 of them, and its IGA platform has SCIM or API connectors for 35. A security review after an incident finds that former employees still had working access to 11 applications months after leaving, mostly through local accounts and personal tokens.

The IAM team starts by classifying the 130 applications. For each, they record whether it uses SSO, whether it allows local logins, whether users can create tokens, how long sessions last, and whether there’s a connector. That classification, built with each application owner, turns into three groups. Twenty-two high-risk applications (the code repository, the cloud consoles, the customer database admin tool, the billing system, the support platform with customer data) get a dedicated deprovisioning step. Sixty medium-risk applications rely on SSO plus a weekly reconciliation. The rest rely on SSO alone.

For the high-risk group, the team builds or enables connectors where possible, which covers 15 of the 22. The leaver workflow now disables the identity provider account at the termination time, then, through those connectors, disables local accounts, revokes sessions, and revokes personal access tokens. For the remaining seven, the workflow creates manual tasks for the application admins with a four-hour service level for involuntary terminations and one business day otherwise.

Reconciliation runs daily for the 22 high-risk applications and weekly for the next tier. In its first run it finds 140 accounts belonging to people who had already left, including 9 active personal access tokens in the code repository and 3 cloud console users with administrator rights. All are disabled the same day, and the tokens are revoked.

Six months later, the time from termination to full removal in the high-risk applications is under four hours for every leaver, reconciliation has found no former employee with access in two consecutive months, and the incident that started the work has a documented control that addresses it.

A shorter example: a legacy system with no API

A credit union’s core banking system dates from the 1990s and has no API. User administration is done by two operators on a terminal screen. Provisioning has always been by email.

The program doesn’t try to build a connector. It sends approved changes to the operators as tasks with the exact profile to grant or remove, tracks a two-day service level, and escalates overdue tasks to the operations manager. It also arranges a nightly export of the user table, which the core system can already produce for its own reporting, and loads it into the IGA platform. Reconciliation against that export confirms each task within a day of completion and catches the occasional change made without a task. It’s slower than an API, and it’s enough to give auditors evidence that every change was approved, executed, and confirmed.

Common mistakes

Treating the connector list as the scope of the program is the biggest one. The applications without connectors are often the ones with the most risk and the least oversight.

Relying on SSO for deprovisioning leaves local accounts, sessions, and tokens behind. Deleting accounts on the termination date destroys data the organization needed and breaks things the leaver owned; disable first, transfer, then delete.

Closing manual tasks without confirmation turns provisioning into an honor system. Retrying failed removals silently, or not at all, lets access survive that everyone believes is gone.

And running reconciliation without acting on what it finds produces long reports of drift that nobody owns. Every category of difference needs a defined response and someone responsible for it.

What to measure

The second row deserves the most attention. Auditors and regulators ask about it directly, and it’s the number that best reflects whether a leaver really leaves.

Where this maps to standards

The technical standard here is SCIM 2.0, defined in RFC 7643 for the schema and RFC 7644 for the protocol, the open way to provision users and groups across domains. The control frameworks all ask for the same outcome in different words. NIST SP 800-53 Rev. 5 covers creating, changing, disabling and removing accounts in AC-2, and its enhancements AC-2(2), AC-2(3) and AC-2(4) add automatic removal of temporary accounts, disabling inactive ones and auditing account actions. PCI DSS v4.0 is the bluntest: requirement 8.2.5 wants access for terminated users revoked immediately, and 8.2.6 wants inactive accounts removed or disabled within 90 days. ISO/IEC 27001:2022, in Annex A 5.18, requires access rights to be provisioned, changed and removed according to defined rules. And the SOC 2 Trust Services Criteria, in CC6.2, expect access to be removed when it’s no longer needed, which auditors test by picking a sample of leavers and checking each one, tokens included.

Closing the loop

Provisioning is where the administration half of IGA, described in the first article of this domain, does its work, and reconciliation is where governance checks that the work happened. Every decision in this module, from approvals to certifications to rule changes, depends on this layer to become real. A program with excellent policies and weak provisioning produces well-documented decisions that the systems never heard about.

Recap

Provisioning turns decisions into changes in real systems, accounts, attributes and entitlements, and every one of those steps can fail on its own. The ways in range from SCIM and directories to custom APIs, databases, files and manual tasks, and the less automated the path, the more the program leans on reconciliation. Disconnected applications carry much of the risk, so they get ranked, the riskiest get connected, the next tier gets reconciled from exports, and none is left out just because it has no API. Removing access is harder than granting it because its failures are silent: disable first, hand over ownership, delete later, and never trust single sign-on to close local accounts, sessions and tokens like the one Daniel left behind. Operations should be retryable, safe to repeat and honestly recorded, with an alert whenever a removal fails, and end dates need a removal that goes through the same retrying queue, in the person’s own time zone, plus a reconciliation that looks specifically for expired access that’s still there. Connectors need watching, above all the time since each last read successfully, and their credentials deserve the same protection as any privileged account. And because reconciliation keeps finding drift, every kind of drift needs a decided response: retry, revoke, adopt, investigate or find an owner.

Three questions to test yourself

1. A leaver’s identity provider account was disabled within ten minutes of termination. List three ways they might still have access to company systems a week later.
2. Reconciliation finds a user in a privileged directory group that no request or rule ever granted. Describe the three possible decisions and what evidence would lead you to each.
3. Why is deleting all of a leaver’s accounts on their last day usually a worse choice than disabling them?

Hands-on exercise

Take five applications you use, at work or personally.

1. For each, find out (or estimate) whether it uses SSO, whether it allows local logins, whether you can create personal tokens or API keys, and how long a session lasts.
2. Classify each as high, medium, or low risk and say which connector type you would use to provision it.
3. Write the deprovisioning steps a leaver process would need for the highest-risk one, in order, including anything that SSO alone wouldn’t close.
4. Decide how often you would reconcile each application and what you would do with an account you found that no one had approved.