CISA Secure by Design: a practical implementation guide

Secure by Design makes security a product property and a responsibility of its manufacturer, not another hardening task transferred to the customer. CISA frames the approach around ownership of customer outcomes, radical transparency and leadership from the top.

This changes product decisions. A feature that increases exposure by default must justify the risk, and essential security capabilities should not be premium add-ons.

Safe defaults

A new account should have MFA available without an upgrade, least privilege and secure session settings. An administration interface should not be internet-facing without an explicit decision. Security event logging should work from the first launch.

Users may change settings, but the product should explain the consequences. A safe initial state cannot depend on reading a long hardening guide.

Remove vulnerability classes

Prioritise controls that eliminate defect classes: parameterised queries, central authorisation, memory-safe languages, safe cryptographic libraries and resilient updates. An API that makes dangerous use difficult is stronger than a list of prohibited functions.

Threat-model before architecture is fixed. Identify trust boundaries, data, roles and abuse cases, then turn findings into application security requirements and tests.

Transparency without theatre

Publish useful information about vulnerabilities, root causes and systemic action. Do not stop at one patch. If a weakness pattern can exist in several components, search the entire product family.

Maintain an SBOM, support policy, secure update channel and vulnerability disclosure programme. Customers need to know how long a product receives fixes and how to report a problem.

Metrics for leadership

Closed tickets are not enough. Measure:

• customers using phishing-resistant MFA;
• time from disclosure to protection across supported versions;
• features exposed publicly by default;
• recurrence of the same vulnerability class;
• security-test coverage of critical journeys;
• products with a supported automatic update path.

These metrics describe customer outcomes, not team activity.

A risk-based release gate

Secure by Design does not mean every finding must stop every release. The team needs explicit criteria: which abuse cases are unacceptable, who can accept risk and for how long, and what evidence must exist before deployment. For authentication, that evidence might cover MFA bypass, session rotation and account recovery; for file import, it might cover type validation, limits and isolated processing.

An exception needs an owner, expiry and remediation plan. Otherwise a temporary deviation becomes permanent architecture. For critical journeys, a gate may require a threat model, change review, automated tests and an independent penetration test. The strength of controls follows risk, not lines of code.

Security after the product is sold

Manufacturer responsibility does not end on release day. Maintain a supported-version inventory, a channel for reports, the capability to produce updates quickly and a way to notify customers. Security telemetry should help identify abuse without collecting more data than necessary. The update mechanism must verify package origin and handle interrupted installation safely.

After a vulnerability, analyse root cause at three levels: the code defect, the process gap and the product decision that enabled exposure. Search for the same pattern in other components and add a control that prevents regression. Counting CVEs alone does not show whether the product is becoming safer.

Relationship to the SSDF and testing

NIST’s SSDF organises secure-development practices into four groups: prepare the organisation, protect software, produce well-secured software and respond to vulnerabilities. It is useful process scaffolding, but does not replace decisions about safe product defaults. A penetration test supplies evidence about a particular release; Secure by Design also requires changing the mechanism that produced a weakness.

Write security requirements as testable outcomes. “The system is secure” cannot be tested. “A user without the finance role cannot read or modify another department’s invoice, including through direct API calls” can be verified in unit, integration and manual tests.

Implementation sequence

1. Appoint an executive sponsor with product authority.
2. Define standards for secure defaults.
3. Map recurring vulnerability classes and root causes.
4. Add security requirements to architecture decisions.
5. Include essential safeguards without an upgrade.
6. Publish support and disclosure policies.
7. Measure outcomes and remove patterns systemically.

Secure by Design succeeds only when security changes the roadmap, budget and release criteria. A pledge that leaves unsafe product defaults untouched does not protect customers.

---

Sources: CISA — Secure by Design, CISA — Shifting the Balance of Cybersecurity Risk, NIST Secure Software Development Framework.