Safeguard 6.5 MFA for administrative access: evidence

What Safeguard 6.5 MFA for administrative access requires in practice

If you run the administrator accounts for your enterprise, Safeguard 6.5 asks for one thing: multi-factor authentication on every account with administrative access to each enterprise asset that supports it, including assets a service provider manages on your behalf. The Safeguard does not stop at your domain controllers and cloud consoles. Hypervisors, network devices, backup appliances and vendor-hosted management portals all count if they accept MFA. Start by listing every privileged account and every system those accounts can administer, then mark which systems support a second factor and which do not. The risk is simple. A stolen or phished administrator password gives an attacker full control of the systems that account manages, often without triggering the alerts a standard user account would. CIS places Safeguard 6.5 in the Users asset class and the Protect security function, and assigns it to all three Implementation Groups, so it is part of IG1 essential cyber hygiene. It is one of the first controls an assessor will check because it is inexpensive relative to the exposure it removes.

The hard part is rarely the MFA product. It is the systems that do not fit the pattern: legacy consoles that only accept local passwords, shared administrator accounts where several engineers know one password, and vendor-run systems where your staff never log in directly. For each of these, decide whether the system can be moved behind your central identity provider, whether a named account with a second factor can replace the shared login, or whether the gap needs a documented compensating control and a review date. Confirm the support status of each system with its vendor rather than assuming it. Prerequisites in the CIS Controls Assessment Specification, Safeguards 4.1 and 5.1, will also help, because a current configuration process and account inventory give you the list of administrative accounts that the measurement depends on.

Which administrative accounts and assets fall under Safeguard 6.5

Safeguard 6.5 applies to every account with administrative access to an enterprise asset that supports MFA, including assets a service provider runs. The cards below cover the account types auditors most often find missing from the scope, and the handling required for the assets that cannot take a second factor.

Local and domain administrators

Local administrator accounts on workstations and servers, and domain administrator groups in Active Directory or a comparable directory, sit at the top of the scope. Confirm that interactive console and remote desktop logons for these groups require a second factor, and that break-glass or built-in administrator accounts are not excluded by default. Include nested privileged groups, since a user added indirectly to a domain admin role still holds administrative access.

Cloud tenant owners and global admins

Global administrators, subscription owners, organization owners and equivalent roles in cloud and SaaS consoles are administrative accounts under this Safeguard, even when they are never used for daily work. Check that MFA is enforced for every role that can change tenant-wide settings, billing or identity configuration, and that service principals and automation accounts with administrative rights are listed separately with a documented exception process.

Network and security device administrators

Firewall, switch, router, wireless controller and VPN concentrator administrators are in scope where the device supports MFA for management logons. Many network platforms authenticate administrators against a central AAA service, so the MFA decision often belongs to the identity layer behind the device. Verify which management interfaces accept local accounts that bypass that path, because a local fallback login can leave the device outside the requirement.

Hypervisor and database administrators

Hypervisor management consoles, vCenter-style platforms, container orchestration control planes and database administrator roles can each grant control over many systems at once. Treat these as administrative access to enterprise assets, and confirm which of them can require MFA at the console or through a bastion host. Where the platform offers only shared database credentials, record the gap and the access path used to reach it, rather than assuming the requirement is met.

Break-glass and emergency accounts

Break-glass accounts exist for use when normal identity services fail, which is exactly when an MFA prompt may be unavailable. Document who holds the credentials, how the account is sealed and monitored, and which second factor or approval step applies when it is used. Auditors commonly look for a written rationale and a test showing that a break-glass login is logged and reviewed, not just a sealed envelope in a safe.

Service provider-managed assets

Assets run by a managed service provider or hosting partner fall under this Safeguard as well. Put the provider's administrative accounts into your inventory, require MFA for their logons into your environment, and check that the contract or service description states how the provider authenticates. Ask the provider for evidence of MFA on its own privileged staff who administer your systems, since that evidence is what an assessor will request.

How an assessor tests MFA on administrative access

