Safeguard 13.5: Manage Access Control for Remote Assets

Safeguard 13.5 requires you to control how remote assets (laptops, mobile devices, remote servers, and third-party endpoints) authenticate and access your environment, with enforced policies and auditable evidence. Operationalize it by inventorying remote-capable assets, routing remote access through managed entry points, enforcing strong authentication, and continuously monitoring and revoking access when risk changes. ¹

Key takeaways:

• Treat “remote asset” as a distinct access-control scope with its own policy, tooling, and evidence set. ¹
• Centralize remote access paths (VPN/ZTNA/VDI/jump hosts), then enforce identity, device posture, and least privilege at those choke points. ²
• Build assessor-ready artifacts: approved access methods, configuration baselines, access logs, exception handling, and recurring reviews. ¹

Remote assets expand your attack surface because they operate outside your managed network perimeter, on variable networks, and often in shared physical environments. Safeguard 13.5: manage access control for remote assets requirement focuses on one thing: ensure that remote endpoints and remote connectivity do not become an unmanaged backdoor into enterprise systems. The control is less about a single technology and more about repeatable, enforceable rules for “how remote gets in,” “what remote can reach,” and “how you prove it.”

For a Compliance Officer, CCO, or GRC lead, the fastest path is to define the remote-access “front door,” require strong identity and device controls at that door, and make the program auditable. This means a policy that names approved remote access methods, technical enforcement (not just guidance), and routine checks that access remains appropriate as users, devices, and third parties change.

This page gives requirement-level implementation guidance you can assign to IT and Security, then validate through evidence. It is written to help you pass internal audit, customer security reviews, and external assessments aligned to CIS Controls v8. ¹

Regulatory text

Framework excerpt (provided): “CIS Controls v8 safeguard 13.5 implementation expectation (Manage Access Control for Remote Assets).” ¹

Operator meaning: You must implement and maintain access controls specifically for remote assets and remote access paths, with controls that work consistently outside your network boundary. The expectation is enforceable access control (who/what can connect, by what method, to which resources) plus evidence that the control operates over time. ¹

What an assessor will look for:

• A defined scope of remote assets and remote access methods. ¹
• Technical enforcement at the access point (identity controls, device controls, authorization). ²
• Ongoing operations: monitoring, access review, and revocation. ¹
• Evidence that is repeatable, not a one-time screenshot. ¹

Plain-English interpretation (what you’re really being asked to do)

You need to ensure that any endpoint or system connecting from “remote” conditions cannot access corporate resources unless:

1. the user is strongly authenticated,
2. the device is known and meets your security baseline (or is isolated), and
3. the access granted is the minimum necessary and can be withdrawn quickly.

“Remote assets” typically include corporate laptops, mobile devices, BYOD (if allowed), remote admin workstations, home lab machines used for work, cloud-hosted virtual machines administered remotely, and third-party endpoints that connect to your systems for support or integration. Your job is to make remote access predictable, policy-driven, and logged. ¹

Who it applies to

Entity scope: Enterprises and technology organizations implementing CIS Controls v8. ¹

Operational scope (where it shows up in real programs):

• Workforce remote work, hybrid work, travel, and field operations.
• IT administrators managing infrastructure remotely.
• Third-party support (managed service providers, contractors) needing privileged or production access.
• Remote access to SaaS admin consoles, cloud consoles, and internal apps.
• M&A or subsidiaries with different endpoint stacks that still require connectivity.

If you have remote connectivity but no formally approved remote access paths, Safeguard 13.5 becomes a “control design” issue. If you have policies but inconsistent enforcement across business units, it becomes a “control operation” issue. ¹

What you actually need to do (step-by-step)

1) Define scope and ownership

• Write a remote access control standard that names: approved remote access methods, prohibited methods, authentication requirements, device requirements, and logging requirements. ¹
• Assign owners: Security Engineering owns enforcement; IT owns endpoint configuration; GRC owns evidence cadence and exceptions. ¹

Deliverable: “Remote Access & Remote Asset Access Control Standard” with a simple RACI.

2) Inventory remote-capable assets and access paths

• Identify remote-capable endpoints (managed and unmanaged) and classify them: workforce endpoints, privileged admin endpoints, third-party endpoints.
• Map remote access paths: VPN, ZTNA, VDI, RDP gateways, bastion/jump hosts, SSH gateways, SaaS admin access, cloud console access.
• Document “shadow paths” discovered in logs (direct-to-server RDP, exposed SSH, ad-hoc tunnels).

