Secure by default means a system ships with its safest configuration active out of the box — encryption on, authentication required, network exposure minimized — so a user has to deliberately weaken it rather than deliberately harden it. The distinction matters because most breaches start with a setting nobody changed, not a vulnerability nobody could have known about. Log4Shell (CVE-2021-44228) tore through millions of Java applications starting December 9, 2021, in part because Log4j 2.x resolved JNDI lookups by default, a feature almost no deployment needed but every deployment shipped with enabled. MongoDB instances were mass-ransomed in January 2017 because early versions ran with no authentication unless an administrator explicitly turned it on. Secure by default flips that model: the safe path is the path of least resistance, and insecure configurations require an explicit, auditable decision. It's now a named requirement in CISA guidance, the EU Cyber Resilience Act, and public pledges signed by dozens of major software vendors.
What does "secure by default" actually mean?
Secure by default means the out-of-the-box configuration of a product is the most secure one the vendor can reasonably ship, without requiring the customer to read documentation or flip switches to get baseline protection. CISA, NSA, and the FBI defined it precisely in their April 13, 2023 joint guidance, "Shifting the Balance of Cybersecurity Risk," as products that are "secure to use straight out of the box, with little to no configuration changes and no additional charge." The key test is who bears the burden: in a secure-by-default system, an attacker or a careless admin has to actively remove protections (disable MFA, open a port, turn off TLS verification) rather than actively add them. Contrast that with the historical norm in enterprise software, where security features existed but were opt-in — present in the manual, absent in the shipped state, and therefore absent in practice for the majority of deployments that never touch the defaults.
Why do insecure defaults cause so many breaches?
Insecure defaults cause disproportionate damage because attackers can scan the entire internet for the default state and exploit it at scale without ever touching a zero-day. The clearest example is the "MongoDB apocalypse" of January 2017: security researcher Victor Gevers and the GDI Foundation documented more than 27,000 MongoDB databases wiped and held for ransom in a matter of weeks, all reachable because pre-2.6 MongoDB bound to 0.0.0.0 with no authentication enabled by default. A decade later, Shodan-style mass scanning still finds thousands of exposed Elasticsearch clusters, Redis instances, and Jenkins servers for the same reason — nobody changed a default that was never safe to begin with. Compare that to a targeted zero-day, which requires an attacker to find and weaponize a specific flaw against a specific target. An insecure default is a standing invitation that every automated scanner on the internet checks within hours of a new instance going live.
How is secure by default different from secure by design?
Secure by design refers to architectural and development-process decisions made before shipping, while secure by default refers to the configuration state the product is actually in when a customer receives it. NIST's Secure Software Development Framework (SP 800-218, published February 2022) treats secure by design as covering things like threat modeling, memory-safe language choices, and dependency vetting during the build process. Secure by default is the downstream artifact of that process — it's what happens when a vendor that has done threat modeling also decides that TLS verification can't be disabled with a single flag, or that a new cloud storage bucket defaults to private rather than public. A team can build a memory-safe, threat-modeled application (secure by design) and still ship it with default admin credentials or a wide-open CORS policy (not secure by default). CISA's 2023 guidance explicitly pairs the two terms because vendors need both: sound engineering decisions during development, and a safe resting configuration when the product reaches a customer.
What does secure by default look like in practice?
In practice, secure by default shows up as vendors removing the "off" switch for baseline protections rather than just offering an "on" switch. AWS began applying S3 Block Public Access and disabling ACLs by default for all newly created buckets in April 2023, reversing more than a decade of opt-in bucket privacy that had caused a steady stream of public-data-exposure incidents. GitHub required two-factor authentication for all code contributors by January 13, 2023, rather than leaving MFA as an account setting most users never visited. Windows 11 disables the legacy SMBv1 protocol by default, closing the same channel that WannaCry and NotPetya abused in 2017. Modern container base images (e.g., recent Node.js and distroless images) run processes as a non-root user by default, so a container escape doesn't automatically hand an attacker root on the host. In each case, the vendor moved the secure state from "available if configured" to "present unless removed."
What standards and pledges require secure by default?
Three concrete mechanisms now push vendors toward secure by default: joint government guidance, a public pledge, and binding EU law. The CISA/NSA/FBI whitepaper published April 13, 2023 laid out secure-by-default as one of its core principles alongside secure-by-design, explicitly naming eliminating default passwords and enabling logging without extra licensing fees. CISA's Secure by Design Pledge, launched at RSA Conference on May 8, 2024, got 68 software manufacturers — including Microsoft, Google, AWS, and Cisco — to commit to measurable defaults like MFA-by-default and reduced use of default passwords within a year. The EU Cyber Resilience Act, which entered into force on December 10, 2024, goes further by making "secure by default configuration" a binding essential requirement under Annex I for any product with digital elements sold in the EU, with reporting obligations phasing in from September 2026 and full enforcement from December 2027. Together these mean secure-by-default is shifting from a best practice into a compliance line item that procurement teams can actually cite in a contract.
How Safeguard Helps
Safeguard helps security teams verify that "secure by default" claims from vendors and internal teams actually hold up in a running environment, rather than trusting a changelog entry. Our reachability analysis confirms whether a default-enabled risky feature — like a JNDI lookup path or a permissive CORS default — is actually exercised in your application's call graph, so you can prioritize the defaults that matter instead of chasing every CVE advisory. Griffin AI continuously reviews new dependencies and configuration changes against known insecure-default patterns (open ports, disabled TLS verification, default credentials) and flags regressions before they ship. Safeguard generates and ingests SBOMs across your build pipeline to track which components ship with unsafe defaults and which have already been hardened, and our auto-fix PRs apply the secure configuration directly in your codebase — flipping the default before an attacker finds it.