Skip to main content

Temporary access for vendors

Give an outside technician access to a specific safe for a limited time, follow their sessions, and withdraw access when the work is finished.

Written for whoever runs IT6 min readUpdated

Vendor access is for a technician from another company who needs to work on a system you manage. An invitation gives that person a limited access window and a specific safe. You do not need to give them a permanent employee account or send them a stored password. Start with the smallest safe that contains the accounts needed for the job; an invitation to a broad safe is broader access than an invitation to a dedicated maintenance safe.

Before you invite someone

Open Privileged access → Vendors. You need permission to manage vendor invitations in the selected organisation. Prepare the target system, its account and the safe first. A successful invitation does not establish that the target is reachable or that its credentials work. Verify an ordinary privileged session to the intended target before scheduling external maintenance. Use a named technician and an agreed purpose so you can recognise the invitation later.

  1. Create the invitation

    Enter the technician’s name, email address and company, select the safe, describe the work, and set the access duration. Review the organisation and safe before submitting.

  2. Deliver the invitation

    Check the delivery result. If the console provides a link for manual sharing because email was not sent, use your agreed secure channel. Treat the link as access material and do not put it in a public ticket or screenshot.

  3. Have the technician accept

    The recipient opens the invitation and follows the acceptance flow. The vendor workspace shows the accounts available through that invitation. An expired or revoked invitation cannot be used as an alternative sign-in method.

  4. Verify the work session

    The technician selects an available account and starts the appropriate session. Check the session result and monitor the work where live monitoring is available. A submitted request is not proof that a remote session connected.

What the invitation permits

Access is limited to the invitation’s organisation, safe and expiry. The vendor flow is intended for using available accounts through the session gateway. It does not grant administration of the safe or permission to reveal its secrets. If the technician cannot find an account, check the safe contents and invitation scope before widening access. If a session fails, check target connectivity, account health and the session gateway. Creating another invitation does not repair those dependencies.

Finish or withdraw access

Review the invitation and its associated sessions when the work ends. Revoke access early when the maintenance window is no longer needed. Check any still-running session separately and use its termination control if it must end immediately; do not infer that a list status alone proves the connection closed. Preserve the purpose, technician, time window and session references with the maintenance record. If you cannot confirm revocation or session termination, involve the system owner before granting another window.

When the expected result is missing

If you see a permission error, ask an administrator for the vendor-management permission rather than using a colleague’s account. If the recipient never gets the email, inspect the delivery result and check the address. An invitation marked pending has not yet become an accepted working session. When requesting help, include the invitation reference and failure time, but leave out the invitation URL, password and any session token.

Was this article wrong?

If a procedure here does not match what you see, or a limit we described has changed, tell us and we will fix the page. Email us about this article, or see how to get help if you need an answer rather than a correction.

Everything in privileged access