Security by Design and by Default: Principles and Practice

Security by design means a product is built so that security is a core requirement from the first design decision, and security by default means it ships in its most secure configuration, with no extra setup or cost for the customer. Put simply, the maker carries the burden of security instead of leaving it to every buyer to harden, patch and configure. Governments now push this hard: CISA's Secure by Design programme and pledge, joint guidance from the Five Eyes and partner agencies, the UK PSTI regime, and the EU Cyber Resilience Act all turn the idea into expectations or law. This guide explains the principles in plain language, then covers what the pledge and regulations ask for, concrete secure defaults, how to implement the approach in a software or product organisation, how to measure it and where it fails. It is for product security leads, engineering managers, architects and buyers who want to hold suppliers to the standard.

Key takeaways

Design and default are different promises. Secure by design reduces the flaws that get built in; secure by default makes sure the safe settings are on when the product arrives.
The burden shifts to the manufacturer. CISA describes secure by default products as secure out of the box, needing little or no configuration, at no additional cost.
The pledge sets seven measurable goals, from MFA and no default passwords to eliminating whole vulnerability classes and giving customers evidence of intrusions.
Some of it is now law. The UK PSTI regime has banned universal default passwords on consumer connectable products since 29 April 2024, and the EU Cyber Resilience Act brings essential requirements for products with digital elements.
Identity defaults matter most. MFA on by default, no shared or hard-coded credentials, and logging of identity events prevent many of the incidents that keep recurring.

What security by design and by default mean

A useful comparison is car safety. Seatbelts, crumple zones and airbags are designed in, and they work without the driver configuring anything. Software has historically been the opposite: products shipped with features switched on, weak settings, and long hardening guides for customers to follow. Secure by design and by default reverse that.

Concept	Plain meaning	Example	Opposite
Secure by design	Security is a business and engineering requirement from the design phase, so classes of flaw are prevented rather than patched later	Writing new components in a memory-safe language; using parameterised queries everywhere through a framework	"Bolt-on" security after release
Secure by default	The shipped configuration is the secure one; customers must deliberately weaken it, and are warned when they do	MFA enforced for administrators at first login; logging on and retained at no extra charge	Hardening guides and paid security tiers
Secure by demand	Buyers require these properties in procurement	Asking suppliers for their pledge progress, update period and vulnerability disclosure policy	Buying on features and price alone

The joint international guidance led by CISA frames secure by design around three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top, meaning executives own security as a business outcome. A related idea in that guidance is replacing customer "hardening guides" with "loosening guides" that explain the risk of each setting a customer chooses to relax.

The UK NCSC's secure by default principles express the same thinking from an engineering angle: start early, fix causes rather than symptoms, keep going for the life of the product, put usability first, work without setup, stay ahead of attackers, use no hidden defences (do not rely on secrecy of design), and require no expertise from the user.

The CISA Secure by Design pledge

CISA launched its voluntary Secure by Design pledge for enterprise software manufacturers in May 2024. Signers commit to a good-faith effort to make measurable progress on seven goals within one year of signing. The pledge is not legally binding, and CISA states that hundreds of companies have signed. Its goals are a practical checklist for any vendor, signed or not.

Pledge goal	What it asks	Evidence a buyer can request
1. Multi-factor authentication	Measurably increase MFA use across products, favouring phishing-resistant methods, especially for administrators	Percentage of customer admins on MFA; whether MFA is enforced by default
2. Default passwords	Eliminate universally shared default passwords, prioritising internet-facing products	Setup flow that forces a unique credential; no shared factory login
3. Reducing entire classes of vulnerability	Pick classes such as SQL injection, cross-site scripting or memory safety flaws and reduce them across products	Trend of CVEs by CWE; framework or language changes made
4. Security patches	Make patching easier, for example automatic updates, and vendor-side patching for cloud and SaaS	Default update setting; time to patch for customers
5. Vulnerability disclosure policy	Publish a policy that authorises good-faith testing, commits not to pursue legal action against good-faith researchers, and gives a reporting channel	Public VDP URL, security.txt
6. CVEs	Issue timely CVEs for critical, high-impact or exploited flaws, with accurate CWE and CPE fields	CVE history and completeness of records
7. Evidence of intrusions	Give customers logs of configuration changes, identity events and data access, retained for a set period, at no extra cost	Log categories available in the base licence and retention period

