CISA Secure by Design: shifting security responsibility to software makers

What it is

In April 2023 the US Cybersecurity and Infrastructure Security Agency (CISA), together with the FBI, NSA and agencies from several other countries, published guidance called Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. An expanded version followed in October 2023 with more international co-signers. The central argument is that the burden of security has fallen too heavily on customers, who must buy extra products, configure complex settings and patch constantly, when many weaknesses could have been avoided by the manufacturer.

Two related ideas are used throughout:

• Secure by design: security is a core business requirement considered from the start, so whole classes of flaws are designed out.
• Secure by default: products are safe out of the box, with protections such as multi-factor authentication and logging enabled at no extra cost and without extra configuration.

Why it matters

A large share of serious incidents still begin with old, well-understood problems: default passwords, SQL injection, memory safety bugs, exposed management interfaces and missing MFA. Each customer defending separately against these is inefficient. If the manufacturer fixes the root cause once, every customer benefits. For engineers buying network equipment, firewalls or SaaS, Secure by Design also gives a vocabulary for asking vendors hard questions.

Key ideas: the pledge

In May 2024 CISA launched a voluntary Secure by Design Pledge for enterprise software makers, covering on-premises software, cloud services and SaaS. Signatories commit to show measurable progress within a year on seven goals:

1. Increase the use of multi-factor authentication by customers.
2. Reduce default passwords.
3. Reduce entire classes of vulnerability, such as SQL injection, cross-site scripting or memory safety bugs.
4. Increase customer installation of security patches, for example through automatic updates.
5. Publish a vulnerability disclosure policy that authorises good-faith testing.
6. Show transparency in CVE reporting, including accurate weakness (CWE) and product (CPE) fields.
7. Improve customers’ ability to gather evidence of intrusions, for example by providing security logs at no extra cost.

Each goal comes with example approaches, and companies may choose how to meet it, either across all products or starting with some and publishing a roadmap for the rest.

What changed recently

The programme has broadened from principles to specific guidance. CISA and partners have published a catalogue of product security bad practices (for example, using memory-unsafe languages for new products without a migration roadmap, shipping default passwords, or including known exploited vulnerabilities), guidance on memory safety roadmaps, and Secure by Demand guides that help customers ask suitable questions during procurement. Related ideas now appear in law: the EU Cyber Resilience Act and the UK product security regime for connected consumer devices (see ETSI EN 303 645) turn several of the same expectations into legal requirements.

How practitioners apply it

1. Use it in procurement. Ask suppliers whether MFA and logging are included at no extra cost, how they eliminate vulnerability classes, how updates are delivered and whether they publish a disclosure policy.
2. Use it in your own development. Adopt memory-safe languages for new components where practical, use parameterised queries and safe templating frameworks, and track vulnerability classes rather than individual bugs.
3. Remove default credentials from anything you ship or deploy, including network devices; see the switch hardening playbook.
4. Publish a security.txt and disclosure policy so researchers know how to report problems.
5. Measure. Track MFA adoption among your users, time to patch, and the number of vulnerabilities by CWE class over time.

Tip: A good test of a vendor’s maturity is to read its recent security advisories. Do they explain root causes and CWE classes, or only say "a vulnerability was fixed"?

The approach also applies inside organisations. An internal platform team that offers developers a pre-hardened container image, a database library that only supports parameterised queries and a single sign-on integration with MFA already enforced is practising secure by default for its internal customers. The same logic, removing the insecure option instead of training people to avoid it, scales from a vendor to a university IT department.

Limitations and open questions

• Voluntary in the US. The pledge has no enforcement, and progress reports vary in depth and quality.
• Measuring outcomes is hard. Fewer reported CVEs might mean better security or less transparency.
• Legacy products with large installed bases are expensive to re-engineer, especially memory-unsafe code.
• Policy continuity. Government priorities change; long-term impact depends on whether customers and regulators keep demanding these outcomes.