Safeguard 6.4 Require MFA for remote network access

What Safeguard 6.4 requires for remote network access MFA

If remote staff and vendors reach your network and an assessor or customer contract asks for proof, the answer starts here: Safeguard 6.4 requires multi-factor authentication for all remote network access. That means every route into the enterprise network from outside it, including VPN gateways, remote desktop, remote administration tools and vendor tunnels, should require a second factor beyond the password. The Safeguard is in the Users asset class and the Protect security function, and it sits in all three Implementation Groups, which makes it part of IG1 essential cyber hygiene. Organizations that have not yet enabled MFA on remote entry points should treat this as a baseline rather than an advanced control. The risk is simple. A password-only VPN or remote desktop login can be guessed, phished, reused from a breached website or captured by malware on an employee's laptop. Once an attacker has a valid username and password, the remote gateway treats them as a legitimate user and may place them inside the network with the same reach as the account holder. A second factor, such as a time-based code from an app, a hardware key or a passkey, means a stolen password alone is not enough. Because the same weakness appears at the most exposed entry point, CIS places the Safeguard at the lowest tier so that every enterprise addresses it first. What makes it hard is rarely the MFA product itself. Common obstacles include legacy VPN clients or older remote desktop tools that cannot prompt for a second factor, unmanaged personal devices that cannot hold an authenticator app, service accounts used by vendors that were never meant to be interactive, and standing exceptions granted to executives or contractors. Each exception is a gap an assessor will ask about. Before committing to a plan, list every remote entry point, record which ones support MFA natively and which need a gateway or identity proxy in front of them, and confirm with each vendor how their support model handles the second factor.

Which remote access paths and identities fall under 6.4

Safeguard 6.4 applies to every route a person can take into the enterprise network from outside it. The scoping work is deciding which paths and identities count, then confirming each one is covered by a second factor before the measurement starts. The cards below cover the access paths most organizations run and the identities that use them.

VPN concentrators

VPN concentrators are the most common remote network entry point and usually the first place an assessor looks. Confirm that every VPN login, including client-based tunnels and clientless portals, requires a second factor and that no legacy profile or local account bypasses it. Record each concentrator in the asset inventory from Safeguard 1.1 so the measurement has a complete list to test against.

Remote desktop and bastion hosts

Remote desktop gateways and bastion hosts give a person an interactive session inside the network, so they carry the same risk as a VPN. Check that the gateway itself enforces MFA before the session opens, not only the application published behind it. Include any jump host reachable from the internet or from a partner network.

SSH jump points

SSH jump points let engineers reach production hosts from outside the network, and they are often configured by hand. Check whether MFA is enforced at the jump point, on the bastion's SSH daemon, or through a broker in front of it. Keys without a second factor do not satisfy the Safeguard on their own, so confirm how each jump point authenticates.

Zero trust access gateways

Zero trust access gateways broker connections to internal applications based on identity and device posture. Where they replace a VPN, they become the enforcement point for 6.4, so their policies must require a second factor for each remote session. Document which applications sit behind the gateway and confirm the policy applies to all of them.

Third-party vendor access

Vendors, contractors and managed service providers often hold remote access through accounts the organization does not directly manage. Include these identities in scope and confirm where their second factor is enforced, whether by the organization's identity provider or by the vendor's own system. Treat vendor-held accounts as a scoping decision to record, not an exception to assume away.

Users asset class and Protect function

CIS places Safeguard 6.4 in the Users asset class and the Protect security function, so the evidence centers on user identities and the controls that guard them. The inventory of users and their remote paths is the starting point for the measurement. Confirm with your assessor how they will sample identities across the paths above.

How an assessor measures MFA coverage for remote access

The CIS Assessment Specification for Safeguard 6.4 defines three measures that roll up into one coverage metric. This table shows what each measure tests, the evidence an assessor requests and the findings that most often lower the score, so you can check your own remote access paths before an assessor does.

