Safeguard 5.4 Restrict administrator privileges to dedicated admin accounts

What Safeguard 5.4 asks for and why admin accounts get separated

If your administrators read email, browse the web and open office documents while holding domain or system rights, Safeguard 5.4 asks you to split that person into two accounts. Administrative rights live on a dedicated administrator account that is used only for administrative tasks. Everyday work such as browsing, reading mail and using office software happens from the person's main account, which carries no elevated privileges. The point is simple: a web page, an attachment or a phishing link that runs in a session should only be able to do what that session's account is allowed to do.

The risk this closes is credential theft and privilege abuse. When a single account holds both ordinary and administrative rights, malicious web content, a poisoned download or a convincing login page can run with those rights and harvest the same credentials that unlock your directory, hypervisors and backup consoles. Separating the accounts means a compromised browser session exposes a standard user, not a domain administrator. Safeguard 5.4 sits in the Users asset class and the Protect security function, and it applies to all three Implementation Groups, which is why CIS treats it as part of IG1 essential cyber hygiene. Organizations of any size can be expected to do it.

The hard part is rarely the technology. It is legacy habit: administrators who have always signed in with one account, shared administrator logins that several engineers use, and service or generic accounts that quietly hold admin rights. Before changing anything, confirm with your identity team which accounts currently hold administrative roles, who uses each one and whether any are shared. Those answers come from the account inventory described in Safeguard 5.1, which the assessment specification treats as the starting data for measuring 5.4. Plan the cutover person by person, with a documented exception path for the rare task that genuinely needs a shared account.

Which accounts, systems and teams fall under Safeguard 5.4

Safeguard 5.4 applies to every account that carries administrator rights, wherever that right lives. The population is usually larger than the domain admin group, so the scoping work starts from the account inventory and asks which entries can change configurations, grant access or bypass controls.

Local and domain administrators

Local administrator accounts on workstations and servers, plus domain and directory administrator groups, are the most common starting point. Check whether members of these groups also use them for email and browsing, and whether local admin rights are granted through shared groups that nobody reviews. Each member should hold a separate admin account, and the list of members should match the account inventory from Safeguard 5.1. Confirm that the membership of privileged groups is reviewed, not only the group definitions.

Cloud tenant and SaaS admin roles

Global, subscription, project and billing administrator roles in cloud tenants, along with admin roles in SaaS platforms such as code repositories, collaboration suites and ticketing tools, all count as administrator privilege. Many of these roles are assigned directly to a user's daily account rather than to a separate one. List every built-in and custom role that can change tenant settings, identity policy or billing, and confirm which people hold each one.

Network and hypervisor administrators

Accounts that manage firewalls, switches, routers, load balancers, hypervisors and their management consoles often sit outside the directory and receive little scrutiny. These accounts can alter traffic, disable logging or reach every guest system, so they belong in scope. Check whether shared or local device accounts exist, whether administrators log in with a personal daily account, and whether management interfaces are reachable only from administrative paths.

Contractors and vendor admin accounts

Contractors and managed service providers who hold administrator rights are in scope for Safeguard 5.4 whether or not they are employees. Vendor accounts that the provider controls, such as remote support or monitoring accounts, need a clear owner inside the organization and a documented decision on who can enable them. Ask each vendor to confirm which admin accounts it uses, and record those accounts in the inventory with the sponsoring internal owner.

Break-glass and service accounts

Break-glass accounts are emergency administrator accounts kept for use when identity systems fail. They are still administrator accounts, so they belong in scope, but they usually have a different control design, such as sealed credentials and alerting on use. Service accounts with administrative rights are covered by the inventory described in Safeguard 5.5. Decide and document how each category is treated, and confirm that the scoping decision is recorded in writing and approved by the owner of the control.

Defining the population from the inventory

The account inventory from Safeguard 5.1 is the starting population for Safeguard 5.4, because the assessment specification treats it as a prerequisite for measuring this Safeguard. Filter the inventory by privilege, then reconcile it with directory group memberships, cloud role assignments and device admin lists. Any administrator account found outside the inventory is a finding. Ask an assessor or internal reviewer to sample accounts from several sources to confirm the population is complete.

How an assessor tests Safeguard 5.4 against the CAS measures

The first thing an assessor looks at is the full population of accounts that hold administrator rights. The CIS Controls Assessment Specification (CAS) for v8.1 defines 6 measures for Safeguard 5.4, and they roll up into 2 metrics. One of those metrics counts administrator user accounts, so the assessor needs a complete and current list rather than a sample from one system. The CAS also lists Safeguard 5.1, the account inventory, as a prerequisite, because that inventory is usually the data source for this count.

