Secure by default means systems and products start in the safer configuration unless an administrator deliberately changes them.
Secure by default means systems and products start in the safer configuration unless an administrator deliberately changes them. In plain language, the product should not make people opt in to the important protections after deployment.
Secure by default matters because many real exposures are caused by weak initial settings, optional security features, or confusing setup decisions. If the safest path requires extra effort, many environments will never reach it.
It also matters because default choices shape the security posture of every deployment that follows.
Secure by default appears in product design, cloud configuration, identity policy, endpoint management, and secure software delivery. Teams connect it to Security Misconfiguration, Security Baseline, Least Privilege, Conditional Access, and Patch Management.
It is one of the most practical principles for reducing avoidable exposure across large environments.
A new cloud storage service starts private, enforces encryption automatically, and requires deliberate policy changes before public access can be enabled. That is a more secure-by-default design than starting open and asking administrators to harden it later.
Secure by default is not the same as “impossible to change.” Administrators may still need flexibility, but the initial state should favor safer behavior.
It is also different from Defense in Depth. Defense in depth is about layered protection, while secure by default is about how the system begins and behaves before customization.