Every route has an owner
The route register lives in a table inside the checklist, and each route’s owner confirms the need by name. A route nobody will claim is visible as exactly that, rather than hidden in a firewall export.
Third-Party Remote Access Review Checklist Template
Every supplier who has ever fixed something for you may have left a way back in: a VPN account, a remote support agent, a firewall rule for their office. Nobody removes them, because nobody has the list.
This free third-party remote access review checklist is for IT and security teams who need to know, every quarter, how outsiders can reach their systems. It covers managed service providers, software vendors with support access, contractors, and the equipment suppliers who maintain building systems, production lines or medical devices remotely. Each cycle lists every route in, gives each one an internal owner and a contract, checks for named accounts, MFA and least privilege, confirms vendor accounts are switched on only when needed, compares sessions with tickets, looks for remote access tools nobody approved, and removes what is no longer needed before a named approver signs the review off.
Assessing a Vendor Is Not the Same as Checking Its Way In
Vendor due diligence asks whether a supplier is trustworthy: its controls, certifications, finances and contract terms. That is the job of the Vendor Risk Assessment Checklist, and it runs before contract and then about once a year. It rarely asks how the vendor’s engineers actually connect today. Remote access drifts much faster than a contract. An engineer sets up an agent during an outage, a firewall rule is added for a one-off migration, the vendor’s staff change, and a VPN account created three years ago is still enabled for someone who left.
This is the route attackers like. The 2013 Target breach is the best-known example: attackers stole network credentials from Fazio Mechanical Services, a heating and refrigeration contractor, and used them to get onto Target’s network before reaching the payment systems. A 2014 staff analysis for the US Senate Commerce Committee identified requiring two-factor authentication for vendor access as one point where the attack could have been stopped. In 2023 CISA, NSA and MS-ISAC warned that attackers use legitimate remote monitoring and management (RMM) software to get in and stay in, and the joint Guide to Securing Remote Access Software, from CISA, the FBI, NSA, MS-ISAC and Israel’s National Cyber Directorate, followed in June 2023.
Vendor risk assessment
Is the supplier trustworthy?
Cadence: before contract, then annually by tier.
Looks at: the vendor’s controls, evidence, contract and residual risk.
Misses: the accounts, agents and rules its engineers use day to day.
Remote access review
This checklist
Cadence: quarterly, plus when a contract ends.
Looks at: every route in, its owner, authentication, access window, logging and use.
Output: a current route register, removed routes and a signed review.
User access review
Are accounts still right?
Cadence: quarterly or half-yearly per system.
Looks at: every account and entitlement on in-scope systems.
Misses: agents, firewall rules, modems and partner admin relationships.
Run the three together. Vendor accounts found here feed the User Access Review Checklist, and vendor IP rules found here should match what the Firewall Rule Review Checklist sees on the firewall itself.
What the Third-Party Remote Access Review Checklist Covers
Seven phases run on a quarterly schedule, from listing every route to signing the review off. The removal phase appears only when the review finds a route to restrict or remove.
Phase 1
Phase 1: Inventory Every Route In
Owned by the IT security lead. Each route goes into the route register table with its type, vendor and what it reaches.
- Export vendor VPN and remote access gateway accounts — including local accounts on the appliance, not only directory groups
- List remote support and RMM tools with vendor access — your MSP’s agent, vendor support tools and attended screen-sharing services, with the hosts each reaches
- List jump hosts, bastions and privileged access gateways vendors use — and the vendor accounts on each
- List cloud guest and delegated admin access — guest users, cross-account cloud roles, SaaS support grants and, in Microsoft 365, partner GDAP relationships from the admin centre’s Partner relationships page
- Pull firewall rules and allow-lists that name vendor IP addresses — inbound rules, NAT and site-to-site VPN tunnels to suppliers
- Find out-of-band routes — modems, cellular routers and built-in remote access on OT, building management and medical equipment, often installed by the equipment supplier
Phase 2
Phase 2: Owner, Contract & Need
Assigned to each route’s internal owner, with the IT security lead checking the answers.
- Name an internal owner for every route — the person who answers for it, not the vendor; a route nobody will own is marked for removal
- Match each route to a current contract or statement of work — a route outliving its contract is closed
- Record what each route can reach — systems, segments and data; flag routes into the cardholder data environment, production or OT networks
- Have the owner confirm the vendor still needs the route — the work it supports this quarter; “might need it one day” is not a reason
- Mark routes with no owner, contract or current need for removal — in the route register, with the reason
Phase 3
Phase 3: Named Accounts & MFA
- Confirm every vendor account belongs to one named person — shared logins such as “vendorsupport” are replaced, or recorded as a time-limited exception
- Ask each vendor to confirm who still works on your account — disable accounts for people who have left or moved on
- Confirm MFA on every route — VPN, remote support tool, jump host and cloud admin, including accounts that bypass single sign-on
- Check the MSP’s RMM console is protected — whoever controls that console controls every agent on your estate; ask for MFA and admin-role evidence
- Move vendor credentials out of email, tickets and shared spreadsheets — rotate them and store them in a vault
Phase 4
Phase 4: Access Window & Least Privilege
- Confirm vendor accounts are enabled only when needed — disabled by default and switched on per ticket or for a fixed window, then disabled again
- Check privileges against the work — no domain or global admin for a vendor that maintains one application
- Restrict where each route lands — named hosts or a segment through the jump host, not the flat network
- Review GDAP and other partner admin relationships — the roles granted, the end date (GDAP allows up to two years), auto-extend, and any relationship holding Global Administrator
- Confirm sessions time out and end when the work ends — idle timeouts on the VPN, jump host and support tool
Phase 5
Phase 5: Monitoring & Unapproved Tools
Unexplained activity found here opens a security incident.
- Confirm vendor sessions are logged — who connected, when, from where and to what; recorded sessions for routes into critical systems
- Compare this quarter’s sessions with change and support tickets — every session should match a request
- Search for remote access tools that are not on the approved list — from the software inventory or endpoint tool, on servers as well as laptops
- Check alerting on vendor accounts — sign-ins outside the agreed window or from unexpected countries reach someone who will act
- Raise any unexplained session or unapproved tool as a security incident — link the incident record to this review
- Record the outcome for every route — keep, restrict or remove in the register, using the findings of Phases 2–5; a Yes/No answer on whether any change is needed switches on Phase 6
Phase 6
Phase 6: Remove & Restrict
Appears only when the last task of Phase 5 records that at least one route needs to be restricted or removed.
- Disable or delete each route marked for removal — accounts, agents, firewall rules, guest users and partner relationships
- Uninstall unapproved remote access software — and block it from reinstalling through application control where you have it
- Remove dormant routes — accounts and rules with no legitimate use since the last review
- Apply each restriction — narrower roles, a shorter window, a new landing host or an added MFA requirement
- Confirm with a fresh export — attach proof that each removed route is gone and tell the owner and vendor what changed
Phase 7
Phase 7: Sign-Off & Next Cycle
The sign-off task is an approval for the IT security lead or CISO. The checklist recurs quarterly.
- Update the route register — every remaining route with its owner, contract, reach, MFA status and access window
- Record exceptions with an expiry date — for example a shared OT vendor login the supplier cannot yet replace, with compensating controls
- Pass findings to the vendor relationship owner — repeated problems belong in the vendor risk assessment and the contract renewal
- Approve the review — confirming that remote access is limited to what is needed and the evidence is attached
Which Controls a Third-Party Remote Access Review Evidences
Most frameworks treat supplier access in two places: supplier management, and access control or remote access. PCI DSS is the most specific about vendor accounts. The table names each reference and the phase whose output you would hand an assessor.
| Framework | Reference | What it expects | Evidenced in |
|---|---|---|---|
| PCI DSS v4.0.1 | 8.2.7 | Accounts used by third parties for remote access enabled only during the time needed, disabled when not in use, and monitored for unexpected activity | Phases 4 and 5 |
| PCI DSS v4.0.1 | 8.4.3 | MFA for all remote network access from outside the entity’s network that could reach or affect the cardholder data environment, including third parties | Phase 3 |
| NIST SP 800-53 Rev. 5 | AC-17, MA-4 | Each type of remote access authorised and restricted; nonlocal maintenance approved, monitored, strongly authenticated and ended when complete | Phases 1, 3 and 4 |
| NIST SP 800-53 Rev. 5 | SA-9 | External service providers meet your security requirements, with oversight and ongoing monitoring of their compliance | Phases 2 and 7 |
| ISO/IEC 27001:2022 Annex A | A.5.19–A.5.22 | Supplier security requirements agreed, ICT supply chain risk managed, and supplier services monitored and reviewed | Phases 2, 5 and 7 |
| SOC 2 (2017 TSC) | CC9.2 | Risks from vendors and business partners assessed and managed | Phases 2 and 7 |
| CIS Controls v8.1 | 15.1, 15.7, 6.4 | Inventory of service providers; providers securely decommissioned, including account deactivation; MFA for remote network access | Phases 1, 3 and 6 |
Your assessor or auditor decides what evidence is sufficient for your scope, so treat the table as a starting point, not legal or audit advice. PCI DSS 7.2.4 also requires user accounts, including third-party accounts, to be reviewed at least every six months; a quarterly cycle meets that and keeps each review small. For the full programmes, see the PCI DSS 4.0 Compliance Checklist and the ISO 27001 Compliance Checklist.
Why Run Remote Access Reviews in CheckFlow?
Removal work appears only when needed
The removal phase appears only when the review finds a route to restrict or remove, so a clean quarter stays short and a messy one cannot close until each change is evidenced.
The same review, every quarter
A quarterly recurring schedule creates the next cycle automatically, with the same tasks and owners. The audit trail shows who confirmed each route and who signed the review, which is the evidence a PCI assessor or SOC 2 auditor asks for.
CheckFlow is not a remote access gateway, privileged access tool or endpoint agent; it runs the human side around them: who owns each route, who confirmed it is still needed, and proof it was removed. Use vendor onboarding software to grant vendor access the right way in the first place, with the contract, NDA and security review completed before any account is created.
Access granted when a new tool is bought belongs in the review from day one, so record it in the SaaS Procurement Security Review Checklist and add it to the route register. When a contract ends, close the vendor’s routes the same week rather than waiting for next quarter.
Frequently Asked Questions
What is a third-party remote access review?
It is a periodic check of every way an outside organisation can connect to your systems: VPN accounts, remote support and RMM agents, jump hosts, cloud guest and partner admin access, firewall rules for vendor addresses, and modems on equipment. For each route it confirms there is an internal owner, a current contract and a real need, that access is by named accounts with MFA, that it is switched on only when needed and logged, and that anything no longer needed is removed.
How often should vendor remote access be reviewed?
Quarterly is a common cadence, and routes should also be closed whenever a contract ends or a vendor engineer leaves. PCI DSS v4.0.1 requires user accounts, including third-party accounts, to be reviewed at least every six months, and its requirement 8.2.7 expects third-party remote access accounts to be enabled only when needed, which in practice means checking them far more often than once a year.
What does PCI DSS require for vendor remote access?
Requirement 8.2.7 says accounts used by third parties to access, support or maintain system components via remote access are enabled only during the time needed, disabled when not in use, and monitored for unexpected activity. Requirement 8.4.3 requires MFA for all remote network access from outside your network that could reach or affect the cardholder data environment, including access by third parties and vendors. Confirm scope with your QSA.
How do we find remote access tools nobody approved?
Start with your software inventory and endpoint management tool, and search for remote desktop and RMM products by name and publisher, on servers as well as laptops. Compare the results with your approved list. CISA’s 2023 guidance notes that attackers favour legitimate remote access tools because security software often trusts them, so an unexpected install is worth investigating rather than simply removing. Application control can then stop the tools from coming back.
Can vendor engineers share one login?
They should not. A shared account means you cannot tell who did what, cannot remove one person when they leave the vendor, and usually cannot enforce MFA properly. Ask for a named account per engineer. Where an equipment supplier genuinely cannot support that yet, record a time-limited exception with compensating controls such as access only through a monitored jump host and a password changed after every session.
What is Microsoft GDAP and why should we review it?
Granular delegated admin privileges (GDAP) is how Microsoft partners such as MSPs and resellers get admin access to a customer’s Microsoft 365 tenant. It replaced the older delegated admin model, which granted broad standing rights. Each GDAP relationship sets the roles granted and a duration of up to two years, and some can auto-extend. Customers can see and remove partner roles on the Partner relationships page of the Microsoft 365 admin centre, which makes it a quick, high-value check every quarter.
Is CheckFlow free for this template?
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.