Note how many goals are identity controls: MFA, default passwords and logs of identity events. See the Phishing-Resistant MFA Guide.

Regulation: where secure by design becomes mandatory

UK PSTI Act product security regime: in force since 29 April 2024 for consumer connectable products. Three requirements: passwords must be unique per product or set by the user and not easily guessable; manufacturers must publish how to report security issues and the timeframes for acknowledgement and updates; and they must publish the minimum security update period, including an end date. The Office for Product Safety and Standards enforces it. See the UK PSTI Act Guide and the ETSI EN 303 645 Consumer IoT Guide, the standard the regime's requirements draw on.
EU Cyber Resilience Act: sets essential cybersecurity requirements for products with digital elements placed on the EU market, including secure by default configuration and vulnerability handling, with obligations applying in stages. We do not repeat the detail here: see the EU Cyber Resilience Act Guide for scope, dates and conformity routes.
US federal software attestation: NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, final since February 2022, was published in response to Executive Order 14028 and is the practice baseline US federal buyers point suppliers to. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.

Requirements and dates in these regimes can change through amending legislation and guidance; check the official source before relying on a date for compliance planning.

Secure defaults in practice: what to ship switched on

Area	Secure default	Why it matters
Administrator access	MFA enforced at first login, phishing-resistant options offered; SSO supported in the base tier	Stolen passwords are the commonest initial access route (MITRE ATT&CK T1078 Valid Accounts)
Credentials	No universal default password, no hard-coded or backdoor accounts; unique credential set during setup	Default accounts are a named ATT&CK technique, T1078.001 Default Accounts
Machine credentials	API keys scoped and expiring by default; secrets never written to logs or client code; workload identity supported	Long-lived keys leak through repositories and builds
Exposure	Management interfaces off the internet by default; unused services and ports disabled (least functionality)	Reduces attack surface without customer effort
Logging	Identity, configuration and data access events logged and retained at no extra cost	Customers can detect and investigate (pledge goal 7)
Updates	Automatic security updates on; published support end date	Matches the pledge patching goal and PSTI update period
Transport and storage	TLS enforced, plaintext protocols disabled; data encrypted at rest	Removes configuration choices that customers get wrong
Permissions	New users and integrations start with least privilege; authorisation checked on every object	Prevents broken object-level authorisation and over-privileged tokens

For machine identities specifically, see the API Key Management Guide and the Workload Identity Federation Guide.

Secure by design in the development lifecycle

Threat model at design time: identify trust boundaries and abuse cases before code exists. See the Threat Modelling Guide.
Eliminate classes, not instances: choose frameworks that make the safe path the easy path, such as templating that escapes output (cross-site scripting) and data access layers that only allow parameterised queries (SQL injection).
Memory-safe languages and roadmaps: memory safety flaws are a major class in C and C++ code. CISA and partners have urged manufacturers to publish memory-safe roadmaps showing how they will move new and high-risk code to languages such as Rust, Go, Java, C# or Swift. See the Memory-Safe Languages Guide.
Follow a recognised practice framework: the SSDF organises practices into four groups: Prepare the Organisation (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). Map your secure SDLC to it. See the Secure Software Development Lifecycle (SSDLC) Guide.
Secure the supply chain: know your components (SBOM), sign builds, and protect the build pipeline's own credentials. See the SBOM Guide and the Software Supply Chain Security Guide.
Test and verify: static and dynamic testing, code review and release gates. OWASP ASVS gives verifiable requirements. See the Application Security Guide.
Be transparent: publish a vulnerability disclosure policy, complete CVE records with CWE, and security update periods.

Implementing the approach: a phased rollout

Executive ownership (month 0 to 1): name an accountable executive, set secure by design as a product requirement, and decide whether to sign the CISA pledge. Small companies can adopt the seven goals informally.
Baseline (months 1 to 3): measure current state against the pledge goals and SSDF: MFA adoption among customer admins, any shared default or hard-coded credentials, top CWEs in your CVE history, default update behaviour, logging available in the base tier.
Quick wins (months 3 to 6): remove default passwords from setup flows, enforce MFA for new admin accounts, publish a VDP and security.txt, and move security logs into the base licence.
Pilot changes safely: introduce new defaults for new tenants or installations first, then existing customers with notice. Use feature flags so a default can be reverted quickly if it breaks integrations, and publish a loosening guide that explains the risk of opting out.
Structural work (6 to 24 months): pick one or two vulnerability classes and eliminate them through frameworks; publish a memory-safe roadmap; integrate SSDF practices into CI/CD gates.
Report progress: publish what changed, as the pledge expects within one year, and feed regulatory evidence for PSTI or CRA.
Rollback and exceptions: keep a documented, time-limited exception process for customers who cannot yet accept a default (for example legacy integrations that cannot do MFA), with an expiry date and a compensating control.

