The Center for Internet Security (CIS) Controls emphasize protecting the most critical aspects of your IT environment, and Control 6.5 focuses on securing administrative access accounts with Multi-Factor Authentication (MFA).

This safeguard is clear: require MFA for all administrative access accounts across your enterprise assets, whether they’re managed on-site or through a third-party provider. Why? Because administrative accounts have the highest level of privileges and are a prime target for attackers.

Here’s what this means:

• What’s an Administrative Account? These are accounts with elevated permissions, such as IT administrators, database managers, or system operators. They can install software, manage users, and modify critical systems.
• Why MFA? MFA adds a critical second layer of protection, making it much harder for attackers to exploit compromised admin credentials.
• Where It Applies: This safeguard covers all enterprise assets, from servers and workstations to cloud services and third-party platforms. If MFA is supported, it should be enforced.
• How to Implement: Most modern directory services and identity providers, like Microsoft Azure AD, Okta, or Duo Security, make it straightforward to apply MFA policies specifically for administrative accounts.

Why is this important? Admin accounts hold the keys to the kingdom. A breach of one of these accounts can lead to widespread damage. Requiring MFA significantly reduces the risk of such incidents by ensuring that access is tightly secured.

To recap, CIS Control 6.5 ensures that all administrative access is protected by MFA. By implementing this safeguard, you’re adding a robust layer of security to the most critical accounts in your organization.

The Center for Internet Security (CIS) Controls continue to set the standard for strengthening cybersecurity, and Control 6.3 is a cornerstone of protecting your organization's external-facing applications.

This safeguard is straightforward: require Multi-Factor Authentication (MFA) for all externally-exposed enterprise or third-party applications. Why? Because MFA is one of the most effective defenses against unauthorized access.

Here’s how it works:

• Externally-Exposed Applications: These are applications accessible from outside your organization’s network—think cloud services, web apps, or third-party tools.
• MFA Enforcement: MFA adds an extra layer of protection beyond just a username and password, such as requiring a code from a mobile app or biometric verification.
• How to Implement: Many organizations already have this covered if they use a directory service like Microsoft Azure AD, Okta, or another Single Sign-On (SSO) provider. These platforms make it simple to enforce MFA for all supported applications.

Why is this so important? External-facing applications are often the first target for attackers, and weak or stolen passwords are a common entry point. Requiring MFA significantly reduces the risk of unauthorized access, even if credentials are compromised.

To recap, Control 6.3 is all about securing the front door to your organization’s external systems. By enabling MFA across your externally-exposed applications, you can ensure that your security posture is strong and that users accessing your systems are who they claim to be.

The Center for Internet Security (CIS) Controls are a trusted framework for helping organizations improve their cybersecurity posture, and Control 6.2 is no exception.

Safeguard 6.2 highlights the importance of having a well-defined, preferably automated, process for revoking access to enterprise assets. While it sounds simple, this safeguard is crucial for reducing the risk of unauthorized access, especially during sensitive transitions like terminations or role changes.

Here’s what it means in practice:

• Immediate Action: The process ensures that accounts are disabled immediately upon an employee's termination, preventing lingering access.
• Rights Revocation: When a user’s access requirements change—whether due to role changes or specific rights no longer being needed—those permissions should be promptly revoked.
• Audit Preservation: Instead of deleting accounts outright, accounts should be disabled to maintain critical audit trails for forensic and compliance purposes.

If you’re using tools like Microsoft Active Directory (on-premises or Azure AD), Okta, or other Identity and Access Management (IAM) systems, automating this process is likely already within your reach. Integration with your HR system can further streamline access revocation during terminations or role transitions.

Why does this matter? Delayed or inconsistent access revocation is a major security risk. Former employees or users with unnecessary privileges could inadvertently or maliciously access sensitive systems. Automating this process reduces that risk, ensures compliance, and gives your organization peace of mind.

To recap, CIS Control 6.2 is all about ensuring you have a reliable and efficient process to revoke access immediately and effectively. Whether it’s due to termination, rights revocation, or a role change, the safeguard ensures that only the right people maintain access to enterprise assets while preserving your audit trails.

Safeguard 6.1 focuses on the critical need for an Access Granting Process and is an integral part of user access management. While this might sound straightforward, the safeguard is essential for ensuring that enterprise assets are protected and that access is only granted to the right people at the right time.

So, what does it involve? Safeguard 6.1 requires organizations to establish and follow a defined process, preferably automated, for granting access whenever a new hire joins, an employee's role changes, or additional rights are required. Automation plays a key role here—it reduces the risk of manual errors, ensures consistency, and simplifies the auditing process.

Let’s break it down:

• New Hires: When onboarding a new employee, the process ensures they are only granted access to the assets and systems required for their role.
• Rights Granting: If an employee needs additional privileges (e.g., temporary administrative access), the process ensures this is documented and monitored.
• Role Changes: For promotions, transfers, or job changes, access rights are updated accordingly—removing what’s no longer needed and adding new permissions where required.

The key is centralizing this process within your Identity and Access Management (IAM) platform, whether you’re using tools like Microsoft Azure Active Directory, Okta, or another IAM solution. Coupling this with Single Sign-On (SSO) and Role-Based Access Control (RBAC) ensures that employees only have access to what’s necessary, no more, no less.

To recap, CIS Control 6.1 is about establishing a streamlined, auditable, and efficient process for granting access—keeping your enterprise secure while empowering your employees to work effectively.

Center for Internet Security Controls or CISControls have become an industry standard to help businesses and organizations of all sizes maintain a best practice standard of Cybersecurity controls.

