CIS Control 6 Access Control Management Guide

Most organisations that claim CIS Control 6 have an MFA policy and a joiner process, yet still have remote access, admin consoles and service accounts that a single stolen password can open. CIS Control 6 (Access Control Management) in CIS Controls v8.1 sets out how access is granted, revoked, authenticated and reviewed across enterprise assets. This guide walks through its eight Safeguards by Implementation Group, explains what each one actually requires, shows how to implement them in order, and lists the evidence an assessor will ask for. It is written for security engineers, IAM teams and GRC staff preparing for a CIS self-assessment, a customer audit or an insurer questionnaire. For the framework as a whole, see the CIS Controls Guide.

Key takeaways

Five of the eight Safeguards are IG1. Granting access (6.1), revoking access (6.2) and MFA for externally exposed applications, remote network access and administrative access (6.3 to 6.5) are essential hygiene for every organisation, whatever its size.
Control 6 covers service accounts too. CIS defines the Control as managing credentials and privileges for user, administrator and service accounts, so non-human identities are in scope, not an optional extra.
Evidence is coverage, not policy. The CIS assessment specification measures counts: accounts and assets with and without MFA, assets covered by a directory or SSO, accounts with an assigned role. A policy document alone does not satisfy an IG1 Safeguard.
Revocation is the weak point. Safeguard 6.2 asks for accounts to be disabled immediately on termination or role change; tokens, API keys and sessions created by the leaver usually survive an account disable and need their own step.
IG2 and IG3 make access manageable at scale. An inventory of authentication and authorisation systems (6.6), centralised access control (6.7) and role-based access with at least annual reviews (6.8) turn one-off MFA projects into a governed access model.

What it is and who it applies to

CIS describes Control 6 as using processes and tools to create, assign, manage and revoke access credentials and privileges for user, administrator and service accounts for enterprise assets and software. It sits directly after Control 5 (Account Management): Control 5 asks whether you know what accounts exist and whether they are still needed, while Control 6 governs what those accounts can reach and how strongly they must authenticate. The two are usually assessed together. See the CIS Control 5 Account Management Guide.

Implementation Groups decide how much of the Control applies to you:

IG1: CIS calls IG1 essential cyber hygiene, the minimum every enterprise should meet. For Control 6 that means Safeguards 6.1 to 6.5. A small business with a cloud identity provider, a handful of SaaS applications and a remote access service is expected to meet all five.
IG2: organisations with dedicated IT staff, several departments and sensitive or regulated data add 6.6 and 6.7. In practice this is where access control moves from per-application settings to a single identity plane.
IG3: organisations with security specialists and regulatory oversight add 6.8, formal role-based access control with recurring reviews.

CIS released v8.1 in June 2024. It added a Governance security function, revised the asset classes, clarified some Safeguard descriptions and realigned mappings to NIST CSF 2.0, but did not change any Implementation Group assignments. The Safeguard numbers and titles below are the same in v8 and v8.1; if you report asset classes or security functions, take them from the v8.1 spreadsheet published by CIS, because those fields changed.

Structure and key requirements

The table summarises each Safeguard as written in the CIS Controls and its assessment specification, with the cadence where CIS sets one.

Safeguard	Title	IG	What it requires
6.1	Establish an Access Granting Process	IG1, IG2, IG3	A followed process, preferably automated, for granting access on new hire, rights grant or role change
6.2	Establish an Access Revoking Process	IG1, IG2, IG3	A followed process, preferably automated, that disables accounts immediately on termination, rights revocation or role change; disabling rather than deleting may be needed to keep audit trails
6.3	Require MFA for Externally-Exposed Applications	IG1, IG2, IG3	MFA on all externally exposed enterprise and third-party applications, where supported; enforcing it through a directory or SSO provider counts
6.4	Require MFA for Remote Network Access	IG1, IG2, IG3	MFA for every form of remote network access
6.5	Require MFA for Administrative Access	IG1, IG2, IG3	MFA for all administrative accounts, where supported, on all enterprise assets, on-site or run by a third party
6.6	Establish and Maintain an Inventory of Authentication and Authorization Systems	IG2, IG3	An inventory of authentication and authorisation systems, on-site and at service providers, reviewed at least annually
6.7	Centralize Access Control	IG2, IG3	Access control for all enterprise assets through a directory service or SSO provider, where supported
6.8	Define and Maintain Role-Based Access Control	IG3	Documented access rights per role, plus access control reviews at least annually to confirm every privilege is authorised