Measure	What the assessor tests	Evidence requested	Common finding
Remote access paths	Every route into the enterprise network from outside, including VPN, remote desktop gateways, zero trust access proxies and jump hosts	Current list of remote access entry points cross-checked against the asset inventory (Safeguard 1.1) and firewall or gateway configuration	A legacy VPN concentrator or remote desktop gateway that is not on the list and has no MFA
MFA enforcement on each path	Whether a second factor is required at sign-in for each path, and whether it can be bypassed by a fallback login method	Identity provider or gateway configuration exports, authentication policy settings and sampled sign-in logs showing a second factor step	Password-only fallback still enabled for a subset of users or for a legacy client version
Coverage across users and sessions	Whether sampled remote sessions actually passed a second factor, showing the configured control works in practice	Sampled session or authentication logs for a defined period, with user, path and factor type recorded	Logs that show the policy exists but sessions from service or contractor accounts never record a second factor
Exception register	Whether each path or user without MFA has a documented, approved and time-limited exception with a compensating control	Exception register with owner, approval, expiry date and compensating control for each entry	Exceptions that never expire, have no owner or were approved verbally and never recorded
Coverage metric	The three measures combined into one coverage figure for remote network access	Calculation worksheet showing the numerator and denominator the organization used, reviewed with the assessor	A metric that counts only the primary VPN and omits secondary access methods

How to roll out MFA on every remote access path

This sequence takes Safeguard 6.4 from an unknown set of remote entry points to a documented, verified state in which every remote path to the enterprise network requires a second factor. Each step produces an artifact an assessor can inspect.

Inventory every remote entry point
Start from the enterprise asset inventory produced under Safeguard 1.1, which the CIS Controls Assessment Specification treats as a prerequisite for measuring 6.4. List every path that reaches the internal network from outside: VPN concentrators, remote desktop gateways, zero trust access proxies, SSH bastions, cloud management consoles reached over the internet, and vendor connections. The owner is the IT or network team, and the step is done when each entry point has a named owner and a row in a register that records how users authenticate to it.
Confirm the secure configuration baseline
Check that each remote entry point is covered by the secure configuration process described in Safeguard 4.1, since the assessment specification also lists that process as a prerequisite for measuring 6.4. Record the current configuration of each gateway, including which authentication methods it accepts and whether any fallback path exists that skips the identity provider. The output is a configuration record per entry point that shows where local accounts or password-only logins still work.
Enforce MFA at the access gateway or identity provider
Choose one enforcement point per path. Where remote access goes through a central identity provider, such as an authentik flow using the authenticator validation stage, require an enrolled second factor for every user who logs in through it. Where a gateway authenticates locally, configure it to delegate to the identity provider or enable its own second factor. The owner is the identity or platform engineering team. The step is done when a test login without a second factor fails on each path and the enforcement setting is captured in version-controlled configuration.
Cover vendor and administrator paths
Apply the same requirement to third-party and administrative remote access, which are the paths most often left with shared credentials or direct network access. Vendor accounts should be individually named and use MFA, and administrator remote sessions should meet the stronger requirements of Safeguard 6.5. Confirm with each service provider, in writing, how they authenticate to your environment. The output is a list of vendor and admin paths with their second-factor method and a matching entry in the vendor register.
Handle legacy clients and documented exceptions
Identify clients or protocols that cannot present a second factor, such as older mail clients, scripts using static credentials, or appliances without modern authentication. Decide for each one whether to retire it, place it behind a compliant gateway, or record a time-bound exception with an owner and a review date. The consequences of accepting an exception should be stated in the register, not left implicit. The step is complete when every exception has an approver, a compensating control and a recorded review.
Enrol users and manage second factors
Give each user a supported second factor such as a TOTP app, WebAuthn or FIDO2 passkey, or hardware token, and define a recovery procedure that does not quietly disable MFA. Where directory services are used, FreeIPA supports TOTP and HOTP tokens, including hardware tokens, and can proxy OTP checks to an existing RADIUS server during migration. The output is an enrolment report showing the share of remote users with an active second factor and a documented recovery path for lost devices.
Verify coverage per path and retain evidence
Test each entry point from outside the network, with a password-only attempt and a valid credential with a second factor, and record the result. Keep the logs of successful and failed authentications, which feed the Control 8 audit log work, and review them on a set schedule. Compare the results with the CIS Controls Assessment Specification measure for 6.4, which combines three measures into one coverage metric. The output is a dated coverage test record per path that an assessor can re-perform.

How a self-hosted MFA layer enforces second factors at login

A self-hosted MFA layer enforces Safeguard 6.4 by making the second factor a condition of access, not an optional prompt. In a typical flow, the user submits a password or other primary credential to the identity service, which then runs an authenticator validation stage. That stage checks the second factors the user has enrolled, such as a TOTP app, a WebAuthn or FIDO2 passkey, or a static recovery code, and only a passed second factor completes the login and issues a session. The remote access gateway, VPN concentrator or application proxy should accept that completed session as the only path in. Authentik's authenticator validation stage is one example of this pattern, and its documentation lists the factor types it can check, including TOTP apps, WebAuthn, Duo, SMS and email codes, and recovery codes.

