CIS Control 6: Access Control Management

DEEP DIVE

Examines least privilege and access control mechanisms. Updating to include a reference link to the comprehensive CIS Critical Security Controls v8 page.

Updated 4/12/2026cis, controls, access-control, least-privilege, v8

While CIS Control 5: Account Management establishes the inventory and lifecycle of the accounts themselves, CIS Control 6: Access Control Management focuses squarely on governing what those accounts are allowed to do. As a critical component of the CIS Critical Security Controls Version 8 framework, this control mandates the use of robust processes and tools to create, assign, manage, and revoke access credentials and privileges for all user, administrator, and service accounts across enterprise assets and software.

The core objective of Control 6 is to ensure that users only possess the minimal authorization required to perform their daily duties, thereby reducing the attack surface if an account is compromised.

Core Access Control Principles

To effectively implement Control 6, organizations must build their access models on several foundational security principles:

  • Role-Based Access Control (RBAC): Access should ideally be granted based on an enterprise role rather than individualized permissions. Developing consistent access rights for each role and assigning those roles to users is a recognized best practice.
  • Least Privilege: Accounts must operate with the absolute minimum access rights necessary to complete their tasks.
  • Need to Know: Access to sensitive data should be restricted strictly to those whose roles explicitly require it, particularly when dealing with privacy requirements.
  • Separation of Duties: Critical business and security operations should be divided among multiple roles to prevent a single user from having unchecked control over a sensitive process.

Managing the Access Lifecycle

Developing a comprehensive program for provisioning and de-provisioning access is essential. Access requirements fluctuate dynamically as employees are hired, change departments, or leave the organization.

Access Granting (Safeguard 6.1) Organizations must establish an active process—preferably automated through an Identity and Access Management (IAM) or directory service—for granting access upon new hire onboarding, specific rights grants, or a role change. Relying on automated provisioning reduces the human error associated with manual entitlement assignments.

Access Revocation and Privilege Creep (Safeguard 6.2) When a user terminates employment or changes roles, their previous access must be revoked immediately. A common edge case in enterprise environments is "privilege creep," where an employee moves to a new department and acquires new permissions but retains their old ones. Automated role-change triggers help mitigate this risk.

Crucially, when de-provisioning accounts, standard practice dictates disabling rather than deleting the account. Deleting an account strips the unique identifiers (like SIDs in Windows) from historical logs, effectively destroying the forensic trail. Disabling the account immediately halts access while preserving data necessary for CIS Control 8: Audit Log Management.

Multi-Factor Authentication (MFA) Strategy

Strong authentication is a heavy focus of Control 6, representing a critical defense against credential stuffing, phishing, and password spraying. The control explicitly mandates MFA across three critical boundaries:

Externally-Exposed Applications (Safeguard 6.3)

All enterprise or third-party applications exposed to the internet must enforce MFA where supported. Integrating applications into a centralized directory service or Single Sign-On (SSO) provider is the most effective and satisfactory implementation of this safeguard, as it centralizes MFA enforcement and simplifies the user experience.

Remote Network Access (Safeguard 6.4)

Any remote network access—such as VPNs, remote desktop gateways, or secure access service edge (SASE) solutions—must require MFA before granting access to the internal environment.

Administrative Access (Safeguard 6.5)

MFA should be universally enforced for all privileged or administrator accounts, regardless of whether the assets are managed on-site or hosted by a third-party provider. Because privileged accounts hold the "keys to the kingdom," the mechanisms used for their authentication require higher scrutiny.

Advanced MFA and Privileged Considerations Not all MFA is created equal. While sending a Short Messaging Service (SMS) one-time code or prompting a simple "push" alert (where the user just taps "Approve") is highly convenient, neither is recommended for privileged administrative access due to risks like SIM swapping and MFA fatigue attacks.

Instead, organizations should utilize:

  • Number-Generator Features: Time-based One-Time Password (TOTP) authenticator apps are significantly more secure than SMS.
  • Privileged Access Management (PAM): These tools broker access to high-level accounts, often requiring a one-time password to be "checked out" for a specific, time-boxed use.
  • Jump-Boxes and Out-of-Band Terminals: For system administration, administrators should not connect directly from their daily-driver workstations. Utilizing dedicated, hardened "jump-boxes" or out-of-band terminal connections provides an isolated environment for executing administrative tasks, drastically reducing the risk of a compromised standard user account pivoting into an administrative session.

Temporary and Exceptional Access

While RBAC handles the majority of access needs, there will always be edge cases requiring temporary or highly granular access (e.g., a vendor performing emergency maintenance or a developer needing temporary access to a production database). This should never be handled by permanently modifying a baseline role. Instead, processes should exist to grant temporary credentials that automatically expire, or to utilize a PAM tool that grants Just-In-Time (JIT) access that revokes itself after a predefined window.