Source of truth: Confirm which inventory, directory group or role assignment the count is taken from, and whether it covers every platform in scope.
Privileged groups: Export membership of local, domain, cloud and application admin groups, not only the one directory you manage centrally.
Named ownership: Each administrator account should map to a named person or documented service owner.
Point-in-time versus trend: Ask whether the assessor will take one snapshot or expect evidence of periodic review.
Scope boundaries: Agree in writing which systems, tenants and asset classes are included.

Before fieldwork, ask the assessor how they expect the population to be produced and in what format, since the CAS defines what to measure but leaves the method to be agreed.

How to separate admin accounts in six steps

This sequence moves administrator rights onto dedicated accounts and leaves everyday work on non-privileged primary accounts, producing an inventory of privileged roles, a documented standard and evidence that an assessor can test against the Safeguard 5.4 measures.

Confirm the account inventory from Safeguard 5.1
Start from the account inventory that Safeguard 5.1 requires, because the CIS Controls Assessment Specification lists that inventory as a prerequisite for measuring Safeguard 5.4. Your identity or IT team should confirm that every user, administrator and service account is listed, with its owner, status and the systems it can reach. Done means the inventory can answer which accounts currently hold elevated rights, and the open gaps are logged with owners. Ask the team to confirm the inventory is exported from the directory rather than maintained by hand.
Identify every privileged role across environments
Map each privileged role on on-premises systems, cloud control planes and SaaS applications. Include directory roles, hypervisor and network device admin rights, cloud subscription owner or policy roles, and SaaS tenant administrator roles, since each can grant broad control. The output is a register of privileged roles with the members of each role, reviewed by the system owner. Confirm that nothing relies on a shared or default administrator login before moving to the next step.
Create dedicated administrator accounts with distinct naming
For each person who needs elevated rights, create a separate administrator account used only for privileged work. Use a naming convention that makes the account easy to recognize in logs and reports, such as a prefix or suffix that differs from the everyday login, and record the convention in the standard. Assign each account only the roles it needs, and link it to the owner in the inventory. Done means every privileged role member has a named admin account and the register reflects it.
Move daily work to non-privileged primary accounts
Confirm that each person's main account has no elevated privileges and is used for browsing, email and office software. Remove standing administrator rights from primary accounts, and check local administrator membership on endpoints as well as directory and cloud roles. Users should be told which account to use for which task, and help desk procedures should follow the same split. The check that closes this step is a sample of primary accounts showing no privileged group memberships.
Restrict administrator accounts to administrative tasks
Limit each dedicated administrator account to administrative work, such as configuration changes, patching and privileged support. Prevent these accounts from being used for email, web browsing or general document work, using access policies where the platform supports them, and clear written rules where it does not. Where your environment allows it, require separate authentication or a privileged access workstation for administrative sessions. Confirm with each platform owner which controls they can enforce, rather than assuming a setting exists.
Document the standard and set up recurring checks
Write the standard that defines dedicated administrator accounts, naming, permitted uses, approval for new privileged roles and removal when someone changes role. Record the procedure that produces the evidence: the privileged role register, the list of administrator accounts and any exceptions with approval. Schedule a recurring access review of privileged roles, and consider an access certification campaign in which designated reviewers keep, change or revoke each role assignment. Done means an assessor could trace any administrator account back to an approved owner, a defined purpose and a review record.

How the admin and primary account split works in practice

The core of Safeguard 5.4 in practice is that an engineer holds two identities, and only one of them can reach the internet and email. Consider an illustrative case: an infrastructure engineer, Alex, has a standard user account in the corporate identity provider that receives mail, opens the web and edits office documents, and a separate administrator account, named with a clear suffix such as adm-alex, that is granted privileged roles only for specific administrative tasks. The identity provider decides which role assignments each account receives. The standard account carries no directory administrator, cloud subscription owner or privileged group membership. The administrator account is never used for mail, browsing or document work, and it is not licensed for a mailbox where the platform allows that choice. Organizations should confirm, for each identity provider and cloud platform they run, which role assignments can be made to an account and whether mailbox or license assignments can be removed from administrator accounts.

