How should you manage contractor access to infrastructure?

A contractor's access should disappear on schedule, not when an administrator remembers it. If revocation depends on an email, a calendar reminder, or the person who remembers where a key was added, the access was designed incorrectly.

A workable setup starts with a separate identity, a restricted route, and an expiration time set in advance. It ends not with disabling a login but with checking every way back in: keys, tokens, automation rules, new accounts, and running processes. Between those points, the log must answer a simple question: who changed what, with whose approval, from which device?

I do not consider a permanent contractor VPN an acceptable price for convenience. That access almost always outlives the task, changes as the infrastructure changes, and eventually becomes broader than the system owner remembers. Temporary access takes more preparation only the first time. After that, it makes routine completion of work boring and predictable, exactly as it should be.

The request must describe a session, not a job title

A good request defines the boundaries of a specific job: the operator, systems, permitted actions, time, and responsible employee. "Access for the supplier's engineer" limits nothing. It describes an employment relationship but does not explain why that person needs to enter production or where their access should stop.

Before creating an account, the system owner must record the operator's identity and verify it through an agreed channel at the contractor's company. A messenger name or the address that sent an email does not prove that the approved specialist is receiving access. For remote work, I require official confirmation of the assignment, a work contact, a multi-factor authentication method, and the name of the work supervisor on the customer's side. If the contractor replaces the specialist, the request goes through approval again.

The minimum access record contains:

• the request identifier and a clear description of the expected result;
• the operator's personal name and organization;
• an exact list of hosts, applications, environments, and roles;
• the start, end, and time zone of the access window;
• permitted source addresses or the corporate connection channel.

The word "servers" is not an access scope. Use resource group names, segments, or labels that can be checked against configuration. "Database diagnostics" is also too broad: reading metrics, viewing a query plan, and changing parameters need different privileges. If the scope is still unknown, grant read-only observation first and handle any expansion as a separate decision.

The request needs one owner inside the organization. That person confirms the start of the session, answers scope expansion requests, and accepts the result. The support team may create access technically, but it should not guess the business need. Separating these roles prevents an operator from getting extra privileges through a single sentence in chat.

I also record the conditions for immediate revocation: the window ends, the task finishes early, the operator changes, work deviates from the plan, a device is lost, or authentication looks suspicious. This is not a legal formality. An on-call administrator must be able to make the decision at night without searching for the contract's author.

A separate temporary account beats a shared login

Every person gets a separate account, even when the contractor sends an entire shift of engineers. A shared login erases accountability, breaks proper multi-factor authentication, and forces everyone to replace a shared secret whenever the team changes. A terminal recording does not help if five people could have signed in under the same name.

A temporary account is different from one used infrequently. NIST SP 800-53 Revision 5 makes this distinction explicit: temporary accounts are intended for short jobs and should be disabled or removed automatically after a defined period. A "supplier" account that someone enables when needed remains a permanent entry point. Its password ages, its privileges grow, and its owner gets lost over time.

The best identity source is usually the same corporate directory that already enforces sign-in rules and stores authentication events. An external user may be created as a guest or added to a separate access group, but that identity must not be mixed with an application's service account. A person signs in as a person, while automation runs under a separate machine identity with a different lifecycle.

Require multi-factor authentication before granting a privilege, not just during the first portal enrollment. A stolen active session or saved password would otherwise bypass the control. For sensitive systems, repeat factor verification when elevating a role and prohibit weak recovery methods that the contractor does not control.

Do not copy the operator's public key into an employee account or add it to a shared authorized_keys file across dozens of hosts. In the first case, the log shows the employee's name. In the second, revocation becomes a search for the same line on inconsistently configured servers. A centralized access broker, a directory, or SSH certificates provide one issuance point and an explicit lifetime.

A local temporary account can still fit an isolated system. Its name should then tie back to the request, such as ext_4821_askar, and its description should contain the owner and expiration date. Do not put it in a permanent administrator group "for now." Grant only the required role and make sure the system did not create a home directory with readable secrets by default.

Expiration must work without an administrator

The end date must exist in the authorization mechanism, not only in the request. Manual revocation sometimes runs late because of a shift change, holiday, outage, or ordinary forgetfulness. NIST recommends automatic disabling of temporary accounts precisely because it is more consistent than an administrative promise.

