Safeguard 6.4: Require MFA for Remote Network Access

Safeguard 6.4 requires you to enforce multi-factor authentication (MFA) for all remote network access so a stolen password alone cannot grant entry. Operationalize it by defining what “remote access” means in your environment, routing every remote path through an MFA-capable access plane (VPN/ZTNA/SSO), and retaining evidence that MFA is technically enforced and monitored. ¹

Key takeaways:

• Scope every remote access entry point (VPN, VDI, SSH/RDP, admin portals, cloud consoles) and close or gate any bypass paths.
• Make MFA a technical control (conditional access, VPN policy, PAM), not a policy-only requirement.
• Keep assessor-ready evidence: system configs, conditional access rules, access logs, exception approvals, and periodic access-path reviews.

The fastest way to fail Safeguard 6.4 is to roll out MFA “for users” while leaving one quiet remote path unprotected, like a break-glass local account on a VPN concentrator, a third-party support tool, or direct SSH to a cloud VM. Safeguard 6.4 is not asking whether MFA exists; it is asking whether remote network access is actually gated by MFA across your remote access attack surface. ¹

For a Compliance Officer, CCO, or GRC lead, the operational problem is scope and proof. You need a clear definition of remote network access, an inventory of all remote access methods, and an enforcement architecture that prevents exceptions from becoming permanent backdoors. You also need repeatable evidence collection: screenshots alone rarely show “enforced” versus “available.” You want configuration exports, policy objects, and logs that demonstrate MFA was required at the point of access. ¹

This page gives requirement-level implementation guidance you can hand to IT and Security, then use to run an audit-ready control that you can test and evidence on a recurring basis. The goal is simple: every remote access attempt hits MFA, every time, with controlled exceptions. ¹

Requirement: safeguard 6.4: require mfa for remote network access requirement

What the requirement means in practice: any access into your environment from outside your trusted network boundary must require at least two factors. “Remote network access” includes both user access and administrative access paths that can reach internal systems or management planes. ¹

Plain-English interpretation

You must:

1. identify every way a person or system can connect remotely to your network or managed assets, and
2. enforce MFA on those paths with technical controls, and
3. be able to prove enforcement with durable evidence. ¹

This is an authentication control aimed at the most common failure mode in intrusions: credential theft plus remote access. MFA reduces the impact of password compromise, but only if it is consistently required on the remote entry points attackers target first.

Regulatory text

Excerpt (framework requirement): “CIS Controls v8 safeguard 6.4 implementation expectation (Require MFA for Remote Network Access).” ¹

Operator interpretation of the text: you are expected to implement MFA as an enforced gate on remote network access. A written policy that “requires MFA” is not enough if VPN, SSH, RDP, VDI, helpdesk tools, or cloud admin portals can be reached remotely with only a password. Your implementation should make MFA unavoidable for remote entry, and you should retain evidence that demonstrates enforcement and ongoing operation. ¹

Who it applies to

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

Operational scope (what to include):

• Workforce remote access: VPN, ZTNA, VDI, remote desktop gateways, remote file access.
• Administrative remote access: domain admin workflows, privileged SSH/RDP, hypervisor management, network device management, bastions/jump hosts, PAM access brokers.
• Cloud management access: cloud consoles, IAM admin portals, infrastructure management planes when reachable from the internet.
• Third-party remote support: managed service providers, contractors, and support tools that can initiate inbound remote sessions.

A clean scoping statement to use internally:
“Any remote interactive access that can reach internal networks, production systems, or management planes must require MFA at the point of entry, with documented and time-bound exceptions.”

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

Step 1: Define “remote network access” in your control narrative

Write one paragraph that your IT team and auditors can both use:

• From outside the corporate network, including home networks and mobile networks.
• From unmanaged devices or unknown networks, even if the user is an employee.
• From third parties connecting to administer systems.

Add boundary examples: public internet to VPN; internet to cloud console; remote admin via jump host.

Artifact: “Safeguard 6.4 Control Narrative” (1–2 pages) mapping scope, systems, and enforcement points. ¹

Step 2: Inventory all remote access entry points (find the bypasses)

Create a remote access register. Minimum columns:

• Entry point name (e.g., “VPN-Primary,” “RDP Gateway,” “AWS Console,” “Support Tool X”)
• User populations (employees, admins, third parties)
• Authentication method (SSO, local accounts, keys, certificates)
• MFA enforcement method (conditional access policy, VPN MFA module, PAM)
• Status (enforced / partial / not enforced)
• Owner and review date