Reading the Safeguards carefully

"Where supported" is not a blanket exemption: 6.3 and 6.5 apply where the application or asset supports MFA. If it does not, the CIS approach is to put it behind something that does (an SSO-enforced proxy, a privileged access workstation or a PAM gateway) or record an exception with a compensating control. An unsupported legacy admin console with no exception record is a finding.
6.3 includes third-party applications: SaaS used by the business counts, not only applications you host. Shadow SaaS signed up with a corporate email and a password is a direct gap.
6.4 is about the path, not the user type: VPN, VDI, remote desktop gateways, bastion hosts and vendor remote support tools all count as remote network access.
6.5 covers every administrative account: domain and cloud admins, hypervisor and network device admin accounts, SaaS tenant admins and accounts at a managed service provider that administer your assets.
6.2 says "immediately": the assessment specification checks that the revocation process covers termination, rights revocation and role change. Movers are the case most processes miss.

Identity and NHI requirements

Control 6 is an identity control, and the CIS overview names service accounts explicitly. The Safeguards were written mainly with people in mind, so interpreting them for non-human identities takes some care.

Safeguard	How it applies to non-human identities	Practical control
6.1 Granting	Service accounts, app registrations, API keys and CI/CD credentials need a requester, an owner and an approved purpose before creation	Request workflow that records owner and scope; no console-created credentials outside it. See the Service Account Inventory Template.
6.2 Revoking	When an application is retired or an owner leaves, its credentials must be disabled; a human leaver's personal tokens and OAuth grants must be revoked	Decommissioning step in change management; token and grant revocation in the leaver runbook. See the OWASP NHI Top 10 NHI1 Improper Offboarding Guide.
6.3 to 6.5 MFA	An NHI cannot complete interactive MFA; the equivalent is strong, non-replayable authentication and no interactive sign-in	Workload identity federation, certificates or managed identities instead of static secrets; block interactive logon for service accounts. See the OWASP NHI Top 10 NHI4 Insecure Authentication Guide.
6.5 Admin MFA	Service accounts with admin rights are the usual way round admin MFA; humans sharing them breaks accountability	Vault the credential, restrict source hosts, alert on interactive use. See the OWASP NHI Top 10 NHI10 Human Use of NHI Guide.
6.6 Inventory	Secrets managers, cloud IAM, Kubernetes RBAC, token services and CI/CD OIDC trust are authentication and authorisation systems	Include them in the 6.6 inventory, not only the IdP and directory
6.8 RBAC	NHI permissions drift upwards because nobody reviews them	Include NHIs in the annual access review with owner attestation. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.

Two points are worth stating in your control narrative. First, record how you treat service accounts under 6.5: assessors increasingly ask, and "MFA not supported" without a compensating control is a weak answer. Second, the strength of MFA matters even though CIS does not grade it. NIST SP 800-63B-4 states that OTPs and out-of-band authenticators are not phishing resistant and requires verifiers at AAL2 to offer at least one phishing-resistant option, so push and SMS MFA should be treated as an interim state for administrators. See the Phishing-Resistant MFA Guide.

Implementation steps

The order below closes the highest-risk gaps first and builds the inventory that later Safeguards depend on.

