Home / Knowledge hub / Secure by design
Knowledge hub
Secure by design
Choosing safe defaults and structures from the start, not bolting protection on later.
What it means
Secure by design means security is a requirement during design, not a patch applied afterwards. The structure of the product is chosen so that whole kinds of flaw cannot happen, or cause little harm if they do. The thinking happens before the first line of code.
CISA, which promotes the idea, describes three principles for software makers: take ownership of customer security outcomes, practise radical transparency and accountability, and build the organisation so that leaders drive security. The focus is on what the builder does, not what the customer must configure.
Why it matters
Fixing a design flaw after launch is expensive, because other things have been built on top of it. A decision made in a design meeting, such as keeping tenants in separate stores, can remove a whole class of data-leak bugs for the life of the product.
It also lowers the burden on customers. If safe behaviour is the default and unsafe behaviour needs a deliberate choice, fewer customers end up exposed through a setting they never knew about. Buyers increasingly ask suppliers whether they build this way.
How it shows up
In practice it looks like threat modelling before building, least privilege in every service, memory-safe languages where practical, and checks done on the server instead of trusted to the browser. It also means choosing secure defaults, so a team that does nothing extra still ends up safe.
The mistakes repeat. A slogan is adopted but no one owns it. Security review is held at the end, when changing the design is no longer realistic. Optional protections are sold as extras. Check whether your last three design documents say what could go wrong and what limits the damage. If they are silent, start there, because that is where the cheapest fixes sit.
Questions people ask
Secure by design, answered
Is secure by design the same as secure by default?
They are related. Secure by design is the wider approach of building safety into the structure. Secure by default is one part of it: products that ship in their safest configuration without extra work.
Does it mean we never need to test?
No. A good design reduces risk but cannot guarantee that the implementation matches it. Testing finds where the built system differs from the intended one. A design can be sound and still be built wrongly.
Is secure by design only for large companies?
No. Small teams benefit most, because early choices are the easiest to change. A short threat model and a few safe defaults cost very little. You do not need a large process to do this.
How does it differ from shifting left?
Shifting left moves checking earlier in the process. Secure by design goes further and removes the weakness through how the product is shaped, so there is less to check. Both are useful together.
What is a simple first step?
Add a short question to your design template: what could go wrong here, and who could make it happen? Answer it before building. It is a small habit with a large effect.
Sources
Where this comes from
Related
Terms that sit next to this one
Secure defaults
Settings that are safe out of the box, so no one has to remember to turn them on.
Threat model
Asking what is worth taking, who wants it, and how they would try.
Least privilege
Giving every person and service the minimum access the job requires.
Shift left
Doing security work while code is written, not as a check at the end.
Defence in depth
Assume any one control will fail, and have something else behind it.
Does the build match the design?
Design intent and running behaviour often differ. We test the running app, and in white-box mode read the code too, to show where the two part ways. 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.