Secure by design is an approach to building software, devices and services in which security is treated as a core requirement from the first design decisions, not added later through patches, add-ons or customer hardening guides. It goes hand in hand with secure by default: products should ship with protective settings already switched on, so customers are safer without extra work or extra cost. The idea puts more of the responsibility for security on the maker of a product and less on the people who buy it.
At a glance
- Security is planned in at design time through threat modeling, safer languages and architecture, and safe coding practices.
- Secure by default means protections such as strong authentication and logging are on out of the box, not sold as upgrades.
- In the US, CISA has promoted the idea through published guidance and a voluntary pledge for software makers.
- It is a set of principles, not a certification; buyers still need evidence of how a vendor applies it.
What problem it solves
Much of the security burden in IT falls on customers. Products ship with default passwords, optional multi-factor authentication, logging locked behind premium tiers, or whole classes of preventable flaws that turn into a stream of urgent patches. Every customer then repeats the same hardening work, and the ones who don’t, often smaller organizations with thin IT teams, get breached.
Secure by design reframes that as a product-quality problem. If the maker removes classes of vulnerability at the source and ships safe defaults, customers benefit together and far fewer have to configure their way to safety. For buyers it also offers a vocabulary for asking vendors to carry more of that weight.
How it works
Design-time decisions. Teams model threats before writing code, choose architecture and components that limit what can go wrong, and apply least privilege inside the product. Choosing memory-safe programming languages, or reducing reliance on memory-unsafe code, is a frequently cited example because memory-safety bugs account for a large share of serious vulnerabilities in some products.
Secure defaults. Protective features are on and included: multi-factor authentication (MFA) available or enforced for administrators, no shared default passwords, security logs available without an upsell, and risky features off until turned on.
Development practice. Secure coding standards, code review, automated security testing in the pipeline and dependency tracking, the practices often grouped under DevSecOps. A software bill of materials (SBOM) records what components are inside.
Transparency and accountability. Makers publish vulnerability disclosure policies, issue accurate CVE records with root-cause information, and make security a leadership responsibility rather than a single team’s job.
In the US, the Cybersecurity and Infrastructure Security Agency (CISA) has championed these ideas, publishing secure-by-design guidance with partner agencies in several countries and inviting software makers to sign a voluntary pledge with specific goals. Details of the program can change, so check CISA’s current material rather than relying on a vendor’s summary.
When it matters for buyers
- When selecting software or connected devices. Default settings, included security features and vulnerability history are concrete signals of a vendor’s approach.
- When negotiating contracts. Requirements for MFA, logging, vulnerability disclosure and patch timelines can be written into security schedules and reviewed in third-party risk management (TPRM).
- When customers ask about your own products. Enterprise and public-sector buyers increasingly ask software suppliers how security is built in, not just tested at the end.
- When patching is overwhelming. A vendor that ships a steady stream of critical fixes for preventable flaw types adds to your vulnerability management load.
If you build software, our application security testing advisors can help you find providers to test what you ship.
Questions to ask vendors
- Which security features are included in every tier, and which cost extra?
- Is MFA available for every account and enforced for administrators by default?
- Does the product ship with any default or shared passwords?
- Do you have a published vulnerability disclosure policy, and how quickly do you fix and disclose reported flaws?
- Can you provide an SBOM and describe how you track third-party components?
- Have you signed any public secure-by-design commitment, and what progress have you reported against it?
How it differs from DevSecOps
DevSecOps is a way of working: building security checks and shared ownership into the software delivery pipeline. Secure by design is a broader principle about outcomes and responsibility: what the finished product should look like when it reaches the customer, and who should carry the burden of keeping it safe. DevSecOps practices are one common way to deliver on secure-by-design goals, but a team can run a mature pipeline and still ship weak defaults, and secure by design also covers product decisions, pricing of security features and transparency that sit outside the pipeline.