This table compares what an assessor checks for each part of Safeguard 6.5 and what evidence closes each check. Read it as a test plan: the inventory and configuration prerequisites come first, then the login flows, then the exceptions. Most findings come from gaps between the admin account list and the MFA enforcement settings, not from missing MFA technology.

Assessment step	What the assessor checks	Evidence that passes	Where it usually fails
Prerequisites (4.1 and 5.1)	Whether the secure configuration process and account inventory exist and are current enough to measure against	Approved configuration baseline, current account inventory with admin role flags, dated review records	Admin accounts exist in tools that are not in the inventory, so the sample starts incomplete
Measure 1: admin account coverage	Whether every account with administrative rights is sampled against the asset inventory	Export of admin group members mapped to the asset list, with the sampling method written down	Local admin accounts on servers, network devices or cloud root users are missed
Measure 2: second factor at login	Whether each sampled admin account must present a second factor when signing in	Authentication policy or flow settings, plus a test login showing the second factor prompt	Break-glass or service-style admin accounts that bypass the MFA flow without a documented reason
Measure 3: supported assets	Whether assets that cannot support MFA are identified and handled, rather than silently excluded	List of unsupported assets with the reason, compensating controls and an owner's approval	Exceptions recorded as unsupported without a check of whether the vendor now offers MFA
Service provider managed assets	Whether admin access run by a provider, such as a hosted console or managed firewall, also requires MFA	Provider contract or admin portal settings showing MFA enforced for the organization's admin users	Provider consoles left out of scope because the organization does not operate the underlying system
Coverage metric	How the three measures combine into one coverage result for the Safeguard	Written scoring method and the raw data behind each measure, retained for re-performance	Results reported as a single percentage with no underlying counts, which an assessor cannot re-perform

Implementation sequence for MFA on every admin account

This sequence turns Safeguard 6.5 into a verifiable state: every account with administrative rights on every supported enterprise asset, including provider-managed assets, requires a second factor, and the few exceptions are recorded and owned. Each step produces an artifact an assessor can check.

Build the account inventory and baseline
Start from the account inventory that Safeguard 5.1 calls for and the secure configuration baseline from Safeguard 4.1, since the CIS Controls Assessment Specification lists both as prerequisites for measuring Safeguard 6.5. The identity team exports every account, including local, directory, service and provider-managed accounts, and the platform team confirms which configuration baseline each asset is held to. Done when every enterprise asset has a named owner and a baseline record.
Classify administrative accounts and assets
Mark each account that holds administrative rights, whether through a built-in admin role, sudo or root access, a privileged group, or a cloud owner role. Record which assets support a second factor for interactive login and which do not, using vendor documentation for each platform. The output is a register of admin accounts, their assets and a support status per asset that a reviewer can trace back to a source.
Enforce a second factor at the identity provider
Where assets authenticate against a central directory or SSO service, enforce the second factor there so administrative logins pass a second-factor check before access. For example, an authenticator validation stage in authentik can check enrolled TOTP apps, WebAuthn or FIDO2 passkeys during login, and FreeIPA can enroll TOTP and hardware tokens. The implementation partner configures the policy, and the organization confirms with a test admin login that the factor is requested. Done when the policy is in place and test logins are logged.
Enforce second factors on local and unsupported assets
For assets that cannot use the central service, configure the second factor on the asset itself where the platform supports it, or record the asset as unsupported with the reason. Changes go through the secure configuration process so each change is tracked. The output is a per-asset result showing either an enforced factor or a documented limitation, which feeds the exceptions register.
Handle provider-managed systems
For assets run by a service provider, the organization asks the provider in writing whether administrative logins on those assets require a second factor, and which factor is used. Contract language and provider attestations are the evidence here, and they should be obtained before the assessment rather than during it. Where the provider cannot enforce the factor, the gap goes into the exceptions register with a named owner. Confirm the specific provider obligations with the provider and your contract terms.
Design and test break-glass accounts
Break-glass accounts are emergency administrator accounts used when the identity provider is unavailable. Decide how each one is protected, for example a hardware token held under dual control, and test that the emergency path works without weakening the second factor for routine admin use. Each break-glass account is logged, reviewed and listed in the admin inventory. The output is a tested procedure and a log showing the test.
Document and approve exceptions
Record every admin account or asset that does not meet the second-factor requirement in an exceptions register. Each entry names the asset, the reason, a compensating control, an accountable owner and a review date set by the organization. Leadership or the risk owner approves the register, and it is reviewed on the schedule the organization sets. Done when the register, approvals and compensating control evidence are stored where the assessor can request them.

