Public Sector Supplier Remote Access: Control Every Session

Public sector supplier remote access should end when the authorised work ends. That requires more than an expiry date on an account. The institution needs to know who is connecting, which service they can change, which active sessions remain and who can withdraw access while preserving essential operations.

A supplier's contract may last several years while an engineer needs access for ninety minutes. Treat those as separate permissions. The proposed workflow below turns each intervention into an access window with an owner, observable boundaries and a verifiable end. Its council example is fictional; it describes no customer's architecture or measured outcome.

Follow the whole access path before approving the account

Map the engineer's route from their device to the final operation. A typical path might include the supplier identity provider, council authentication, a VPN or access broker, a jump host and an application administration role. An API key created inside that application can become another path with a different lifetime.

For every step, record who grants access, who can revoke it and which evidence shows that revocation worked. A supplier can disable its employee identity without controlling an application token issued by the council. Conversely, the council can close a network route while a separate cloud administration session remains available.

Separate interactive maintenance from unattended service connections. A nightly integration needs an accountable service identity and credential lifecycle; it should not borrow an engineer's account. Mixing the two makes an urgent employee departure difficult to handle without breaking production.

Place the service dependencies alongside this path. Our council network security plan shows how to assign service owners and verify continuity. The remote access decision then becomes specific: which part of that service can this person reach during this intervention?

Agree an access window that an operator can enforce

The NCSC supplier assurance questions ask organisations to consider how supplier access is limited, controlled and monitored, whether remote support agreements exist and whether sessions are logged. The following record converts those questions into a proposed operational handover between the institution and its provider.

Change reference: municipal waste scheduling connector update
Service owner and alternate: named council contacts
Supplier engineer: verified individual identity
Purpose: replace connector configuration and validate delivery
Start/end: explicit date, UTC times and local display
Allowed targets: approved administration endpoint only
Allowed actions: configuration update and synthetic job check
Transfer channel: approved package repository
Stop authority: council duty lead or incident commander
Closure owner: named access administrator
Closure evidence: session ended, temporary role removed,
                  issued credentials reconciled, test denied

Add the device and authentication conditions that the operator can actually check. A requirement saying “secure device” is too vague to accept or reject a connection. Specify the approved evidence source, freshness and response when that evidence is unavailable.

An access window is an operating record, not a replacement for procurement or legal terms. Ensure the contract supports the necessary notification, personnel changes, subcontractor approval and evidence delivery. Otherwise, the technical team may be expected to enforce conditions the provider has never agreed to meet.

Define extensions explicitly. A delay does not silently extend the original permission. The service owner or authorised alternate decides whether to continue, narrow the task or restore the previous state. Record the revised deadline and ensure the enforcement mechanism receives it.

Onboard the person, the device and the exit process

Verify the engineer through a previously established supplier contact. Do not accept a new telephone number or identity solely because it appears in the urgent access request. Check whether the person belongs to the contracted organisation or a subcontractor with separate approval requirements.

Issue an individual identity for the approved work. Keep elevated roles distinct from ordinary collaboration access, and apply the institution's authentication policy. For privileged access, prefer phishing-resistant authentication where the supported architecture allows it. Document any exception, its owner and its expiry.

Before activating the identity, ask the supplier how it will notify the institution when the engineer leaves, changes role or loses a device. Name the recipient and the response owner. An annual supplier review is too slow for an access decision tied to a specific person's current employment.

Test the offboarding procedure with a test identity during onboarding. Discovering that application sessions cannot be terminated at the end of a real intervention leaves the council negotiating a control gap after access has already been granted.

Broader questions about compromised software and vendor dependencies remain part of supply chain risk assessment. This workflow addresses the permissions used by people performing an authorised service task.

Bound the route and the target permission separately

An engineer who can reach a server should still receive only the application privileges required for the task. Network reachability, operating system rights and application roles are separate decisions. Record all three where relevant, including the control that prevents access to unrelated services.

ANSSI's secure administration guide, version 3.0, recommends a dedicated remote access chain for third-party administrators and dedicated access and administration accounts. Use its architecture recommendations with a local assessment of the systems concerned; a supplier assurance document does not replace controls within the institution.

A VPN or ZTNA product must be evaluated against the actual path. The NCSC ZTNA implementation guidance explicitly retains the need for local network segmentation. ZTNA access decisions and controls on movement between internal segments serve different purposes.

Ask whether the connector or jump host can reach unrelated targets, whether file transfer is permitted and whether a supplier can introduce another remote support tool. For the agreed intervention, approve necessary channels and prevent unexplained alternatives. A temporary troubleshooting shortcut can otherwise survive the original access window.

A municipal supplier change from request to closure

Consider a fictional council updating the connector that sends collection schedules to a waste contractor. The supplier needs to modify one configuration and confirm delivery of a synthetic schedule. It does not need access to revenues, resident case records or the identity directory.

The service owner schedules a ninety-minute window after the operational export. The change record includes the actual date, UTC times and their local equivalent to avoid daylight-saving ambiguity. The council retains the previous connector configuration and confirms that the existing schedule is available to operational staff if the update fails.

