Server access for suppliers and external support teams: time-limited and auditable

The safe way to give a contractor or external support team server access is to tie the access to the job: a named person, a specific resource, a fixed period and, when the active session policy requires it, an approved request. When the work ends, access closes and the records stay available for review. Cerberus builds this flow from assignment, time-limited access, session approval, revocation and audit logs.

Why standing VPN accounts and shared passwords fall short

Two setups are common for supplier access: a VPN account that stays open, and an administrator password that circulates inside the team. Neither ties the end of the job to the end of access.

• A VPN account opens a broad path at the network layer. The path stays open until someone disables the account, and the person can reach more than the job needs.
• A shared password blurs who did what and when. Because the password is copied and passed around, closing access is not just a button in a panel; the question of where the password still lives stays open.
• Records are usually scattered: the request in email, the approval in chat, the access in a firewall.

The job ends, the account and the password remain. The flow below reduces these three gaps to one chain of records.

How does supplier access flow?

The flow has five steps. Each one maps to a Cerberus capability and a guide.

Assignment: person and resource scope

A session decision uses the person, role, resource assignment, time and policy. The supplier employee is assigned only the server the work happens on; other resources in the workspace stay hidden. The decision inputs are on Identity, scope and assignment, and the assignment steps are in Assign resources.

Time-limited access

When creating an invitation or member access, the timed access option sets an end time or a supported usage budget. If the work runs long, the period is extended; an extension does not add resources. After expiry, the decision to start a new session follows that condition. See Time-limited access for the steps.

Session approval

When the active session policy requires approval, the approval flow makes visible which person and resource a session starts for, and with what duration and policy. The member, resource and requested time are checked; the request is approved if suitable, the approval window is extended if more time is needed, and the request is rejected otherwise. A rejected request opens no session. Details are in Manage session approvals.

Revocation

Revocation is three separate operations: closing new sessions, ending the open session, and withdrawing resource readiness for the connection model in use. Removing an assignment does not close an open session by itself; an authorized user ends the active session separately when work is open. If the end request fails, the product does not mark it as a successful closure. The full sequence is on Revocation and evidence.

Working without sharing the password

The credential for the target resource does not have to be handed to the person doing the work. In the credential custody model the person sees the resource without having to see the password; the credential is used inside the session context. On Windows resources this can be supported by the managed local account model. Scope and limits are described on Credential custody.

What if ending the session fails?

If the end request fails or times out, the product does not count it as a successful closure. The order is:

1. Remove the assignment or close the period to stop new access.
2. Read the open session’s last seen state and last event in the panel.
3. If the connection path is online, retry in a controlled way; if it is offline, move to the gateway and Agent checks in the connection troubleshooting guide.
4. If the result does not change, add the resource ID, session ID and end request time to the support record. Do not add passwords or private connection values.

What records are kept?

Audit logs show who acted on which resource and session, and when: access request, approval (if the policy requires it), session start, change and closure. For revocation, the person who started the action, the affected person and resource, the assignment change, the end result and the closure reason are linked too. Filter by workspace, time range, member, resource or action type to review; the steps are in Review audit logs.

These are event records: decision, start, state change, revocation and closure. They are not screen video. Session recording is in development.

Checklist for supplier access

• Each supplier employee has an individual user; there is no shared account.
• The employee is assigned only the resource the work needs.
• The end time or usage budget matches the work schedule.
• If the session policy requires approval, the person who approves session requests is named.
• The target resource password was not given to the employee.
• When the work ends, the assignment is removed or the period closed, and any open session is ended.
• After the work, the audit logs show the access, any approval and closure events.

Which resources does this apply to?

Cerberus manages access to your own servers, virtual machines and desktops; it does not provide hosting. Windows machines join the same assignment, session and record flow through the Windows Agent, and Linux servers and other targets through agentless connection. Resources connected without an agent give fewer in-machine readiness signals.

To try the flow with your own resources, open the live demo.