Evidence that shows administrative accounts require MFA

An assessor testing Safeguard 6.5 needs to see which administrative accounts exist, which ones enforce a second factor, and where exceptions are recorded. The cards below cover the artifacts that answer those questions, and each one should be exported from the system of record rather than rebuilt by hand. Refresh them on a fixed cadence so the evidence reflects the environment on the day it is tested.

Account inventory with admin flags

An export from the directory or identity provider listing every account that holds administrative rights, with the enterprise assets and applications where those rights apply. Safeguard 6.5 depends on Safeguard 5.1 for this inventory, so the export should come from the same account inventory the organization already maintains. Check that service accounts with interactive or console access are flagged, and that shared or break-glass administrator accounts appear rather than being left out. Regenerate the export at each review and keep the prior versions so changes between reviews can be traced.

MFA enrollment report per admin

A report that shows, for each administrative account, which second factors are enrolled and when each was registered. Pair it with the inventory so every admin row has a matching enrollment status, and treat any admin without a factor as a finding until it is closed. The authentik authenticator validation stage and FreeIPA OTP tokens both hold this data, so confirm which system is authoritative for each asset. Note the enrollment date for recovery codes as well, because a static code issued years ago can outlive the control it was meant to support.

Identity provider policy exports

Exported configuration showing which authentication flows, stages and policies require a second factor for administrative groups. An enrollment report shows who has a factor, but only the policy export shows that login actually requires it. Review the bindings to confirm that administrative groups are bound to the stage that checks the second factor, and that no bypass policy applies to them. Keep the export under version control so each change has an author, a date and a review record.

Login logs showing second-factor events

Authentication logs that record each administrative sign-in and whether a second factor was presented and accepted. These logs show the control working in practice, not just configured. Sample logins across the review period, including logins to hosts and consoles that are not behind the central identity provider, and check for failed second-factor attempts followed by success. Confirm that these events are forwarded to central log storage, which Control 8 covers, so the records are retained and protected.

Exception register for unsupported assets

A register listing each enterprise asset or administrative interface that cannot enforce MFA, the reason it cannot, the compensating controls in place, the accountable owner and a date for review. Safeguard 6.5 applies only where the asset supports MFA, so an honest register is part of the evidence rather than a weakness. Each entry should name the replacement or upgrade path and be reviewed at least annually. Ask the assessor to confirm how they will treat exceptions before the review starts.

Provider attestations for managed assets

Written statements from service providers that run enterprise assets, confirming how administrative access to those assets is protected with MFA. Safeguard 6.5 explicitly covers assets a service provider manages, so the organization needs evidence from the provider, not only its own configuration. Request the attestation, the date it covers and the scope of accounts it describes, and check that the provider's administrators are the population being attested. Refresh these when the contract renews or when the provider changes its authentication setup.

Open-source tools that produce MFA evidence for admin access

authentik is an open-source identity provider licensed under MIT. Its authenticator validation stage is the point in a login flow where enrolled second factors are checked. Administrators can attach this stage to the flows that protect administrative applications, consoles and directory-facing services, so that a password alone does not complete sign-in for those users. The stage can check several factor types, which lets you match the method to the asset, but the factor list must be confirmed against the version you deploy.

Factor types: The documentation describes validation of TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. Confirm which of these your version and configuration enable.
Enforcement by group: Bind the stage to a flow used by administrator groups so that the requirement applies to the accounts Safeguard 6.5 covers, not only to a general user population.
Enrollment records: Export the list of enrolled authenticators per account to show which administrators have a second factor registered.
Event logs: Login and flow events can show that the validation stage ran for an administrative sign-in. Check what events are emitted and how long they are retained.
Recovery code handling: Static recovery codes are a fallback. Document who may issue them and how their use is recorded, since an assessor will look for that control.

