Server Access Ownership After Team Changes

When an employee, contractor, or vendor changes roles or leaves, server access must change with them. Removing one Linux account is not enough: the person may also have copied SSH keys, shared passwords, deployment tokens, control-panel access, DNS credentials, or knowledge of an emergency account.

Treat the change as a bounded access review. Inventory every identity and credential the person could use, preserve an authorised recovery path, revoke or rotate affected access, and prove the old paths no longer work. The result should leave the organisation in control without locking out the people who remain responsible.

Start with an access inventory

Build the inventory from the server, configuration repositories, password or secrets manager, provider and domain consoles, automation systems, and the outgoing person's documented responsibilities. Do not rely on a manager's memory or a single list of Linux users.

Check each of these access surfaces:

• Linux users: interactive accounts, home directories, shell access, group membership, and disabled-but-retained accounts.
• SSH keys: keys in every relevant authorized_keys file, certificate authorities, bastion hosts, and automation destinations.
• Sudoers: direct rules, group-based privileges, included configuration files, and command-specific grants.
• API tokens: application, provider, DNS, monitoring, backup, CI/CD, and third-party integration tokens.
• Control-panel accounts: named users, roles, sessions, recovery contacts, and multi-factor authentication methods.
• VPN accounts: user identities, device certificates, pre-shared material, and allowed network routes.
• Git and deployment identities: repository access, deploy keys, CI/CD credentials, runner identities, and release approvals.
• Monitoring accounts: dashboards, alerting tools, status systems, log platforms, and notification destinations.
• Backup accounts: backup agents, repositories, encryption-key access, restore consoles, and recovery contacts.
• DNS/domain accounts: registrar, DNS provider, domain ownership, API credentials, transfer controls, and recovery contacts.
• Vendor access: named vendor users, support tunnels, temporary keys, remote-management tools, and contract end dates.

For each item, record whether the identity is personal, a service account, a vendor identity, or an emergency path. Also record its scope and where revocation must occur. One credential can exist on several servers or services; removing only the first copy does not complete the review.

Separate people, systems, and vendors

Human users should have named identities that can be revoked without interrupting an application. Automated systems should use dedicated service identities owned by a team or service, not an employee's personal account. Vendors should have named, time-bounded access that is distinguishable from both internal staff and automation.

Do not let a service run under a departing person's account, and do not share one administrator login among a team. Shared identity hides who acted and makes offboarding destructive: changing it can break automation, while leaving it unchanged preserves access for the former user.

Assign an accountable owner to every non-human identity. The owner approves its scope, knows where its credential is stored, reviews its use, and can revoke or replace it. If ownership is unclear, resolve that before the team change is closed.

Rotate what changed

Revoke access that belongs only to the departing or reassigned user. Then rotate every secret or key that the person could copy, view, export, or recover—even if it was intended to be shared temporarily. Typical examples include shared administrator passwords, private deployment keys, API tokens, VPN pre-shared keys, recovery codes, and backup encryption material.

Replace first, verify the replacement, and then remove the old credential when a service depends on it. This avoids turning off a deployment, backup, monitor, or DNS update before its new identity works. Record every destination where the old credential was removed.

Prove revocation from outside the trusted session. Test that the old SSH key, password, token, VPN certificate, panel session, or vendor route fails, and that the replacement succeeds only within its intended scope. Review recent authentication and administrative logs for unexpected use around the change, but do not put reusable secrets into the evidence record.

Preserve recovery paths

Before removing access, confirm that at least one authorised person can recover administrative control without using the identity being removed. Test the path far enough to prove that the required account, multi-factor method, recovery contact, and credential are available and current.

Recovery may depend on more than the VPS login. Confirm ownership of the provider account, DNS/domain account, password or secrets manager, backup restore path, and any encrypted recovery material. If a former employee is the only recovery contact or multi-factor holder, transfer that dependency before revoking the working access.

Keep emergency access separate from daily administration. Store it in an approved controlled location, restrict who can retrieve it, alert or log when it is used, and require credential rotation after use. Test it on a schedule and after ownership changes; an untested break-glass account is not a recovery plan.

Make ownership visible

Maintain one access register that links every identity to a current owner and a known revocation action. It can live in an access-governance system or another controlled record, but it should not contain plaintext passwords, private keys, tokens, or recovery codes.

Review the register whenever someone joins, changes role, leaves, or gains temporary access. Also reconcile it periodically against the actual server, identity provider, repositories, consoles, VPN, monitoring, backup, and DNS systems. A register is evidence only when it matches deployed access.

Offboarding checklist

• Identify the exact person, role change, effective time, systems, and approving owner.
• Inventory Linux, SSH, sudo, token, panel, VPN, deployment, monitoring, backup, DNS/domain, and vendor access.
• Transfer ownership of services, repositories, recovery contacts, devices, and non-human identities.
• Establish and test an authorised recovery path before removing the working one.
• Replace shared or copyable credentials and verify replacements before revocation.
• Disable named access, remove keys and privileges, revoke tokens and sessions, and close vendor routes.
• Test that every old access path fails and intended replacement paths succeed.
• Review authentication and administrative logs for unexpected post-change access.
• Update the access register with the owner, verification date, and revocation evidence.

When a VPS is the right fit

A VPS can fit a team that needs customer-operated control over operating-system users, SSH keys, service identities, deployment credentials, and access logs. That control also creates responsibility: the customer must configure, review, revoke, rotate, and recover those access paths.

Virtarix VPS services are self-managed. Virtarix providing root access does not mean Virtarix manages the customer's Linux users, firewall, VPN, application accounts, secrets, or offboarding workflow. A single VPS is also one failure domain, so access recovery and service redundancy must be designed separately when the workload requires them.

For more detail on restricting automation credentials, see least-privilege deployment keys on a VPS.

FAQs

When should access be removed during offboarding?

Align revocation with the approved effective time and the organisation's risk process. Prepare the inventory, replacement identities, and tested recovery path beforehand so access can be removed promptly without improvisation.

Which shared secrets need rotation?

Rotate any credential the person could read, copy, export, or recover, including shared passwords, private keys, API tokens, VPN material, recovery codes, and backup encryption keys. If exposure cannot be determined, treat the secret as known and replace it.

How should emergency access be handled?

Keep it separate from daily accounts, restrict retrieval, record use, test it periodically, and rotate it after use. It must have an accountable owner and must not depend solely on the person being offboarded.

What evidence proves access was removed?

Record the affected identities and destinations, revocation time and approver, failed tests using the old paths, successful tests for intended replacements, and relevant authentication-log review. Do not store reusable secret values in the evidence.