Safeguard 6.3 MFA for externally exposed applications

What Safeguard 6.3 asks for and why MFA on external applications is hard to prove

If your enterprise runs internet-facing applications and a partner, customer or auditor asks how you meet CIS Controls coverage for multi-factor authentication, the answer is this: Safeguard 6.3 requires MFA on every internet-facing application that supports it, whether you built the application or a third party runs it for you. MFA enforced centrally by a directory service or single sign-on provider is accepted as meeting the Safeguard, so you do not need each application to run its own second factor. Password-only access to an exposed application is the exposure this Safeguard addresses. A stolen or guessed password is enough to reach a webmail portal, a file sharing service or a vendor billing tool from anywhere, and the application has no reason to question the login. The Safeguard is part of Implementation Group 1, the essential cyber hygiene baseline CIS sets for every enterprise, so a small organization with a handful of SaaS tools is in scope just as a large one is. The hard part is proving coverage, not turning on MFA. The assessment specification expects you to know which applications are internet-facing, which of them support MFA, and which do not. Start by building a list from your DNS records, load balancers, identity provider application catalog and cloud accounts, then compare it with what users actually sign into. Record every exception with a named owner, the reason the application cannot take a second factor, and a compensating control such as IP restriction or a VPN wrapper. Legacy applications that accept only basic authentication are the usual gap, and an auditor will ask for that exception record. Confirm the exact measures and how coverage is calculated in the CIS assessment specification before you design your evidence.

Which applications, users and third parties fall under 6.3

Safeguard 6.3 applies to any application reachable from the internet, whether the enterprise built it, buys it as SaaS or a third party operates it. The cards below work through the scoping decisions that determine which applications and users must sign in with a second factor, and which data from other Safeguards you need to prove coverage.

Enterprise-built internet-facing applications

Start with applications your teams wrote and publish on public addresses, including customer portals, partner dashboards and internal tools reached through a public load balancer or reverse proxy. Confirm that each one is listed with its public hostname, not only its internal name. Check whether the application accepts logins directly or delegates them to a central identity service, because that choice decides where MFA is enforced.

SaaS and third-party applications

Every SaaS tool that users reach from the internet with enterprise credentials falls under the Safeguard, including tools bought by a business unit outside IT. Compare your identity provider's application list with the software inventory from Safeguard 2.1 to find tools that sign users in with local passwords. Where a vendor supports MFA only on certain plans, record that limit as a finding rather than assuming coverage.

Administrative and management portals

Admin consoles for cloud platforms, hypervisors, firewalls and monitoring tools are often exposed to the internet for convenience and kept outside normal application reviews. Treat each one as in scope, and tie it to the administrative accounts identified through Safeguard 5.1. These portals carry the highest impact if compromised, so a missing second factor here is a priority gap.

Partner, contractor and vendor access

Accounts held by contractors, consultants and partner staff that reach your applications from the internet are in scope even when the enterprise does not own the identity. Decide whether these users sit in your directory with MFA enforced, or in a federated partner directory where you must confirm that the partner enforces an equivalent second factor. Record the decision and the evidence for it.

Applications where MFA is technically unsupported

Some legacy applications, embedded devices or API-only services cannot prompt for a second factor. Document each exception with the vendor's statement, the compensating control in place, such as network restriction or a gateway that enforces MFA in front of the application, and an owner who reviews it. Assessors will ask for this record, so an undocumented exception reads as a missing control.

Inventory data that measures coverage

Coverage cannot be measured without three inventories: the software inventory from Safeguard 2.1, the secure configuration records from Safeguard 4.1, and the account inventory from Safeguard 5.1. Together they show which applications exist, how each one authenticates and which accounts use them. The Users asset class and the Protect security function place this Safeguard among the identity controls that protect user access to these applications.

How an assessor measures MFA coverage under the CAS

Before testing any application, an assessor needs a complete list of internet-facing applications. The Assessment Specification lists Safeguards 2.1 (software inventory), 4.1 (secure configuration process) and 5.1 (account inventory) as prerequisites because they usually produce the data this step needs. The assessor checks whether the external list was built from those inventories or from memory, and whether it includes third-party SaaS applications that staff reach over the internet as well as applications the organization hosts itself.

