Why Orphaned Credentials Stay Open Long After Contractors Leave
The offboarding checklist says it's done. HR closed the laptop. The Slack account is deactivated. The contractor is gone—professionally, at least. But somewhere in your AWS IAM console, a service account they created is still active. An API key they generated for a Zapier integration is still accepting requests. A read-write token they used to connect your CRM to a data warehouse is still valid and completely unmonitored.
This is not a theoretical scenario. It is one of the most common and least-discussed security failures in organisations with between 10 and 500 staff. The reason it persists is structurally predictable: credential creation is easy, credential revocation requires deliberate process, and most small teams have no formal process at all.
Contractors and freelancers sit at the worst intersection of access and oversight. They are often onboarded quickly, given broad access to get up to speed fast, and offboarded informally—a final invoice, a thank-you email, and a handshake. The technical accounts they touched during their engagement rarely appear on any checklist because nobody mapped them comprehensively in the first place. The developer who spent three months building your payment integration may have created several different credentials across multiple systems. Your internal team may know about only a fraction of them.
The threat is compounded by the velocity of modern work. Contractors rotate frequently. Projects spin up and wind down. Third-party tools proliferate as teams adopt SaaS solutions to solve immediate problems without security review. Each connection point creates a new credential. Each credential without an owner is a door without a lock. Over an extended period of normal business operation, a small SaaS company can accumulate a significant number of orphaned credentials across its technology stack—none of them flagged, none of them expiring, all of them quietly exploitable.
The Hidden Attack Surface Inside Your Third-Party Integrations
Orphaned contractor credentials are only one dimension of the problem. The deeper, less visible attack surface lives inside your third-party integrations themselves—the API connections, OAuth grants, webhook endpoints, and service-to-service tokens that glue your technology stack together.
Consider a typical SaaS business operating at modest scale. It might connect its CRM to a marketing automation platform, pipe billing events to an accounting tool, sync support tickets into a project management system, and use a no-code automation platform to bridge gaps between tools. Each of these integrations involves credentials. Many credentials are granted broad scope because developers often request elevated permissions to avoid repeated authentication errors during setup. Many of those credentials are stored as plaintext environment variables. Almost none of them are rotated on any schedule.
From a threat exposure perspective, each integration is a lateral movement opportunity. If an attacker compromises a third-party vendor in your supply chain—the accounting tool, the marketing platform, the no-code automation service—they may inherit access tokens that grant them read or write access to your core systems. Supply chain attacks of this nature have been well-documented, including in guidance from the Cybersecurity and Infrastructure Security Agency (CISA). This attack vector affects organisations of all sizes, but SMEs typically have less visibility and fewer compensating controls than large enterprises.
OAuth grant proliferation deserves specific attention. When a team member connects a new tool using OAuth, an access grant is created in the background. That grant persists until explicitly revoked—which almost never happens. When the team member leaves, the grant remains. When the tool is abandoned for a better alternative, the grant remains. Your Google Workspace or Microsoft 365 admin console almost certainly contains OAuth grants that staff cannot fully explain or account for. Each one represents a third party with a persistent claim on your data.
The operational reality for SMEs is that this attack surface grows faster than most small security teams can monitor manually. Without a structured approach, the credential estate becomes a sprawling, undocumented liability that is essentially invisible until something goes wrong.
What Vendor and Third-Party Risk Management Actually Covers
Vendor and Third-Party Risk Management is frequently framed as a compliance exercise—a questionnaire you send to suppliers before signing a contract, filed away and never revisited. That framing dramatically undersells what the discipline actually does and why it matters operationally for organisations without dedicated security teams.
At its core, Vendor and Third-Party Risk Management is the continuous practice of understanding, assessing, and controlling the risk that external parties introduce into your environment. It spans the full lifecycle of a third-party relationship: initial due diligence before onboarding, access provisioning during engagement, ongoing monitoring throughout the relationship, and structured offboarding when the relationship ends.
For credential management specifically, Vendor and Third-Party Risk Management provides the governance framework that answers four questions your team probably cannot answer today: Who has access to what? Why do they have it? When did they get it? And does that access still need to exist?
In practice, this translates into several concrete disciplines. A vendor inventory ensures you know every external party with access to your systems, data, or infrastructure. An access register maps which credentials exist, what they permit, and who is responsible for reviewing them. A minimum-privilege policy ensures credentials are scoped as narrowly as possible at the point of creation. A credential lifecycle process governs rotation schedules and revocation triggers. And an offboarding protocol ensures that when a vendor relationship or contractor engagement ends, every access path is identified and closed—not just the obvious ones.
For regulated organisations, Vendor and Third-Party Risk Management is also the mechanism that satisfies a growing body of regulatory expectation. Frameworks including ISO 27001, SOC 2, GDPR, and sector-specific regulations in financial services and healthcare all include requirements around third-party access control and supply chain security. A mature vendor risk programme does not just reduce technical risk—it generates the documented evidence that demonstrates compliance when auditors come asking.
The important distinction for SMEs is that Vendor and Third-Party Risk Management does not require enterprise infrastructure to be effective. It requires process, documentation, and regular review cadence. These are achievable without a dedicated security function if the right framework and support are in place.
Building a Credential Lifecycle Process Small Teams Can Sustain
The most common reason credential hygiene fails in small organisations is not negligence—it is the absence of a sustainable process. A credential lifecycle process does not need to be elaborate. It needs to be consistent, documented, and owned.
Start with an inventory. Before you can manage credentials, you need to know they exist. Run an audit across your key systems: cloud providers, identity platforms, SaaS tools with API access, development environments, and integration platforms. Export service accounts, API keys, OAuth grants, and personal access tokens. For each credential, capture the system it accesses, the level of permission it holds, the date it was created, and the name of the person or service it was created for. This single exercise will almost always surface credentials that nobody on your current team can account for.
Next, assign ownership. Every credential should have a named internal owner—not the contractor who created it, not the vendor who uses it, but an internal team member who is accountable for reviewing it on a defined schedule. Without internal ownership, credentials become ownerless assets that persist indefinitely.
Define a rotation policy appropriate to your risk profile. Production API keys with write access to sensitive systems should rotate on a reasonably short cycle—many security practitioners recommend quarterly as a starting point, with more frequent rotation for high-risk integrations. Read-only keys in lower-risk contexts might rotate semi-annually. The important thing is that rotation is scheduled and enforced, not left to chance.
Build offboarding into your project closure process. When a contractor engagement ends, the project closeout should include a mandatory credential review: identify every system they accessed, every key they generated, every OAuth grant they initiated, and revoke or transfer each one before the final invoice is paid. This step is most effective when it is a formal gate—not a best-effort afterthought.
Finally, implement Just-In-Time access where your tooling supports it. Rather than issuing persistent credentials, some platforms allow time-bound access grants that expire automatically. This removes the revocation burden entirely for short-duration access needs and is increasingly available across major cloud and identity providers.
For a team of three to ten people managing security part-time, this process can be embedded into existing quarterly reviews without significant overhead. The initial audit is the heaviest lift. Maintaining the inventory from that point forward is a continuous but manageable discipline.
Red Flags in Your Current Vendor Access Audit Trail
If your organisation has never conducted a formal vendor access review, there are specific signals that indicate your credential estate is likely carrying significant unmanaged risk. Recognising these red flags is the first step toward understanding the scope of your exposure.
Credentials with no expiry date and no rotation history are the most obvious signal. In most systems, an API key or service account that was created more than 12 months ago and has never been rotated is a credential that has never been reviewed. If it is still active and still in use, that may be operationally necessary—but if it is active and you cannot confirm it is in use, it is an orphaned credential by another name.
Access grants associated with email addresses that no longer exist in your identity directory are a direct indicator of orphaned contractor or ex-employee credentials. If an OAuth grant is linked to an account belonging to a freelancer who finished an engagement some time ago, that grant is still active and still usable by anyone with access to that account.
Over-permissioned credentials are a structural red flag. If your third-party analytics platform has admin-level API access to your production database because the developer who set it up defaulted to maximum permissions, that is a misconfiguration that has likely been silently present for months or years. An access review will surface the mismatch between what a credential needs to do and what it is actually permitted to do.
Vendors who cannot provide evidence of their own security controls are a process red flag. If a supplier holds sensitive data or has privileged access to your systems and cannot answer basic questions about their access management practices, encryption standards, or incident response capability, your exposure through that relationship is difficult to bound. A vendor risk questionnaire and periodic review cycle is the mechanism for identifying these gaps before they become your problem.
Finally, the absence of a vendor access log itself is a red flag. If you cannot answer the question of who accessed what and when for your key third-party integrations, you have no detection capability for misuse. Logging and monitoring of third-party access is a foundational control, not an advanced one.
Closing the Gap Without an Enterprise Security Budget
The common assumption among SME leadership is that the controls necessary to close the third-party credential gap are expensive—that they require enterprise identity platforms, dedicated security staff, or lengthy implementation programmes. For many organisations, that assumption does not reflect what is actually available to them today.
The foundational controls described in this article—credential inventory, access ownership, rotation schedules, and offboarding protocols—are process controls. They cost time and discipline, not significant budget. A spreadsheet-based vendor access register, maintained honestly and reviewed quarterly, closes more risk than an expensive tool that nobody uses consistently. The process is the product.
For identity and access management tooling, many of the platforms SMEs already use include capability that goes underutilised. Google Workspace and Microsoft 365 both provide OAuth grant visibility and third-party app management in their admin consoles. AWS IAM Access Analyzer identifies unused permissions and external access grants. GitHub and GitLab both surface stale tokens and personal access keys. The tools to begin this work are frequently already in your stack—they simply require someone to look.
For organisations that need structured support without the overhead of building an in-house security function, working with a managed security partner who specialises in continuous threat exposure management provides a scalable alternative. The right partner brings a vendor risk framework, conducts the initial credential audit, maintains the inventory, and runs the quarterly review cycle as an ongoing managed service. For a smaller company, this may be more cost-effective than hiring a dedicated security engineer, and it helps ensure the discipline is sustained rather than deprioritised when operational pressure builds.
Regulated organisations in particular benefit from this approach because the documented evidence generated by a formal Vendor and Third-Party Risk Management programme satisfies audit requirements directly. The quarterly vendor access review becomes the evidence file. The offboarding records become the compliance artefact. The work serves two purposes simultaneously—operational risk reduction and demonstrable compliance—without requiring double the effort.
The contractor who left some months ago with their API key still active is not an exotic threat scenario. It is a routine consequence of operating without a credential lifecycle process. Vendor and Third-Party Risk Management is the discipline that closes that gap—not because compliance requires it, but because the alternative is an attack surface that grows silently while your attention is elsewhere. For SMEs without a dedicated security team, getting this right is less about resources than about building the habit of asking, consistently and on schedule: who still has access, and should they?