VPN and Remote-Access Security Review Checklist

Remote access is a system, not a tunnel. NIST SP 800-46 Rev. 2 says components of telework and remote-access technologies, including organization-issued and BYOD client devices, should be secured against expected threats identified through threat models. Review gateway, identity provider, endpoint, policy, destination, administration plane, and logging together. Encryption protects transport; it does not decide who may reach which internal resource or whether endpoint is safe.

This checklist creates a review record for named access paths, not VPN certification. Scope identifies gateway and management URLs, versions, public exposure, identity sources, groups, device classes, destinations, sessions, and logging.

Map exposure before access policy

Inventory every external gateway, portal, update endpoint, management interface, and federation callback. Confirm DNS names, IP addresses, ports, TLS endpoints, version, support status, and administrators. Test internet-reachable management, obsolete services, and revealing errors. Keep dated exposure record.

Patch review captures version, supported-release reference, advisory review, backup date, maintenance owner, and change record. CISA KEV is input to prioritization, not complete vulnerability list. An exposed gateway with applicable known-exploited vulnerability needs immediate triage, containment, and verified remediation.

Example flow:

managed laptop requests vpn.example
  | phishing-resistant MFA verifies named user
  | device posture says encrypted, supported, security agent healthy
  | group policy grants finance-app subnet only
  | gateway creates 8-hour maximum and 15-minute idle session
  | logs link identity, device, gateway, policy, and destinations

Require MFA with resistant recovery

Define primary authentication and recovery separately. Review factors, enrollment, reset authorization, and identity-provider failure. Privileged and gateway-administration accounts need separate policy.

Run controlled tests: password-only request, wrong factor, factor reset without required proof, former user with old factor, and administrator access from normal remote-access group. Record expected denial and event evidence. Break-glass access may be needed, but it must be limited, time-bound, monitored, and reviewed after use. Never leave emergency credentials as untracked standing access.

Review entitlement lifecycle

Remote access should follow assigned work, not organization membership. Map each group to explicit destination, protocol, action, owner, and review date. “VPN users” is too broad when a user needs only one application or subnet. Separate standard user, contractor, vendor support, administrator, and automated service paths. Remove access when employment, contract, project, or approved role ends.

Use joiner-mover-leaver evidence: access request, owner approval, group assignment, last review, termination event, removal timestamp, and exception record. Test an expired contractor, a user moved out of role, and a stale privileged group. Each should lose access at expected boundary. If manual removal creates delay, record failure and remediation such as identity-driven deprovisioning, periodic recertification, or a narrower group design.

Check device posture and BYOD boundary

A device can authenticate while still failing security requirements. Define posture signals: operating-system support level, disk encryption, screen lock, endpoint security agent, device-management enrollment, and recent check-in. Define source, freshness, owner, failure behavior, and privacy limit for each. Do not collect more device data than policy requires.

For managed devices, test stale agent, disabled encryption, unsupported OS, and missing management enrollment. For BYOD, decide which resources remain available and which require managed device or browser-isolated path. A single “compliant” flag without signal details creates weak evidence. When posture provider fails, policy must state whether access denies, degrades to lower-risk resources, or uses a documented exception; test that behavior.

Bound sessions and watch use

Session controls limit exposure after access is granted. Review maximum session age, idle timeout, reauthentication for sensitive actions, concurrent-session rule, token revocation, network-change response, and user-visible warning. Values depend on risk; record reason rather than copy a universal timer. A short timer without revocation is not enough if a disabled account retains valid session.

Exercise session lifecycle: wait for idle expiry, revoke identity or device, change entitlement during session, reconnect from different network, and access blocked destination. Capture gateway, identity, and destination logs. Logs should reconstruct user or workload, device, authentication result, policy or group, gateway, session identifier, start/end, and material destination decision. Protect logs from secrets and unnecessary personal data.

Completed review ledger

Remote-access check	Proof collected	Responsible role	Test outcome	Follow-up boundary
Gateway exposure	asset list, port scan record, version and advisory review	gateway owner	Pass/Fail	disable service, patch, restrict management
MFA and recovery	factor policy, denied tests, reset procedure	identity owner	Pass/Fail	remove weak recovery path
Entitlement lifecycle	group map, approvals, leaver test, review date	access owner	Pass/Fail	deprovision automation
Device posture	signal definitions, stale-device test, failure mode	endpoint owner	Pass/Fail	require management or limit resource
Session controls	timeout policy, revoke test, correlated logs	security owner	Pass/Fail	add revocation or reauthentication

Evidence references should include configuration revision, test date, redacted event IDs, owners, and retest requirement. Pass means stated control produced expected result for stated path. Fail means absent, bypassed, stale, or unobservable control. An exception requires affected path, business reason, compensating control, approver, expiration, remediation owner, and retest date.

Questions for buyer review

Ask which remote entry points exist, who owns each, and which destinations each group can reach. Ask how MFA recovery is protected, how access disappears after role change, what device signals are enforced, and how active sessions are revoked. Ask for evidence of a denied stale device, denied former user, denied unrelated destination, and ended idle session.

Finish with scope, asset register, policy exports, test results, pass/fail decisions, exceptions, remediation owners, and a retest date. Re-run review after gateway upgrade, identity change, new contractor path, device-posture change, or new internal destination.

Validate destination enforcement

Test destination control after tunnel establishment. An approved finance user may reach only named finance services; a successful VPN login does not prove that boundary. Capture assigned address, route table, group or policy version, attempted destination, gateway decision, and destination-side log. Retest after group, gateway, or route changes. This separates authenticated tunnel access from actual least-privilege resource access.