The vendor account problem is a specific version of identity sprawl that most IT teams recognize immediately. You start with a reasonable naming convention and good intentions. Two years later you have 200 accounts with the VN prefix, half of which probably belong to vendors whose contracts expired, and you are not sure which half.

The issue is not that you failed to govern vendor access. It is that the mechanisms for governing it, AD account expiry dates set manually, spreadsheets updated when someone remembers, and naming conventions that only you understand, are not connected to the information that would make them reliable. You do not know if the vendor account should still exist because nothing in your system knows whether the vendor contract is still active.

Fixing this requires connecting two things that are usually managed separately: identity and access on one side, vendor contract status on the other.

Why Vendor Access Is Harder Than Employee Access

Employee lifecycle is reasonably well-defined: someone is hired, they work, they leave. HR records these events and IT can hook into them for provisioning and deprovisioning. The connection between the HR event and the access change is at least theoretically possible to automate.

Vendor lifecycle is messier. A vendor's contract status lives in procurement or finance, not in IT systems. A vendor representative may leave their employer and be replaced by a colleague using a different account, leaving the old account active. Contracts renew silently or lapse without formal IT notification. A vendor you brought in for a specific project two years ago still has their account because nobody thought to terminate it when the project ended.

The consequence is a growing population of external accounts with unclear status, unknown access scope, and no clear owner to make the decommission decision.

The Minimal Control Set That Actually Works

The practitioner community consensus from the Reddit thread is consistent and practical: external vendor accounts should not have persistent, always-on access. The controls that come up repeatedly are:

Mandatory account expiry. Every vendor account should have an expiration date set at creation. When the account expires, access is blocked automatically. The vendor or their internal sponsor has to actively request an extension, which forces a periodic review without requiring someone to proactively audit a spreadsheet. Setting expiry at 6 to 12 months is common; the right duration depends on the contract term and the nature of the work.

Separate OU for external accounts. Putting all vendor accounts in a dedicated organizational unit makes them queryable as a group. You can run last-login reports, apply specific policies, and review the population without having to distinguish them by naming convention.

Request-based access activation. Requiring vendors to request access each time they need it, rather than having always-on access, reduces the exposure window. For vendors who need regular access, a supervisor can approve a session or a standing access grant with a time limit. For infrequent access, the account stays locked until a ticket is raised.

Sponsored accounts. Every external account should have a named internal sponsor who is accountable for whether the account should exist and whether the vendor still has a valid business relationship. When the sponsor leaves the company or the project ends, a review of their sponsored accounts should be triggered.

These controls are achievable with Active Directory and a ticketing system. They do not require purpose-built software. But they do require consistent execution, which is where the spreadsheet approach breaks down.

The Structural Gap: Contract Status and Access Are Disconnected

The question the OP raised, "I'm not sure if they should have access anymore or if they even still have a valid contract," identifies the core gap.

An IT admin cannot reliably answer the "should they still have access" question without knowing the answer to "is the contract still active." That information lives in procurement or finance. An IT admin either has to chase it manually or guess based on last login dates.

The scalable solution connects these two systems. When a contract is recorded with a start date and end date, the access governance layer should surface that information alongside the account status. When the contract end date approaches, automated alerts should go to both the contract owner and the access reviewer. When the contract expires, the account should be flagged for review or deactivated automatically.

This is the "one stop shop" the OP was looking for: not a separate vendor management system, but a governance layer that connects contract data to identity data and surfaces the combination.

How Zluri Addresses Vendor Identity Sprawl

Zluri operates as an identity governance platform that addresses the vendor access problem through several specific capabilities.

Automatic identity categorization. Rather than relying on naming conventions to distinguish vendors from employees, Zluri classifies identities based on configurable rules: email domain, email address patterns (.ext, .ctr, or vendor-specific domains), HR attributes, or directory OU membership. Once categorized as External, vendor accounts are queryable and manageable as a distinct population separate from the employee identity lifecycle.

Scoped access reviews for external accounts. Zluri's access review module can run certification campaigns scoped specifically to the External user category. Internal sponsors receive a list of the vendor accounts they own, along with current access scope, and are prompted to confirm continued need or revoke access. If a reviewer revokes access, Zluri automatically triggers a deprovisioning playbook that removes the account from connected systems. This converts the "I'm not sure who still needs access" problem into a structured process with documented outcomes.

Contract management with automated alerts. Zluri includes a contract management module where vendor agreements can be logged with start date, end date, and associated vendor details. Automated alerts fire at configurable intervals before contract expiry (60, 30, 15, and 1 day), going to the IT or finance owner responsible for the relationship. This means "is the contract still active" becomes an answerable question within the same platform rather than a call to the procurement team.

Time-bound access for new vendor onboarding. When a vendor or their internal sponsor requests system access, the request includes an access duration. When that duration expires, a deprovisioning playbook runs automatically and the account access is revoked. No manual follow-up required, no accounts that persist indefinitely because someone forgot to set an expiry date.

Continuous discovery for shadow vendor access. Zluri's discovery engine surfaces applications in use across the organization, including SaaS tools that individual teams have given vendor access to without IT visibility. Vendor accounts in systems IT does not know about are exactly the accounts that never get cleaned up. Discovery brings them into the governance scope.

Cleaning Up the Existing Mess

The immediate cleanup problem requires a different approach from the ongoing governance solution.

For the legacy vendor accounts with unclear status, the practical starting point is a targeted access review: generate a list of all External accounts, identify their last login date, and send the list to internal sponsors for review. Accounts with no sponsor and no logins in the past year are candidates for immediate deactivation (with a grace period to catch any "reliable system" vendors who only log in once a year for maintenance).

For accounts with identified sponsors, the review question is: does this vendor still have an active contract and a current business need? If the sponsor cannot answer yes to both, the account should be deactivated.

Running this as a formal campaign with documented approvals and outcomes produces an audit trail that shows when the cleanup happened and what decisions were made. This is more defensible than a bulk deletion with no record.

Once the legacy accounts are cleaned up, the ongoing governance controls prevent the same accumulation from happening again: mandatory expiry at creation, sponsor assignment, contract tracking, and time-bound access for new vendor onboarding.

The Audit Trail Requirement

Vendor access in particular draws scrutiny in compliance audits because external parties with system access represent a third-party risk. Auditors want to see that vendor access is granted through a controlled process, that it is reviewed periodically, and that it is revoked when the business relationship ends.

An audit trail that consists of AD account expiry dates and a Smartsheet does not tell the complete story. A governance platform that logs every access grant with requester, approver, timestamp, and duration, combined with a record of every access review and its outcomes, provides the evidence chain auditors actually need.