Contractors have no HR record: the identity lifecycle nobody owns
Every identity lifecycle automation in the enterprise is anchored to an HR event. Between fifteen and forty percent of the identities in a large estate belong to people the HR system has never heard of, and for them the lifecycle is a ticket and a hope.
Who owns a contractor's identity lifecycle?
Nobody, structurally. Employees are created and terminated by HR events with a system behind them. Contractors, vendors, auditors and partners are created by a ticket and terminated by someone remembering, and the person who would remember has usually moved on themselves.
- Lifecycle automation depends on an authoritative source. Non-employees have none, so the sponsoring manager is a free-text field and the end date is optimistic.
- Renewal by signature inverts the failure mode: authority lapses unless someone affirmatively extends it.
- Count your non-employee identities before anything else — the number is usually a surprise and it is what funds the work.
Part of Access governance and certification
What I learned from a licence audit
We were reconciling software licences and found six hundred accounts we could not attribute to anyone. Not orphaned employee accounts — those we knew how to find. These were contractors, auditors, partner engineers, agency designers, and a category the spreadsheet called external.
We had been paying for the licences, which is how we noticed. What we had not noticed was that a meaningful fraction still had working access to systems those people had no current business reason to enter.
Nobody had done anything wrong. There was simply no event, anywhere in our systems, that corresponded to a contractor's engagement ending.
Why the lifecycle works for employees
An employee's identity lifecycle is driven by HR events: hire, transfer, promotion, leave, termination. The HRIS is authoritative, the events are structured, and joiner-mover-leaver automation subscribes to them.
That architecture is genuinely good, and it is why employee offboarding works reasonably well in most enterprises. It also explains precisely why non-employee offboarding does not: the subscription has nothing to subscribe to.
The population, counted
| Population | Authoritative source | Termination event exists? |
|---|---|---|
| Employees | HRIS | Yes |
| Contingent workers via a managed service provider | VMS, sometimes | Sometimes, if integrated |
| Direct contractors | A ticket | No |
| Vendor support engineers | A contract | No |
| Auditors and assessors | An engagement letter | No |
| Partner staff on joint projects | An email thread | No |
| Interns and temporary staff | Varies | Frequently no |
Rows three through seven are where the residual access accumulates, and in most enterprises they collectively outnumber row two.
Why hard end dates do not work
The obvious answer is to require an end date at provisioning and expire automatically. Most organisations have tried it.
What happens is that the end date is set optimistically, the engagement runs long, the contractor loses access mid-project, someone escalates, and the service desk extends it — by a year, to avoid the same interruption. Within two cycles the end date is a formality.
The failure is not the date. It is that extension is easier than renewal, and it requires no one to reconsider anything.
Sponsor accountability
Make issuance and renewal a signed act by a named sponsor.
{
"type": "manav-stmt/1",
"action": "non_employee_identity_issued",
"subject": "[name, organisation]",
"purpose": "[engagement, project reference]",
"scope": "[systems and access levels]",
"notAfter": "[date — 90 days maximum]",
"sponsor": "[named employee, credential assertion]",
"renewal_requires": "fresh_signature"
}The last line is the mechanism. Renewal is not a date edit performed by a service desk agent; it is a new signature by the sponsor, who must therefore re-form an opinion about whether the access is still needed.
Ninety days, not a year
The interval matters more than it appears. Ninety days means a typical six-month engagement requires one renewal — enough to catch engagements that ended early, few enough not to become noise.
A twelve-month interval recreates the original problem at a slower cadence, and twelve months is what organisations choose when they optimise for sponsor convenience rather than for the control's purpose.
What to count first
- Identities in your directory with no corresponding HRIS record. That is the population.
- Of those, how many have authenticated in the last 30 days, 90 days, and never.
- Of those, how many have a populated sponsor field, and how many of those sponsors are current employees.
- Licence cost attached to the population, which is the number that makes this a finance conversation rather than a security one.
Step four is the one I would run first, because it is what got our audit funded. The security argument was correct and the licence bill was persuasive.
The sponsor model
The fix is not a new system but a named accountable person per non-employee identity, with an expiry by default. If the sponsor leaves, the identity is flagged rather than orphaned, and renewal is an affirmative act rather than an omission.
| Property | Effect |
|---|---|
| A named sponsor, not a team | Teams do not remember; people do |
| Expiry by default | Persistence requires a decision |
| Sponsor departure triggers review | The most common orphaning cause |
| Renewal is a signed act | Someone owns the continued access |
Objections and honest limits
“Our access reviews catch orphaned accounts.” Quarterly at best, and a review asks a manager about an account whose purpose they may not know. Expiry by default catches it without anyone reviewing anything.
“Contractors need long-lived access.” Many do, and renewing every ninety days is a signature rather than a re-onboarding. The cost is proportionate to the risk of an indefinite grant.
Implementing sponsorship
- Require a named sponsor at creation. A person, never a team or a ticket queue.
- Set expiry by default. Ninety days is a reasonable starting point.
- Trigger review on sponsor departure. The most common cause of orphaning.
- Make renewal a signed act. So continued access has an owner.
Terms used here
- Non-employee identity
- A contractor, vendor, auditor or partner account, created outside the HR lifecycle.
- Sponsor
- The named individual accountable for a non-employee identity's existence and scope.
- Orphaned account
- An identity whose sponsor or purpose no longer exists, which persists because nothing triggers its removal.
Frequently asked questions
What about contingent workers managed through a VMS? If the VMS is integrated as an authoritative source, they behave like employees for lifecycle purposes. The problem is everyone outside that integration.
Will sponsors accept quarterly renewal? A signature takes seconds. The friction is receiving the request, which is a notification design problem rather than a burden problem.
What happens when a sponsor leaves? Their sponsored identities surface immediately as needing a new sponsor, which is the correct outcome and is currently invisible.
Is ninety days too aggressive? For a six-month engagement it is one renewal. Longer intervals restore the problem; shorter ones become noise. Ninety is a defensible default, not a rule.
Why do contractor accounts outlive contracts? Because deprovisioning depends on someone remembering, and there is no system event equivalent to an HR termination.
Why a named sponsor rather than a team? Teams do not remember. A named person can be asked, and their departure is a detectable trigger.
Is expiry by default disruptive? Renewal is a signature, not a re-onboarding. The cost is proportionate to the risk of an indefinite grant.
Where this fits in Manav
Manav turns an access or elevation decision into an artefact: what the approver was shown, who they were, what authority they held, signed and verifiable without your systems.
Sources and further reading
- 2026 research on residual access among departing and non-employee populations.
- Verizon Data Breach Investigations Report
- SAP / Oracle segregation of duties control guidance (ISACA)
- NIST SP 800-53 Rev. 5 — access enforcement