FreeIPA handles the same requirement from a directory-centered design. Its OTP support covers HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. During a migration, FreeIPA can proxy OTP checks to an existing RADIUS server, which lets an organization move users in stages while the legacy RADIUS infrastructure still answers. Confirm which token types your remote path can present, since a VPN client, a browser-based portal and a command-line SSH session may each handle a second prompt differently. Test the flow end to end on each remote path, including the fallback when a token is lost, and record which factors each path accepts.

Before relying on a platform for Safeguard 6.4, ask the vendor or your integrator to confirm three things for your specific remote path: whether the gateway enforces the second factor itself or trusts the identity provider's result, whether recovery codes or fallback methods bypass MFA, and whether legacy protocols such as plain RADIUS or password-only SSH can still reach the network. Those answers decide whether the evidence an assessor will request, such as configuration exports and login logs showing MFA challenges, actually covers all remote access. Your organization owns the control; a partner can build and document the configuration, but an independent assessor must test it.

Evidence that shows remote MFA is enforced

An assessor testing Safeguard 6.4 wants proof that every remote path into the network demands a second factor, not just a policy that says so. The cards below cover the configuration exports, log samples, factor records, exceptions and coverage math that together show enforcement, and how to refresh each one between audits.

Identity provider policy exports

Export the authentication flows and policy bindings that apply to VPN, remote desktop and zero-trust access, and keep the dated exports with change records. An assessor compares these exports with the remote access list from Safeguard 1.1 and the configuration baseline from Safeguard 4.1, so every remote entry point should appear. Re-export after each change to a flow, and check that no flow allows a bypass for a group or network range.

Gateway configuration showing MFA required

Keep the configuration of each remote access gateway, such as VPN concentrators, reverse proxies and firewall remote access rules, showing that a second factor is required before a session opens. Store the configuration as versioned text so that a diff shows any removed MFA step. Record which gateway enforces the check and which identity source it calls, because an assessor will ask where the second factor is verified.

Authentication logs sampled per remote path

Pull authentication logs for each remote path and sample successful sessions to confirm that a second factor was presented. Sample by path rather than by user, so a VPN with strong logs cannot hide a web gateway with none. Keep the sampling method, the date range and the reviewer's notes, and flag any successful remote login that lacks a second-factor event for investigation.

Enrolled factor reports

Report which users have enrolled a second factor, which factor types they use and when each was enrolled or last used. Include the factor types supported by the identity platform, such as TOTP apps, WebAuthn passkeys, hardware tokens and recovery codes, and check that recovery codes are stored and issued under the same control as primary factors. Review the report monthly for accounts with no enrolled factor, because those accounts cannot pass the check.

Exception register with approvals and expiry

List every remote access path or account that does not require MFA, with the business reason, the named approver, the compensating control and an expiry date. Assessors look for exceptions that never expire, so set a review date on each entry and close it when the path is retired or enforced. Treat a missing approval as a finding, not a note, and reconcile the register against gateway exports at each review.

Coverage calculation

Calculate coverage as the share of remote access paths and accounts that require MFA, drawn from the inventory and the exception register. The CIS Controls Assessment Specification defines three measures for Safeguard 6.4 that combine into one coverage metric, so record the numerator, denominator and source for each measure. Recalculate on a set schedule and after any new remote service, and confirm the result with the independent assessor's sampling plan before the audit.

What meeting Safeguard 6.4 costs in money and effort

This table breaks down the money and effort behind meeting Safeguard 6.4 for remote network access, showing who is paid for each component, whether it is one-time or recurring, and what drives it up or down. Use it to shape a written scope and to check that a quote covers every component before you sign.

