the contractor who's been gone for eight months

In March 2025, a mid-market SaaS company hired a creative agency for a rebrand. Scope: a six-month engagement, five agency people working closely with the marketing team, full access to the Google Drive brand folder, Figma workspace, Notion pages for campaign planning, and two Slack channels.

The engagement ended in September. The final deliverables were accepted, the invoice was paid, and the relationship ended warmly. Nobody from the agency has been in a meeting with the company since.

In April 2026, seven months after the engagement closed, an internal access audit found the following. All five agency contacts still had active Google accounts federated through their agency domain, with their original access scopes unchanged. Three of the five had been reassigned to other agency clients. One had left the agency entirely and was now working at a competitor. The fifth had started her own consultancy. Each of them, from any device they still used, could log in and read the company’s brand assets, campaign strategy docs, and Slack message history from the engagement.

Nobody at the company had been bad. Nobody at the agency had been bad. The engagement had simply ended the way most engagements end, through a series of emails that trailed off, a final invoice, a Slack channel that went quiet, and nothing else. The access, which had been granted through a process, was not revoked by any process. It persisted, because persistence is what access does when nothing actively removes it.

This pattern applies to contractors, consultants, agencies, freelancers, and vendor implementation teams. It is the offboarding problem every company solves for employees and no company solves for anyone else.

the HR workflow stops at the W-2

Employee offboarding, in a company that has been through a SOC 2 audit or similar, has a workflow. Last day gets entered in the HRIS. The HRIS fires events. SCIM propagates the deprovisioning. Tickets get filed for anything that isn’t SCIM-integrated. A checklist runs. Somebody, usually a lightly-resourced IT generalist, walks through the applications not covered by SCIM and removes the person manually.

The workflow has gaps. The gaps are well-documented. Every identity vendor’s pitch deck includes the statistic about departed employees retaining access. But at least a workflow exists. There is a named system that is supposed to handle the case. When it fails, the failure is attributable and fixable.

For contractors, freelancers, and agency staff, the equivalent workflow does not exist. These identities are typically not in the HRIS, because the HRIS is for W-2 employees. They might be in a contractor management system, if the company has one, most mid-market companies don’t. They might be in an AP system, because someone has to pay them. The AP system doesn’t fire identity events. The AP system fires invoice events.

The end of a contractor relationship, from the identity provider’s perspective, is a silent event. Nothing in the HRIS changed. Nothing in the AP system fired a signal. The Slack channel went quiet. The final invoice was paid. No identity lifecycle event was generated anywhere. The person’s account continues to exist, because the event that would remove it was never raised.

Multiply this across every agency engagement, every consulting arrangement, every freelance gig, every vendor implementation project the company has run over the last five years. Each of those engagements ended the same way, without a deprovisioning trigger. Each of them left its access graph behind, unchanged, indefinite.

why a contractor's access has no natural end date

an employee leaves

one clear trigger

• HR records an end date
• The end date disables the account in the identity provider
• Payroll closes, and someone notices if it doesn't

a contractor leaves

three parties, no trigger

• The end lives in a purchase order or an email
• Access may come from the agency's login or a guest account
• Nobody is told, so nothing is switched off

the three-way problem

Contractor identity has a structural complication that employee identity doesn’t. There are three parties involved, and each of them has partial information.

The client company, the one that paid for the work, knows the engagement started and ended. It doesn’t know what’s happening inside the contractor’s life between engagements. It doesn’t know when the contractor left the agency, switched clients, retired, died, or got hired by the client’s competitor. Those events happen in a third-party HR context the client cannot observe.

The contractor’s own organization, the agency, the consultancy, or the contractor themselves if they’re solo, knows what’s happening with their identity. They know when someone left the agency. They might even deprovision that person’s agency account. What they don’t control is the dozen client-side accounts that person accumulated across client engagements. Those accounts live in client systems, managed by client IT.

The identity provider, Okta, Entra, whatever SSO system, knows only what both parties have communicated to it. If the agency federates its employees through its own IdP and the client federates access for the agency through a guest arrangement, you have at least two federation relationships in play. Deprovisioning requires all three parties to coordinate. In practice, none of them do.