Before relying on any of this, check the current authenticator validation stage documentation and test a sample administrative login in a non-production environment to capture the evidence you intend to show.

What meeting Safeguard 6.5 costs and where open source changes it

Meeting Safeguard 6.5 costs money in five places, and only some of them are one-time. The first is second-factor hardware, such as security keys for administrators, which is bought once per person and replaced when lost or worn out. The second is the identity platform, where licenses or subscriptions for an MFA-capable directory or access broker recur every year and usually scale with users or applications. The third is engineering time: someone must enroll each administrative account, configure MFA on each asset that supports it, and document the exceptions for assets that do not. That effort is largely one-time per asset class but grows with the size of the estate, including systems run by service providers, where you may need contract changes as well as configuration. The fourth and fifth are recurring: evidence upkeep (keeping the account inventory, enrollment records and exception register current, which Safeguards 4.1 and 5.1 feed) and assessor sampling, since an assessor may pick several administrative accounts and ask for proof of enrollment and enforcement at the time of testing.

Open-source identity tools can remove the license line, but they move cost into build and run effort. authentik and FreeIPa both support the second factors that matter here, including TOTP, WebAuthn and FIDO2 passkeys, and FreeIPa supports hardware tokens such as YubiKeys, so the recurring subscription for the MFA component can often be avoided. You still pay for deployment, integration with each administrative system, hardening, backups, upgrades and the operational support that keeps the identity service itself available. Ask any implementation partner for a written scope quote that separates these items: hardware procurement (if it is included), platform licenses (which may be zero for the open-source components), integration per asset class, evidence design, upgrade and support terms, and any assessor-support hours. Confirm the supported second factors and asset integrations with each vendor, since capability differs by product and version.

Cost components for MFA on administrative access

This table lists the cost components of meeting Safeguard 6.5, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request, then compare each line against your own account and asset inventory.

Cost component	One-time or recurring	Main cost drivers and how to reduce them
Administrative account inventory	One-time, then recurring review	Number of admin accounts across directories, cloud tenants and local systems. Reduce by consolidating admin roles and removing shared or dormant admin accounts before enrolling MFA.
Asset and platform coverage mapping	One-time, updated when assets change	Count of enterprise assets and the share that support MFA for admin access. Reduce by documenting unsupported assets early so exceptions are scoped once, not discovered during assessment.
Service provider-managed assets	One-time negotiation, recurring oversight	Share of admin access held by providers, which needs contractual MFA terms and evidence requests. Reduce by adding MFA and admin access evidence clauses to renewals rather than renegotiating mid-term.
Legacy systems without native MFA	One-time integration, possible recurring workaround upkeep	Age and number of systems that cannot enforce MFA directly. Reduce by fronting them with a central identity provider or privileged access gateway where the platform allows it.
Hardware token policy	One-time purchase, recurring replacement and issuance	Number of administrators, token type, and replacement for lost or damaged devices. Reduce by allowing software authenticators for lower-risk roles and reserving hardware keys for the most privileged accounts.
Identity platform licensing	Recurring	Commercial MFA and identity licenses charged per user or per account. Self-hosted open-source options such as authentik and FreeIPA can remove per-user licensing, but they add hosting and maintenance effort.
Deployment and integration services	One-time	Number of platforms to integrate, configuration complexity and testing scope. Reduce by fixing a written scope and phasing assets by risk before work starts.
Operations, recovery and evidence	Recurring	Enrollment support, account recovery requests, MFA logs retained for review and periodic evidence collection. Reduce by standardizing recovery procedures and automating log export to your existing log management.

Who owns the control, who prepares evidence, and who assesses it

Your organization owns Safeguard 6.5. That means someone accountable must decide which administrative accounts exist, which assets they reach, which second factors are acceptable, and what happens when a factor is lost. CIS places the Safeguard in the Users asset class and the Protect security function, and it applies to all three Implementation Groups, so it is expected of every enterprise. The control does not transfer to a vendor because a vendor installed the software.