Cost component	Who is paid or who bears it	One-time or recurring	What drives the cost
MFA licenses or self-hosted tooling	Vendor for commercial MFA or SSO; no license fee for self-hosted open source, though staff time remains	Commercial licenses usually recur; open-source software has no license fee	Number of users, remote entry points and whether an existing identity provider is already licensed
Engineering time to integrate remote paths	Internal staff or an implementation partner under a fixed-scope agreement	One-time, with later changes when new VPNs, gateways or applications are added	Count of remote access paths (VPN, gateways, bastions, cloud consoles) and how many use a shared identity source
Hardware keys and software tokens	Organization buys hardware keys; users enroll software authenticators on their own devices	Hardware keys are a one-time purchase per user, with replacements for loss; software tokens cost little to issue	Share of users who need hardware keys, replacement rate and whether a mobile device policy already exists
Recovery and enrollment support	Internal help desk or service desk, sometimes a managed provider	Recurring, driven by resets and lost devices	Quality of self-service enrollment, documented recovery procedures and user training
Evidence upkeep	Internal compliance or security staff	Recurring, usually tied to each review cycle	Whether MFA settings, enrollment logs and remote access logs are exported automatically or collected by hand
Independent testing or review	External tester or assessor, engaged by the organization	Periodic, usually per assessment cycle	Scope of remote paths tested and whether the test covers bypass of second factors
Auditor sampling	Independent auditor or assessor, paid by the organization	Recurring per assessment, as sampled users and remote sessions are checked	Number of remote paths, population size and how readily evidence can be produced on request
Quote request checklist	Ask each provider to itemize the components above	Confirm before signing	Ask for licensing terms, integration effort by path, token policy, evidence export method and retest scope in writing

Who owns remote MFA: your team, a partner and the auditor

Your organization owns Safeguard 6.4 because the control decides who may reach the enterprise network from outside and how each person proves identity. The CIS Controls are free to use for your own improvement and do not replace any regulatory scheme, so accountability for the control stays with your leadership and cannot be handed to a vendor or partner.

Scope of remote access: Decide which remote paths count as enterprise access, such as VPN, zero trust gateways, remote desktop, SSH jump hosts and vendor connections, and which user groups must enroll.
Accepted second factors: Set which methods are permitted, such as authenticator apps, hardware keys and passkeys, and decide whether SMS or email codes may serve as a fallback.
Exceptions and recovery: Approve every exemption in writing, define how lost devices and recovery codes are handled, and record who may grant an emergency bypass.
Policy and evidence ownership: Keep the access control policy current, name the person who reviews enrollment coverage and failed-login reports, and set the review cadence.

Before any partner starts work, confirm that each of these decisions has a named owner and a named approver in your organization.

Where remote MFA programs usually fall short

Most remote MFA programs fail at the edges rather than at the main login page. The gaps below cover bypass paths, shared credentials, legacy protocols, informal exceptions and missing measurement, which together decide whether Safeguard 6.4 can be shown as met.

VPN paths that bypass the IdP

A remote access gateway may authenticate users against a local account store or a legacy RADIUS server while the main identity provider enforces MFA. Users then reach the network without a second factor even though the SSO portal shows it. Inventory every remote entry point, including site-to-site and vendor tunnels, and confirm each one validates a second factor through the same identity source.

Vendor accounts with shared credentials

Third-party support staff often sign in with a shared account that no one can tie to a named individual, and that account frequently sits outside MFA enrollment. The shared password may also be known long after the engagement ends. Check whether each remote vendor has a named, enrolled identity, and whether shared logins were retired or wrapped behind a per-person authenticated broker.

Legacy protocols still accepting passwords

Older remote access methods such as some mail clients, file transfer services or directory binds can accept a password alone and skip the MFA step entirely. Attackers look for these fallbacks because they are easier to attack than the primary login. Test each protocol that reaches the network from outside, and either disable password-only authentication or confirm it is restricted to approved internal sources.

Undocumented exceptions

Exceptions granted for a service account, an executive device or a vendor during an outage often remain in place for years without an owner or expiry date. Each exception weakens the Safeguard, and an assessor will ask for the approval record. Keep a register of every exemption with the business reason, compensating control, approver and review date, and remove exemptions that no longer have a reason.

No coverage metric

Many programs enable MFA on a gateway and never measure what share of remote sessions actually required a second factor. Without a figure, the organization cannot show that Safeguard 6.4 is implemented across the enterprise. Build a coverage report from authentication logs that counts remote sessions with and without MFA, and review the gap each period.

Questions buyers ask about Safeguard 6.4 cost, effort and scope

How much effort does it take to require MFA for remote network access?

Effort depends mainly on how many remote access paths exist and how many identity sources feed them. A single VPN gateway, one directory and one user population is a contained job. Each additional entry point, such as a separate VPN concentrator, a jump host, a remote desktop gateway or a vendor access portal, adds configuration, testing and user enrollment work. Plan for effort in four areas: inventorying every remote path, enrolling second factors for each user, configuring the enforcement point so MFA cannot be skipped, and proving coverage with logs. Ask any partner to break the estimate down by access path rather than giving one total.

Can our internal team implement MFA for remote access without outside help?