There are two different lifetimes, and teams often mix them up. The account lifetime defines the period of the relationship with the external specialist. The privilege activation lifetime limits one work session. A contractor may remain registered for a week, while the administrator role should activate only for the approved hours. Role expiration does not remove the identity, and identity expiration does not always terminate an open session, so both layers need control.

Microsoft Entra Privileged Identity Management describes the eligible and active model: a person may be entitled to request a role but receives active permissions only after verification, justification, and approval when required. Microsoft documentation also recommends setting the assignment start and end. This is a useful pattern for other platforms too: the permanent element is the right to request access, not the right to change production.

On a standalone Linux host, you can create an account with a disable date:

sudo useradd -m -s /bin/bash -e 2026-08-01 ext_4821_askar
sudo chage -l ext_4821_askar

The useradd -e command interprets the date in UTC. The chage -l output should contain a line like Account expires : Aug 01, 2026; check it immediately because the work window's time zone and the disable date may differ by a day. This constrains the account, but it does not fully revoke every token issued to it.

A short certificate is more convenient for SSH. A certificate authority can sign the public key with the request identifier, permitted principal, and validity interval:

ssh-keygen -s /secure/ca_user -I CHG-4821 -n ext-maint \n  -V 20260728100000:20260728140000 contractor_key.pub
ssh-keygen -L -f contractor_key-cert.pub

The OpenSSH ssh-keygen manual confirms that -V sets the certificate's start and end times. In the inspection output, look for Key ID: "CHG-4821", Principals: ext-maint, and the exact Valid interval. The certificate will stop authenticating after expiry, but emergency revocation before then requires a key revocation list or another way to stop trusting that specific certificate.

Choose a short window with enough time to verify the result, not enough time to absorb a possible week of delays. An extension should create a new decision and a new log event. An "extend forever" button turns a temporary scheme into a permanent one with more interfaces.

The network route must end at the required system

Restricting the source IP helps, but it does not prove identity or replace expiration. A contractor's office address may serve many people, a home address changes, and a compromised host inside the permitted network is already on the correct side of the filter. A network rule reduces the attack area when it works with personal authentication.

The contractor should enter through one managed route: a remote access gateway, bastion, or published proxy for a specific application. Direct SSH, RDP, and administrative web interfaces from the internet should be closed. The gateway makes it easier to apply multi-factor checks, tie the connection to a request, record the session, and break active connections during revocation.

CISA's Guide to Securing Remote Access Software warns that attackers use legitimate remote access programs as a ready-made channel into someone else's network. I therefore consider permission to use "any familiar support tool" bad practice. The organization approves a specific channel, prohibits unapproved remote management agents, and controls the installation of new services.

Build the route to the resource, not to the entire internal network. For a web console, open one address and port. For maintenance of a server group, allow the bastion to reach only its management interfaces. Access to directories, backups, hypervisors, and security consoles remains closed unless the request names them.

The source address is also better tied to a managed channel. If the contractor cannot guarantee a static address, issue a separate VPN profile or provide access through a controlled workstation. A country or autonomous system filter may cut noise, but it cannot replace an allowlist of specific routes.

Check outbound connections too. The engineer may need an update repository, but the application server does not need arbitrary internet access during the job. Restricted egress makes quiet data extraction harder and complicates installation of a persistent management channel. Record exceptions with destination names and an expiry, not an any rule.

After configuration, test the negative case: the account must not see an adjacent host, and a connection from an unapproved address must fail. A successful sign-in confirms only half the configuration. Most dangerous mistakes sit in the resources a person could reach beyond the plan.

Grant rights for an operation, not a server

Access to a server and permission to perform the job are not the same. An engineer changing one service's configuration rarely needs an interactive root shell, directory administration, or access to backups. If you cannot name the commands or objects required for the task, you have not defined the role yet.

Start in read-only mode. Application metrics, logs, and service status often provide enough information for diagnosis. Permit elevation only for a confirmed change: restarting a specific service, editing one file through a managed process, or running a restricted database procedure. A separate viewing role and separate activation for changes show clearly when risk has increased.

In sudoers, do not replace least privilege with a long list of shells and general-purpose utilities. Permission to run vim, less, tar, an interpreter, or a command with uncontrolled arguments often creates a path to arbitrary execution. It is safer to wrap the operation in a reviewable script with fixed parameters, root ownership, and logged input.

A container platform can hide excessive access just as easily. Permission to create a privileged pod, mount a host path, or read every secret is effectively broader than administration of one application. Role names such as edit do not describe the consequences. Review the permitted actions and resources, then test an attempt that should be denied.

