Safeguard 6.3: Require MFA for Externally-Exposed Applications

Safeguard 6.3 requires you to enforce multi-factor authentication (MFA) on every externally-exposed application so an attacker can’t gain access with a stolen password alone. To operationalize it fast, inventory internet-facing apps, put them behind a centralized identity provider or access proxy, enforce phishing-resistant MFA where possible, and retain recurring evidence that MFA is technically enforced and exceptions are governed. (CIS Controls v8; CIS Controls Navigator v8)

Key takeaways:

• Scope is “externally-exposed applications,” not just VPN or admin consoles; include SaaS, partner portals, and public APIs with interactive auth. (CIS Controls v8; CIS Controls Navigator v8)
• Audits fail on evidence: you must prove enforcement, coverage, and exception handling over time. (CIS Controls v8; CIS Controls Navigator v8)
• Centralize control points (IdP/SSO/access proxy/WAF + auth gateway) to reduce drift and make evidence repeatable. (CIS Controls v8; CIS Controls Navigator v8)

“Externally-exposed applications” are where credential theft turns into direct access: the login prompt is reachable from the internet, attackers can automate attempts, and users reuse passwords across services. Safeguard 6.3 focuses on a single outcome: require MFA wherever an application is exposed externally. (CIS Controls v8; CIS Controls Navigator v8)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a coverage and proof problem. Coverage: do you know every internet-facing app and authentication entry point (including SaaS and third-party hosted portals used by your workforce)? Proof: can you show, on demand, that MFA is enforced today, and that onboarding new apps routes through the same MFA gate? (CIS Controls v8; CIS Controls Navigator v8)

This page gives requirement-level implementation guidance: who is in scope, what “require MFA” means in practice, the minimum control mechanics you should standardize, and the evidence package that avoids last-minute scramble during an assessment. It also includes exam-style questions, common operational hangups (service accounts, APIs, legacy auth, and “temporary exceptions”), and a practical execution plan you can assign to Identity, Security Engineering, Application Owners, and IT Operations.

Requirement: safeguard 6.3: require mfa for externally-exposed applications requirement

Plain-English interpretation

You must ensure that any application accessible from the internet requires users to authenticate with at least two factors, not just a password, before granting access. “Require” means the application (or a centralized control in front of it) technically enforces MFA; user training or “recommended MFA” does not meet the expectation. (CIS Controls v8; CIS Controls Navigator v8)

The operational target is simple: no external login page, remote access flow, or externally reachable session token issuance should succeed without MFA for the relevant human users.

Who it applies to (entity and operational context)

Entity scope: Any enterprise or technology organization adopting CIS Controls v8, especially those with workforce access to SaaS, customer-facing portals, partner extranets, or remote administration surfaces. (CIS Controls v8; CIS Controls Navigator v8)

Operational scope: Any system that meets both conditions below:

• Externally exposed: reachable from the public internet or exposed to external networks (customers, partners, contractors, remote employees).
• Application access: an authentication flow exists for humans (employees, admins, customers, contractors) or privileged functions are exposed externally.

Common in-scope examples (use as your inventory checklist):

• SaaS apps used by staff (SSO-enabled or direct login)
• Customer portals and partner portals
• Remote access portals (VPN, ZTNA, VDI gateways)
• Cloud consoles and admin UIs
• Code repos, CI/CD web UIs, ticketing systems, knowledge bases exposed externally
• Externally accessible APIs that authenticate end users interactively (for example, OAuth authorization endpoints)

Common “gray areas” to decide explicitly in policy:

• Public APIs that use only machine-to-machine keys (not MFA-eligible, but still need strong auth controls; document how you handle these)
• “Marketing sites” that still have an admin panel reachable externally
• Third-party hosted portals branded for you (still your risk; you need contractual and assurance coverage)

Regulatory text

Source requirement excerpt: “CIS Controls v8 safeguard 6.3 implementation expectation (Require MFA for Externally-Exposed Applications).” (CIS Controls v8; CIS Controls Navigator v8)

Operator meaning: you need a control design where MFA is mandatory for access to externally-exposed applications, and a control operation where you can show it stays that way as apps change, new apps appear, and exceptions are requested. The most assessable implementation maps Safeguard 6.3 to documented control operation and recurring evidence capture. (CIS Controls v8; CIS Controls Navigator v8)

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