Baseline from Control 5 (weeks 1 to 2): export accounts from every directory, IdP, cloud tenant and key SaaS application. Tag each as human, administrative, service or shared. Without this list you cannot measure 6.3 to 6.5 coverage.
Close administrative MFA (6.5) first (weeks 2 to 6): enforce MFA on cloud admin roles, identity provider admins, domain admins, hypervisor and backup consoles. Use conditional access or equivalent policies scoped to admin roles, start in report-only or audit mode for a week to find breakage, then enforce. Keep two break-glass accounts excluded, with long random passwords or hardware keys stored offline and alerting on every use. See the Break-Glass Account Guide.
Remote access (6.4) (weeks 2 to 6, in parallel): list every VPN, VDI, remote desktop gateway and vendor remote support tool, including ones run by suppliers. Enforce MFA at the gateway, disable password-only fallbacks and legacy protocols that bypass it. See the VPN Security Guide.
External applications (6.3) (weeks 4 to 12): from the Control 2 software inventory, list internet-facing and SaaS applications. Move each behind SSO with MFA enforced at the IdP; where SSO is not possible, enable native MFA. Disable legacy authentication protocols that skip MFA, such as basic authentication on mail protocols. Track exceptions with an owner and expiry.
Write down and automate granting and revoking (6.1, 6.2): drive provisioning from the HR system through the IdP or IGA tool, with SCIM to applications that support it. Define the mover trigger explicitly. Test revocation with a real leaver each quarter: confirm accounts are disabled, sessions are revoked and personal tokens are removed. See the Joiner-Mover-Leaver Guide.
Inventory authentication and authorisation systems (6.6, IG2): record each IdP, directory, PAM tool, secrets manager, certificate authority, cloud IAM plane and application with local authentication, with owner, hosting location and whether it federates. Review it at least annually.
Centralise (6.7, IG2): use the 6.6 inventory to push remaining local-login applications and infrastructure onto the directory or SSO. Disable local accounts where the application allows, or vault them as emergency access. See the Identity Provider and SSO Security Guide.
Role-based access (6.8, IG3): define roles per job family from current entitlements, document the access each role needs, then run at least an annual review in which owners confirm every privilege. Start with privileged and sensitive-data roles. See the Role Mining and Role Design Guide.

Rollback: keep MFA and SSO policy changes in version-controlled configuration where the platform allows, roll out by group (IT first, then pilot users, then everyone), and keep break-glass access tested so that a misconfigured policy cannot lock administrators out.

Small versus large organisations

Small (IG1): a single cloud IdP with security defaults or an equivalent baseline, MFA enforced for everyone, admin roles separated from daily accounts, and a written leaver checklist is often enough to meet 6.1 to 6.5.
Large (IG2/IG3): the hard parts are coverage and drift: hundreds of applications, several IdPs after acquisitions, supplier accounts and NHIs. Invest in IGA for 6.1, 6.2 and 6.8 and use the 6.6 inventory to retire duplicate identity stores.

Evidence and assessment

The CIS Controls Assessment Specification defines inputs, operations and measures for each Safeguard. Assessors working from it, or from the CIS Controls Self Assessment Tool (CSAT), look for counts and dates rather than statements.

Safeguard	Evidence an assessor expects	Measure to report
6.1	Documented granting process covering new hire, rights grant and role change; sample tickets or IGA records with approvals	Share of sampled grants with approval recorded
6.2	Documented revocation process covering termination, revocation and role change; HR leaver list reconciled with disabled accounts	Median time from HR termination to account disable
6.3	List of externally exposed and third-party applications; per-application MFA or SSO enforcement evidence; exception register	Accounts on exposed applications with and without MFA
6.4	List of remote access services; gateway configuration showing MFA required; no password-only path	Remote access assets enforcing MFA versus total
6.5	Admin account list; policy export showing MFA on admin roles; break-glass justification	Admin accounts configured to require MFA versus not
6.6	Inventory of authentication and authorisation systems with last review date	Months since last review (target 12 or fewer)
6.7	Mapping of assets to directory or SSO; list of assets with local-only authentication	Assets covered by at least one directory or SSO service
6.8	Role definitions; evidence each account has a role or group; last access review sign-off	Accounts with an assigned role; months since last review

Monitoring and KPIs

Admin MFA coverage: percentage of administrative accounts with enforced MFA (target 100 per cent, with named break-glass exceptions).
Remote and external MFA coverage: percentage of remote access services and externally exposed applications enforcing MFA.
Leaver latency: median and 95th percentile hours between HR termination and account disable, including SaaS outside SCIM.
SSO coverage: percentage of applications in the software inventory authenticating through the central IdP.
Review completion: percentage of entitlements reviewed in the last 12 months, and percentage revoked as a result (a revocation rate near zero suggests rubber-stamping).