Do not pass secrets in the request, in email, or on a command line that will enter shell history. Retrieve a one-time secret through the approved vault, then revoke its version or read permission after the job. If the contractor saw an application's permanent password, ending interactive access changes nothing: the password still works.

Do not grant production access merely because the test environment "is not similar enough." Rehearse the procedure on a test system or a copy of the configuration first, then transfer only the confirmed actions. If diagnosis needs data, prepare a minimal masked sample rather than access to the whole database. Temporary full access is still full access.

The system owner must approve any privilege expansion, and the technical administrator must be able to see the difference between the old and new roles. A spoken "add root for five minutes" does not create a reviewable decision. If an outage truly requires it, record the reason before activation or immediately afterward under a separate emergency access procedure.

The log must connect the person, session, and change

A useful log proves the chain of events: approval, authentication, role elevation, commands, changes, and exit. A VPN log shows only the start of the tunnel. Shell history on the target server depends on user settings and can be cleared easily, so it is not independent evidence.

NIST SP 800-53 control MA-4 requires organizations to approve and monitor remote maintenance, and it separately calls for logging those sessions and reviewing records for anomalous behavior. I agree with that combination, with one practical condition: the log must leave the system the contractor administers. Root on the target host can alter local traces.

Collect events from the directory, gateway, target system, privilege elevation mechanism, and cloud control plane. Every source must use synchronized time. Put the request identifier in the certificate name, activation reason, or session metadata so an investigation does not have to connect events by guesswork.

Recording terminal input and output helps with risky interactive work. Sudo supports log_input and log_output, while privileged access gateways can record a terminal or screen. A recording does not replace system logs: it shows intent and the visible result, but platform auditing captures an API call from a background process better.

Do not record secrets indiscriminately. A password, token, or personal data can appear in video, terminal input, or a command body. First prohibit sending secrets through recorded channels, use issuance from a vault, and restrict access to the recordings themselves. Investigation and contract requirements should set retention, not a desire to collect everything forever.

Before the work window, generate a test event and find it in the central store. Check that the sign-in is present and that the fields are complete: identity, source address, target resource, role, request, time, and result. An empty user field tends to be discovered only when an investigation already needs it.

During a risky change, the responsible employee watches the session or receives notifications about role elevation and deviations. Observation does not mean dictating every command. It shortens the response when an engineer opens the wrong cluster, starts a bulk export, or installs an unapproved agent.

Revocation begins before the work ends

Design the revocation process at the same time as issuance, because every permission needs a known reverse path. "We will remove access later" hides the absence of an inventory. The request owner must see every created object and the person who can disable each one without help from the contractor.

Normal closure starts by confirming that changes are saved, the service works, and unfinished commands and file transfers have stopped. The administrator then terminates active sessions, removes the privileged role, blocks external sign-in, and revokes issued credentials. Automatic expiration remains a safety net, but it is not a reason to wait until the end of the window when the job finishes early.

The order matters. If you remove the directory account first but leave a VPN session or cloud token, the issued session may survive until its own expiry. If you close the network first, a background process on the server continues locally. Revocation must cover the identity, active sessions, roles, secrets, network, and processes.

For emergency revocation, the on-call employee should not need to assemble a committee. The procedure specifies in advance who may cut access after a lost device, unexpected operator replacement, work outside the approved scope, or signs of compromise. Review and restoration of the window can happen later. Keeping a suspicious privileged session alive for formal approval adds needless risk.

Notify the contractor about the access termination through an independent channel, but do not make their confirmation a condition for blocking it. Record the exact decision time and the actual disable time. The difference shows whether the process works across shifts and whether the team can meet its promised response target.

Revocation automation must be safe to repeat. A second run must not restore a removed role, fail because a group is absent, or skip every later object after the first error. Keep the result of each step and route failures to the owner while the request remains open.

Close the request only after technical verification. An engineer's "all done" message reports on the work but proves nothing about access. The responsible employee accepts the result, the access team confirms revocation, and the system owner accepts residual risk if an object cannot be removed immediately.

After revocation, look for every remaining path

Disabling the original account does not find access paths the contractor could create during legitimate work. A person with administrative privileges can add a key to another user, issue a token, register an application, change a scheduled task, or leave a remote agent behind. The review must look for changes and new entry paths across the entire work window.

I use this review order:

1. Confirm that the identity is blocked, active sessions are closed, and no assigned roles remain in any affected system.
2. Compare new accounts, groups, SSH keys, certificates, tokens, applications, and trust rules with the starting snapshot.
3. Find changes to services, schedulers, startup entries, containers, images, network rules, and remote management software.
4. Review issued secrets, replace permanent values the operator could read, and revoke temporary versions.
5. Compare command and API logs with the approved plan, then send unexplained actions for investigation.

Simple checks help on Linux, although exact paths depend on the distribution:

sudo loginctl terminate-user ext_4821_askar
sudo passwd -l ext_4821_askar
sudo find /home /root -name authorized_keys -type f -newermt '2026-07-28 10:00 UTC' -ls
sudo systemctl list-timers --all
sudo journalctl --since '2026-07-28 10:00 UTC' --until '2026-07-28 14:30 UTC' _UID=104821

The first command ends the user's sessions, and the second locks the password. They do not remove keys, processes owned by someone else, containers, or application tokens. Searching by time narrows the review but does not replace comparison with a known state: an existing file may have changed without a new file being created.

In cloud platforms, review interactive sign-ins and machine access paths. Look for new service accounts, application consents, API keys, federated trusts, policy changes, disk snapshots, and public addresses. Separately inspect roles the contractor may have assigned to another identity. Removing a guest does not automatically remove such assignments from every product.

Check whether the completed work created a hidden dependency. A new monitoring agent, package repository, or support channel may be part of the approved solution, but it needs an internal owner, a documented network route, and its own update process. Otherwise, a temporary job has quietly created a permanent external administrator.

Store revocation evidence with the request: disable events, the list of terminated sessions, role comparisons, search results, and decisions for discovered objects. A screenshot of one green button is weaker than exported events with identifiers and timestamps. A month later, nobody should have to reconstruct the procedure from memory.

Emergency revocation needs a practical test

A procedure the team has never performed usually fails at the first unavailable owner or unknown token. Test emergency revocation with a training temporary account and measure the path from the decision to actual loss of access. Each organization sets its own target according to system risk, but privileged production access should be stopped in minutes, not on the next business day.

The test must include an active session. Simply disabling a user in the directory may block a new login while preserving an issued token, SSH connection, or web console session. During the exercise, the operator keeps a connection open, and the team confirms that it actually breaks at every layer.

Test the situation without the primary administrator. The on-call shift must find the request, identify affected resources, use emergency privileges, and retain an action log. The organization's emergency account must not be the contractor's account or depend on the same external identity provider.

A lost contractor device needs its own scenario. Blocking one identity is not enough if the device held shared secrets, VPN configurations, or keys for several environments. An inventory of issued data indicates what must change. Without it, the team either underestimates the exposure or begins an expensive rotation of every secret.

After the exercise, fix the mechanism, not the presentation: add a missing revocation API, shorten token lifetime, give the on-call employee the required role, configure session termination, and eliminate manual searches. A repeated test must confirm the fix. A report listing known gaps without owners and deadlines merely documents a future outage.

The contract and architecture must say the same thing

A technical control cannot fix a contract that permits unknown subcontractors, personal devices, and indefinite data retention. The contract should name the approved channel, identity and device requirements, the operator replacement process, incident notification times, session recording rules, and the duty to delete obtained data.

At the same time, a contract phrase such as "access only for the duration of the work" is useless without automatic expiration in the directory, gateway, and roles. Match each substantive requirement to an enforceable control and evidence. If a clause cannot be checked through an event, configuration, or acceptance record, it remains a wish.

Organizations often buy a privileged access product and consider the job finished. I disagree with that recommendation: the product does not know the business scope, appoint an internal owner, or determine which permanent secrets an engineer saw. It can enforce duration, route, and recording well, but the team still owns access issuance and the search for remaining paths.

For new infrastructure, include an access broker, centralized logging, and short-lived credentials before the first supplier request arrives. Adding them during an outage is expensive and dangerous. For an existing environment, begin with an inventory of permanent external accounts and replace the broadest access with individual identities that expire automatically.

As a system integrator, GSE.kz can account for this process when designing server and software infrastructure, including the remote maintenance route and centralized event collection. The specific roles, lifetimes, and boundaries must still come from the customer's systems and approved procedures.

Reliable revocation appears in negative tests: the former identity cannot sign in, the old token fails, the adjacent resource remains unavailable, the active session is gone, and no new path has appeared. Until the team has those results, contractor access has not been revoked.