Step 1 — Define “externally-exposed application” for your environment

Write a one-page scope definition your app owners can apply consistently:

• Include: any app with an internet-reachable login or session issuance flow.
• Include: third-party hosted apps accessed directly (not only via SSO) if users can log in from the internet.
• Include: admin panels and support tools exposed externally. Then publish it as a control standard referenced by your access control policy. (CIS Controls v8; CIS Controls Navigator v8)

Step 2 — Build and maintain an inventory of externally exposed apps

You cannot enforce MFA on what you cannot name. Create a living register with:

• Application name and owner
• Hosting model (internal, cloud, SaaS, third party)
• External exposure method (public DNS, reverse proxy, SaaS direct)
• Authentication method (SSO/SAML/OIDC, local auth, basic auth, API key)
• MFA enforcement point (IdP policy, app-native MFA, access proxy policy)

Practical sources to populate the list:

• DNS and certificate inventories
• Reverse proxy / WAF route tables
• SSO/IdP app catalog exports
• Cloud load balancer listeners and public IP inventories
• Procurement list of SaaS and third-party services

Step 3 — Standardize your MFA enforcement pattern

Pick one primary enforcement approach and make exceptions rare.

Preferred patterns (in order of auditability and control):

1. Centralized SSO with conditional access MFA (IdP enforces MFA before issuing tokens)
2. Access proxy / ZTNA in front of the app (proxy enforces MFA and device/user policy)
3. Application-native MFA (acceptable, but harder to prove consistently across apps)

Where feasible, set stronger requirements for privileged roles and admin surfaces (for example, enforce phishing-resistant factors). Document your factor standards and align them to your risk tolerance without over-specifying in ways you can’t meet consistently. (CIS Controls v8; CIS Controls Navigator v8)

Step 4 — Configure technical enforcement (make “bypass” hard)

For each in-scope application:

• Route authentication through the chosen enforcement point (IdP/proxy) where possible.
• Disable legacy auth methods that bypass MFA (for example, basic auth to webmail equivalents, legacy protocols, or local accounts) where they exist.
• Require MFA at login and for high-risk events (new device, new location, step-up for privileged actions) if your tooling supports it.
• Block direct-to-app authentication endpoints if you intend SSO-only (common gap: app still allows local logins).

Step 5 — Handle non-human access explicitly (APIs, service accounts, automation)

MFA is for humans. Auditors still expect you to show you didn’t ignore machine access:

• Identify service accounts tied to externally exposed applications.
• Replace shared credentials with token-based access, workload identity, or scoped keys where possible.
• Document compensating controls for non-interactive auth paths (key rotation, IP allowlisting, mTLS, strict scopes). Tie this back to the same inventory so assessors see you made a deliberate decision. (CIS Controls v8; CIS Controls Navigator v8)

Step 6 — Create a governed exception process (and keep it small)

You will get legacy apps and edge cases. Put an exception process in writing:

• What qualifies (technical impossibility, vendor limitation, short-lived migration window)
• Required compensating controls (access proxy, IP restriction, read-only mode, extra monitoring)
• Approval authority (Security + app owner; add Risk acceptance sign-off for material exposure)
• Expiration and revalidation requirements (set a standard cadence you can consistently follow)

Step 7 — Operationalize recurring evidence capture (what most teams miss)

Assessments do not accept “we have MFA” without proof. Build a recurring evidence job:

• Export IdP conditional access policies showing MFA requirements for relevant app groups.
• Export app list and assignments from the IdP.
• For apps with native MFA, capture configuration screenshots or admin exports showing MFA enforced and any bypass disabled.
• Sample test results: a controlled test account attempt that shows password-only login fails for an external app.
• Exception register and approvals.

Daydream fits naturally here as the system to map Safeguard 6.3 to a documented control operation and to schedule recurring evidence pulls so you can answer “prove it” quickly with consistent artifacts. (CIS Controls v8; CIS Controls Navigator v8)

Required evidence and artifacts to retain

Keep evidence in a single folder or GRC control record and refresh it on a predictable cadence.

Minimum evidence pack (practical and defensible):

• Externally-exposed application inventory with owners and MFA enforcement method
• IdP/SSO conditional access policy export showing MFA required for external access and for specific app groups
• IdP application catalog export tying apps to MFA policies (assignment lists)
• Configuration evidence for non-SSO apps (screenshots or exported settings demonstrating MFA enforced)
• Exception register with business justification, compensating controls, approval, and expiry
• Change management linkage: tickets/PRs showing new external apps must integrate with SSO/MFA before launch