Source of the population: Confirm the list comes from the software inventory, DNS and public address records, reverse proxy or load balancer configuration, and identity provider application catalogs.
Third-party applications: Check that SaaS tools accessed through the browser are included, not only applications the enterprise builds.
Support status: Record whether each application supports MFA, since the Safeguard applies only where support exists.
Owner assignment: Look for a named owner for every entry so exceptions can be traced later.
Reconciliation: Compare the external list against the account inventory to catch applications with no accounts or accounts with no recorded application.

Ask the organization how the external list is refreshed and when it was last reconciled.

How to implement MFA across external applications in sequence

This sequence moves from knowing which internet-facing applications exist to proving that each one either requires a second factor through a central identity service or has a documented, compensated exception. The output is a coverage record an assessor can test against Safeguard 6.3.

Build the external application inventory
Start by listing every application reachable from the internet, whether it is built in-house, hosted by a third party or delivered as SaaS. Use the software inventory (Safeguard 2.1) and the account inventory (Safeguard 5.1) as the primary sources, then check the list against DNS records, load balancer configurations and firewall rules, since shadow applications often appear only there. The output is a single register with the application name, owner, hostname, and where its login originates. The step is complete when the platform owner confirms that no internet-facing application is missing from the register.
Classify each application by MFA support
For each entry in the register, record whether the application can accept a second factor, either natively or through a federated login. Check the vendor documentation and the application's own settings, and test the login path rather than trusting the marketing description. Mark each application as supported, supported only through federation, or not supported. The output is a classification column in the register with the evidence reference for each decision. Confirm the classification with the application owner before moving on, because a feature that exists in the product may be disabled in the tenant.
Route logins through a central directory or SSO
Point each supported application at one identity provider, such as a self-hosted directory or SSO service, so that users authenticate in one place and the application trusts that provider. Common protocols are OpenID Connect, OAuth 2.0 and SAML 2.0, and many SSO services can broker logins to upstream identity providers. Where an application cannot use federation, place it behind an authenticating proxy or record it as an exception. The output is a configuration record per application showing the protocol, the identity provider and the login URL, plus a test login that succeeds through the central service.
Enforce second factors at the identity provider
Configure the identity provider so that every user who signs in to a routed application must complete a second factor, and so that no application-level bypass remains active. Confirm which factor types the provider accepts, such as TOTP apps, WebAuthn or FIDO2 passkeys, and recovery codes, and decide how enrollment and recovery are controlled. Test the policy with an account that has no second factor enrolled to confirm that access is denied. The output is an exported policy or configuration snapshot and a test record showing the denied and approved sign-ins.
Document exceptions with compensating controls
Where an application is not supported and cannot be federated, record it as a formal exception with the business reason, the named risk owner and an expiry review date set by the organization. Define compensating controls such as network restriction to known sources, a separate hardened access path, enhanced logging, or a plan to replace the application. The output is an exception record for each application, approved by the risk owner. Ask the vendor in writing whether a future release will add MFA support, and keep that answer with the record, since an assessor will look for it.
Verify coverage and retain the evidence
Compare the final register against the external inventory from the first step to confirm that every internet-facing application is either enforced through the central service or covered by an approved exception. Sample several applications and users to repeat the login test, and capture logs showing second-factor challenges for those sessions. Schedule the register to be updated when new applications are published or the identity provider changes. The output is a coverage report that shows the measured share of applications with enforced MFA, the open exceptions and the logs that back each result.

Evidence that shows every external application enforces MFA

An assessor testing Safeguard 6.3 wants to see that every internet-facing application is on a list, that each one is covered by MFA, and that exceptions are approved and reviewed. The cards below cover the artifacts that show each of those points, and the routine that keeps them current between assessments.

External application inventory with MFA status

This is the starting point for the measurement. It lists every internet-facing application, whether built in-house or provided by a third party, with its owner, its login path and whether MFA is enforced through the directory or SSO service. Assessors use it to test coverage, so it should be generated from the systems themselves where possible, not maintained by hand. Check that it matches the software inventory from Safeguard 2.1, since an application missing from one list is usually missing from the other.

