Common Security Misconfigurations: The CISA and NSA Top 10

Common security misconfigurations are not obscure mistakes. They are ordinary settings that give attackers a shorter path from discovery to control.

Teams often review each setting alone. One default account looks low priority. One flat network segment looks like architecture debt. One missing log source becomes a backlog item. An attacker sees a chain: enter through the default, move across the flat network, take the shared administrator account, and operate where nobody is watching.

The right unit of work is the attack path, not the count of failed checks. This guide uses the ten failures identified by CISA and NSA, then adds the evidence, ownership, and action order most summaries leave out.

What are common security misconfigurations?

A security misconfiguration is an unsafe system, application, identity, cloud, or network setting. It may come from a weak default, a manual change, a missing hardening step, a failed deployment, or an exception that outlived its reason. Unlike a software defect, the dangerous behavior can often be removed by changing state rather than replacing code.

In their October 5, 2023 joint advisory on the top ten cybersecurity misconfigurations, CISA and NSA drew from red team and blue team assessments, hunt work, and incident response. The list matters because it reflects repeated access paths in large organizations, not a theoretical control catalog.

The 2025 OWASP Security Misconfiguration category moved from fifth to second. OWASP reports 719,084 occurrences across 16 mapped weakness types and 1,375 CVEs, with an average incidence rate of 3.00 percent. Every application in the contributed test data had some form of misconfiguration. That is application data, not a universal fleet rate, but it shows the problem is not rare.

What are the ten common security misconfigurations from CISA and NSA?

1. Default configurations of software and applications

Defaults favor installation and compatibility. They may leave sample apps, old protocols, open management interfaces, vendor accounts, or broad permissions enabled. Inventory every default that creates access or data exposure. Replace it through the build path, then prove new systems receive the safer value.

2. Improper separation of user and administrator privilege

Daily work performed with administrator rights turns one stolen session into broad control. Separate accounts, restrict where privileged identities can log in, and record elevation. Check effective privilege, not just group membership in a directory that may be stale.

3. Insufficient internal network monitoring

Perimeter logs do not show an attacker moving between internal systems. Collect identity, process, service, name resolution, and network evidence around sensitive paths. A log source has value only when somebody knows what decision it supports and how long the evidence remains available.

4. Lack of network segmentation

Flat networks let one foothold reach systems with different owners and consequences. Segment administration, user, server, build, backup, and control networks according to needed flows. Test that denied paths are actually denied. A diagram is not enforcement evidence.

5. Poor patch management

Missing patches are sometimes treated as a separate vulnerability program, but deployment policy is configuration. Track product, version, support status, required restart, exception, and final state. Prioritize evidence of exploitation and local exposure instead of sorting only by severity.

6. Bypass of system access controls

Alternate protocols, local paths, legacy services, recovery interfaces, and direct resource URLs can route around the main control. Test the protected action from each reachable path. An identity policy does not help if an old management port still accepts a local password.

7. Weak or misconfigured multi factor authentication

Multi factor authentication can fail through optional enrollment, weak recovery, unprotected service accounts, push abuse, or legacy protocols that never invoke the control. Measure coverage by authentication path and account consequence. A tenant wide enabled flag is not enough.

8. Insufficient access control lists on network shares and services

Broad read access exposes secrets and internal data. Broad write access can turn a share into a path for code execution. Inspect effective access, inherited rules, anonymous paths, and service identities. Tie each exception to a business owner and expiry date.

9. Poor credential hygiene

Shared passwords, reused local administrator credentials, embedded secrets, long lived tokens, and credentials stored on network devices shorten the attack. Rotate exposed material, reduce scope, remove dormant credentials, and use distinct identities for machines and people.

10. Unrestricted code execution

If users, scripts, macros, interpreters, or downloaded binaries can execute without boundaries, prevention rests on every earlier control being perfect. Restrict execution by role and source, log command context, and test the business workflows that need exceptions. A block that operators must disable every day is not a working control.

Which security misconfiguration should you fix first?

Fix the shortest path to meaningful harm. Start with public exposure, default or weak credentials, privileged access, and routes into sensitive systems. Add evidence about active services, reachable paths, account use, data consequence, existing controls, and whether an attacker is already exploiting the condition.

Avoid a flat severity score for every failed setting. A missing header on a retired internal app and a default password on an internet facing appliance should not share a queue lane. The first may need planned maintenance. The second needs immediate containment and credential rotation.

Use the configuration drift operating guide when a safe setting changed after deployment. Use the drift and vulnerability risk analysis when the changed state affects the priority of an existing CVE.

