Home / Knowledge hub / Secure defaults
Knowledge hub
Secure defaults
Settings that are safe out of the box, so no one has to remember to turn them on.
What it means
Secure defaults are the settings a product has before anyone changes anything. If those starting settings are safe, a customer or developer who does nothing ends up protected, which is the situation for most people most of the time. If they are unsafe, protection depends on someone knowing what to change.
Typical examples are new accounts that start with the least access, features that are off until needed, sample passwords that cannot be used, and storage that is private until someone deliberately shares it. The idea is that the safe path takes no effort.
Why it matters
People rarely change defaults. A setting that ships open will be open in most installations, for years, because nobody has a reason to look. Exposed storage and default admin passwords are common causes of avoidable breaches for exactly this reason.
For a software business, it moves the risk off your customers and off your support desk. You also avoid the awkward moment of telling a customer that the breach came from a setting your product left unsafe, however clearly the documentation explained it.
How it shows up
You meet this in new tenant setup, API keys with broad scope, debug switches, sample accounts, open cross-origin rules and permissive cloud buckets. Frameworks help only if you check what they ship with. A debug mode left on in production is a default that was never changed.
Review each setting and ask what happens if no one touches it. Prefer deny by default. Make unsafe options a deliberate choice, with a warning. Test a fresh install as a newcomer would, and compare it with your hardening guide, which should be the default, not a chore.
Questions people ask
Secure defaults, answered
Are secure defaults the same as hardening?
Not quite. Hardening is work someone does to tighten a system after it is set up. Secure defaults mean the tightening is already done when the product arrives. Hardening is the cleanup, and defaults are the prevention.
Do secure defaults hurt usability?
Sometimes a little, at first. Good products reduce the friction with clear prompts and easy ways to loosen a setting on purpose. Ease of setup should not come from leaving everything open, because that trades a few minutes now for risk later.
Who is responsible for defaults, the vendor or the customer?
Both, but the maker sets the starting point. A customer can only change what they know about, and cannot fix what they cannot see, so the vendor carries the first responsibility for what ships.
What is a common example of a bad default?
A shared admin password, a storage bucket that is public on creation, or a setup that allows any origin to call your API. Each is easy to miss and easy to fix.
How do we find unsafe defaults in our own product?
Install it fresh in a clean environment and look at what is exposed, which accounts exist and which features are on. Then test the running app from the outside to confirm.
Sources
Where this comes from
Related
Terms that sit next to this one
Secure by design
Choosing safe defaults and structures from the start, not bolting protection on later.
Deny by default
Refusing every request unless a rule explicitly allows it.
Debug mode in production
Leaving developer switches on in a live app, which leaks internals.
Cloud misconfiguration
A cloud setting left unsafe, such as open storage or an overly broad permission.
Least privilege
Giving every person and service the minimum access the job requires.
What does a fresh install expose?
Settings left open, debug switches and default credentials are the kind of weakness we look for when testing a running app. Each finding is one we exploited, with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.