The consequence is that a contractor’s access to a client system persists until the client explicitly removes it. The agency’s internal offboarding of that contractor, however well-run, does not propagate to the client. The contractor’s departure from the agency does not send a signal to every client that agency works with. Each client is on its own to detect and respond.

Detection requires the client to be watching. In most mid-market companies, nobody is watching contractor accounts specifically. Contractor accounts sit in the general SSO pool, categorized only by a tag or a group membership, and aging silently.

the engagement end is undefined

Even within the single client company, the end of a contractor engagement is rarely a sharp event. Employee termination has a date and a last day. Contractor engagement end is a fuzzy process.

A consulting project delivers its final report on October 15. The consultants remain available for questions through November. A follow-up conversation happens in January about a possible phase two. Phase two gets funded in March and the same consultants come back. Between October and March, their access was continuously active, because nobody made the call to shut it off and restart it, because restarting would have been annoying and they might be coming back.

An agency engagement ends on December 31. The invoice is paid in February. A retainer agreement is signed in March for ongoing brand support at a reduced scope. The contractors who worked on the original engagement might or might not be on the new retainer. Their access, from December through March, is in limbo, nobody has said the engagement ended in a way that would trigger cleanup, because a successor engagement is under negotiation. When the retainer starts, the original access stays in place.

A freelance designer finishes a project on June 1. No follow-on work is planned. Nobody tells the designer that the engagement is over, because no such notification is a normal part of freelance work. The designer moves on to other clients. Their Figma access to the original client remains active for years, until somebody happens to look.

The employee model assumes a termination event. The contractor model frequently has no termination event. The absence of a clean ending is how the access survives indefinitely.

where a contractor's access usually lives

• guest accountin your identity provider, with no end date
• agency single sign-onfederated from their side
• direct tool accountscreated inside a SaaS tool, outside SSO
• repository collaboratoradded to one repo, never removed
• shared loginsthe password they were given on day one
• VPN or remote accessoften tied to a certificate

often still openusually handled

the agency pattern specifically

Agencies have a specific pattern worth separating from the general contractor case, because the pattern is common and the blast radius is wider than most clients realize.

A creative agency, a marketing agency, or a development agency typically staffs each client engagement with a team. The team might be three to eight people depending on the engagement size. Each team member gets client-side access, usually through their agency email, federated via guest access or direct account provisioning.

The engagement ends. The agency moves the team to other clients. Within the agency, this is normal, staff move between client accounts all the time. From the original client’s perspective, those people have no ongoing relationship with the company. They do, however, still have their access tokens and their account provisions.

Now layer on agency churn. Agency turnover is historically higher than most industries. The average agency creative stays at an agency for about two years. Over a five-year window, an agency that staffed eight people on a client engagement has likely turned over most of them. Those people have left the agency. They’re now at other agencies, or at client companies, or running their own shops.

Their client-side access from the original engagement, unless the client actively removed it, persists through the departure from the agency. An ex-employee of an agency, no longer associated with the agency at all, can still have an active account in a client’s Google Workspace, tied to an agency email that may or may not still forward correctly.

This pattern compounds. A mid-market company that has worked with five agencies over three years, with an average team size of six people and typical churn, has somewhere between forty and eighty ex-agency contractors with residual access. None of them is currently doing any work for the company. Some of them have forgotten the account exists. A few of them are now employees of competitors. The client has no idea which is which, because the client never had a system that tracked agency churn.

the vendor implementation tail

A specific subcase worth isolating: the vendor implementation team.

When a mid-market company buys a non-trivial SaaS product, a new CRM, a new ERP, a new analytics platform, the purchase typically comes with an implementation engagement. The vendor’s services team, or a contracted implementation partner, gets deep access during the setup period. Admin-level access in the target system. Often admin-level access in adjacent systems, because implementation requires integrations.

The implementation period is usually three to nine months. During that time, the implementation team has what amounts to privileged access across multiple critical systems. They configure things, load data, build integrations, set up reports, train end users.