Safeguard 5.6 wraps up Account Management and while it's only required as part of Implementation Groups 2 and 3, this is something you likely already have in place - in fact I would probably bet that you have it in place today.

Safeguards 5.1 and 5.5 hit the inventory aspect where you need to know what you have to secure from users, admins, and any service accounts. Safeguard 5.6 simply requires you to "Centralize Account Management". Wait that's it?

Yes, that's it. So if you have a local Microsoft Windows Domain (AD) or Microsoft Azure AD (AAD), or even a Red Hat Linux Domain then you have the centralized account management. Really the only way you don't have this is if you are still using POP3 and Workgroups - that's so 1990 of you.

As more companies migrate to cloud services the need for Identity Access Management (IAM is critical. Your account management should be where your base infrastructure is, locally or in the cloud. From there tie in Single Sign On (SSO) wherever you can and let your employees enjoy the freedom of only having to remember 1 credential.

So to recap, Control 5, if you are running EntraID or a local domain, with maybe just a little house cleaning you can check off 5.1, 5.3, 5.4, and 5.6. 5.2 and 5.5 may require a little more work depending on your business and how you willingness to split your administrative access from your standard account.

Center for Internet Security Controls or CISControls for short have become an industry standard to help businesses and organizations of all sizes maintain a best practice standard of Cybersecurity controls.

Safeguard 5.5 is similar to 5.1 where it calls for an inventory of accounts, but 5.5 specifically requires the inventory of your service accounts. At minimum it must contain the department owner, review date, and purpose. You should also perform service account reviews to validate that all active accounts are authorized on a recurring schedule at least quarterly.

We covered this in 5.1 where every account that can successfully login should be inventoried and 5.5 doesn't change that. It does however require you to to store different data as with 5.1 you have to store the person's name, username, start and stop dates, and department - 5.5 requires the department owner, review date, and the purpose of the service account. Which is enough for it to be called out separately.

Safeguard 5.5 is also only required if you are seeking implementation group 2 or 3 status - but let's be honest this is a requirement for everyone. You want to know everyone that has keys to your house, why wouldn't you want to have an inventory of everyone that has access to your data.

Active Directory counts as an inventory tool as it maintains the records and you can add notes or custom attributes to cover the requirements here. This is where having SSO setup can also help you where you are forcing a single sign on inventory platform, so you know all of these systems are using my AD or AAD (EntraID) platform.

You have it done, it's just making sure you check the sub boxes here is where most of us will fall short - and it's great practice to start doing that today. So review your service accounts and document the department owner, today's date (last review date), and the purpose of the account.

Then check off 5.5 and you're already well into your process of hitting IG2 compliant.

Center for Internet Security Controls or CISControls for short have become an industry standard to help businesses and organizations of all sizes maintain a best practice standard of Cyber security controls.

Safeguard 5.4 requires that you RESTRICT administrator privileges to dedicated administrator accounts. Yes! General computing activities such as web browsing, email, Microsoft office suite, gaming, etc should be done as a non-administrator.

One thing that is still common today is IT people love the power, and they don't like having to log off and log back on as their YOURNAME_Admin account to get it. It slows us down, It makes me less productive, I can't do my job without the elevated rights.

Let's get real. You can't be secure if you are not taking the time to even secure your own usage. Out of the 8 hour work day, maybe 30 minutes (on most days) you need to be elevated. Outside of that, it's not needed.

Everyone that should have administrative level rights, including domain admins, enterprise admins, global admins, and admin level rights to your SaaS apps - have two different credentials.

I commonly see the appending 'admin' to the username to designate the difference for the end user. Hackers know this as well. So ensuring MFA or long passwords is a must (remember 5.2).

This one isn't rocket science but it is required for Implementation Groups 1, 2, and 3 so this is something we all have to improve with, and the biggest obstacle in our way is ourselves.

Let's explore Center for Internet Security Controls or CISControls, which have become an industry standard to help businesses and organizations of all sizes maintain a best practice standard of Cybersecurity controls.

Safeguard 5.3 requires the deletion or disabling of any dormant accounts after a period of 45 days of inactivity, where supported.

When you have a user leave the company, you should be disabling, resetting the credentials, or removing the account immediately and with some cloud services a user may be able to reset credentials with multiple verification methods that you may not have control over, so disabling or removing the account should be the preferred practice.

Here you are typically looking at accounts that were setup for a vendor or service account that has been decommissioned and the account was forgotten in the process. So 5.3 while is viable if you're not removing standard user accounts, it's intent is to ensure those other accounts are disabled or deleted timely.

Over the years I have seen "legacy" accounts maintained for access to files, a specific application, or e-mail.

When you decommission a user the files should be migrated to the user replacing them or their manager.

Users should not be logging in with other user accounts to access an application, if you have issues getting the application working for another user account then contacting the application vendor's support team is your best next step.

Finally, I love using e-mail compliance backup tools like Barracuda's E-mail Archiver. I know all of the email is retained and can give another user access to it there and the user account and mailbox can go away. Even if a new e-mail comes in and can't be delivered, archiver will still archive it.

There are products and processes that are readily available that eliminate any argument your users would have on why you can't "remove" access to another user account.

Here I use the service Liongard which monitors most of the services including EntraID and Active Directory for unused or those dormant accounts.

All you need to do here is have the policy that outlines how you identify and handle dormant accounts, be prepared with logs or an auditing tool that shows that you actually follow the policy if you ever need to prove it. The last thing you want is an active dormant account used to breach your network.