Accountable owner: Name an executive or security lead who signs off on the administrative account population and the exception process.
Account inventory: Keep the list of administrative accounts current, because the CIS Controls Assessment Specification treats the account inventory (Safeguard 5.1) as a prerequisite for measuring this Safeguard.
Policy and exceptions: Decide in writing which assets do not support MFA and how each exception is approved, reviewed and retired.
Operations: Run enrollment, recovery and offboarding for administrators as daily work, not as project tasks.
Assessment readiness: Keep the records an assessor will ask for, such as configuration exports and access review results.

Confirm with your own assessor which evidence format they accept before you build it.

Common gaps that fail MFA coverage testing

An assessor testing Safeguard 6.5 looks for administrative accounts that sit outside MFA, not for a policy that says MFA is required. The gaps below are the places where coverage usually breaks down, and each one can be checked against the account inventory and the enrollment records before the assessment starts.

Shared administrative credentials

A single administrator login used by several engineers cannot show which person authenticated, and a second factor tied to one phone or token is often shared with the team. Assessors measuring coverage will treat these accounts as unmanaged because MFA does not identify the individual. Check whether every administrative action traces to a named person, and replace shared logins with individual accounts that each enroll their own second factor.

Break-glass accounts without second factors

Emergency accounts are often excluded from MFA so administrators can recover during an identity outage, and that exclusion is exactly what the measure counts against coverage. Break-glass accounts still need MFA where the asset supports it, or a documented compensating control that the organization can explain. Confirm where the recovery credentials are stored, who can reach them, and how each use is logged and reviewed.

Provider consoles outside the inventory

Safeguard 6.5 covers administrative accounts on assets that a service provider manages, which means a hosting console, managed database portal or SaaS admin panel can fall in scope even though no internal team runs it. When these consoles are missing from the account inventory, the coverage figure is incomplete. Reconcile provider administrator accounts against the inventory and confirm which of them accept a second factor.

Unclear support determinations

The Safeguard applies only where the asset supports MFA, so each administrative interface needs a recorded answer to whether it does. A vendor appliance with a local admin console that cannot enforce a second factor may be excluded, but only if the determination is written down with the vendor's documentation as its basis. Undocumented exclusions read as gaps during testing. Record the support status, the source checked and the date of the decision for every asset.

Enrollment without enforcement

Many environments let administrators enroll an authenticator but do not require it at sign-in, so an account can still log in with a password alone. Enrollment reports look reassuring, while the login logs show password-only sessions. The check is to compare enrolled second factors against successful administrative logins and confirm that the authenticator validation step cannot be skipped for administrative roles. Authentik's authenticator validation stage is one example of a step that checks enrolled factors at login, so confirm how your own flows call it.

Questions buyers ask about MFA for administrative access

Does Safeguard 6.5 require MFA on every administrative account?

Yes, the Safeguard asks for multi-factor authentication on every account with administrative access to an enterprise asset, but only where the asset supports it. The measurement is about coverage: an assessor checks whether each administrative account on each in-scope asset is protected by a second factor at sign-in. Accounts that cannot use MFA because the platform does not support it are a documented exception to resolve, not a silent gap. Start by listing administrative accounts from your account inventory (Safeguard 5.1), since that inventory is one of the prerequisites the assessment specification names for measuring 6.5. Your team owns the decision on which accounts are administrative and where MFA is enforced.

How does MFA for administrative access work on assets run by a service provider?

The Safeguard covers assets that a service provider manages, so the obligation does not end at the contract boundary. Your organization still owns the control, which means you need to confirm with each provider that administrative logins to your assets require a second factor, and keep evidence of that setting. Where the provider's platform offers MFA enforcement, ask for the configuration or a written statement that you can review. Where it does not, record the gap and the compensating measure. Service provider management (Control 15) is the related area to review in your contracts.

Is SMS a valid second factor for administrative accounts?

SMS codes are a second factor the Safeguard does not exclude by name, but they are the weakest option for accounts with administrative power, and many assessors and regulators will question them. Stronger choices include TOTP apps, WebAuthn or FIDO2 passkeys and hardware tokens. Open-source identity platforms such as authentik list SMS codes among supported stages, so the decision is a policy choice you document and justify. Prefer phishing-resistant methods for privileged accounts and confirm with your assessor how they treat SMS before you rely on it.

