- › Almost every insider threat program is triggered by HR events, and a large population of people with real access never generates one.
- › Contractors, agency staff, and vendor engineers are onboarded by a manager who needed them and offboarded by nobody in particular.
- › The access they hold is frequently deeper than a comparable employee's, because it was granted to solve a specific problem fast.
- › The failure is structural and not a question of trust, since the process was built around a population these people are not part of.
- › Start by counting them, because most organizations cannot produce the number and the gap between the count and the badge list is the finding.
There is a person who has been coming into your building, or into your systems, three days a week for the past year and a half. They know the codebase. They know which of your internal tools lie to you. They know the name of the person in accounts who can push a payment through quickly.
They have never had a performance review with you, they are not in your org chart, and when they stop coming nobody will send an email about it. Somebody’s cost center pays an agency, and the agency pays them.
Every insider threat program I have looked at is built on a foundation of HR events. A hire runs provisioning, a role change triggers an entitlement review, and a resignation starts a clock so the notice period gets watched. It is a reasonable design and it works well for the population it was designed around, and the problem is that a substantial share of the people holding your access generate none of those events, ever.
The Population Nobody Counts
Ask a security leader how many people have access to their environment and you will usually get the headcount number, occasionally adjusted upward with a vague gesture at contractors. Ask for the actual number of active non-employee identities and the room goes quiet, because answering it means joining data from a system that tracks employees, a procurement system that tracks contracts, and a directory that tracks accounts, and those three have never agreed with one another.
The group is larger and more varied than people expect. It includes staffing agency placements sitting alongside your engineers, managed service provider staff who administer systems on your behalf, vendor support engineers with standing remote access granted during an implementation, consultants who stayed on, seasonal workers, and the developer somebody brought in through a marketplace to fix one thing in 2024.
Every one of those arrived through a different door. Not one of them arrived through the door your process watches.
Why Their Access Is Often Deeper
Here is the part that reverses most people’s intuition. You might expect a contractor to hold less access than an employee doing similar work, on the grounds that they are less established and the organization knows them less well. In practice the opposite is common, and the reason is entirely about how the access got granted.
A contractor is usually brought in because something is urgent. There is a deadline, a migration, an outage, a specialist skill nobody on staff has. The engagement starts with a clear problem and a short runway, and somebody senior is paying real money by the day.
Now think about what happens when that person hits a permissions wall on day three. An employee in the same position waits for the access request to go through the normal queue, because they have other work and they will still be here next month. The contractor escalates, and the manager who is paying for their time by the day approves something broader than necessary so that the blocking does not happen again. Nobody is behaving badly here, and the incentive structure produced a wider grant that it will produce again next time. Then the engagement ends, or drifts into something else, and that access stays exactly where it is.
The Offboarding That Never Fires
An employee leaving triggers a process that has been rehearsed hundreds of times and has an owner. A contract ending triggers an invoice stopping.
That asymmetry is the whole problem, and it is worth being concrete about how the ending actually looks. Contracts lapse rather than conclude. Engagements taper, so the person is around less and less until one week they are not around at all, and no single day is the day they left. A staffing agency reassigns somebody and sends a different person next week, which is a change of human being with no change of account. Somebody goes on a break and comes back in four months, and nobody suspended anything because they were expected back.
None of those produce a moment where a named person is responsible for saying this individual is done. Compare that to a resignation, which produces a date, an email, a checklist, and a manager who has to confirm it happened.
The CrowdSec disclosure last week is the version of this that made the news, where an attacker used the still-live GitHub account of an employee who had just left, and that was a departing employee inside a process designed to catch exactly that. The contractor version fails more quietly and more often, because there is no process to fail.
This Is Not About Trust
I want to be careful here, because there is a version of this argument that turns into suspicion of contractors, and that version is both unpleasant and wrong.
The people in this population are not less trustworthy than your staff. Many of them are more experienced, and the good ones are exactly the people you would hire if you could. Treating them as suspects produces a worse working relationship and does nothing about the actual risk, which sits in your process rather than in their character.
The honest framing is that you have built a control system around a set of life events, and these people live outside those events. That is a design gap. Somebody with no intent to do anything wrong still holds standing access to production eleven months after their engagement ended, and that access is now an asset to anybody who compromises their personal laptop.
This is the same systems-over-people read that applies when the only control you have is the audit log. The behavior follows the design, so the design is the thing to change.
What to Actually Do
Count them first
You cannot manage a population you cannot size. Pull every active identity in your directory, mark the ones that map to a current employee record, and look at what is left. That remainder is your working number, and in most organizations it is a share of headcount that nobody in the room has seen written down before. Expect the first pass to be ugly, since shared accounts, service accounts that are really a person, and accounts whose owner nobody can name are all findings in their own right and not obstacles to finishing the count.
Give every one of them an expiry date
The single highest-value change is making non-employee access time-bound by default. Access is granted until a specific date, and on that date it stops unless somebody renews it deliberately.
The renewal is the point rather than the expiry. Somebody has to look at this person, decide they are still working here, and say so. That is the HR event you were missing, reconstructed out of a calendar entry, and it costs a few minutes per person per quarter.
Name an internal owner for each one
Every non-employee identity needs a named employee who is accountable for it. The agency is not the owner, because the agency does not know what your access means. The owner is the person who asked for this individual and who will be asked, at renewal, whether they are still needed. When nobody can name an owner for an account, you have your answer about whether the account should still exist.
Put the ending in the contract
Procurement can do something security cannot, which is make access termination a term of the agreement rather than a favor. The contract should say who notifies whom when a named individual rolls off, and it should say it in the part of the document somebody actually reads. This is the fix that outlasts you, because it changes what happens by default when nobody is paying attention.
The Number Is the Argument
If you take one thing from this, make it the count. Not a program, not a policy document, not a new tool. Produce the number of active identities in your environment that do not correspond to a current employee, put it next to your headcount, and take both figures to whoever owns risk.
I have watched that single slide do more than a year of advocacy, because the gap between what leadership believes the access population is and what it actually is tends to be large enough to end the conversation about whether this matters. The program work follows naturally once somebody senior has seen the two numbers side by side, and it goes nowhere at all until they have.
Marie Welch is Director of Behavioral Security Operations at Grab The Axe.
With a dual background in I/O Psychology (PhD Candidate) and Business Management (MBA), Marie bridges the gap between clinical rigor and operational strategy. She oversees B2B relations, compliance, and the 'business' of risk management.
View Author Page →
