Security misconfiguration: What it is and how to catch it when it returns

Teams harden their systems against a benchmark, close the unused ports, turn on logging, and pass the review. Then a patch resets a setting, an engineer opens a firewall rule at 2 a.m. to fix an outage and never closes it, and a new server gets built from an older image. A few months later, the environment looks nothing like the one that was approved.

That's security misconfiguration. OWASP ranked it fifth in 2021 and second in 2025, and it keeps climbing because you can patch every known vulnerability and still leave the door open with a setting nobody remembered to change.

Security misconfiguration: A setting that's wrong, missing, or left at default

Security misconfiguration is a weakness caused by settings that are missing, incorrect, or left at insecure defaults. The software works as designed. The way it's set up exposes it.

A vulnerability is a flaw in the code, and the vendor fixes it with a patch. A misconfiguration comes from a decision, or the lack of one, in how a system was deployed or changed. The fix is a settings change, and it's your team's job to make it and keep it in place.

Misconfigurations can sit in operating systems, databases, web servers, cloud platforms, network devices, and applications. They often go unnoticed because nothing breaks and the system keeps running.

Security misconfiguration examples on servers, in the cloud, and on network devices

Many of these come down to a single line in a config file. Here's what drift looks like in two common ones.

      # /etc/ssh/sshd_config 

 

# Drifted 

PermitRootLogin yes 

PasswordAuthentication yes 

 

# Hardened 

PermitRootLogin no 

PasswordAuthentication no 
      

      # nginx.conf 

 

# Drifted 

autoindex on;        # directory listings exposed 

server_tokens on;    # version number in every response 

 

# Hardened 

autoindex off; 

server_tokens off; 
      

Both drifted versions run fine, which is why nobody notices them. Change Tracker's file contents tracking can watch config files like these and flag the moment a value changes.

Most of these take only a settings change to fix. Finding them across a large estate is the slow part.

Misconfigurations keep coming back after hardening

Setup mistakes do happen, and so do changes made after setup. The technical term for the second kind is configuration drift: the gradual movement of a system away from its approved, hardened state.

Patches and updates change settings as a side effect. Emergency fixes get made outside the normal process because the business can't wait. Systems that were supposed to be identical get built at different times by different people. When something does change, there's often no clean record of who changed it, when, or why.

That's why a one-time audit falls short. It shows your systems as they stood on the day you checked, and drift can begin the next day. Teams that review quarterly or annually are always working from a snapshot that's already old.

What a misconfigured system costs you

A misconfigured system gives an attacker an easier way in and gives an auditor a finding. Both cost time and money.

Misconfigurations can expose data, widen the access an attacker gets once inside, and make an intrusion harder to spot because logging wasn't set up to catch it. A bad setting can also cause an outage, and tracking down the cause eats hours when nobody can say what changed. Frameworks like PCI DSS, NIST 800-53, and HIPAA expect organizations to maintain secure configuration standards and show evidence that systems still match them. A drifted system fails that test even if nothing bad has happened yet.

Finding and fixing security misconfiguration in four steps

1. Start with a standard. You can't find a misconfiguration without something to measure against. Most organizations begin with an industry benchmark such as the CIS Benchmarks or DISA STIG and adjust it for their environment. Some build their own standard from a system they've already hardened and trust.
2. Assess every system against it. Check servers, databases, cloud accounts, and network devices against the benchmark and score the results. You end up with a list of what's out of line, ranked by how much it matters.
3. Fix what you find. Start with the highest risk. Where a deviation is intentional, document it as an approved exception so it doesn't come back as a false alarm.
4. Monitor changes. After remediation, the environment keeps changing. Continuous monitoring tells you when a system moves away from its approved state, so you fix a drifted setting in hours instead of finding it at the next audit.

Detection without context turns into alert noise

After teams add monitoring, the alerts start rolling in. Every patch, maintenance window, and approved update can generate change events, and across hundreds of devices a team can’t tell the routine changes from the risky one.

A change to a configuration file is only a problem if it wasn't supposed to happen. Telling the difference means comparing what changed against what was approved.

Closed-loop change control does that comparison. Approved changes are recorded as planned changes, either by connecting to the IT service management system where requests already live or by defining them directly. When a change shows up on a system, it's checked against the plan. A match gets classified as planned and stays out of the way. Anything else is flagged as unplanned, and that short list is what the team investigates.

Meet Netwrix Change Tracker

Netwrix Change Tracker benchmarks systems against a known standard, catches drift as it happens, and separates planned changes from unplanned ones.

For assessment, Change Tracker includes compliance reports based on the CIS Benchmarks, and Netwrix is a CIS Certified Vendor. Reports cover Windows, Linux, Unix, databases, network devices, VMware ESXi, and cloud platforms including Azure, AWS, GCP, and Microsoft 365. If your organization has its own build standard, any device can serve as a baseline source, so you can define a gold build from a system you trust and measure the rest against it.

For monitoring, it tracks files, folders, and file contents, plus processes, services, and open network ports. On Windows, it also tracks registry settings, installed software, local accounts, and security and audit policy. Collection works with or without an agent, which matters in environments that mix servers, appliances, and devices where you can't install software. Every change is recorded with what changed and when, so you build a searchable history for when something goes wrong.

For change control, it compares detected changes against planned ones. It integrates with ITSM platforms including ServiceNow, BMC Remedy, Cherwell, ManageEngine ServiceDesk Plus, and OpenText Service Management, so approved requests become planned changes automatically. Unplanned changes can raise an incident in ServiceNow, which puts the investigation in front of the person who owns the system.

You get a security configuration you can verify at any time, and a clear answer when someone asks what changed.