How much effort and time does enabling MFA for administrators take?

The effort depends on how many administrative accounts exist, how many platforms they touch, and whether those platforms share one identity source. Enrollment itself is usually quick per user, but integrating each administrative system with a central identity service, testing break-glass access and handling exceptions take longer. No duration figure is supplied for this work, so ask for one in a written scope that lists the systems, the account count and the integration method. Most engagements are fixed-scope, so the agreed deliverables and timeline are set in writing before work starts.

What does the client team need to provide for this work?

The work needs named owners for administrative roles, a current list of administrative accounts and the systems they access, and access to the identity source those systems use. It also needs a decision on supported second factors, a plan for emergency access if a token is lost, and someone who can approve changes to production administrative logins. Security and platform staff should be available to test sign-in on each system. Ask the implementation partner to list these inputs in the written scope so that gaps are visible before work starts.

Can our own team enable MFA for administrative access in-house?

Yes, many teams do this in-house, especially where the identity platform is already in place and the number of administrative systems is small. The main risks are inconsistent coverage across platforms, lockouts during rollout and evidence that is hard to collect later. An outside partner can prepare the configuration, testing and evidence, while your organization keeps ownership of the control. Independent auditors or certification bodies, not implementation partners, issue any report or certificate. Decide based on your internal capacity and the number of systems in scope.

Which open-source tools can enforce MFA for administrative logins?

Two open-source options are commonly evaluated. authentik, licensed under MIT, has an authenticator validation stage that checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. FreeIPA, licensed under GPL-3.0-or-later, supports HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. Confirm that the chosen platform covers each administrative system you run before you commit to it, since support for individual applications varies.

What evidence shows that administrative MFA is working?

Assessors typically look for the policy or configuration that requires a second factor for administrative roles, a list of administrative accounts with their enrollment status, and sign-in logs that show the second factor being checked. Exception records with approvals and compensating controls are also expected where MFA is not supported. Keep these artifacts current, because the measurement is a coverage check at the time of assessment. Confirm the exact evidence format with your assessor before collection starts.

How DeployOpen scopes and prepares MFA evidence for Safeguard 6.5

DeployOpen plans, implements and documents self-hosted identity and MFA for administrative access inside your own infrastructure, under a fixed written scope agreed before work starts. The first decision is the boundary: which enterprise assets, administrative roles and service provider-managed platforms fall inside Safeguard 6.5, and which are excluded with a stated reason. We recommend that the scope document list every administrative account type (domain administrators, cloud tenant owners, hypervisor and firewall administrators, and break-glass accounts) and name the asset each one controls. DeployOpen prepares the systems and the evidence for an assessment, but the organization owns its controls. Only an independent auditor, assessor or certification body issues reports or certificates, so the scope should also state which assessor will review the output.

Evidence preparation starts with the prerequisites the CIS Controls Assessment Specification names for this Safeguard: the secure configuration process (Safeguard 4.1) and the account inventory (Safeguard 5.1). Confirm with your team that both exist before scoping MFA work, because the measurement depends on them. Within the implementation, DeployOpen typically configures the second-factor enrollment and validation stages, exports the policy bindings that enforce MFA for administrative groups, and captures per-asset coverage records. A useful check for your own review is whether every administrative account in the inventory maps to an enforced second factor, with exceptions documented and approved. Ask any partner to show how that mapping is produced and refreshed, since a one-time export becomes stale quickly.

Ask for these items in a written quote: the in-scope asset list, the administrative account categories, the MFA methods to be enabled, the evidence artifacts to be delivered and their format, and who performs the final review. Clarify which tasks recur. Initial configuration and evidence capture are typically one-time, while account reviews, enrollment of new administrators and platform upgrades recur. Confirm the handover terms, including who holds the configuration, the recovery codes and the documented procedures after the engagement ends. Any scope that promises an audit result, a certification or a fixed compliance outcome should be treated with caution, because those outcomes belong to the independent assessor.

Safeguard 6.5 Require MFA for administrative access