The supplier completed the project. Its remote-access account remains enabled because someone might need it again. Then the account identifier appears in exposure evidence.
The main problem is not that a vendor was involved. It is that no one can quickly explain what access is still justified and who is responsible for the decision.
Find the business sponsor
Start with the person or team that requested the access. Confirm the current business purpose, supplier relationship, authorized users, and systems reachable through the account.
NIST's supply-chain risk guidance treats supplier relationships as risks that need ongoing management. Access ownership should continue after procurement and onboarding.
Do not assume the employee who created the account still owns the relationship. Projects move, contracts change, and supplier personnel leave.
Make the access boundary visible
For a hypothetical equipment-maintenance supplier, document the supported equipment, access hours or approval conditions, authentication requirements, and available administrative controls.
Ask whether the supplier uses named identities or one shared login. Record how individual access is removed when a technician changes roles.
An email address in a historical record does not settle who currently controls the vendor account. Use your access records and the supplier's established security contact to confirm ownership.
Coordinate the exposure response
Your team can review the account and resources it administers. The supplier may need to review its own identities or endpoints.
Agree on action owners, a secure evidence-sharing channel, and a confirmation deadline. Share only the context required for the review; avoid distributing complete exposed passwords through ordinary project correspondence.
If access no longer has a justified purpose, the authorized owner can remove it through the standard process. That access decision need not depend on proving where the historical record originated.
Put an end date on “just in case”
NIST's remote-access guidance is a useful reference when defining the broader access arrangement. Translate requirements into operational conditions your own administrators can verify.
Give exceptions a current sponsor and review date. Emergency support can have a documented activation process instead of permanent broad access.
Close the investigation with what was confirmed: account relevance, authorized systems, action taken, and supplier response. If the supplier could not establish device history, retain that as an uncertainty rather than inventing an attribution.
Read contractor exposure responsibilities and least privilege after credential exposure. An accountable access relationship is easier to investigate than an old account kept alive by an informal expectation.