Identity provider policy exports

Export the authentication policies, flows or stages from the directory or SSO service that govern each application. These exports show that MFA is a required step in the login path rather than an optional prompt a user can skip. Store dated copies with the change record so an assessor can see the configuration in force on a given date. Confirm that administrators cannot disable the policy without generating an audit event.

MFA enrollment reports

Enrollment reports show which users have registered a second factor such as a TOTP app, WebAuthn or FIDO2 passkey, or a hardware token. They answer whether the policy can actually be satisfied by every account that signs in to external applications. Review accounts with no enrolled factor, including service and shared accounts, and confirm that any such account is covered by a recorded exception rather than silently bypassing the requirement.

Authentication logs with second-factor events

Logs from the identity provider should record each second-factor challenge, its outcome and the application it protected. Sampling these events across a period shows that the control operated, not just that it was configured. Look for failed challenges followed by successful logins from unusual sources, and confirm that logs are retained long enough to cover the assessment period and are protected from edit by application administrators.

Exception register with approvals and review dates

Some applications cannot support MFA, and some legacy integrations need a documented workaround. Each exception should name the application, the reason MFA is unavailable, the compensating control, the approver, and a review date. An exception without an expiry or review date tends to become permanent, which assessors will question. Confirm that the register is reconciled against the external application inventory each cycle so that no application is excluded without a record.

Configuration baselines and change records

Baselines capture the approved state of the identity provider and of each application's login settings, such as session lifetime, allowed authentication methods and redirect URIs. Keep them under version control, with changes linked to tickets that show who approved them. Comparing the current configuration with the baseline on a schedule reveals drift, such as a provider that was reconfigured to allow password-only sign-in. Confirm the review cadence with the auditor before the assessment begins.

What meeting Safeguard 6.3 costs in money and effort

This table lists each cost component of meeting Safeguard 6.3, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to shape the questions you ask in a written quote, since most of the effort sits in application onboarding and exception handling rather than in software licenses.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Identity platform licenses or self-hosted operation	Software vendor for commercial licenses, or your own team and cloud provider for self-hosted open source	Licenses recur; self-hosted operation recurs as infrastructure and staff time	User count, identity provider features needed, hosting model, and whether you run high availability
Engineering time to route applications through SSO	Internal platform or application teams, or an implementation partner under a fixed-scope agreement	One-time per application, plus effort for each new application	Number of internet-facing applications, protocol support (OpenID Connect, SAML 2.0, LDAP), and how much customization each app needs
Legacy and unsupported application handling	Application owners and vendors; may require a compensating control or a replacement project	Often one-time for the workaround, recurring while the exception stays open	Count of applications that cannot enforce MFA, vendor responsiveness, and planned retirement dates
Second-factor device or app rollout	Internal help desk and security team; device or key costs paid by the organization	Rollout is one-time; enrollment support and replacement devices recur	Number of users, choice of factor (authenticator app, WebAuthn passkey, hardware key), and regional or contractor access
Help desk and user support	Internal service desk; sometimes an outsourced support provider	Recurring	Lockouts, lost devices, recovery code handling, and time zones covered
Exception and risk acceptance handling	Security or risk function, with approval from the accountable executive	Recurring while exceptions remain open	Number of exceptions, review frequency, and whether each exception has a compensating control and an expiry
Evidence upkeep	Internal compliance or security staff; an independent assessor reviews the evidence	Recurring, usually tied to each assessment cycle	Quality of the application inventory, whether MFA settings are exported automatically, and how often configurations change
Auditor sampling and testing	Independent auditor or assessor, paid under the engagement terms	Recurring per assessment cycle	Number of applications in scope, sample sizes the assessor selects, and how easily you can produce proof for each sample

Who owns MFA coverage, who prepares it, and who issues the opinion

Your organization owns Safeguard 6.3. CIS measures whether MFA is enforced on every internet-facing application where the application supports it, and that outcome depends on decisions only your organization can make: which applications are in scope, which owners are accountable for each one, and who may approve an exception when a vendor application cannot accept a second factor. Accountability sits with the security function for the policy and with named application owners for each system they run.

