This secure remote access checklist has 12 checks on how people reach your business applications. Each check scores 2, 1 or 0 against the evidence you can show. The total tells you whether the access path holds up. If a check has no proof to show, it scores 0, and a zero on a critical check overrides a high total.
Last reviewed 2026-11-05 by Manish Sharma.
It asks who reaches which application, by which route and with what proof. That supports the goal of checking access to business applications. Why a VPN is the weak point explains why a network-wide link needs this scrutiny. Staff laptops and home set-ups sit elsewhere, in the checklist for staff working from home.
How the Secure Remote Access Checklist Scores
Key Takeaway A check earns 2 with its evidence in hand, 1 for a partial pass, and 0 for a fail or no evidence.
A check earns 2 when it meets its pass rule and you can produce the evidence beside it. It earns 1 when the rule holds in only part of the estate, for example in some applications but not all. It earns 0 when the rule fails or the evidence does not turn up.
Mark a check N/A only when the thing it tests does not exist, for example a VPN appliance the firm does not run. When you drop a check, scale each band limit by the share of checks you kept and round to the nearest whole point.
When a check asks for a sample, the reviewer draws it from the full list. The IT lead scores, together with the identity owner and one application owner.
The result is a self-review and no certification.
Every number here is our own suggestion, and you can change it. They are 12 checks, 24 points and a sample of 10 accounts. The windows are 30 days, 90 days, 1 business day and 2 business days. None is a benchmark or a study finding. Use the matching step of the six-step guide to fix a failed check, unless the table says the guide does not cover it.
The Full Secure Remote Access Checklist: Pass Rules and Evidence for Each Check
This secure remote access checklist holds 12 checks in three copyable tables, worth 24 points, and Figure 1 shows how they group. Copy them into a sheet, then add columns for date, reviewer, score and fix owner.
Secure Remote Access Checklist, Checks 1 to 4
| Check | Pass rule | Evidence | Where the guide fixes it |
|---|---|---|---|
| Check 1: Multi-factor sign-in on every remote path (critical) | Every route to a business application asks for a second factor, including the VPN and any direct web route. No route lets a password alone through. | The sign-in policy for each route, and one test sign-in per route that asks for the second factor. | Step 2 |
| Check 2: Second-factor reset has an approver | A named person approves each reset after confirming who is asking, and the firm tested the reset path in the last 90 days. | The approver’s name, the written reset steps and the date of the last test. | Step 2 |
| Check 3: Access is per application, with no network-wide reach (critical) | Each person reaches only the applications their job needs. Every server and network segment outside the list refuses a connected user’s account. | The access list for three applications, and a test from a normal account that fails to reach an application outside its list. | Step 4 |
| Check 4: The application list is current | One sheet lists every business application with its owner, its users and how staff reach it. The firm reviewed the sheet in the last 90 days. | The sheet with its review date, and a count of applications with no owner. The pass rule is zero. | Step 1 covers the sheet and owners, but the guide does not cover the review period. |
Checks 5 to 8 of the Secure Remote Access Checklist
| Check | Pass rule | Evidence | Where the guide fixes it |
|---|---|---|---|
| Check 5: Sign-in checks device health | A written device standard exists. The firm blocks a device that fails it, or limits it to a short list of applications, with a plain message to the user. | The standard, the setting that applies it, and one failed test device showing the block. | Step 3 |
| Check 6: Remote desktop does not answer from the internet (critical) | An outside scan of the firm’s public addresses, run in the last 30 days, finds no remote desktop port answering. | The dated scan output, or a signed statement from whoever ran it, listing the addresses scanned. | Not covered, because the guide treats remote desktop as out of scope. |
| Check 7: VPN or gateway patch status carries dates (critical) | Every VPN or gateway device runs a version its supplier still supports. Each urgent supplier fix reached the device within 2 business days. | A device list with the running version, and the release and application date of each urgent fix. | Step 6 has one line on patching, but the guide does not cover the dated record. |
| Check 8: Sign-in logging is on and kept | The firm records successful and failed sign-ins to business applications and the VPN for 90 days, and one named person owns the logs. | The retention setting, the owner’s name and an export from yesterday. | Step 6 names an owner for logs, but the guide does not cover the retention period. |
Secure Remote Access Checklist, Checks 9 to 12
| Check | Pass rule | Evidence | Where the guide fixes it |
|---|---|---|---|
| Check 9: A named reviewer checks a log sample | A named reviewer checks a sample of sign-ins every 30 days, and each finding has an owner and a date. | The last two review records, with the sample drawn and the findings closed. | Step 6 names an owner for logs, but the guide does not cover the review routine. |
| Check 10: Leavers lose access in time | Each person who left in the last 90 days lost access within 1 business day of their last day. | A sample of up to 10 leavers, each with the leaving date and the removal date side by side. | Step 1 removes people who no longer need access, but the guide does not cover the time limit. |
| Check 11: Contractor and vendor access ends on a date | Each outside account has a named sponsor and an end date no later than the contract end. If an account has expired, it is off. | The list of outside accounts with sponsor, end date and last sign-in. | Step 6 applies the same policy as for staff, but the guide does not cover the time limit. |
| Check 12: Exceptions have an owner and an end date | Every exception to the rules above has a named owner and an end date. None is past its date. | The exception list, with an owner and an end date on each row. | Step 6 |
Sign-In and Application Checks: What to Ask For
Request the policy, then watch a test run. A single yes-or-no question about multi-factor does not show the routes you forgot, so check 1 asks per route.
For check 1, ask for one test sign-in on every route, including any direct web address to an application. Check 2 asks who approves a reset, how that person confirms who is asking, and when the firm last tested the path.
For check 3, the evidence is a refusal: take a normal account, try an application outside its list, and watch it fail. NIST SP 800-207 describes zero trust as granting no implicit trust to an account based solely on network location. The test is the same whether the firm runs a VPN or zero trust network access (ZTNA).
For check 4, count the applications with no owner; checks 1, 3 and 5 ask you to pick applications from this sheet. For check 5, ask to see the block on one failed test device.
Key Takeaway For checks 1 to 5, the proof is a test you can watch: a second-factor prompt, a refused sign-in or a blocked device.
Remote Desktop and Patch Checks: What to Ask For
A description such as “we patch regularly” earns 0.
Check 6 is a yes or no from a scan of the firm’s public addresses. The six-step guide does not cover remote desktop, so the fix is a task for the IT lead. This article does not give it.
Check 7 asks for dates instead of reassurance. For each VPN or gateway device, ask for the running version and two dates for every urgent fix: released and applied. The gap between them is the number to read.
Key Takeaway A zero on check 6 or check 7 stops a high total from reading as a pass.
Both are critical checks. In our view, a zero on either should void a high total, since you can test both from outside.
Logging, Leaver and Vendor Checks: What to Ask For
For check 8, ask for the retention setting and an export from yesterday. The export gives some sign that logs are flowing, while a setting alone does not show it. For check 9, a log nobody reads proves nothing, so the evidence is a sample that you draw, with its findings closed. Because the guide leaves the review routine out, this is a gap you fill yourself.
For check 10, put the leaving date against the removal date for up to 10 leavers, drawn by the reviewer from the HR list. A wide gap on any row is a finding, even when the average looks fine.
For check 11, vendors are their own case, and access for outside vendors covers it in full. For check 12, an exception with no owner or end date is a permanent gap with a polite name.
What Your Score Means: Pass, Fix First or Not Ready
Add the points out of 24, then read the band in Figure 2.
| Score | Band | First action |
|---|---|---|
| 21 to 24 | Pass | Store the evidence, then run the review again on the schedule you set. |
| 15 to 20 | Fix first | Fix the failed checks, critical ones first, then rescore after 30 days. |
| 9 to 14 | Not ready | Begin with checks 1, 3, 6 and 7, then work through the rest in table order. |
| 0 to 8 | Unowned | Write down who owns remote access, and list every route to every application (check 4). |
If any critical check (1, 3, 6 or 7) scores 0, the access path is not ready whatever the total. Those four checks cover the ways in that a high total would otherwise hide.
We chose the band limits and the gate rule ourselves, so adjust them to suit the firm.
This illustration is fictional, not data. A firm scores 20 of 24, which reads “fix first”. Check 6 scores 0 because a scan finds a remote desktop port answering. The gate rule overrides the band to “not ready”, and the first job becomes shutting that port.
This page claims nothing about a named standard or a legal duty.
Secure Remote Access Checklist FAQ: Questions on Scoring and Evidence
How frequently should you run a secure remote access checklist?
Who should score the checks?
Can a small firm use this secure remote access checklist as it stands?
What if the evidence for a check is missing?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.