Restricting the administrator account goes further than role assignment. Where the platform allows it, block administrator accounts from email and general web access through conditional access or equivalent policy, so that a phishing message or malicious page cannot run in the privileged session. Confirm the exact policy conditions available in your own environment, since the identity provider, endpoint management tool and browser configuration each provide different controls. Privileged sessions should also go through a dedicated administrative workstation or a hardened session, and the Safeguard does not require a specific product to do this. Organizations often need outside help to design these conditions, test them against real workflows and document exceptions, and this is a fixed-scope piece of work that an implementation partner can prepare, while the organization approves the policy.

Separation has to be verified, not assumed. Pull sign-in and directory audit logs for every administrator account and check that each privileged action is traceable to a named person, that no administrator account signs in to mail or browsing services, and that no standard account has gained a privileged role. Keep the account inventory from Safeguard 5.1 as the reference list, because the assessment specification uses that data as input when it measures administrator accounts. Review the privileged role membership on a fixed schedule and record who approved each exception. Ask the assessor which log sources and reporting periods they will sample, and confirm that your logs are retained long enough to cover that sample. The assessor, not the implementation partner, decides whether the evidence is sufficient.

Which evidence shows administrator accounts are separated

An assessor testing Safeguard 5.4 wants to see that administrator rights sit on dedicated accounts and that those accounts are used only for administrative work. The cards below cover the records that prove it, and each one should be generated from the same account inventory so the pieces agree with each other.

Administrator account list

This is the list of every account that holds administrator rights, with its owner, purpose and whether it is dedicated to administration. Tie each entry back to the account inventory from Safeguard 5.1, since the Assessment Specification treats that inventory as the starting data for measuring 5.4. Check that every administrator account has a named owner and that no personal everyday account appears on the list.

Directory role assignment exports

Export role assignments from the directory or identity service, showing which users hold roles such as domain administrator, global administrator or cloud subscription owner. Compare these exports against the administrator list to find any assignment that is not recorded. Ask the assessor to see the export date and the filter used, because an export without them cannot show the current state.

Privileged group membership reports

Reports of membership in privileged groups on servers, applications and cloud platforms show who can elevate rights outside the directory. Look for ordinary user accounts, or the everyday account of an administrator, inside these groups. A report that includes nested groups is more useful than one that lists only direct members, because nesting is a common way administrator rights spread unnoticed.

Written standard for administrator accounts

A written standard states that administrator rights live on separate accounts, that these accounts are not used for email or web browsing, and who approves their creation. It should also name the owner who reviews it and the date of the last review. Confirm that the standard matches what staff actually do, because an assessor will compare the written rule against the sign-in records.

Sign-in logs for administrator accounts

Sign-in logs for administrator accounts should show that they are used for administrative tasks and not for everyday work from the same device or session as the person's main account. Filter the logs for interactive sign-ins by administrator accounts to office, web or email applications. Any such sign-in is a finding to explain, even if it is a one-off, and should lead to a documented exception.

Scheduled exports between audits

Schedule the administrator list, role exports, group reports and sign-in extracts to run on a fixed cadence and store them with date stamps in a location that cannot be altered. Retaining several periods of exports lets you show that separation held over time, not only on the day of the assessment. Confirm the retention period with your auditor and the log platform's retention settings, since they may differ.

What meeting Safeguard 5.4 costs in money and effort

This table breaks down the cost components of meeting Safeguard 5.4, who is paid for each one, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a written scope and to ask potential partners for a quote that separates license spend from engineering effort. No prices or durations are given because none are supplied for this Safeguard.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Directory and identity licenses	Software vendor, if commercial licensing is used	Recurring	Number of user and admin identities, and whether privileged access features are included in the license tier. Self-hosted open-source identity tools can remove this line, but confirm feature parity first.
Engineering time to create dedicated admin accounts	Internal platform or identity team, or an implementation partner under a fixed-scope agreement	One-time	Number of admin roles in scope, the number of systems that still use shared or local administrator accounts, and how many people need separate accounts.
Role redesign and privilege separation	Internal identity engineers, with partner support if scoped	One-time	Current role sprawl, how many people hold standing admin rights, and whether roles map cleanly to job functions. Expect more effort where roles were granted ad hoc over years.
Cloud and legacy system sprawl	Internal cloud and infrastructure teams, or a partner	One-time, then recurring as systems change	Number of cloud accounts, subscriptions, and legacy applications with built-in administrator accounts that cannot easily use directory identities.
User change management	Internal managers, service desk and training staff	One-time, with periodic refresh	Number of staff who must adopt a second account, the workflow for elevation, and how many helpdesk requests the change creates in the first weeks.
Access reviews and revocation	Designated reviewers in each business owner group, and the identity team	Recurring	Review frequency, number of privileged roles, and whether a certification tool automates reminders and revocation. Ask any partner how reviewers are assigned and how decisions are recorded.
Evidence upkeep	Internal compliance or security team, with partner support if retained	Recurring	Frequency of role changes, how many systems produce admin account records, and whether logs and role exports are collected automatically or by hand.
External review and auditor sampling	Independent auditor or assessor, who issues any report or attestation	Recurring, tied to the audit cycle	Sample sizes the auditor selects, the number of admin accounts requiring evidence, and whether the organization can produce current account lists on request.

