What CIS Controls 6.3 to 6.5 ask of your MFA design, and the short answer
If your baseline is CIS Controls v8.1 and you need to show MFA on internet-facing applications, remote network access and administrative accounts, self-hosted MFA enforced centrally by a directory or SSO provider can meet all three Safeguards. CIS accepts central enforcement by a directory service or SSO provider as satisfying Safeguard 6.3, so the design question is less about which second factor you buy and more about whether every relevant login path passes through one enforcement point you control. Safeguard 6.4 covers remote network access, and Safeguard 6.5 covers accounts with administrative access to enterprise assets, including assets a service provider manages. Each one needs its own coverage check, because a VPN or an admin console that bypasses the central point will fail the test even if the rest of the estate is covered.
CIS places all three Safeguards in the Users asset class and the Protect security function, and assigns them to Implementation Groups 1, 2 and 3. That makes them part of IG1, which CIS describes as essential cyber hygiene and a minimum standard for every enterprise. Treat them as a first-wave commitment, not a later maturity goal. Before you design anything, list every internet-facing application, every remote access path and every administrative account, and confirm which of them your directory or SSO provider can actually enforce MFA on. Anything that cannot be enforced centrally needs a documented exception and a compensating plan.
Keep the scope of this claim clear. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, and an assessor will still ask whether MFA meets the specific rules that apply to you. Evidence that a central policy is enforced for each of the three Safeguards is a strong start, but it does not by itself satisfy a sector rule. Confirm with your assessor or regulator which framework applies, and which configuration and logs they expect you to keep, before you treat this page's mapping as complete.
How each Safeguard maps to what the MFA platform must do
This table compares what each of Safeguards 6.3, 6.4 and 6.5 asks the MFA platform to do, and how privacyIDEA or Keycloak can carry that job. Read each row as a requirement, then check the configuration column against your own applications and access paths. The main takeaway is that CIS accepts central enforcement through a directory or SSO provider, so the design should route every in-scope login through one MFA path wherever the application allows it.
| Safeguard | What the MFA function must do | How to configure it with privacyIDEA or Keycloak |
|---|---|---|
| 6.3 Internet-facing applications | Require MFA on every internet-facing application, including third-party SaaS, where the application supports it. Central enforcement through a directory or SSO provider meets the Safeguard. | Put apps behind Keycloak as the OIDC or SAML broker, with privacyIDEA as the second factor via its Keycloak plugin. Use the privacyIDEA REST API for custom apps. Apps without MFA support need a reverse proxy or an SSO gateway in front of them. |
| 6.4 Remote network access | Require MFA for every remote network session, including VPN, remote desktop gateways and any remote admin tunnel. | Configure privacyIDEA as a RADIUS server for OpenVPN, Fortinet and Palo Alto. Use challenge-response or push so remote staff get a prompt. Log every accept and reject for audit review. |
| 6.5 Administrative access | Require MFA on every account with administrative rights to enterprise assets, including accounts that a service provider manages. | Enable the privacyIDEA PAM module on Linux admin logins and sudo, and the credential provider on Windows admin logons. Enroll admin accounts first and separate them from daily user identities. |
| Applications without MFA support | Identify each application that cannot accept a second factor and record it as a documented exception with a compensating control. | Front the app with Keycloak or a reverse proxy that enforces the SSO login. Where neither works, restrict network reach and confirm with the vendor whether a supported MFA option exists. |
| Evidence an assessor expects | Show the enforcement point, the list of in-scope applications and access paths, and logs of MFA events. | Export the Keycloak client list and authentication flow settings, privacyIDEA policy and token records, and RADIUS or PAM logs for a sample period. |
| Service and automation accounts | Confirm which non-human accounts hold admin access and how each is covered, since interactive MFA cannot run inside scripts. | Use service accounts with restricted scope and key-based access, and record them as exceptions under Safeguard 6.5 with an owner and review date. |
Which self-hosted platforms fit each Safeguard
Safeguards 6.3, 6.4 and 6.5 cover three different entry points: web applications, remote network access and administrative accounts. No single platform covers all three equally well, so the choice usually follows the entry point you need to close first. The cards below set out the fit and limit of each option and what to confirm before you commit.
privacyIDEA for network and host logins
privacyIDEA is the most direct fit for Safeguard 6.4 and for host logins under Safeguard 6.5. Its RADIUS support covers VPNs such as OpenVPN, Fortinet and Palo Alto, its PAM module covers Linux and SSH, and its credential provider covers Windows logon. The limit is that each of these integrations is a separate configuration on each system, so confirm with the vendor and your own test environment that your specific VPN firmware, PAM stack and Windows versions are supported before you plan rollout. Also confirm how it handles offline Windows logons for laptops.
Keycloak for web app MFA
Keycloak fits Safeguard 6.3 because it can sit in front of internet-facing applications as the OpenID Connect or SAML 2.0 identity provider, enforcing MFA centrally before the application sees the login. CIS accepts MFA enforced centrally by an SSO provider as meeting the Safeguard, so the work is mostly client registration and policy. Keycloak supports WebAuthn for phishing-resistant second factors. The limit is that applications that cannot use OIDC or SAML still need a proxy or a direct MFA integration, and you should confirm which of your applications can be federated before scoping.
FreeIPA for directory-backed OTP
FreeIPA suits organizations that already keep users and groups in a Linux-centric directory and want OTP enforced at the directory level. Its OTP support can protect Linux and SSH logins through central policy rather than per-server setup, which matches the administrative access requirement in Safeguard 6.5. The limit is narrower token and integration coverage than privacyIDEA, particularly for Windows and third-party VPNs. Confirm with the vendor which token types, RADIUS or proxy options and client integrations your environment needs, and test how service accounts that cannot answer an OTP prompt will be handled.
ZITADEL for passkeys and tenants
ZITADEL is worth evaluating when passkeys (FIDO2 and WebAuthn) are the target second factor and when one deployment must serve several tenants or customer groups. Its README lists SSO, MFA, passkeys, OpenID Connect certification, SAML 2.0 and SCIM, which covers the web application side of Safeguard 6.3. The limit is that ZITADEL is an identity platform rather than a RADIUS or PAM MFA server, so VPN and host logins would need a separate component. Confirm its AGPL-3.0 licensing terms with your legal team and check how it integrates with your existing directory.
The order to roll out MFA across 6.3, 6.4 and 6.5
Start with administrative access (Safeguard 6.5), then remote network access (6.4), then internet-facing applications (6.3). Administrative accounts carry the most exposure because a compromised domain admin or root login can disable every other control, and remote network access is the path most attackers test first from outside. Internet-facing applications come third in this order not because they matter less, but because most of them can be placed behind the SSO provider in one change, so the coverage arrives in a single cutover once the identity layer is ready. In practice, that means enforcing MFA on the privacyIDEA or Keycloak realm that administrators use for Windows, Linux and SSH access first, then the VPN RADIUS path, then the SSO-fronted applications. Confirm with each application owner whether it supports a second factor at all, since 6.3 applies only where the application supports it.
Service accounts, scheduled jobs and CI pipelines cannot answer a push prompt or type a TOTP code, so they need a separate, documented path rather than an exemption buried in policy. Inventory them first, then sort each one into three groups: human accounts that were given a shared login (move these to named accounts), non-interactive accounts that can authenticate with a certificate or SSH key, and accounts that run on a vendor's managed service where the vendor controls the login. For the second group, the control objective is to bind the credential to a host or workload and to restrict where it can be used, which should be recorded in the asset inventory as a deliberate exception with an owner and a review date. Do not treat these accounts as a reason to delay the administrative rollout. Staging enrollment by group works best with a pilot of named administrators, then a wider wave for remote staff, with a help desk plan that covers lost tokens before the first enforcement date. Ask your partner to show how the enrollment wave and the exception register will appear in evidence for CIS Safeguard 6.5.
How the rollout sequence runs in practice
The sequence starts with an inventory of exposed entry points, applies one central MFA policy, proves it on administrator accounts, then widens coverage and removes single-factor fallbacks. Each stage ends with a record that an assessor can check against Safeguards 6.3, 6.4 and 6.5.
Inventory internet-facing apps, admin accounts and remote paths
The security team and the owners of each system list every internet-facing application, every remote network access path (VPN gateways, remote desktop gateways, SSH bastions) and every account that holds administrative rights to enterprise assets, including accounts that a service provider manages. For each entry, record whether the product supports MFA, which identity source it uses and who owns it. The inventory is complete when every entry has an owner and a support answer, and the list is reviewed against the asset inventory and the directory so nothing is left out.
Set one central MFA policy in the directory or SSO
Choose the place where MFA is enforced once for many applications, such as the directory or the single sign-on provider, and define the token types, enrollment rules and exceptions there. Where a product can only trust a RADIUS, PAM or SAML assertion, configure that integration to pass the MFA result from the central service. CIS accepts MFA enforced centrally by a directory service or SSO provider for Safeguard 6.3, so this step produces one policy record that a reviewer can read instead of many per-system settings. Confirm with the vendor how the chosen product reports successful and failed second factors.
Pilot the policy with administrator accounts first
Enroll administrator accounts first, because they carry the highest impact if compromised and they cover Safeguard 6.5 directly. Test enrollment, normal login, failed attempts, and the recovery path on a small set of systems, such as one Linux bastion and one Windows admin host. Record the test results and any service accounts that cannot take an interactive second factor, and decide in writing how each of those is handled. The pilot is done when administrator logins to the pilot systems require a second factor, failures are logged, and the recovery procedure has been run once.
Expand coverage to VPN and web applications
Apply the same policy to remote network access and to the internet-facing applications from the inventory, in batches sized so that the help desk can handle enrollment questions. Start with the VPN or remote access gateway (Safeguard 6.4), then web applications that already sit behind the single sign-on provider, then applications that need their own integration. For each batch, confirm that a login from outside the network triggers the second factor and that the application cannot be reached through an alternate path that skips it. The batch is complete when the owner signs off against the inventory entry.
Retire single-factor fallbacks and capture evidence
Disable password-only logins, legacy protocols and local accounts that bypass the central policy, and document each exception with an owner and a review date set by your own policy. Then assemble the evidence that an assessor will ask for: the inventory with status for each entry, the policy configuration export, enrollment and exception records, and sample authentication logs that show the second factor being checked. Ask the implementation partner, and your auditor, which format they expect. The step is complete when a reviewer can trace each entry in the inventory to a configured control and a log record.
Evidence auditors ask for and which component produces it
This table maps the evidence an assessor typically asks for under Safeguards 6.3 to 6.5 to the self-hosted component that produces it and how to keep it for the assessment period. DeployOpen prepares this evidence, but independent auditors assess it and decide whether it is sufficient. Confirm the retention period and sampling approach with your assessor before the period starts.
| Evidence item | Source component | How to keep it for the assessment period |
|---|---|---|
| MFA policy configuration exports | privacyIDEA policy definitions or Keycloak authentication flows, exported as configuration | Export on a fixed schedule and after each change, store read-only with a hash, and keep every version that was live during the period |
| Enrollment report per user | privacyIDEA token list or Keycloak credential reports, filtered by user and token type | Snapshot at period start, end and at intervals, reconcile against the directory so every in-scope account is listed with a factor |
| Sample authentication logs showing second-factor events | privacyIDEA audit log, Keycloak event log, and VPN or Windows and Linux PAM logs forwarded to a central log store | Forward logs to a retained, access-controlled store, tag events by in-scope system, and pull samples for each system across the period |
| Exception and service account register | Directory group for MFA exemptions, plus a register kept in your GRC or ticketing system | Record owner, justification, compensating control and review date for each exception, and archive every approved version |
| Change records for the MFA policy | Git or configuration management history, and change tickets linked to the policy version | Require a ticket reference for each policy change, keep approvals with the change, and retain the diff between versions |
| Coverage of internet-facing applications and remote access | Application inventory from your CMDB, and MFA enforcement settings per application or VPN gateway | Review the inventory against enforcement settings each quarter and record gaps with dates and owners |
| Administrative account MFA status | Directory privileged group membership and MFA enrollment status for those accounts | Export privileged group membership with factor status at period start and end, and record any account without MFA as an exception |
What MFA tooling alone does not satisfy
Does MFA on the identity provider cover every internet-facing application?
No. Safeguard 6.3 applies to every internet-facing application where the application supports MFA, so MFA only covers what is actually routed through the SSO or proxy layer. Applications that cannot be fronted by SSO, such as some legacy web tools, vendor portals with local accounts and older appliance interfaces, need their own inventory entry and a documented decision: integrate, front with an authenticating proxy, or record a compensating control. Start with an application inventory that lists each internet-facing system, its login method, and whether MFA is enforced there. Confirm with each application owner, since some vendor products support MFA only in a paid tier or a different login path.
How should service accounts be handled when they cannot use MFA?
Service accounts, API clients and automation jobs cannot answer a prompt, so they fall outside interactive MFA by design. The control gap is that they still need a documented owner, a secret rotation method, restricted network paths and monitoring of their use. Keep them out of human login flows, bind them to specific hosts or IP ranges where the platform allows it, and store their credentials in a secrets manager. Where a service account has administrative rights, the team should confirm how Safeguard 6.5 is met for that account, because the requirement is written around accounts with administrative access and not around humans specifically.
What is the problem with shared administrative accounts and MFA?
A shared administrative account gives MFA no individual to verify, so a second factor on a shared login does not show who acted. MFA on a shared account is weak evidence of individual accountability. The remedy is to move administrators to named accounts, each enrolled in MFA, and to keep any break-glass shared credential sealed, with its use alerted and reviewed. Expect this to take time on older systems that have no per-user admin model. The engineering effort depends on how many systems rely on shared logins, which the inventory should reveal before any rollout plan is set.
Why does help desk recovery create an MFA bypass risk?
Help desk resets are the most common route an attacker takes around MFA, because a convincing caller can ask for a token to be removed. The MFA platform will not define a secure recovery process on its own. Write a procedure that requires identity verification through a second channel, logs every reset with the requester and approver, limits who can reset administrative accounts, and sends a notice to the user. Test the procedure with the help desk before go-live. The staffing effort and the number of resets per month depend on your user base and token mix, so confirm those figures from your own ticket history.
Which Safeguard 6 assessment measures does the MFA platform not produce?
The CIS Controls Assessment Specification defines the inputs, operations and measures that verify each Safeguard, but an MFA platform only produces part of that evidence. Enrollment reports, policy exports and authentication logs help, yet they do not show that every account in scope was reviewed, that exceptions were approved, or that the inventory is complete. The assessor will also expect records that the implementation was checked over time. Read the assessment specification for Safeguards 6.3, 6.4 and 6.5 and list each measure against a source system, so gaps in evidence are visible before an assessment starts. Note that the specification explains what to measure, not how, so the method is your decision.
Who should own the MFA policy after go-live?
Policy ownership usually falls between the identity team, the security team and application owners, and unclear ownership is where coverage drifts. Assign one accountable owner for the MFA policy, with written responsibilities for exceptions, enrollment standards, reset procedures and periodic review of which applications and administrators are covered. Define who approves an exception, how long it lasts, and how it is revisited. Governance work is recurring, not a one-time project, so budget time for it in the operating model. The right owner depends on your structure, and your reporting lines should decide it rather than the tooling.
Can DeployOpen take over MFA governance and the application inventory?
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms in the client's own infrastructure, and it prepares systems, controls and evidence for compliance assessments. Inventory work, exception design, reset procedures and evidence packs can be defined in a written scope, and most engagements are fixed-scope. DeployOpen does not issue audit reports or certifications, and the policy decisions and accountability remain with your organization. Ongoing governance support is available as a retainer. Ask for a scope that lists each deliverable, the systems covered, and who approves exceptions.
What a DeployOpen engagement on this framework includes
DeployOpen plans, implements and documents self-hosted MFA inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. For Safeguards 6.3, 6.4 and 6.5, that work typically covers the identity provider or MFA server, the policies that require a second factor for internet-facing applications, remote access and administrator accounts, and the integrations that enforce them, such as privacyIDEA with your VPN or Linux PAM, or Keycloak in front of web applications. DeployOpen also prepares the configuration records, enrollment results and policy exports that your team can hand to an assessor. The assessor or certification body decides whether any control is met. DeployOpen does not issue audit reports, attestations or certifications. Before work starts, confirm with your auditor which evidence format they expect, because that determines what the documentation deliverables look like.
Engagements are fixed-scope. The written scope names the systems in each safeguard, the token types and user stores in use, the environments involved, the deliverables and the timeline, and it should state which accounts are excluded and why, such as service accounts that cannot use an interactive second factor. Changes to scope go through a written amendment. Once the MFA service is live, many clients keep a retainer for patching, upgrades, token and enrollment support and periodic configuration reviews, which keeps the evidence current through the assessment period. Ask each partner to show how the retainer covers vendor release upgrades for the components you choose, and what response expectations apply to MFA outages, since an MFA server failure can lock out administrators and remote staff at the same time.
How DeployOpen scopes, delivers and supports CIS-aligned MFA
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For CIS Safeguards 6.3 to 6.5, that means agreeing in writing which applications, remote access paths and administrator accounts are in scope before any MFA component is deployed.
How we scope
- Inventory internet-facing applications, remote network access paths and administrative accounts that must enforce MFA under Safeguards 6.3 to 6.5.
- Confirm which systems support a second factor natively and which must sit behind an SSO provider that enforces MFA centrally.
- Agree the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.
How we build
- Deploy the chosen MFA components, such as privacyIDEA or Keycloak, in your environment with the user stores and token types your policy requires.
- Integrate VPNs, Linux PAM, Windows logon and web applications in the rollout order agreed during scoping, starting with administrative access.
- Test enrollment, lockout, recovery and fallback paths, then document configuration so the evidence can be reviewed later.
How we hand over
- Deliver architecture, configuration records and runbooks that map each in-scope system to its MFA enforcement point.
- Prepare control evidence for your assessors, such as policy settings, enrollment reports and authentication logs, without issuing any audit opinion.
- Train administrators and help desk staff on enrollment, token replacement and recovery procedures before handover is signed off.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement ends.
- Track vendor releases, such as privacyIDEA and Keycloak updates, and schedule upgrades in a controlled change window.
- Ask any partner for written service levels, response terms and upgrade responsibilities before signing, since DeployOpen does not publish a price list.