Decision guidance

Enforce versus encourage: enforce for administrators and internet-facing products; for end users, default on with an opt-out that is logged and warned about. Usability first, as the NCSC puts it, but not usability instead of security.
Backward compatibility versus security: the joint guidance favours forward-looking security over backward compatibility. Give long deprecation notice for insecure protocols, then remove them.
Small vendors: focus on credentials, MFA, automatic updates and a VDP; these need little engineering. Large vendors should add class elimination programmes, memory-safe roadmaps and public metrics.
Buyers: ask suppliers for the evidence column in the pledge table above and include it in contracts. See the Software Supply Chain Security Buyer's Guide.

Detection and measurement

Monitor product telemetry for: tenants or devices still on initial credentials, admins without MFA, customers who disabled default protections, logging disabled or retention reduced, and devices past their published update period.

KPI	Target direction
Share of customer administrator accounts using MFA (and phishing-resistant MFA)	Rising towards 100%
Products or SKUs with any universal default or hard-coded credential	Zero
CVEs per release in the targeted CWE classes	Falling, ideally to zero for eliminated classes
Proportion of new code in memory-safe languages	Rising against the published roadmap
Customers on automatic updates; median time to patched	Rising share; falling time
Length of the hardening guide (settings customers must change to be secure)	Shrinking

Framework mapping

Theme	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1
Design principles	SA-8 Security and Privacy Engineering Principles	PR.PS-06	8.27 Secure system architecture and engineering principles	Control 16 Application Software Security
Secure development process and testing	SA-15, SA-11	PR.PS-06	8.25 Secure development life cycle, 8.28 Secure coding, 8.29 Security testing	Control 16
Secure configuration defaults	CM-6 Configuration Settings, CM-7 Least Functionality	PR.PS-01	8.9 Configuration management	Control 4 Secure Configuration
Authentication defaults	IA-2, IA-5	PR.AA-03	8.5 Secure authentication	Control 6
Supply chain	SR-3	GV.SC-01	5.21 ICT supply chain security	Control 15 Service Provider Management

Common failure patterns

Dormant default and test accounts: in the McHire default password flaw, a test administrator account with 123456 as username and password, no MFA, and an API without object-level authorisation checks exposed access to an estimated 64 million applicant records.
Hard-coded credentials in firmware: HPE Aruba Instant On CVE-2025-37103 shipped a built-in administrator login the owner could not change or disable, rated CVSS 9.8. This is exactly what pledge goal 2 and the PSTI password rule prohibit.
MFA available but not enforced: the Change Healthcare breach started on a remote access portal without MFA. If a product allows remote access without MFA by default, someone will deploy it that way.
Security logging as a paid add-on: customers on the base tier cannot see identity or configuration events, so intrusions go unnoticed.
Pledges without metrics: signing and announcing without baselines or published progress turns the pledge into marketing.
Defaults applied only to new installs: the existing customer base stays on insecure settings indefinitely because nobody plans a migration.

Practitioner checklist

Name an accountable executive and record secure by design as a product requirement.
Remove every universal default and hard-coded credential; force a unique credential at setup.
Enforce MFA for administrators by default and offer phishing-resistant methods.
Include identity, configuration and data access logs in the base product with a stated retention period.
Turn on automatic security updates and publish the support end date.
Publish a vulnerability disclosure policy and issue complete CVE records with CWE.
Choose vulnerability classes to eliminate and publish a memory-safe roadmap.
Map the SDLC to SSDF practice groups PO, PS, PW and RV.
Replace hardening guides with loosening guides and track how many customers loosen defaults.
Ask your own suppliers for the same evidence before you buy.

Security by Design and by Default Guide: Principles, Pledges and Practice