For detection, alert on sign-ins that bypass MFA (legacy protocols, excluded locations), MFA method changes on admin accounts, repeated MFA prompts that indicate push fatigue (ATT&CK T1621), and interactive sign-ins by service accounts. Valid account abuse (T1078) and external remote services (T1133) are the techniques this Control most directly reduces. See the ITDR Guide.

Mapping to other frameworks

Safeguards	NIST CSF 2.0	NIST SP 800-53 Rev 5	ISO/IEC 27001:2022 Annex A	ATT&CK techniques reduced
6.1, 6.2	PR.AA-01, PR.AA-05	AC-2, AC-2(3)	A.5.16 Identity management, A.5.18 Access rights	T1078 Valid Accounts
6.3, 6.5	PR.AA-03	IA-2, IA-2(1), IA-2(2)	A.8.5 Secure authentication, A.8.2 Privileged access rights	T1078.004 Cloud Accounts, T1110 Brute Force
6.4	PR.AA-03	AC-17, IA-2(1), IA-2(2)	A.8.5 Secure authentication	T1133 External Remote Services
6.6, 6.7	PR.AA-01	IA-5, AC-2	A.5.15 Access control, A.5.17 Authentication information	T1078
6.8	PR.AA-05	AC-3, AC-5, AC-6, AC-6(5)	A.5.15 Access control, A.5.18 Access rights	T1078, T1068 Exploitation for Privilege Escalation (impact limited)

CIS publishes official mappings to CSF 2.0 and other frameworks with v8.1; use those for formal crosswalks and treat this table as a working guide. For least privilege and separation of duties beyond 6.8, see the Segregation of Duties Guide and the Privileged Access Management Guide.

Common pitfalls

MFA on paper, password at the gateway: the policy says MFA everywhere, but one remote access portal was never migrated. The Change Healthcare breach began with a stolen credential on a Citrix remote access portal that did not have MFA, exactly the gap Safeguard 6.4 exists to close.
Counting the IdP, forgetting the bypasses: MFA is enforced in the IdP, but legacy authentication, local application accounts or API endpoints still accept a password. Assess 6.3 by trying the alternative paths, not by reading the IdP policy.
Service accounts used as admin back doors: admin MFA is enforced for people, so engineers log in with a privileged service account instead. This defeats 6.5 and leaves no individual accountability.
Disabling the account but not the access: the leaver's directory account is disabled, but SaaS local accounts, personal access tokens, OAuth grants and SSH keys keep working. See the Employee Offboarding Security Guide.
Exceptions without expiry: "MFA not supported" exceptions granted for a migration never close. Every exception needs an owner, a compensating control and a review date.
Rubber-stamp reviews: 6.8 reviews are completed on time with a near-zero revocation rate, because reviewers see entitlement names they cannot interpret. Give reviewers context (last used, role, sensitivity) and review high-risk access more often than annually. See the Access Reviews Guide.

Practitioner checklist

Confirm your target Implementation Group and record which Control 6 Safeguards apply.
Export every administrative account across directories, cloud tenants, SaaS and infrastructure, and prove MFA is enforced on each (6.5).
List every remote access path, including supplier tools, and remove password-only fallbacks (6.4).
Reconcile the software inventory against SSO and MFA enforcement for exposed and third-party applications (6.3).
Run a revocation test on a real leaver and a mover, covering sessions, tokens and OAuth grants (6.2).
Document how service accounts meet the intent of 6.3 to 6.5: no interactive sign-in, vaulted or federated credentials, named owner.
Build and date the authentication and authorisation system inventory, including secrets managers and cloud IAM (6.6).
Track SSO coverage and set a date to retire local-only authentication (6.7).
Define roles for privileged and sensitive-data access first, then run and evidence an annual review (6.8).
Keep an exception register with owner, compensating control and expiry for every "where supported" gap.

CIS Control 6 Access Control Management Guide: Safeguards, Implementation Groups and Evidence