How to discover paths quickly:

• Network/security team: VPN concentrators, firewalls, remote access gateways.
• Identity team: SSO apps flagged as admin or high risk.
• Cloud team: list internet-exposed management endpoints and console access patterns.
• Procurement/IT: any remote support/remote control tools used by IT or third parties.

Artifact: Remote Access Register (owned by Security/GRC, maintained by IT). ¹

Step 3: Choose the enforcement architecture (make MFA unavoidable)

Pick the control points that can technically enforce MFA:

Common patterns

1. SSO + Conditional Access: Require MFA for remote sign-ins to critical apps and admin portals; block legacy auth where possible.
2. VPN with MFA: Integrate VPN authentication with an MFA provider; require MFA for all remote VPN connections, including admins.
3. ZTNA (identity-aware proxy): Enforce MFA and device posture before granting access to internal apps.
4. PAM + Jump Host/Bastion: Force privileged remote sessions through a broker that requires MFA and records sessions.

Decision rule for operators: if a remote path cannot be centrally enforced and logged, treat it as a risk exception until remediated.

Artifacts: architecture diagram(s) showing remote entry points and MFA enforcement locations; list of systems in scope. ¹

Step 4: Implement MFA policies by access type (user vs privileged vs third party)

Use separate policies because audit questions differ.

A. Standard workforce remote access

• Require MFA for VPN/ZTNA/VDI.
• Prevent split tunneling exceptions from becoming “security exceptions” without review.
• Ensure service desk and IT tools used remotely also require MFA.

B. Privileged remote access

• Require MFA for admin portals, jump hosts, and PAM checkouts.
• Eliminate direct remote admin to servers where possible; route through controlled gateways.

C. Third-party remote access

• Require unique identities (no shared accounts) where feasible.
• Require MFA for the third party’s entry point.
• Contractually require MFA if the third party authenticates on their side, but prefer your enforcement at your perimeter when possible.

Artifacts: conditional access rules/policy objects; VPN MFA configuration exports; PAM policy settings; third-party access procedures. ¹

Step 5: Handle exceptions as a formal, time-bound risk decision

You will have edge cases: legacy systems, emergency access, remote access for devices without interactive MFA.

Minimum exception requirements:

• business justification and compensating controls (IP allowlisting, time windows, jump host only, monitored accounts)
• expiration date and owner
• evidence of approval (Security + system owner)
• plan to remediate

Artifacts: exception register; signed approvals; compensating control description; closure evidence.

Step 6: Operational monitoring and recurring evidence capture

Auditors will ask “how do you know it stayed enforced?” Answer with:

• Authentication logs showing MFA challenges for remote sign-ins.
• Alerts for MFA policy changes, disabled MFA, or new remote access apps.
• Periodic review of the Remote Access Register and policy objects.

Practical approach: set a recurring control cadence where GRC collects evidence and IT attests to no unapproved changes.

Artifacts: log samples; change tickets; access review notes; periodic control test results. ¹

Required evidence and artifacts to retain (audit-ready checklist)

Retain evidence that proves both design and operation:

Design evidence (what should happen)

• Safeguard 6.4 control narrative and scope statement. ¹
• Remote Access Register with owners and enforcement method. ¹
• MFA policy standard (who must use MFA, for which access types).
• System diagrams or data flows showing remote entry points and MFA gates.

Operating evidence (what did happen)

• Configuration exports or screenshots of:
  • VPN MFA enforcement settings
  • SSO conditional access rules requiring MFA for remote access
  • PAM/jump host MFA requirement
• Sample authentication logs showing remote access required MFA (date-stamped).
• Change management records for MFA policy updates (tickets, approvals).
• Exceptions: approvals, compensating controls, expiry, closure.

Control mapping evidence

• A mapping showing where 6.4 is implemented and how evidence is captured on a recurring basis, aligned to “documented control operation and recurring evidence capture.” ¹

Daydream (if you use it) fits naturally here as the system of record for the Remote Access Register, exception workflows, and recurring evidence tasks so you can demonstrate continuous operation without rebuilding an audit binder each cycle.

Common exam/audit questions and hangups

Expect these, and prepare short, evidence-backed answers:

1. “What do you define as remote network access?”
   Provide your scope statement and examples; show the Remote Access Register.