Yes, many teams do this in-house, especially when they already run a directory and a VPN or access gateway. The work that most often stalls internal projects is the inventory and the coverage check, because remote paths tend to be spread across network, application and vendor teams. Outside help is most useful for the parts that need concentrated time: mapping every remote path, building a self-hosted identity service with a second factor, testing failover and documenting the result as evidence. DeployOpen implements and documents these systems inside the client's own infrastructure, but the organization keeps ownership of its controls and decides whether to bring in a partner.

How long does a fixed-scope MFA engagement take to agree on?

DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements are fixed-scope. No duration is stated here because it depends on the access paths, identity sources and approval steps in your environment. To reach a written timeline, prepare a list of remote entry points, the directories they authenticate against, the user groups involved and any change windows. Ask for the timeline to be tied to named milestones, such as inventory complete, enrollment complete and coverage evidence accepted, so progress can be checked against the written scope.

What does our organization need to provide before MFA work starts?

Several inputs shape both the quote and the schedule:

A current list of remote access methods, including VPNs, remote desktop, jump hosts and vendor access
Access to the existing directory or identity source and the groups that will be enrolled
Records of the enterprise asset inventory and secure configuration process, since CIS lists Safeguards 1.1 and 4.1 as prerequisites for measuring Safeguard 6.4
Decisions on acceptable second factors, recovery methods for lost devices and help desk procedures
A named owner who can approve changes and accept the coverage evidence

Missing inputs usually cost time later, so confirm them before the scope is signed.

Do self-hosted open-source tools remove the license cost of MFA?

They remove per-user licensing fees for the software itself, but they do not remove cost. Authentik is published under the MIT license, FreeIPA under GPL-3.0-or-later, and OPNsense under BSD-2-Clause, so the software is free to deploy. Remaining costs include the infrastructure that hosts the services, the engineering time to configure and integrate them, testing, backup and upgrade work, and staff who operate the platform after handover. Ask any quote to separate one-time implementation from recurring operations, and to show the infrastructure assumptions behind each figure.

What drives the cost of MFA for remote access up or down?

The main drivers are the number of remote access paths, the number of users and devices to enroll, and whether an existing directory or RADIUS service can be reused. Costs rise when remote access relies on legacy appliances that cannot enforce a second factor, when several identity sources must be consolidated, or when hardware tokens must be issued and replaced. Costs fall when one identity service fronts all remote paths and when enrollment is self-service with clear recovery steps. Ask for the quote to show how each driver was priced, so you can see which change would move the total.

Who pays for the MFA assessment, and does DeployOpen issue the certificate?

The organization pays for its own implementation and for any independent assessment it chooses to commission. DeployOpen prepares systems, controls and evidence, but it does not issue audit reports, attestations or certifications. CIS Controls content is free for organizations to use to improve their own cybersecurity, and CIS does not certify implementations through this Safeguard. Where a customer, contract or regulator asks for independent evidence, an auditor or certification body performs that review and issues the result. Confirm with your assessor which evidence they will accept before implementation begins.

How DeployOpen scopes and prepares remote MFA evidence

DeployOpen approaches Safeguard 6.4 as a scoped piece of work inside your own infrastructure. We prepare the remote access systems, the MFA configuration and the evidence an assessor will ask for, while your organization keeps ownership of the control and an independent auditor or assessor issues any report.

How we scope

Agree in writing which remote access paths to the enterprise network fall in scope, such as VPN, remote desktop gateways and browser-based access.
Confirm the enterprise asset inventory (Safeguard 1.1) and secure configuration process (Safeguard 4.1) that the assessment specification expects as inputs.
Document the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.

How we build

Configure the second-factor checks for remote sessions on the identity platform, such as authentik, or on FreeIPA where OTP and hardware tokens are in use.
Set firewall rules and aliases on OPNsense so remote traffic reaches the enterprise network only through the MFA-protected path, with rule matches logged.
Test each remote access path with and without a second factor to confirm coverage across the measured population for Safeguard 6.4.

How we hand over

Deliver configuration records and a coverage report showing which remote access paths enforce MFA, mapped to the three CAS measures.
Provide runbooks for enrolling tokens, handling lost devices and recovering access, so your team can operate the control after handover.
Package the evidence an independent assessor will request, such as configuration exports, login logs and test results, and confirm with the assessor which formats they accept.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Review remote access changes, new VPN or gateway endpoints and MFA policy updates as part of the retained service, as agreed in writing.
Confirm with your auditor or assessor which evidence period and sampling they expect, since DeployOpen does not issue audit reports or certifications.