The Great Unmanaged
You are listening to a Wednesday “Headline” feature from Bare Metal Cyber Magazine, developed by Bare Metal Cyber. Think about a simple request on a change calendar: someone asks to onboard an external analytics contractor with temporary access for ninety days. The project ships, the team moves on, and six quarters later that account is still live in production. It might be tied to a shared mailbox nobody really owns, with wider access than anyone now remembers approving. No one is quite sure who extended it, and no one wants to be the person who turns it off. In many environments, that pattern is not an exception. It is how things normally work. The quiet accumulation of non-employee access is the perimeter attackers see first.
Modern organizations run on people who will never appear on the payroll list. Implementation partners shape your cloud deployments. Managed service providers tweak production settings. Niche consultants dip into finance or human resources data for a quarter at a time. Outsourced support teams impersonate customers inside your flagship product. Logistics partners, system integrators, and boutique development shops all have their own slices of your environment. None of those people are employees, but all of them can reach assets your board would describe as critical. From an identity perspective, they are not at the edge of your world. They are woven through the middle of it.
Most of these non-employee identities arrive through reasonable, even essential, business decisions. A product team under deadline brings in a specialist to unlock a bottleneck. A key vendor wants deep access so they can resolve incidents more quickly. A new partner arrives with a strong reference and a polished pitch deck, and nobody wants to sour the relationship by opening with a long debate over least privilege and expiry dates. The easy path is obvious: give them what they need to start delivering value, and promise to tighten things later. Later rarely comes. Each new admin console, shared configuration, or remote support channel becomes another door opened for good reasons and left ajar indefinitely.
Over time, you end up with dozens or hundreds of external individuals and teams who can reset passwords, push code, modify entitlements, or pull reports on sensitive data, all under the label of “partner access.” The risk is not only the malicious actor hiding behind a vendor account. It is also the well-meaning contractor who reuses passwords across clients, the small supplier whose own defenses are weak, or the support engineer who clicks the wrong link on a busy day. These identities are attractive to attackers precisely because they sit in a grey zone: powerful enough to matter, peripheral enough that no one inside your organization truly feels accountable for them.
Temporary access does not usually break in a dramatic way. It breaks by never truly ending. A contractor account created for a six-month enterprise resource planning migration, or Enterprise Resource Planning (E R P), 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 quietly reused for every subsequent engagement with that same firm. None of those individual steps feels reckless in the moment. Each one carries an unspoken promise that someone will clean it up later. Almost nobody has both the context and the mandate to do that work.
The mechanics behind this drift are mostly boring and very persistent. Onboarding flows are tuned for speed and for clear business value. Deprovisioning is scattered across tools, queues, and teams that do not see themselves as owners. Service tickets treat creation of access as planned work, with clear deadlines and obvious customers, while revocation is logged as low-priority maintenance. Project teams disband, so the people who know why access was granted are not around when someone wonders whether it is still needed. In hybrid environments, non-employee access lands across cloud consoles, Software as a Service, or S A A S, admin panels, legacy virtual private networks, and “temporary” shared repositories. The people move on; the permissions remain. Over the years, those permissions become part of the mental model of the environment, even when nobody would deliberately design it that way.
Structural change adds yet another layer. Mergers and acquisitions bring in entire ecosystems of contractors, managed service providers, and opaque vendor relationships. In the rush to stabilize operations, teams clone old patterns into new platforms, promising to rationalize them later. Business units hand responsibilities to specialized partners but leave internal access in place as a safety net, creating double exposure. Each reorganization multiplies the number of places where non-employee identities can lose their expiry date. The result is a long tail of accounts, tokens, and federated links that no one has consciously chosen to keep, but that no one feels safe to remove. It is not the outcome of one bad decision; it is the default outcome of a system that never really expects access to end.
Underneath this, many organizations have built identity governance on a simple assumption: the system of record is the human resources platform, or Human Resources (H R). Joiner, mover, and leaver flows are engineered around employee start dates, job functions, and termination events. Entitlements are linked to internal roles that mirror the org chart. That model works reasonably well for people on the payroll. It fails the moment you step into the outer ring of contractors, partners, vendors, and temporary staff whose lifecycles are tracked in contracts, purchase orders, vendor tools, or even spreadsheets rather than in H R. Governance often stops where the payroll file stops. The risk does not.
When non-employee identities live outside the core identity fabric, they accumulate in odd corners. A vendor support team might be managed entirely through a single S A A S admin portal, with accounts created by whichever product owner happens to be online. A strategic partner may authenticate through a custom gateway that nobody has ever tied into central entitlement reviews. Contractors might exist as one-off entries in the directory because “we could not hook them to H R,” which means they never show up in the identity governance dashboard. Meanwhile, vendor management focuses on statements of work, insurance certificates, and price, not on the identities that log into production systems. Ownership for access sits in a foggy space between functions.
The incentives pull in different directions. Procurement pushes for speed and favorable terms. H R is measured on employee experience, not vendor access. Business leaders need external help to deliver roadmaps. Security teams want coherent control, but often lack both the authority and the data to enforce it across non-employees. Without an explicit design, each group optimizes for its own objectives, and non-employee identities predictably fall through the cracks. You end up running two parallel estates: a reasonably governed internal identity world, and a relationship-driven external world that touches the same critical systems. At some point, leaders have to choose whether to pull those non-employee identities into the same governance fabric as employees, adapted for their realities, or to give them their own first-class lifecycle with clear data sources and owners. Hoping that the payroll boundary will somehow act as a security boundary is not a serious option.
Treating non-employee access as a first-class problem begins with naming it and sorting it. Instead of one vague “contractor” label, you can define distinct populations: embedded contractors who work day to day like staff, project-based consultants, vendor support teams, strategic partners, outsourced operations, and so on. Each of those has different patterns of access, sponsorship, and lifecycle events. The aim is not to cram them into a single monolithic process. The aim is to define a small set of clear archetypes and build repeatable paths for each, with expectations about how identities are created, how they are used, and when they are supposed to end. That turns a sea of exceptions into a finite set of designed flows.
Those flows need a system of record, even if it is not H R. That could be a vendor management platform, a project portfolio tool, or a dedicated non-employee registry that tracks which organization the person works for, which contract or statement of work covers their involvement, and who inside your company sponsors them. Access requests for these identities should move through the same approval and logging channels you use for employees, but with extra guardrails: mandatory end dates, a default-deny stance for high-privilege roles, and a clear rule that every identity has a named sponsor who is accountable when reviews come due. Expiry should be the standard outcome, not a special event.
On the technical side, leaders have to decide how non-employee lifecycle hooks into control points. That might mean grouping non-employee accounts into dedicated parts of the directory, enforcing stronger conditional access and multi-factor authentication, or Multi Factor Authentication (M F A), policies for them, and making sure they are always in scope for access reviews. For external partners that connect from their own identity providers, you might never see individual user accounts, but you still control the trust boundary: which roles that federation can assert, which applications it can reach, and when that connection has to be re-attested. The important shift is to design non-employee access as part of your identity architecture from the start, not as a stack of urgent exceptions you keep promising to clean up.
When an incident eventually involves a long-departed contractor account, the surface story often sounds technical. A password was stolen. A session was hijacked. An application programming interface token, or Application Programming Interface (A P I) token, was misused. Underneath that, the real failure is lifecycle and accountability. Somewhere, a contract ended, a project closed, or a vendor relationship changed, and nobody translated that change into access removal. Risk registers and policy documents might mention third-party risk in broad strokes, but the specific identities tied to those relationships were left untouched. Over time, every engagement leaves behind a residue of access that accumulates into a long tail of exposure. You only see that tail clearly when something goes wrong and people start asking who owned the account and why it was still active.
Customers, regulators, and auditors are increasingly uninterested in vague appeals to shared responsibility. If a breach runs through third-party access into your environment, it is your name that appears in headlines and your customers who feel harmed. Contract language and right-to-audit clauses can move some liability or define cooperation, but they do not repair trust after an incident linked to “temporary” accounts that never expired. Due diligence questionnaires are changing as well. They no longer stop at asking whether you assess your vendors. They ask how you govern the specific channels vendors use to reach your systems, how often you review their access, and what exactly happens when contracts change. A policy sentence that says “vendor access will be periodically reviewed” without concrete lifecycle mechanics is not going to hold up well under scrutiny.
That is why legal, procurement, and security leaders need to spend time in the same conversation. Contracts can and should reference specific identity practices: time-bounded access, mandatory re-attestation for sensitive roles, minimum authentication standards, logging requirements, and clear expectations for incident support. Vendor selection and renewal should factor in whether a partner can actually operate under those conditions, not just say yes in a questionnaire. Internally, boards and risk committees should see third-party access as its own category with visible metrics over time, such as the number of active non-employee identities, the proportion with named sponsors, and progress on reducing aged accounts. Managing the long tail of access is not glamorous, but it is one of the rare levers that directly changes your real exposure when a partner becomes part of an attack path.
Even the best design will stall if the culture does not support turning things off. In some organizations, disabling access feels like a hostile act. Teams worry about slowing a project, upsetting a vendor, or being blamed if something breaks later. So they keep access “just in case,” and the great unmanaged grows. Leaders have to reset that norm. Time-limited access, automatic expiry, and periodic reviews should be seen as normal hygiene, not as acts of bravery. When an identity reaches its end date and is cleanly removed, that should feel as routine as rotating a log file.
Creating that culture means making revocation safe and supported. When access needs to be extended, the sponsor should have to make a conscious, visible decision, ideally with another end date attached, rather than simply bypassing the control. When teams discover obviously stale access, they should have clear authority to close it out and a predictable path to restore it if they later learn it was still needed. Vendor managers and business sponsors should be part of that rhythm, not surprised by it. Over time, you want people to assume that access will end unless there is a good reason to keep it, instead of assuming that access is forever unless someone fights to remove it.
At its core, this entire issue is about whether your organization is willing to treat non-employee identities as a designed part of your security model, instead of a permanent pile of exceptions. The reality is that your critical systems are touched every day by people who do not appear in H R records but who hold meaningful power in your environment. “Temporary” access tends to drift into permanence, governance often stops at the payroll boundary, and legal mechanisms frequently ignore the very identities that matter most when something goes wrong. The uncomfortable truth is that the great unmanaged is not a fringe problem. It is your actual perimeter.
Changing that picture does not require an instant, sweeping program. It requires a sequence of deliberate choices. You can start by defining non-employee populations explicitly and deciding where ownership for their lifecycle really sits. You can invest in the fabric that ties contracts, sponsorship, and access together, and design time-bounded access as the default. You can build re-attestation into the normal business rhythm, and make sure that every external identity with meaningful access can be traced to a living business owner. Most of all, you can give teams permission to turn things off, and back them when they do, even when it is inconvenient in the short term.
A practical way forward is to choose one slice of the problem and bring it into focus. Pick a critical application used by multiple partners, a category of contractors with broad privileges, or a cluster of “temporary” groups that never expire. Ask who owns those identities, how they are supposed to end, and what it would take to make expiry the default outcome rather than the exception. The answers will show you how far you have to go, and where the highest leverage changes sit. The great unmanaged will not shrink on its own. Once you choose to see it clearly, you can design it into something you are prepared to explain, defend, and continuously improve.