2. “Is MFA enforced or merely available?”
   Show policy objects (conditional access rules, VPN config) that block access without MFA.

3. “Do admins and third parties follow the same MFA requirement?”
   Show separate policies or a single policy that clearly includes privileged and third-party access paths.

4. “How do you prevent bypass?”
   Demonstrate that direct-to-system paths (SSH/RDP from internet) are blocked or routed through MFA-gated gateways.

5. “How do you know it stayed on?”
   Provide logs, monitoring alerts, and change control records.

Frequent implementation mistakes (and how to avoid them)

• Mistake: MFA only for VPN, while cloud consoles remain password-only.
  Fix: include cloud management portals and identity provider sign-in policies in the Remote Access Register.

• Mistake: “Break-glass” accounts with no controls become permanent.
  Fix: store break-glass credentials securely, restrict network paths, require approval to use, and review usage logs.

• Mistake: Third parties use shared accounts.
  Fix: assign named accounts and require MFA; if shared accounts are unavoidable, treat as an exception with compensating controls and expiry.

• Mistake: You cannot produce evidence beyond screenshots.
  Fix: export policy objects/configs and keep log extracts that show MFA challenges for remote sessions.

• Mistake: MFA prompts are inconsistent due to “remember device” settings.
  Fix: set session and re-auth requirements appropriate for remote access risk, and document the rationale in your standard.

Enforcement context and risk implications

CIS Controls v8 is a framework, not a regulator, and the provided sources do not include public enforcement cases tied to Safeguard 6.4. ¹ Practically, failure to enforce MFA on remote access increases the likelihood that stolen credentials lead directly to an intrusion, which can cascade into regulatory findings under whichever laws apply to your industry.

Practical 30/60/90-day execution plan

First 30 days (baseline and containment)

• Publish the Safeguard 6.4 control narrative and scope.
• Build the Remote Access Register and identify any remote paths without enforced MFA.
• Implement quick blocks for high-risk bypasses (disable direct internet admin where feasible; require remote access through a single controlled path).
• Establish exception process with expirations and approvals.

Next 60 days (enforcement rollout and hardening)

• Enforce MFA on remaining remote entry points via SSO conditional access, VPN MFA integration, and PAM/jump hosts.
• Bring third-party access under the same MFA gate or controlled exceptions.
• Align change management: MFA policy changes require documented approval and are logged.

By 90 days (evidence, monitoring, and repeatability)

• Stand up monitoring for MFA policy drift and new remote access apps.
• Run an internal control test: attempt remote access on each registered entry point to confirm MFA enforcement.
• Implement recurring evidence capture (policy exports + log samples) and a periodic review of the Remote Access Register.
• If you use Daydream, centralize the register, exceptions, and evidence tasks so the control stays “always audit-ready,” not “audit-week ready.”

Frequently Asked Questions

Does “remote network access” include access to SaaS and cloud consoles?

If the access is remote and can affect your environment or data, include it in scope and enforce MFA at the identity layer. Treat cloud management consoles as high-risk remote entry points and require MFA through SSO or native controls. ¹

Is SMS-based MFA acceptable for Safeguard 6.4?

CIS 6.4 requires MFA but the excerpt provided here does not prescribe specific factor types. Set an internal standard for acceptable factors based on your risk profile, document it, and enforce it consistently across remote access paths. ¹

How do we handle service accounts or non-interactive remote access?

Separate interactive human remote access (must use MFA) from non-interactive system-to-system access, then control the latter with strong credential management and tight network restrictions. If a non-interactive path effectively grants remote administrative control, treat it as a risk exception until redesigned.

What’s the minimum evidence an auditor will accept?

Provide (1) a remote access inventory, (2) the exact policy objects/configs that enforce MFA, and (3) log evidence showing MFA challenges for remote access attempts. Add exceptions with approvals and expirations to show governance. ¹

We have MFA, but users can bypass it on some apps. What’s the cleanest fix?

Put remote access behind a single enforcement layer (SSO conditional access, ZTNA, or VPN MFA) so app-by-app MFA gaps do not matter. Then block legacy authentication paths that bypass modern MFA controls.

How should we treat emergency “break-glass” access?

Allow it only with written criteria, restricted network paths, tight monitoring, and documented approval for each use. Review break-glass events and rotate credentials after use, then retain the event record as part of your operating evidence.

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8