Skip to main content

CISA Updates Secure-by-Design Guidance

· 3 min read
SBD Community
Maintainer

On 12 May 2026, CISA highlighted an updated version of the joint Secure-by-Design guidance, co-sealed by additional international cybersecurity agencies. The update reinforces the core message behind the movement: technology providers should take ownership of customer security outcomes, be transparent about their security posture, and treat security as an executive-level product responsibility (CISA Secure-by-Design resource).

This matters for connected-device manufacturers because Secure-by-Design is no longer just a useful engineering philosophy. It is becoming a way for customers, regulators, and supply-chain teams to evaluate whether a manufacturer is serious about product security.

What changed

The updated guidance builds on the three principles already familiar from CISA's Secure-by-Design update:

  • Take ownership of customer security outcomes.
  • Embrace radical transparency and accountability.
  • Lead from the top.

The important shift is in emphasis. CISA is not only telling manufacturers to build safer products; it is also giving customers a clearer basis for asking whether suppliers are doing so.

That aligns with the broader trend we are seeing under the EU Cyber-Resilience Act (CRA): security claims need to become evidence, not just positioning.

Why product teams should care

Secure-by-Design guidance is voluntary, but it is becoming a market signal. Customers increasingly expect manufacturers to explain:

  • how security decisions are governed,
  • how vulnerabilities are received and fixed,
  • whether security features are enabled by default,
  • what product security metrics are tracked, and
  • how leadership is accountable for customer risk.

These are also the kinds of questions that appear during supplier due diligence and technical-file preparation.

What to do next

Use the updated CISA guidance as a check on your product security program. At minimum, a connected-device manufacturer should be able to show:

  1. A named owner for product security outcomes.
  2. A public vulnerability disclosure channel.
  3. A support-period and update policy.
  4. Evidence that secure defaults are part of product acceptance criteria.
  5. A roadmap for reducing systemic vulnerability classes, not just patching individual bugs.

Handbook resources

The bigger picture

The practical lesson is simple: Secure-by-Design is becoming something teams will need to demonstrate. A claim that a product was designed securely is useful only if it is backed by governance, engineering controls, lifecycle support, and public accountability.