The implementation completes. The contract moves to a support arrangement, or to no arrangement at all. The implementation team moves on to the next client.

Their privileged admin access on the client’s CRM, ERP, or analytics platform, granted for the implementation, almost always remains in place. The client’s admin, who may or may not have been closely involved with the implementation, knows that “the vendor has some admins on the system.” Some of those admins are current employees of the vendor’s services team. Some are former employees. Some have moved to the vendor’s competitor. All of them are still configured in the system.

A year after implementation, nobody reviews this. Two years after implementation, the client has forgotten which specific people from the implementation were granted admin. Three years after implementation, the implementation partner has reorganized its services team twice, and the client has no current contacts at the partner who can even tell them which of the residual admin accounts are still valid.

The residual admin accounts on critical enterprise systems are the highest-stakes version of the contractor problem. They have the most privilege, they are rarely reviewed, and they come from a relationship that the client cannot easily audit because it’s inside a partner’s staffing model.

the specific workflow that’s missing

The fix for this problem has a specific shape. It is straightforward to describe and organizationally uncomfortable to implement.

Every contractor, consultant, agency staffer, and vendor implementer who gets a client-side account needs an engagement end date set at the time of provisioning. The end date should be the estimated engagement completion, with a default buffer of thirty days. On that date, the account is disabled automatically, unless someone explicitly extends it.

Extensions require a new end date, not an indefinite extension. There is no “active indefinitely” state for contractor accounts. Every extension is time-bound and requires a justification.

The owning business relationship, the internal person who hired the contractor, is responsible for the account. If that person leaves the company, the account is flagged for re-ownership review. If re-ownership cannot be established within thirty days, the account is disabled.

At the end of every contractor engagement, a specific closeout task runs. The closeout task is owned by the business owner, not by IT. The task asks: is the engagement still active? If no, disable access. If yes, what is the updated end date?

The workflow has a single organizational requirement that most companies resist. Someone internal needs to own each contractor relationship from an access perspective, with the understanding that the ownership includes responsibility for ending it. In practice, “ownership” of contractor relationships usually lives with the business sponsor who hired them, and that person has no incentive to focus on ending the access because their focus is on getting the work done.

This is a governance problem more than a technical one. The technical piece is trivial, expiration dates on accounts, automated disablement, reminder emails to business owners. The governance piece is getting the company to agree that contractor accounts need owners, and that owners need to pay attention to them.

the specific discovery exercise

If you run IT or security at a mid-market company, here is the exercise that will surface the scale of this problem in your environment.

Pull a list of every account in your identity provider that is flagged as “external,” “guest,” “contractor,” “partner,” or whatever category your company uses for non-employees. If you don’t have such a category, pull every account whose email domain is not your company’s primary domain. Call this list L.

For each account on L, pull the last login timestamp and the provisioning timestamp. Sort the list by last login, oldest first.

Everything on L with a last login more than 180 days ago is a candidate for immediate disablement. The contractor is either no longer active, no longer needs the access, or hasn’t noticed they still have it. Any of those three is a reason to disable.

Everything on L with a provisioning date more than twelve months ago is a candidate for renewal review. The engagement that originally justified the account was approved in some previous quarter. The current quarter’s business owner may not remember what the engagement was for. That’s the conversation to have.

For the accounts with privileged access specifically, anything in the admin or elevated tier, the review should be immediate regardless of last login. An inactive admin account is a higher-risk artifact than an inactive standard account, because the account is one compromise away from full privileges on a critical system.

The first time a company runs this exercise, the share of external accounts in one of the categories above is usually larger than anyone expected. That is the point of running it. It becomes routine if you run it quarterly.

The routine version is what you want. The first-time version is the one you need to do to see the shape of the problem.

The contractor who finished their work eight months ago is still an account in your identity provider. The agency team that wrapped the rebrand is still listed as collaborators on your brand drive. The implementation partner’s services team from two years ago is still admin on your CRM. None of these people are doing work for you. All of them still could read, copy, or change your data today.

The employee offboarding workflow runs on last-day events that don’t exist for these people. The substitute workflow has to be owned, named, and scheduled, because nothing else will raise the event for you.