Most security breaches in 2026 exploit a default that was wrong at install. The application that ships with a default admin password. The cloud service that ships with a public S3 bucket. The network device that ships with a default SNMP community string. The library that ships with a permissive CORS policy. The default was set by the vendor. The default was never reviewed by the operator. The default was wrong. The attacker found the default. The breach happened.
The defender who fixes the defaults fixes the breach. The defender who reviews every default setting on every new deployment prevents the breach that would have happened three years later when the wrong default met an attacker. The work is unglamorous. The work is mostly automation. The work pays off in the incidents that do not happen. Here is the field guide for what to look for in 2026, and how to fix it without slowing the business down.
The categories of bad default
Five categories, in roughly that order of frequency. First comes the authentication default: the application that ships with a default admin account (admin/admin, root/toor, postgres/postgres), the application that ships with password authentication enabled when SSO sits available, the application that ships with MFA disabled. The fix is to disable password authentication entirely in production, to require SSO, to require MFA, and to delete the default accounts at install. Second comes the network default: the cloud storage bucket that ships public, the database that ships with a public IP, the API that ships with no authentication. The fix is the cloud configuration baseline: no public storage, no public databases, all APIs require authentication, all network access goes through a known entry point. Third comes the encryption default: the TLS configuration that supports TLS 1.0, the cipher suite list that includes RC4, the certificate that ships self signed. The fix is the modern TLS profile, with the legacy versions disabled, the weak ciphers removed, and the certificate replaced with a properly issued one. Fourth comes the logging default: the application that ships with logging disabled, or with logging to a location no one monitors. The fix is to enable logging at install, route the logs to the SIEM, and have an alert on the first failure. Fifth comes the update default: the application that ships with auto update disabled, the library that ships with a known vulnerable version and no upgrade path. The fix is to enable auto update where it exists, and to maintain an upgrade plan for the rest.
How to do this without slowing the business
Three moves, in priority order. The first is to codify the secure default. The organisation should have a written baseline of what the secure default looks like for every category of system. The baseline gets updated as new bad defaults are discovered. The second move is to automate the check. The defender cannot review every default for every deployment by hand. The defender has to have a tool that checks the default against the baseline and flags the exceptions. AWS Config, Azure Policy, GCP Org Policy, the open source tools (Prowler, ScoutSuite, Steampipe) all do some version of this. The third move is to make the secure default the easy default. The application that ships with SSO required by default does not need a security review to deploy. The application that ships with a public S3 bucket by default does. The defender who can flip the default to the secure option is the defender who prevents the next breach.
The bottom line
Codify, automate, make the secure default the easy default. Most breaches exploit a default that was wrong at install. The defender who fixes the defaults fixes the breach. The work is mostly automation. The work pays off in the incidents that do not happen.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