Policy and scope: Define which applications count as internet-facing and which MFA methods are acceptable, and approve the written standard.
Application owners: Confirm for each application whether MFA is supported and enabled, and keep that status current.
Exception approvals: Record every application that cannot enforce MFA, with a named approver, a compensating control and a review date.
Operational ownership: Run enrollment, recovery and help desk procedures so that users are not locked out and attackers cannot reset factors easily.
Dependencies: Reconcile results with the software inventory (Safeguard 2.1), the secure configuration process (Safeguard 4.1) and the account inventory (Safeguard 5.1).

Confirm that a named owner signs off on the in-scope application list and every exception before an assessor arrives.

Where MFA coverage usually breaks down and how to close each gap

MFA on externally exposed applications rarely fails in one dramatic way. It usually erodes through apps nobody listed, logins that skip the identity provider, and exceptions that outlive their reason. The cards below cover the gaps assessors most often find and the closing action for each.

Incomplete external application inventory

Safeguard 6.3 applies to every internet-facing application, so the starting point is a complete list of them. Build it from DNS records, load balancer and reverse proxy configuration, cloud load balancers, and the identity provider's own application list, then compare the sets. Any application present in one source and missing from another is a gap to resolve before measuring coverage. Assign each entry an owner and a documented MFA status.

Shadow SaaS outside central sign-in

Teams often sign up for SaaS tools with a work email and a local password, and the tool never reaches the directory. These applications are invisible to the Safeguard 2.1 software inventory and to the identity team until something goes wrong. Check expense records, OAuth consent logs and email sign-in notifications for unmanaged services. Move each one to federated sign-in where the vendor supports it, or record it as an exception with a review date.

Local login bypassing SSO

Many applications keep a built-in login form next to their SSO button, so an attacker or a careless user can sign in with a password alone. The MFA policy in the directory does not apply to that path. Test each external application by opening its login page in a private session and confirming that only federated sign-in is offered. Disable local password login where the product allows it, and restrict any break-glass account to a documented, monitored procedure.

MFA enabled but not enforced for all groups

An MFA policy scoped to a pilot group, a default set to optional, or a conditional rule that exempts legacy clients leaves real users unprotected while the policy looks active. Export the enforcement settings for each application and compare them with the full user population, including contractors, service desk staff and guest accounts. Remove optional modes and exemption groups, or document each remaining exemption with an approver and an expiry date.

Undocumented MFA exceptions

Exceptions tend to appear for a vendor that cannot support a second factor, a batch job, or an executive who objected. Without a record, nobody knows whether the exception is still needed. Keep a register that names the application, the user or service account, the compensating control, the approver and a review date. Where an application does not support MFA, document the reason and confirm the vendor's roadmap in writing, since Safeguard 6.3 applies only where the application supports it.

Authentication logs not retained

Coverage claims need proof, and sign-in logs show whether MFA was challenged for each application over time. If logs roll off after a short default period, an assessor cannot confirm enforcement for the audit window. Confirm that sign-in and MFA events from the identity provider and each application reach a central log store, and set retention to match the period your auditor will sample. Test a retrieval by pulling one application's MFA events for a past date.

Questions buyers ask about Safeguard 6.3 cost, effort and scope

Does a self-hosted open-source identity platform satisfy Safeguard 6.3?

Yes, the platform itself can satisfy the Safeguard when it enforces MFA centrally for every internet-facing application that supports it. CIS accepts MFA enforced by a directory or SSO service as meeting Safeguard 6.3, so the question is less about where the software runs and more about whether every external application sits behind it. Self-hosted options such as Keycloak, authentik, FreeIPA and Zitadel can each act as that central layer. The organization still owns the decision, the configuration and the evidence. Confirm with your assessor which applications and second factors they expect to see, and whether any application that cannot support MFA needs a documented exception.

How long does MFA coverage work take for external applications?

The duration depends on the drivers, not a fixed number. The main factors are how many internet-facing applications exist, how many are already behind a single sign-on provider, how many need protocol changes such as moving from header-based login to OpenID Connect or SAML 2.0, and how many are third-party services whose vendors must be contacted to enable MFA. Discovery of applications is also a prerequisite, since the Safeguard assumes you know what is exposed. Ask any partner for a fixed-scope plan that lists the applications, the integration method for each and the testing window before work starts. DeployOpen agrees scope, deliverables and timelines in writing before work begins.