Before the window, a test confirms that the engineer cannot open the administration session. The access administrator then activates the approved role and route. The engineer authenticates with the agreed identity and device; the observer checks that the session appears in the expected logging systems.

During the intervention, the engineer changes the configuration and submits the labelled synthetic schedule. The service team confirms receipt and removal of that test record. An authorised check against an unrelated test target confirms that the supplier route cannot cross into the revenues environment. Do not substitute an unavailable target for proof that a control denied access.

If the synthetic schedule fails, the service owner chooses rollback or a separately approved extension before the deadline. The engineer does not gain broader access simply because the initial diagnosis is inconclusive. An additional target requires a new reason and permission.

At closure, the access administrator ends the remote session, removes the temporary role and checks any credentials issued during the change. The observer verifies denied access using the same test identity and records what happened to the already established session. The council then confirms that the real scheduled export remains healthy.

Reserve part of the window for this handover. If all ninety minutes are allocated to the technical change, closure becomes an activity performed after the approval has expired. Set a point at which the engineer stops making changes and starts verification, leaving enough time for the agreed rollback. The appropriate margin depends on the operation and its recovery steps; record it in the change rather than adopting a universal percentage.

Also reconcile anything designed to run later. An approved export job may legitimately continue after the engineer disconnects, but a new scheduled task, remote support agent or API credential needs an identified purpose and owner. Record whether each item is a permanent service dependency approved by the institution or a temporary artefact to remove. Ending the visible session does not explain these background changes. Ask the application owner to verify their configuration against the change record before accepting closure, and record any incomplete check as outstanding work.

Revocation must cover state that survives login

Build a closure checklist from the actual technology. Include the network session, jump-host session, application session, temporary role, refresh mechanism, API key and any local credential introduced by the intervention. Not every system uses every item. The important question is whether something still authorises an operation after the account's main permission changes.

For each item, identify the supported termination or invalidation mechanism. Check whether removing a role affects an existing session immediately or only after another authorisation check. Check whether logging out of a browser leaves an independently issued token usable. Do not assume that two products respond identically to the same identity event.

Where immediate termination is unsupported, record the maximum remaining lifetime and a tested containment action, such as withdrawing the specific network path or disabling the affected target capability. Assess service impact before relying on that action. Shorter future lifetimes do not revoke a credential already issued under a different policy.

Verify closure with a safe, authorised attempt that would require the withdrawn permission. Test existing access as well as a new login. Preserve failure evidence without recording token values or passwords. A provider's statement that it “logged out” is not equivalent to institution-side evidence that the operation is no longer authorised.

Rotate credentials that were exposed or must change under the agreed procedure, with dependency checks for applications using them. Indiscriminate rotation of shared secrets can interrupt unrelated services. An inventory of issued credentials makes precise revocation possible.

Record limitations discovered during verification. If an application only supports delayed expiry, the owner needs its actual duration before the next window. Describing access as closed without that qualification would misrepresent the evidence and prevent an informed decision about the next intervention.

Keep an emergency route that does not become routine

Write the emergency process before a supplier needs it at night. Define which service disruption justifies its use, who can approve it and how the requester is verified if the usual identity system is unavailable. Name an alternate approver so one missing person does not force an improvised exception.

Restrict the route to the recovery operation and have a second authorised person observe or promptly review its use where feasible. Maintain an independent record when the normal ticketing system is unavailable, then reconcile it afterwards. Emergency access still needs a deadline and a closure owner.

Exercise the process without disrupting production. Confirm that the stored contact details, credentials, device and target are usable under the assumed failure. A recovery account that depends on the failed authentication path cannot fulfil the intended purpose.

Afterwards, review why the normal path failed, reconcile privileged changes and close temporary permissions. Repeated emergency use for the same service should trigger a design decision, rather than normalising an exceptional route.

Keep evidence useful without exposing the investigation

The audit package should connect approval to activity and closure. Retain identity, target, timestamps, relevant policy decisions, change reference and verification results. If session recording is used, define its purpose, access restrictions and retention with the relevant institutional owners. Screen recordings can contain resident information and credentials.

When activity is unexpected, preserve original events and follow the IP, DNS and process investigation workflow. A shared supplier egress address identifies infrastructure, not necessarily the individual responsible. A reputation check provides additional dated evidence, not identity assurance.

Do not paste session URLs, internal hostnames or signed download links into public scanning tools. The analyst OPSEC guide explains how an investigation can disclose the material being assessed.

For an initial IsMalicious assessment, the institution can select one of its own public domains or public IP addresses and review the indicator report. If reputation data will feed an existing control, first specify who interprets matches and who approves restrictions affecting supplier access. A clean reputation result must never reopen a closed permission.

At contract exit, reconcile the full access register with the service owner: people, routes, application roles and non-interactive credentials. Complete any required service transfer before removing dependencies, then retain the closure evidence under the approved policy. The supplier's final invoice is not evidence that its technical access has ended.