Common exam/audit questions and hangups

Use these as your readiness checklist:

• “Show me your list of externally exposed applications and how you know it’s complete.”
• “Demonstrate MFA enforcement for three applications: one SaaS, one internally hosted, one customer-facing.”
• “Can a user bypass SSO and log in locally?”
• “How do you handle service accounts and API access tied to external apps?”
• “Who approves MFA exceptions, and how do you ensure they expire?”
• “What evidence shows the control operates over time, not just on audit day?” (CIS Controls v8; CIS Controls Navigator v8)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Counting VPN MFA as “done”	External apps may be reachable without VPN, or SaaS logins bypass VPN	Inventory external apps and enforce MFA per-app or via IdP/proxy
“MFA available” but not enforced	Users can opt out or use weaker flows	Require MFA via policy and test password-only failure paths
SSO enabled but local logins still active	Attackers target the bypass path	Disable local auth, restrict it to break-glass, and monitor
No evidence strategy	You scramble to prove configuration and coverage	Automate exports and keep a recurring evidence pack (CIS Controls v8; CIS Controls Navigator v8)
Exceptions never close	Temporary becomes permanent exposure	Add expirations and re-approval, and track to remediation tickets

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this safeguard, so you should treat this as a framework-driven expectation rather than a cited enforcement trend for this page. The risk case is still straightforward: externally exposed login surfaces are a primary path for credential-stuffing, phishing-derived passwords, and account takeover. MFA materially reduces the chance that password compromise becomes unauthorized access, and it limits blast radius during credential leaks.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and quick wins)

• Publish your definition and scope standard for “externally exposed application.”
• Stand up the external app inventory with owners and auth methods.
• Identify the top-risk external apps (admin consoles, customer portals, payroll/finance, code repos) and confirm MFA is enforced, not optional.
• Draft the MFA exception process and register template.

Days 31–60 (centralize enforcement and close bypasses)

• Move priority apps to centralized SSO/conditional access or an access proxy.
• Disable known bypass paths (local logins, legacy protocols) where feasible.
• Formalize service account handling for external apps (document the non-human access pattern and compensating controls).
• Start recurring evidence capture (policy exports, app lists, samples, exception register).

Days 61–90 (operationalize and make it repeatable)

• Expand coverage to remaining externally exposed apps, including shadow SaaS discovered through procurement and SSO catalogs.
• Tie “new external app” onboarding to an MFA gate in architecture review and change management.
• Run an internal control test: pick a sample of external apps and confirm password-only login fails; document results and remediation.
• Implement ongoing reporting: coverage, open exceptions, upcoming expirations, and apps not behind the standard enforcement pattern.

Frequently Asked Questions

Does Safeguard 6.3 apply to SaaS applications we don’t host?

Yes if they are externally accessible and used for access to your data or workflows. Treat SaaS MFA enforcement as part of your control design, either through SSO conditional access or verified app-native MFA. (CIS Controls v8; CIS Controls Navigator v8)

What counts as “externally exposed” if an app is behind a reverse proxy?

If the proxy is reachable from the internet and forwards traffic to an app with authentication, the app is externally exposed. Enforce MFA at the proxy or at the identity layer used by the app.

Are APIs included, and how do we “MFA an API”?

Human interactive flows that issue tokens (for example, authorization endpoints) should require MFA for the user session. For non-interactive machine-to-machine APIs, document why MFA is not applicable and implement strong compensating controls tied to service identity.

Is application-native MFA acceptable, or must we use SSO?

The requirement is “require MFA,” not “use SSO.” SSO simplifies consistent enforcement and evidence, but app-native MFA can meet the expectation if it is mandatory and you can prove it. (CIS Controls v8; CIS Controls Navigator v8)

How do we handle “break-glass” access?

Keep break-glass accounts rare, monitored, and tightly controlled. Document the procedure, store credentials securely, and review access events; do not allow break-glass paths to become normal user access.

What evidence is most persuasive to an assessor?

Exports from your IdP showing MFA-required conditional access tied to specific applications, plus an app inventory mapping each external app to its enforcement point and an exception register with approvals and expirations. (CIS Controls v8; CIS Controls Navigator v8)