What does the work need from our own staff?

The work needs named owners on your side, and the time they give is often the largest variable. Expect to involve application owners who can confirm login flows and test changes, a directory or identity administrator who manages user records and groups, a network or platform engineer who controls how applications are published, and someone from security or compliance who approves the MFA policy and exceptions. Business users will also need enrollment support during rollout. Ask for a written list of these roles and time commitments in the quote, so your team can plan around them.

Can our internal team set up MFA without an outside partner?

Many teams can, particularly when they already run a directory service and have engineers familiar with OpenID Connect and SAML. The decision usually turns on three points: whether the team has time to integrate every external application and test it, whether it has the skills to harden the identity platform itself, and whether it can produce the evidence an assessor will sample. An implementation partner can take on integration, hardening, documentation and evidence preparation, while your organization keeps ownership of the controls. Weigh these against your current workload and skills before deciding.

What will an assessor sample to test Safeguard 6.3?

An assessor typically tests the population of internet-facing applications and checks whether MFA is enforced on each one that supports it. The CIS Controls Assessment Specification measures coverage, so expect requests for your application inventory, the list of applications that support MFA, configuration exports from the central identity service, and a sample of login attempts or policy records showing a second factor is required. Assessors may also ask how exceptions are approved and reviewed. Keep the inventory current and export configuration with dates, because a sample is only as good as the records behind it.

Does CIS certify that we meet Safeguard 6.3?

No. CIS publishes the Controls and the Assessment Specification, and it does not issue certificates or attestations for an organization's implementation of Safeguard 6.3. Independent assessors, auditors or certification bodies test your environment and issue whatever report or certificate your framework requires. CIS Controls Accreditation applies to CIS SecureSuite member organizations that provide implementation, auditing or assessment services, which is a different matter from certifying your enterprise. DeployOpen prepares systems, controls and evidence for assessment, and it does not issue audit reports or certifications.

What drives the cost of MFA for external applications?

Cost is driven by the work, not by a standard fee. The main cost components are the time to inventory and classify external applications, the integration effort for each application (native OpenID Connect or SAML support is usually simpler than custom work), licensing or support terms for any commercial component you choose, and the testing and rollout effort across users. Recurring costs include platform operations, upgrades, user enrollment support and periodic access reviews. Ask for a quote that separates one-time integration from recurring operations and lists each external application individually. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen prepares MFA coverage evidence for Safeguard 6.3

DeployOpen plans, implements and hardens self-hosted identity platforms inside the client's own cloud accounts, data centers or air-gapped networks, and prepares the MFA coverage evidence that a Safeguard 6.3 assessment will examine. The work runs under a fixed written scope that names the identity platform, the applications in the external inventory, the second factors to be supported and the deliverables. DeployOpen does not decide whether the enterprise meets Safeguard 6.3, and it does not issue an opinion on it. The organization owns the control, and an independent assessor or certification body reaches any conclusion.

In practice, the preparation starts with a reconciled list of every internet-facing application, including third-party SaaS and vendor portals, matched against the software inventory from Safeguard 2.1 and the account inventory from Safeguard 5.1. Each application is then either routed through the central identity provider or recorded with a documented reason why it cannot support MFA. Platforms such as authentik, Keycloak and FreeIPA each support MFA differently, so the scope should state which second factors (for example TOTP, WebAuthn or FIDO2 passkeys) are enforced and where, and the enforcement settings are captured as configuration exports. Decision for the reader: confirm who approves exceptions for applications that lack MFA support.

The evidence pack typically includes the application inventory with coverage status, exported authentication flow and stage bindings, test logins showing an MFA challenge for each protected application, and records of exceptions with owners and review dates. DeployOpen can prepare and document these artifacts, and can run the coverage checks, but the organization should ask the assessor which format and sampling approach they expect before work begins. Ask for the assessment specification measures in writing so the pack is built to the same test the assessor will apply.

Safeguard 6.3 Require MFA for externally-exposed applications