Deliverable: Remote access data flow diagram + system list tied to your asset inventory. ¹

3) Centralize remote access through controlled entry points

• Choose sanctioned entry points (examples: VPN with device checks, ZTNA with posture validation, VDI for high-risk access, bastions for admin protocols).
• Block direct inbound management protocols from the public internet where feasible; force remote administration through the sanctioned path.
• For third parties, prefer isolated access methods (VDI/jump host) and time-bounded accounts.

Deliverable: Architecture decision record for remote access paths, plus firewall/security group rules showing approved ingress. ²

4) Enforce strong authentication and authorization for remote access

• Require MFA for remote access and for administrative access from remote conditions.
• Tie authorization to role-based access groups and least privilege.
• Add conditional access rules where possible: higher assurance for privileged actions, restrict high-risk geographies, restrict unknown devices.

Deliverable: IdP/SSO conditional access policy exports + group/role mapping. ¹

5) Enforce device posture for remote assets

Decide your posture approach by asset type:

• Managed corporate endpoints: require device management enrollment (MDM/EDR), encryption, supported OS, screen lock, and endpoint protections.
• BYOD (if permitted): restrict to low-risk apps, require MDM containerization, or require VDI.
• Third-party endpoints: require VDI/jump host or attestations plus additional monitoring; avoid persistent VPN from third-party laptops unless you can validate posture.

Deliverable: Endpoint baseline standard + MDM/EDR compliance reports showing remote devices meeting baseline. ¹

6) Monitor, log, and review remote access activity

• Centralize logs from VPN/ZTNA/VDI, IdP sign-ins, bastion sessions, and key admin consoles into your SIEM or logging platform.
• Define alerts for high-risk events: impossible travel, repeated failures, new device enrollment, privileged logins from remote networks, third-party account use outside approved windows.
• Conduct recurring access reviews for privileged remote access and third-party access.

Deliverable: Logging coverage map + sample alert rules + evidence of review and remediation actions. ¹

7) Build an exception and break-glass process

• Define allowed exceptions (example: emergency outage support) with approvals, time limits, and compensating controls.
• Maintain break-glass accounts with strong controls, separate logging, and frequent review.
• Require after-action review for any emergency remote access.

Deliverable: Exception register + break-glass runbook + post-incident reviews. ¹

8) Map the control and automate evidence capture

This safeguard often fails due to “we do it, but can’t prove it.” Treat evidence as a recurring operational output:

• Save policy exports (IdP conditional access, VPN config, ZTNA policy sets) on a schedule.
• Snapshot group membership and privileged access assignments.
• Store logs and review tickets in a system that supports retrieval.

Daydream can help by mapping safeguard 13.5: manage access control for remote assets requirement to a documented control narrative and setting up recurring evidence collection prompts so audit readiness is continuous, not a scramble. ¹

Required evidence and artifacts to retain

Use this table as your audit-ready checklist:

Evidence type	What “good” looks like	Owner
Remote access standard	Approved methods, prohibited methods, MFA/device requirements, logging	GRC + Security 1
Remote access architecture	Documented entry points (VPN/ZTNA/VDI/bastion), network restrictions	Security Engineering 2
IdP/SSO policies	MFA + conditional access exports, policy change history	IAM 1
Endpoint posture reports	MDM/EDR compliance for remote devices, baseline enforcement	IT Endpoint 1
Third-party access controls	Contractual/security requirements + technical enforcement + account lifecycle	Vendor/Third-Party Risk + IAM 1
Logging and monitoring	Log sources list, SIEM ingestion proof, alert catalog, sample investigations	SecOps 1
Access reviews	Evidence of periodic review, findings, and removal actions	IAM + System Owners 1
Exception register	Approvals, time bounds, compensating controls, closure	GRC 1

Common exam/audit questions and hangups

1. “What counts as a remote asset here?” Have a written scoping statement and examples for workforce, admin, and third-party endpoints. ¹
2. “Show me the approved remote access methods.” Provide the standard plus technical configurations that enforce it. Auditors dislike “policy-only” controls. ¹
3. “Prove MFA is enforced for remote access.” Bring IdP policy exports and a test account walkthrough plan. ¹
4. “How do you prevent direct RDP/SSH from the internet?” Show firewall/security group rules and bastion architecture. ²
5. “How do you control third-party remote access?” Show time-bounded access, least privilege, session logging, and offboarding evidence. ¹

