by Heath Gieson

Every device you deploy and every application you install arrives configured for ease of use, not security.

When was the last time someone examined the configuration of your network switch? What about the network-connected printer that has been sitting in the corner for the last ten years? These are not edge cases. They are the rule. Devices like these get deployed, forgotten, and left running on whatever configuration they shipped with. They rarely appear on anyone’s security radar until something goes wrong.

Default passwords, open ports, unnecessary services running in the background, these are features from the manufacturer’s perspective. From a security perspective, they are open doors. CIS Controls 4.1 and 4.2 are about closing those doors deliberately, documenting your decisions, and making sure configuration drift does not quietly undo your work.

 

What These Controls Actually Require 

CIS 4.1 requires a documented secure configuration process for all enterprise assets, workstations, servers, mobile devices, IoT, and the software running on all of them. CIS 4.2 applies that same discipline specifically to network infrastructure: firewalls, switches, routers, and wireless controllers.

The requirement for both is the same. Document what a secure configuration looks like for your environment, apply it, and review it at least annually or after any significant change.

That word documented is doing a lot of heavy lifting. The intent is not just to configure things correctly once. It is to make a formal, written decision about what “correct” looks like, and then measure against it consistently.

The CIS Benchmarks are the natural starting point. They provide consensus-based configuration recommendations for more than 25 vendor product families, covering Windows, macOS, Microsoft 365, cloud platforms, and network devices from vendors like Fortinet, Cisco, Palo Alto, and others. For most small and mid-sized businesses, the Level 1 benchmark is the right place to start.

It is also worth noting that both 4.1 and 4.2 fall under the NIST CSF function of Govern, not Protect. This is an organizational decision about your security posture, not just a technical task. It requires leadership buy-in and a review cadence treated with the same seriousness as your financial controls.

 

The Configuration Drift Problem 

This is where most organizations quietly fail, even the ones that start strong.

Configuration drift happens when the gap between your documented baseline and your actual environment slowly widens. A software update here, a setting tweaked to resolve an urgent ticket there, a new device added without following the standard. None of it is malicious. None of it gets documented. Over time, your environment drifts away from the secure state you intended and you lose visibility into how far it has traveled.

The fix is not complicated. All configuration changes need to go through a lightweight change management process so there is a record that can be reviewed, referenced during an incident, or used to support an audit. Pair that with RMM tooling configured to alert on deviations from your baseline, and you have something genuinely valuable: visibility into the gap between where you are and where you are supposed to be.

Network devices deserve special attention here. Endpoints get replaced on a regular cycle. Firewalls and switches often sit in place for years, configured once and rarely revisited. Firmware goes unpatched. Default credentials go unchanged. Access control lists accumulate exceptions nobody can explain anymore. A firewall running on a stale, undocumented configuration is not a security control. It is a false sense of security.

 

CIS 4.1 & 4.2 Implementation Checklist 

Foundation

• Confirm your asset inventory (CIS Controls 1 & 2) is current and complete
• Identify all assets in scope: workstations, servers, mobile devices, IoT, software applications, firewalls, switches, routers, and wireless controllers
• Assign a named owner for each asset category’s configuration standard

Building Your Baseline

• Download the applicable CIS Benchmark(s) for your endpoint and server platforms
• Download the applicable CIS Benchmark(s) for your network infrastructure
• Select Level 1 as your starting baseline
• Document any approved deviations with a written business justification for each

Documentation

• Create a formal Secure Configuration Standard for each asset category
• Store standards in your centralized IT documentation platform with a named owner and last-reviewed date
• Store backup copies of current network device configurations, updated after every approved change

Enforcement

• Apply the documented baseline to all in-scope endpoints and network devices
• Use your RMM platform or Microsoft Intune to push and enforce endpoint policy settings
• Replace default vendor credentials on all network devices with organization-managed credentials
• Validate that all new devices are provisioned to the approved baseline before going into service

Drift Detection & Change Management

• Configure your RMM or endpoint management tool to alert on baseline deviations
• Implement a change management process: all configuration changes documented and approved before implementation
• Log all changes with a timestamp, description, and the name of the person who made them
• Include network device firmware in your patch management process

Annual Review

• Schedule your annual review and put it on the calendar
• Compare your documented baselines against the current CIS Benchmark versions
• Revisit all approved deviations and confirm they are still justified
• Update documentation to reflect any changes made during the review

 

Where to Start 

If you do not have a documented configuration standard today, the goal is not perfection. The goal is to begin.

Pick your most critical platforms, pull the relevant CIS Benchmark, and build your first baseline from Level 1. Document your deviations honestly. Store it somewhere accessible and assign it an owner. Then build the review into your calendar so it actually happens.

Misconfigurations are consistently one of the leading causes of security incidents. Not sophisticated exploits or advanced persistent threats. Open ports, default credentials, and undocumented changes that nobody caught. The organizations that take 4.1 and 4.2 seriously are not just checking a compliance box. They are removing the low-hanging fruit that attackers count on finding.

Secure by design is a choice. These two controls give you the framework to make that choice consistently and defend it when it matters.

 

At Forthright Technology Partners, we help organizations build and maintain secure configuration standards across their endpoint and network environments. If you are not sure where your configurations stand today, that is exactly the right place to start the conversation.