The request looked simple on the change calendar: “Onboard external analytics contractor – temporary access, 90 days.” Six quarters later, the same account is still active in production, tied to a shared mailbox no one really owns, with access to far more than the original scope. No one remembers who approved the extension. No one wants to be the person who turns it off. And in most environments, this is not an exception; it is the default. That quiet accumulation of non-employee access is the real perimeter your attackers see.
This Wednesday “Headline” feature in Bare Metal Cyber Magazine looks at a problem most leaders recognize but rarely treat as a first-class design question: what happens when contractors, partners, vendors, and temporary staff never really “leave” your environment? Over the next few years, as organizations lean harder on external talent and embedded partners, those non-employee identities will define more of your effective attack surface than your official org chart. The tools, workflows, and risk models built around employee lifecycles were never designed for this growing outer ring of people who are essential to your operations but sit outside your HR systems and often outside your governance model.
For security and technology leaders, the hard part is not spotting one or two obvious zombie accounts. It is deciding whether non-employee access is going to remain a series of ad hoc exceptions or become a deliberately engineered identity population with clear ownership, lifecycles, and limits. That decision shapes everything that follows: which systems you instrument, which processes you harden, which teams you empower, and how you talk about third-party risk with your board and customers. This article argues that treating these identities as “edge cases” is no longer viable. The great unmanaged is already here; the question is whether you choose to see it and design for it.
The Perimeter of People You Don’t Employ
If you map who actually touches your critical systems on a given day, the picture does not look like your HR roster. It looks like an ecosystem. Implementation partners have deep hooks into your cloud platforms. Managed service providers can see and change production configurations. Niche consultants carry elevated access to finance or HR data for “just this quarter.” Outsourced support teams can impersonate customers in your flagship product. Logistics partners, integrators, and boutique dev shops all have their own slices of your environment. None of them are on your payroll. All of them are inside your effective perimeter.
In many organizations, these non-employee identities arrive through the most well-intentioned channels: business owners who need to move quickly, project teams under deadline, vendor relationships that feel too important to slow down. A new partner shows up with a strong reference and a clean marketing deck, so no one wants to start the relationship by arguing about least privilege or access expiry. The path of least resistance is clear: “Just give them what they need to get started; we’ll tighten it later.” Later rarely comes. Each new integration, shared admin console, and remote support capability becomes another door in the wall, opened for good reasons and then left ajar.
This is how you end up with dozens, sometimes hundreds, of external individuals and teams who can reset passwords, push code, modify entitlements, or pull reports on sensitive data, all under the banner of “partner access.” The risk is not only the malicious outsider who abuses that access; it is also the well-meaning vendor who gets phished, the contractor who reuses credentials across clients, or the small partner who runs without security monitoring you would tolerate internally. From an attacker’s perspective, these identities are attractive because they sit in the grey zone: powerful enough to matter, peripheral enough that no one feels truly accountable for them.
For security and technology leaders, the first shift is conceptual. The perimeter is no longer the line between employees and the outside world. It is the set of people and systems, regardless of who pays their salary, who can meaningfully change your environment or extract value from it. Once you see that, contractors, partners, and temporary staff are not exceptions to your identity model. They are at the heart of it.
How ‘Temporary’ Access Becomes Permanent Infrastructure
Temporary access almost never fails loudly. It fails by quietly never ending. A contractor account created for a six-month ERP migration gets extended “just until the hypercare period ends.” A shared admin login for a vendor support team is granted broad roles because no one wants to block a critical incident at three in the morning. A partner integration group in your directory is spun up “just for go-live,” and then reused for every subsequent engagement with that vendor. None of these decisions feels dramatic in the moment. Each one carries an implicit promise that someone will circle back and clean it up. Almost no one does.
The mechanics of this drift are usually mundane. Onboarding flows are optimized for speed; deprovisioning flows are fragmented across systems and teams. Ticket queues handle creation as planned work, but revocation is often categorized as low-priority maintenance. Project teams disband, leaving no one with both the context and authority to close out identities they no longer see every day. In hybrid environments, non-employee access gets scattered across cloud consoles, SaaS admin panels, legacy VPNs, and “temporary” shared drives. The people involved move on; the permissions stay. Over time, these once-temporary roles become part of the de facto infrastructure, embedded into scripts, runbooks, and mental models.
Mergers, acquisitions, and organizational reshuffles add more layers. Acquired businesses often arrive with their own consulting contracts, managed service providers, and half-documented vendor portals. In the rush to stabilize operations, teams replicate old access patterns into new environments and promise to “rationalize later.” Business units spin off responsibilities to specialized partners but forget to retire internal access, leaving a double exposure. Each structural shift multiplies the number of places where non-employee identities can lose their expiration date. The result is a long tail of accounts and integrations that no one has deliberately chosen to keep, but that no one feels safe to remove.
Leaders need to see this not as individual oversights but as a system that defaults to permanence. When the easiest path is to grant broad, long-lived access and the hardest path is to revoke or narrow it, the outcome is predictable. “Temporary” becomes a label, not a lifecycle. Treating this as an infrastructure problem means asking different questions: where does time-bounded access actually live in our processes, what must happen for an identity to die cleanly, and how do we design work so that expiry is the normal outcome rather than an act of courage.
When Identity Governance Stops at the Payroll Boundary
In many organizations, identity governance tooling and process design begin with a simple assumption: the source of truth is the HR system. Joiner-mover-leaver flows are built around employee start dates, job codes, and termination events. Entitlements are tied to roles that map neatly to internal org structures. That works reasonably well for people on the payroll. It fails the moment you move into the outer ring of contractors, partners, vendors, and temps whose lifecycle is tracked in contracts, purchase orders, vendor portals, and spreadsheets rather than HR data. The governance perimeter ends where the payroll file ends. The risk does not.
When non-employee identities sit outside the core identity fabric, they accumulate in odd places. A vendor support team might be managed entirely through a SaaS admin console, with individual accounts created by whichever product owner happened to be online. A strategic partner might authenticate through a bespoke portal that no one has integrated into central entitlement reviews. Contractors might exist as one-off entries in the directory with no corresponding record in the identity governance and administration platform, because “we could not hook them to HR.” Meanwhile, vendor management focuses on contracts, insurance certificates, and financial terms, not on the specific identities logging into production systems. Ownership for access sits in a fog.
The incentives are misaligned. Procurement wants speed and favorable terms. HR is measured on employee experience. Business units want external help to get work done. Security wants control but often lacks the authority or data to enforce it across non-employees. Without a clear design, each group optimizes for its own goals, and non-employee identities fall through the cracks. Leaders end up with two parallel worlds: a reasonably governed internal identity estate and a loosely managed, relationship-driven external estate that touches the same critical systems. Closing that gap requires a decision: non-employee access must either be pulled into the same governance fabric as employees, with adapted patterns, or given its own first-class lifecycle with explicit data sources and owners. Pretending the payroll boundary is a security boundary is the most dangerous option of all.
Designing a First-Class Lifecycle for Non-Employees
Treating non-employee access as a first-class problem starts with naming it as such. Instead of a catch-all “contractor” flag, leaders can define distinct populations: embedded contractors working like staff, project-based consultants, vendor support teams, strategic partners, outsourced operations, and so on. Each population has different patterns of access, sponsorship, and lifecycle events. The goal is not to design a single monolithic process that fits everyone poorly. It is to define a small set of clear archetypes and build repeatable paths for each, with explicit expectations about how identities are created, what they can touch, and when they expire. This turns a sea of exceptions into a finite set of designed flows.
From there, governance and architecture decisions become more concrete. Non-employee identities need a system of record, even if it is not HR. That might be a vendor management platform, a project portfolio tool, or a dedicated non-employee registry that tracks who the person is working for, which contract or statement of work they sit under, and who their sponsoring business owner is. Access requests for these identities should flow through the same approval and logging mechanisms used for employees, but with additional constraints: mandatory end dates, default-deny stance for high-privilege roles, and a requirement that every identity has a clearly named sponsor who can be held accountable when reviews come due. Expiry should be the default state, not an optional checkbox.
Leaders also need to decide how to integrate non-employee lifecycle into technical controls. That can include grouping non-employee accounts into dedicated directories or organizational units, enforcing stronger conditional access and multi-factor authentication policies for them, and ensuring they are always in scope for access reviews. For external partners connecting from their own identity providers, you may never see the individual user accounts, but you can still govern the trust relationship: which roles that federation can assert, which applications it can reach, and when that connection must be re-attested. The key is that non-employee access is designed as part of your identity architecture from the outset, with clear flows for onboarding, renewal, and removal, rather than bolted on as a series of urgent exceptions.
Risk, Contracts, and the Long Tail of Access
When a long-departed contractor account is abused in an incident, the technical root cause often looks simple: credentials stolen, session hijacked, or a misused API token. The real failure, though, is lifecycle and accountability. Somewhere, a contract ended, a project closed, or a vendor relationship shifted, and no one translated that change into access removal. Contracts and risk registers may mention third-party risk in broad terms, but the specific identities tied to those relationships keep living in your systems. Over time, every engagement leaves a residue of access that accumulates into a long tail of risk. That tail is invisible until something goes wrong, at which point everyone asks the same question: “Who owned this account, and why was it still active?”
Regulators, customers, and auditors are increasingly uninterested in hand-waving about shared responsibility. When third-party access is involved in a breach, it is your brand on the front page and your customers who feel the impact. Contract language and right-to-audit clauses might shift some liability or set expectations, but they do not rebuild trust after an incident tied to “temporary” access that never ended. Due diligence questionnaires increasingly ask not just whether you assess your vendors, but how you govern the specific ways they access your environment, how often you review that access, and what happens when contracts change. A policy that says “vendor access will be periodically reviewed” without concrete lifecycle mechanics is unlikely to satisfy a determined regulator or an angry customer.
This is where legal, procurement, and security leaders need to meet in the same room. Contracts should reference concrete identity practices: time-bound access, mandatory re-attestation for high-privilege roles, minimum authentication standards, logging and monitoring requirements, and clear incident cooperation clauses. Vendor selection and renewal processes should factor in whether a partner can support those practices in reality, not just on paper. Internally, boards and risk committees should be able to see third-party access as a distinct risk category with metrics over time: number of active non-employee identities, proportion with named sponsors, and reduction in aged accounts. Managing the long tail of access is not glamorous, but it is one of the few levers leaders can pull that directly changes their exposure when, not if, a partner or contractor becomes part of an attack path.
Where Leaders Go From Here
At its heart, this topic is about whether your organization is willing to treat non-employee identities as a designed part of your core security model, or leave them as a permanent collection of exceptions that attackers can quietly exploit. We started with the simple reality that your critical systems are touched every day by people who do not appear on your HR roster, yet hold meaningful power in your environment. From there, we followed how “temporary” access drifts into permanence, how governance tends to stop at the payroll boundary, and how legal and contractual mechanisms often ignore the specific identities that matter most during an incident. The conclusion is uncomfortable but clear: the great unmanaged is not a corner case; it is your actual perimeter.
Closing that gap requires more than a cleanup project. It asks leaders to define non-employee populations explicitly, choose where ownership for their lifecycle sits, and invest in the fabric that ties contracts, sponsorship, and access together. It means designing time-bounded access as the default, building re-attestation into normal business rhythm, and ensuring that every external identity with meaningful access can be traced back to a living business owner. It also means giving teams permission to turn things off, and backing them when they do, even when it feels inconvenient in the short term. Over the coming years, as reliance on contractors, partners, and embedded vendors grows, organizations that make these choices early will find it much easier to explain their third-party risk posture to boards, regulators, and customers.
For security and technology leaders, the next move is not to launch a massive all-or-nothing program. It is to pick a slice of the problem and bring it into focus: a critical application used by multiple partners, a category of contractors with broad access, a cluster of “temporary” groups that never expire. Ask your teams three simple questions: who owns these identities, how do they end, and what would it take to make expiry the default instead of the exception? The answers will tell you how far you have to go, and where to start. The great unmanaged will not shrink on its own. But once you choose to see it, you can design it into something you are willing to defend.