Frequent implementation mistakes (and how to avoid them)

• Mistake: Multiple remote access tools with inconsistent policy. Fix by selecting sanctioned paths and decommissioning or blocking alternatives. ¹
• Mistake: Treating VPN connection as “compliant” without device checks. Add device posture requirements or force high-risk access through VDI/bastion. ¹
• Mistake: Third parties share accounts or keep access indefinitely. Require named accounts, approvals, and removal triggers tied to contracts and tickets. ¹
• Mistake: Logging exists but isn’t reviewable. Ensure logs are centralized, retained, and linked to a review workflow with tickets. ¹
• Mistake: Evidence is ad hoc. Implement recurring evidence capture (policy exports, reports, reviews) and store it in a consistent repository. ¹

Risk implications (what can go wrong)

Remote access is a common pathway for credential theft, unauthorized lateral movement, and persistence through unmanaged endpoints. Weak control over remote assets also increases third-party risk: a third party’s endpoint security becomes your exposure if you allow direct network-level access without posture checks and session controls. Safeguard 13.5 is a practical way to reduce that exposure by forcing remote connectivity through managed choke points and requiring higher assurance for high-impact access. ¹

Practical execution plan (30/60/90-day)

First 30 days (Immediate hardening + scope lock)

• Publish the remote access standard with approved methods and minimum requirements. ¹
• Inventory remote access paths and identify any direct-to-internal exposures.
• Enforce MFA for remote access where technically feasible; document gaps as exceptions. ¹
• Define evidence owners and storage location (GRC repository or Daydream control record). ¹

Days 31–60 (Enforcement + posture)

• Centralize remote admin protocols through bastion/jump hosts where feasible. ²
• Implement device posture checks for managed endpoints; restrict unknown devices. ¹
• Formalize third-party remote access: named accounts, approvals, time bounds, session logging. ¹
• Start recurring access reviews for privileged remote access. ¹

Days 61–90 (Operational maturity + audit readiness)

• Tune monitoring and alerts for remote sign-ins and privileged activity; link alerts to incident workflow. ¹
• Run a tabletop test of the exception/break-glass process and collect artifacts. ¹
• Produce an “assessment packet” with: policy, architecture diagram, key configs, sample logs, access review evidence, and exception register. ¹
• Automate evidence collection schedules in Daydream so the control stays continuously provable. ¹

Frequently Asked Questions

What exactly counts as a “remote asset” for Safeguard 13.5?

Treat any endpoint or system that connects from outside your controlled network as remote, including workforce laptops, mobile devices, remote admin workstations, and third-party endpoints. Define your scope in writing and tie it to your asset inventory. ¹

Do we need VPN, or can we meet the requirement with ZTNA or VDI?

CIS is technology-agnostic; assessors care that remote access is controlled, enforced, and auditable. Choose one or more sanctioned paths (VPN/ZTNA/VDI/bastion) and block or retire unsanctioned paths. ²

How should we handle third-party remote support access?

Prefer isolated access methods (VDI or jump host) with named accounts, least privilege, and session logging. Time-bound approvals and remove access promptly when work ends. ¹

Is MFA alone enough to satisfy Safeguard 13.5?

MFA is necessary for most environments, but Safeguard 13.5 also expects access control for remote assets as a whole, including approved access methods, authorization, device posture, and monitoring. Build evidence that you enforce those elements consistently. ¹

What evidence should GRC collect without becoming a bottleneck?

Collect stable exports (IdP conditional access policies, VPN/ZTNA policy sets, MDM compliance reports) and periodic review records, then store them in a structured control record. Daydream helps by prompting recurring evidence capture and keeping the control narrative aligned to the requirement. ¹

We have multiple business units with different endpoint tools. How do we make this auditable?

Standardize the outcome (MFA, posture, logging, approved entry points) and allow tool variation only if each unit can produce equivalent evidence. Document equivalency decisions and keep exceptions time-bound. ¹

Footnotes

1. CIS Controls v8

2. CIS Controls Navigator v8