Who owns Safeguard 5.4, who helps, and where the auditor stops

Your organization owns Safeguard 5.4 in full. CIS Controls are a set of safeguards your enterprise implements and operates, and no outside party can take over the decision about who holds administrative rights. The people who approve privileged access, define what an administrator account may do and answer for the outcome must sit inside your organization, with named owners and a documented process.

Admin account policy: Written rules on when a person may hold a separate administrator account, who approves it and how long it lasts.
Approval decisions: Named approvers who grant, change and remove elevated rights, recorded with a reason and a date.
Accountability: A named executive or control owner who signs off on the Safeguard and answers for exceptions.
Exception handling: A documented route for any user who needs standing administrative rights that the policy does not cover.
Periodic review: Scheduled reviews of who holds administrator accounts, with a record of what was kept, changed or revoked.

Check that each of these items has a named owner in your own records, not just a team name in a policy document.

Where admin account separation usually fails audits

Safeguard 5.4 is easy to state and hard to prove. Most failures come from privileged rights that were granted for convenience, never listed in one place, or never reviewed after the person or system changed. Each card below names one gap an assessor tends to find and the check that closes it.

Admin accounts used for daily work

An administrator who browses the web, reads email or opens office documents while signed in with an elevated account exposes every session to phishing and malicious downloads. Safeguard 5.4 expects the everyday work to run from a standard primary account. To close the gap, give each administrator a separate account for privileged tasks, remove administrator group membership from the primary account, and test by confirming that a routine email client session cannot install software or change system settings.

Shared administrator credentials

When several engineers sign in with one administrator login, the logs cannot show who made a change, and removing one person means rotating a password for everyone. Assessors look for individually named privileged accounts that map to a person. Close the gap by issuing one named administrator account per person, retiring shared logins that cannot be replaced, and confirming that the account inventory from Safeguard 5.1 records an owner for each privileged account.

Unlisted cloud and SaaS admin roles

Cloud tenants, code repositories, ticketing tools and SaaS platforms often grant administrator roles through built-in or delegated roles that never appear in the directory inventory. These are the privileged accounts most likely to be missed in an assessment. Close the gap by exporting role assignments from each cloud and SaaS platform, adding every holder of an administrative role to the account inventory, and flagging any role held outside the approved administrator population.

Dormant privileged accounts

A former contractor or a project-specific administrator who has not signed in for months still holds rights that an attacker can use. Safeguard 5.4 is measured against administrator accounts that should not exist, so an enabled, unused privileged account counts against the environment. Close the gap by linking each administrator account to an accountable owner, disabling those with no active need, and tying the offboarding checklist to revocation of every privileged role, not only the primary login.

No evidence of periodic review

Many organizations grant administrator rights correctly and then never look at them again, so the decision cannot be shown to an assessor. A recorded review shows who holds each role, why, and who approved it. Close the gap by running a scheduled access review of all administrator accounts, recording keep, change or revoke decisions with a reviewer name and date, and retaining the export as evidence. Access certification tools such as midPoint can record these decisions with designated reviewers and deadlines.

Questions buyers ask about Safeguard 5.4

Can we restrict administrator privileges to dedicated accounts in-house?

Yes, most organizations can do this with their own identity and endpoint staff, because the work is mostly policy, account design and cleanup rather than new technology. The organization owns the control and must decide who receives administrator rights, which accounts they use, and how exceptions are approved. The main effort is finding existing administrators who use one account for both everyday work and privileged tasks, then separating those roles. An implementation partner can help with the account model, directory configuration and evidence, but the decision to grant privilege stays with the organization.

What drives the effort of separating administrator accounts?

