3 MIN READ
Picture the install moment. Vendor ships the software with a default admin password, a public S3 bucket, a default SNMP community string, a permissive CORS policy. Operator clicks through the setup wizard and the defaults stay in place. Three years later an attacker finds them. The breach happens. That sequence is what most of 2026’s compromises look like, and the failure point is not the attacker, it is the moment nobody asked what the defaults were.
Fix the defaults and the breach goes away. The security org that reviews every setting at install prevents the compromise that would have hit three years later, when the wrong default met an attacker. Most of the work is unglamorous automation, and the payoff lives 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. Authentication first: 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. Lock these down at install. SSO required, MFA required, default accounts deleted, password auth disabled in production.
The network default runs second: the cloud storage bucket that ships public, the database with a public IP, the API with no authentication. The fix sits in a configuration baseline. No public storage, no public databases, every API behind authentication, every network path through a known entry point.
Encryption comes third: the TLS configuration that still allows TLS 1.0, the cipher suite list that includes RC4, the certificate that ships self signed. Replace it with a modern TLS profile, legacy versions off, weak ciphers removed, certificate reissued.
Logging sits fourth: the application with logging disabled, or with logs going somewhere nobody watches. Turn logging on at install, route the streams to the SIEM, and put an alert on the first failure.
Updates come last: the application with auto update disabled, the library pinned to a known vulnerable version with no upgrade path. Enable auto update where it exists, and keep a written upgrade plan for the rest.
How to do this without slowing the business
Codify the secure default first. The platform team writes a baseline of what the secure default looks like for every category of system, and updates the baseline every time a new bad default shows up in the wild. Pinned to a doc, version controlled, the same baseline the auditors and the new hires both read.
Then automate the check. The security org cannot review every default on every deployment by hand, and a manual review becomes a process that decays the moment the team is busy. AWS Config, Azure Policy, GCP Org Policy, the open source tools (Prowler, ScoutSuite, Steampipe) all do some version of this. The tool checks the deployed config against the baseline and flags the exceptions, and the exception queue is the only thing a human has to look at.
Then flip the 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 procurement lead who picks the secure default at contract time prevents the next breach before it reaches the security org.
The bottom line
Codify, automate, flip the default. Most breaches exploit a setting that was wrong at install, and the security org that fixes the settings fixes the breach. The bulk of the work is unglamorous automation, and the payoff lives in the incidents that never 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.