What is the review cost of a misconfiguration scan?

Suppose 5,000 assets receive ten high value checks. That creates 50,000 evaluations. If two percent fail, the tool returns 1,000 findings. At six minutes per review, the first pass consumes 100 hours. That is before owners test a fix or schedule a change.

Group by cause and remediation action. If 720 failures came from one device policy that missed a business unit, create one owned deployment change with 720 verification targets. Keep every asset in the evidence set, but do not open 720 separate tickets.

How should teams test the ten misconfigurations?

Test one representative path for each claim. Attempt the default account from the management network. Confirm a normal user cannot perform an administrator action. Verify a denied network route from the source that matters. Exercise recovery and legacy authentication so multi factor coverage is not assumed from the main login page.

Use safe checks in production and reserve disruptive proof for an approved test environment. Record the command, identity, source, target, time, expected result, actual result, and cleanup. A scanner match without an outcome is evidence of a setting, not proof of the full attack path.

Retest after repair through a different observation path where possible. If a policy tool says it removed local administrator access, query effective membership or attempt the bounded action. If a firewall deployment reports success, test the route. Independent verification catches partial rollout and management tools that report intent instead of state.

What evidence proves a misconfiguration is real?

Capture observed value, effective value, collection time, system identity, system role, source authority, baseline version, recent change, exposure, and control outcome. A file value can differ from the effective runtime value. A group membership can differ from the token an active session already holds.

Write the claim precisely. “MFA disabled” is vague. “Privileged account can authenticate to the public VPN with password only through a legacy protocol” tells an owner what to test and close. The proof should survive handoff without forcing the next person to repeat discovery.

What recent attacks show about configuration mistakes?

An August 27, 2025 joint advisory on compromised network devices documents state sponsored actors changing configurations, using unencrypted management protocols, and extracting device configuration data. In at least one case, a device stored a TACACS+ shared secret with reversible Cisco Type 7 obfuscation.

The advisory also gives a concrete Cisco IOS XE hardening pair for management access. The first command disables the HTTP server. The second enables HTTPS. Validate platform support and management reachability in a controlled change before use.

no ip http server
ip http secure-server

This is the development older list articles miss. Attackers are not just benefiting from unsafe settings. They are collecting and changing network configuration as part of long term access. Baseline comparison, configuration backup integrity, and unexpected change review belong beside hardening.

How often do configuration errors expose data?

The 2026 Verizon Data Breach Investigations Report records 1,757 incidents in its miscellaneous errors pattern, including 1,750 with confirmed data disclosure. Personal data appeared in 98 percent of those breaches. Verizon identifies misconfiguration and misdelivery as the primary error types.

Those numbers describe the report's dataset, not the probability that any one setting causes a breach. Use them to justify focused control on exposed data stores, publishing workflows, and access policy. Do not turn an industry count into a local risk score.

How do you prevent common security misconfigurations?

Begin with secure role based builds. Remove unnecessary services and defaults before deployment. Put the baseline in a versioned system, name the management authority, and test the effective state after installation. A golden image without a final state check is only an assumption.

Control urgent changes with an emergency path that is faster than improvisation. Require a reason, owner, evidence snapshot, expiry, and scheduled review. Then detect deviations continuously for controls that change exposure, privilege, and logging.

Build the full operating process with the configuration management security guide. Security should define the control intent. Platform teams should own deployment. Service owners should approve exceptions. Every repair should end with an independent observation of final state.

Frequently asked questions

What is the most dangerous security misconfiguration?

There is no universal winner. Public management access with default credentials is usually urgent because exposure, access, and privilege are already connected. Rank settings by reachable harm and current evidence.

Is a missing patch a misconfiguration?

The software flaw is a vulnerability. The decision to run an affected version, delay a restart, or exempt a system is configuration state. Treat patch deployment and its exceptions as part of configuration control.

Can a compliant baseline still contain misconfigurations?

Yes. A baseline can be stale, scoped to the wrong role, or approved before a safer vendor setting existed. Compliance proves comparison with a standard. It does not prove the standard is correct for the current system.

Should every misconfiguration create a security ticket?

No. Group instances by root cause, owner, and deployable fix. Preserve asset coverage and final verification, but create one action when one change can repair many systems.

Executive takeaway

Start with the connected path. Find public services, weak identity, excess privilege, broad access, and missing evidence on the same systems. Give each condition an owner and verified repair. Then fix the deployment path that created it. The goal is not a prettier compliance score. It is fewer cheap routes from discovery to control.