A supplier, contractor or support partner may need access to an organisation’s systems to do agreed work. That access should have a named user, a clear purpose, a limited scope, an internal owner and an end point. If those details are not recorded, the organisation may be unable to tell who still has access, whether it is still required or how to remove it when the relationship changes.
Start with an inventory of external identities
List third parties that can access business systems, including individual accounts, shared accounts, service identities, remote-management tools and accounts held by a partner organisation. Record the identity, supplier, internal sponsor, systems reachable, access method, approval date, reason and expected end date.
Do not assume that every external account is visible in one directory. Some applications maintain their own users, while a vendor may connect through a remote support tool, cloud console or network device. Ask system owners to check the services they manage, and include non-human identities that support integrations or automation.
The aim is not to collect a perfect spreadsheet for its own sake. It is to make access discoverable enough that an owner can make a decision and the technical team can act on it.
Make access specific and time-bound
Grant access to the named people who need it, rather than a generic supplier account where the system supports individual identities. Limit the systems and privileges to the task. If access is needed only for a maintenance window or project phase, define when it starts and when it should end.
NIST SP 800-53 includes controls for account management, least privilege and remote access. Its remote-access control calls for organisations to document restrictions and connection requirements and authorise each type of remote access before it is allowed.^1 These are control examples, not a statement that every organisation must follow a specific US federal baseline.
CISA’s guide to securing remote access software recommends controls such as multifactor authentication and monitoring for provider-managed access. Its advice is a useful prompt for reviewing a support connection, but the organisation should adapt it to its own environment and contracts.^2
Keep an owner accountable
Every external identity should have an internal sponsor who can explain why the access exists and whether the work is still active. The sponsor should know who is authorised to approve changes, what the supplier is permitted to do and how an incident is escalated.
Review higher-risk access more frequently than routine, low-impact access. Prioritise administrator privileges, remote access to important systems, accounts that can change security settings and access to sensitive information. The review should state what the user can reach, not only the account’s display name.
If no one can identify the owner or business purpose, do not simply delete the account without checking dependencies. Investigate whether it supports a service, confirm what would break and plan a controlled revocation or replacement.
Record and monitor what happens
Enable relevant logs for authentication, remote sessions, privilege changes and administrative actions where the platform supports them. Decide who reviews alerts, what information is needed for an investigation and how long records are retained under the organisation’s policies.
CISA describes logging as a way to record who accessed what, when and from where, and recommends protecting logs from unauthorised access or deletion.^3 Logs do not prevent misuse on their own. They need an owner, suitable coverage and a process for responding to an unusual event.
For sensitive maintenance, consider whether the organisation needs to approve the session, observe the work or review the activity afterward. The right control depends on the system, the task and its operational impact.
Offboard the relationship, not just the person
When a supplier contract ends or the work changes, review all related access. Disable named accounts, remove group membership, revoke tokens and keys, close remote-access pathways and update shared secrets if they were used. Confirm whether any service identities or integrations remain necessary.
Make this part of contract close-out and project handover. Ask the supplier to confirm that accounts, credentials and copies of data under its control have been handled according to the agreement. Keep a record of what was removed, what remains and who accepted any exception.
Test the review process
Choose a supplier and trace access from request to approval, use, logging, review and revocation. Check whether the sponsor can identify the access and whether the technical owner can remove it. Note gaps in the process and assign an owner and due date to each fix.
Repeat the exercise when systems, suppliers or operating responsibilities change. Access reviews are most useful when they are tied to actual events, not performed only as an annual paperwork exercise.
Make external access visible
Third-party access can be legitimate and necessary. The control objective is to make it limited, owned, observable and removable. Read how identity governance supports access decisions and how ZTNA changes remote access. For AltTab’s current identity, secure-access and implementation scope, see Zero Trust services.