The effort rises with the number of people holding privileged rights, the number of systems and applications that use local or shared admin logins, and how many scripts or service jobs depend on personal admin accounts. Teams usually need an accurate list of who holds administrator rights, a naming convention for admin accounts, a way to keep privileged accounts out of email and browsing sessions, and time to test that everyday tools still work from the standard account. Each system that supports only one admin login will need a decision on how to handle it. Ask any partner to show how they will find existing admin access before proposing a design.

How long does it take to move administrators to dedicated accounts?

The timeline depends on how many people and systems are in scope, and no duration is set by CIS for this Safeguard, so the reader should confirm it with the team or partner. A practical starting point is to inventory privileged access first, because Safeguard 5.1 provides the account inventory that the assessment specification treats as a prerequisite for measuring Safeguard 5.4. Work then splits into policy and account design, rollout to administrators, and removal of unnecessary admin rights. Ask for a timeline that lists these phases and the systems each one covers.

Does Safeguard 5.4 affect SOC 2 CC6.1 and CC6.3 or ISO 27001 mappings?

CIS's v8.1 mapping in the CIS Controls Navigator links Safeguard 5.4 to SOC 2 CC6.1 and CC6.3, and to ISO/IEC 27001:2022 Annex A 5.15 and 8.2. A mapping shows where the two frameworks address related ground, so it does not mean that meeting Safeguard 5.4 satisfies either criterion or control on its own. The SOC 2 and ISO 27001 auditors decide what evidence is sufficient for their scope. Use the mapping to plan shared evidence, such as admin account lists and access reviews, and confirm the mapping against the current Navigator entry before you rely on it in an audit plan.

What does an assessor ask for to verify dedicated administrator accounts?

The CIS Controls Assessment Specification defines six measures for Safeguard 5.4, which combine into two metrics: administrator user accounts and unauthorized administrator accounts. In practice, an assessor will expect a current list of accounts with administrator rights, evidence that each administrator also has a separate standard account for daily work, and a way to show that accounts without authorization were found and removed. Records of approval for privileged access and periodic review of who holds it are useful supporting evidence. An independent assessor or auditor reaches the conclusion, so ask them early which evidence format they accept.

What should we ask a partner to include in a quote?

Ask for a written scope that names the systems, directories, cloud accounts and applications covered, the number of administrators in scope, and the deliverables. The quote should separate one-time work, such as account design, configuration and testing, from recurring work, such as periodic admin account reviews and support. Confirm who handles which step, what the organization must provide (for example, access to directories and a list of current admins), and how exceptions for legacy systems are documented. DeployOpen works from a fixed-scope written agreement, and it prepares systems and evidence for assessments but does not issue audit reports or certifications.

How do we keep administrators from browsing and reading email with privileges?

The core rule is that administrators sign in to their main account for web browsing, email and office software, and use the dedicated admin account only for privileged tasks. Technical controls support this rule, such as limiting which accounts belong to local administrator groups, using privileged workstations for admin work, and requiring elevation only when needed. Confirm which of these your directory and operating systems support before you promise them internally. Test that routine applications work for standard users, because broken workflows often lead staff to request permanent admin rights again.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems, separation of duties and evidence behind Safeguard 5.4 Restrict administrator privileges to dedicated administrator accounts, inside the client's own infrastructure. The organization owns its controls and decides how privileged access is granted, and an independent assessor reaches its own conclusion about whether the Safeguard is met.

How we scope

Engagements are fixed-scope, with the systems, identity sources and admin roles in scope agreed in writing before work starts.
The written scope lists which administrator accounts, platforms and endpoints must use a separate privileged account and which daily-use accounts stay unprivileged.
We confirm with the client which account inventory data from Safeguard 5.1 will be available to measure administrator accounts and unauthorized admin accounts.

How we build

We configure dedicated administrator accounts, separate from each person's everyday account, in the directory or identity platform the client runs.
We set up the platform-level checks that list administrator group membership, so the two metrics in the assessment specification can be produced from system data.
We test that daily browsing, email and office work runs from the non-privileged account and that elevation requires the dedicated admin account.

How we hand over

We document the admin account naming, the approval path for granting and removing elevated rights, and the owner of each privileged role.
We deliver a short evidence pack: exported admin group lists, the recurring review records and the test results for the measures we configured.
We walk the client's security and identity staff through the runbook so they can operate and review the separation without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, covering changes to admin roles and new platforms.
Between engagements, we can re-run the admin account checks when the identity platform is upgraded or reconfigured.
We can prepare the evidence for an independent auditor, but the auditor or certification body is the one that issues any report or certificate.