Secure by Design: What Changed When It Became Law

Most guidance on this term still describes a voluntary engineering philosophy for software you deploy. If you ship a physical product into the EU, that description is two years out of date.

The best-known American instrument for secure by design does not cover connected devices. CISA's Secure by Design Pledge is scoped to enterprise software: on-premises products, cloud services, and SaaS. Physical products such as IoT devices and consumer hardware are explicitly out of scope.

The EU went the other way. The Cyber Resilience Act put secure-by-default configuration and freedom from known exploitable vulnerabilities into binding law, for exactly the products the pledge leaves out.

Same phrase, opposite force, depending on what you build and where you sell it. Asking whether secure by design is required produces no useful answer until you say who is asking.

What follows is what the term means, the principles underneath it, where the obligation is now legal rather than aspirational, and what changes when the thing you ship is a device rather than a service you can reconfigure on Tuesday.

What Secure by Design Actually Means

The load-bearing idea is not timing. It is who is accountable when a product turns out to be insecure.

Under a secure by design approach, responsibility for secure outcomes rests with the producer rather than the customer. Vulnerabilities get prevented before release, and security functions as a core engineering and business requirement instead of a feature customers configure themselves. CISA states the same premise from the other direction: products built this way treat customer security as a core business requirement, not a technical add-on.

The design principles are well established. Treat security as a design constraint rather than a later addition. Assume the system operates in a hostile environment with active adversaries. Grant least privilege. Layer controls so no single failure is total. Expose only the interfaces the product actually needs.

Two adjacent terms cause most of the confusion.

Secure by default describes how a product ships, not how it was built. Protections are enabled out of the box, at no extra cost, with no customer action required. The distinction matters more than it sounds, because the Cyber Resilience Act writes secure-by-default configuration into law as a requirement separate from secure design.

Shift left is narrower than either. It moves testing earlier. Secure by design constrains what gets designed at all, which is a different intervention with a different ceiling.

The Three Principles, and the Seven Goals That Operationalize Them

The most common way secure by design fails is organizational. Security gets assigned to a team with no authority over architecture, then asked to approve decisions finalized months earlier.

CISA's framework rests on three principles. Take ownership of customer security outcomes, including after the product ships. Embrace radical transparency and accountability, meaning complete and timely vulnerability advisories. Lead from the top, so security is not delegated to people who cannot change the product.

The pledge translates those principles into seven goals, and remains the only concrete published expression of them:

• Multi-factor authentication. Measurably increase MFA use, favoring phishing-resistant methods.
• Default passwords. Eliminate universally shared credentials, especially on internet-facing products.
• Reducing entire classes of vulnerability. Drive a class down at scale rather than patching instances.
• Security patches. Ease installation via automatic updates and clear end-of-life communication.
• Vulnerability disclosure policy. Authorize good-faith public testing, with no legal action against researchers.
• CVEs. Include accurate CWE and CPE fields in every record, and file promptly for critical flaws.
• Evidence of intrusions. Give customers the logs to investigate incidents themselves.

Signatories grew from 68 at the May 2024 launch to roughly 367 by mid-2026. The list now works less as a compliance mechanism than a procurement checkpoint for due diligence.

One consequence catches teams off guard. CISA notes that a manufacturer working seriously to reduce a vulnerability class may see its CVE count rise in the short term, and says this should be treated as success provided the class declines over time. If your organization grades product security on raw CVE volume, it will read genuine progress as regression.

Why the Design Phase Is Where the Cost Is Decided

Most defects do not originate in code. Capers Jones's research attributes roughly 30 to 35 percent of defects to code itself, 20 to 25 percent to requirements, and 25 to 30 percent to design. Requirements and design together outweigh implementation, yet nearly all security tooling spend points at the code.

The cost curve is the argument everyone reaches for, usually without sourcing it. The figures come from the IBM Systems Sciences Institute: roughly 1x to fix a defect in design, about 6.5x during implementation, about 15x in testing, and 60 to 100x after release.

Treat those as directional. They trace back to Barry Boehm's analysis of TRW project data from the 1970s, usually offered as grounds for skepticism. It cuts differently for hardware. Boehm's data came largely from medium-to-large embedded and commercial systems, not the SaaS products the 100x figure now gets quoted at. The multiplier is arguably more applicable to firmware than to the software it usually describes.

Design-phase work is concrete. Define trust boundaries and where enforcement happens. Reduce attack surface by removing interfaces rather than defending them. Threat model before code exists. Choose memory-safe languages for new components. OWASP adds a useful point: doing the design work first makes threat modeling cheaper, because the exercise finds edge cases instead of foundational flaws that force a redesign.

Design intent alone has not been sufficient. Several hundred CVEs for cross-site scripting and SQL injection were logged in the first three months of 2025, decades after both classes were fully understood.

Scanning finds instances in code that exists. Design work removes the conditions that produce the instances. Only one of them gets budget by default.

Secure by Design Is Not Voluntary Anymore

The CISA pledge is voluntary and not legally binding, and CISA states plainly that it neither enforces nor verifies adherence.

It also produced an odd result: device manufacturers signed it anyway. TP-Link and Axis Communications both signed an enterprise-software pledge that does not cover what they sell, because they wanted a secure-by-design signal and it was the only one available.

The EU built the other kind of instrument. Regulation (EU) 2024/2847, the Cyber Resilience Act, is the first EU-wide law setting mandatory cybersecurity requirements for products with digital elements, hardware and software, across the full lifecycle. A product may only be placed on the market if it meets the essential requirements in Annex I, demonstrated through conformity assessment, an EU declaration of conformity, and CE marking.

Annex I Part I requires products be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks, then made available without known exploitable vulnerabilities and with a secure by default configuration. Further clauses require limiting attack surfaces, reducing incident impact through exploitation mitigation, controlling unauthorised access, monitoring internal activity, and enabling secure automatic updates by default.

That is a statutory restatement of the principles in the previous two sections.

The dates make it operational. The Article 14 reporting obligation took effect 11 September 2026, requiring a 24-hour early warning once you become aware of an actively exploited vulnerability and fuller notification within 72 hours. Full application arrives 11 December 2027, with support periods generally expected to run at least five years. Because the obligations recur release after release, CRA compliance is a continuous program, not a one-time audit.

Part II adds process obligations, including documenting the vulnerabilities and components in the product and drawing up a software bill of materials. Under the CRA, the SBOM is a legal artifact rather than a best practice.

Sector regimes point the same way: FDA section 524B for medical devices, IEC 62443-4-1 for industrial, ISO/SAE 21434 and UNECE R155 for automotive.

One nuance matters. The CRA is deliberately technology-neutral, mandating no named testing methodology, not even penetration testing. It defines outcomes and leaves manufacturers to choose and justify their own methods.

Sell software into the US and secure by design remains a commercial signal. Place a connected product on the EU market and it is a condition of access with a date attached.

Why This Is Harder for Physical Products

General secure by design guidance assumes you can change the architecture once you learn something. The standard advice runs to API gateways, service mesh mTLS, and staged rollouts. On a device that has shipped, the architecture is the product.

Four differences are structural, not matters of degree.

Design decisions freeze earlier and bind longer. There is no config push and no gradual rollout. Hardware constraints set the security ceiling before firmware is written, and the support obligation outlives the last design decision by years.

Most of the code is not yours. Third-party and vendored components dominate a firmware image. Most guidance reduces this to SBOM hygiene and CVE monitoring, skipping the harder problem: a supplier's declared component list is a claim, not an observation, which is why manufacturers verify it against the binaries.

Source-level discipline does not describe the shipped artifact. When firmware is compiled, components get statically linked, vendor packages and nested libraries get merged, and open-source libraries arrive through indirect paths, which is why source-based SCA fails on firmware. A team can run a rigorous secure development lifecycle and still ship a binary nobody has an accurate inventory of. Our researchers found a flaw first disclosed in 2002 still shipping inside a home security camera in 2026, because no one along the supply chain examined the final artifact.

Memory safety is the concrete case. CISA and the FBI set 1 January 2026 for publishing a memory safety roadmap, non-binding guidance that is now past. Roughly two-thirds of reported vulnerabilities in memory-unsafe languages still relate to memory issues. CISA's own guidance concedes that memory-safe language performance affects constrained embedded devices, a rare acknowledgement that the embedded case is genuinely different.

The workable pattern is not a rewrite. Teams handling this well produce a defensible component inventory, then move new development and the highest-risk components (parsers, network-facing code, cryptography) to memory-safe languages as a bounded parallel track.

Note where the pressure came from. That non-binding date migrated into security questionnaires, CRA readiness reviews, and acquisition diligence, where a missing answer costs deals, not fines.

The discipline transfers cleanly from software to hardware. The verification problem does not.

Proof Is the Part Nobody Plans For

A pledge asks you to declare intent. A conformity assessment asks you to prove a property of a specific artifact. Those are different engineering problems, and only one has a deadline.

Because the CRA specifies outcomes, not methods, the quality of your evidence becomes the compliance variable. Annex I Part II requires documented components and vulnerabilities, regular tests and reviews, and disclosure of fixed vulnerabilities. None of that is satisfied by having good practices. It is satisfied by producing records about a particular build.

Which is where most programs break. Evidence assembled after the fact is a reconstruction, and regulators tell the difference. CRA obligations recur every release across the support period, so a package built once for one assessment does not survive the second year.

Evidence has to be an output of the engineering work, not a project that follows it. For connected devices that means starting from the artifact you ship. Binary analysis of compiled firmware produces a ground-truth component inventory reflecting what was actually linked in, rather than what a build manifest or supplier declaration claims. Reachability analysis then establishes which findings matter in that specific build context, which makes the remaining work tractable instead of a queue of thousands of unreachable CVEs.

These are the same artifacts the regulator, the notified body, and the customer questionnaire ask for, produced once and serving every audience.

Have you adopted the practices without building the proof? Most teams have, and they find out during an audit or a deal review, not on their own schedule. Our CRA Readiness Assessment shows where your program stands against the CRA deadlines and what it takes to answer from evidence you already hold.

FAQ

What is the difference between secure by design and secure by default?

Secure by design describes how a product is built, with security as an engineering and business requirement from the outset. Secure by default describes how it ships, with protections enabled out of the box and no customer configuration required. Current guidance expects both, and the Cyber Resilience Act makes secure-by-default configuration a separate legal requirement in Annex I.

Does the CISA Secure by Design Pledge apply to IoT devices?

No. The pledge is scoped to enterprise software products and services, covering on-premises software, cloud services, and SaaS. Physical products such as IoT devices and consumer products are explicitly out of scope, though signatories are welcome to demonstrate progress there voluntarily. Several device manufacturers have signed regardless, because no hardware-specific equivalent exists.

Is secure by design legally required?

It depends on your market and product. In the US it remains voluntary and unenforced by CISA. In the EU, CRA Annex I makes secure design and secure-by-default configuration a condition of market access for products with digital elements, enforced through conformity assessment and CE marking. Sector mandates add to this: FDA section 524B, IEC 62443-4-1, and ISO/SAE 21434 with UNECE R155.

Can secure by design be applied to a product that has already shipped?

Yes, though fundamental architecture and implementation changes are considerably harder after release. For connected-device manufacturers it is not optional. CRA obligations reach across products already in the field, and support periods are generally expected to run at least five years, so the installed base carries requirements for years after the last design decision.

Why did our CVE count go up after adopting secure by design?

Because systematically hunting a vulnerability class surfaces instances never reported before. CISA addresses this directly, noting that a short-term rise in CVEs is expected and should be regarded as success provided the class declines long term. It also cautions against reading CVE volume itself as a negative signal.

How do we prove secure by design to a regulator or customer?

Through documented evidence about a specific build, not a description of your process. Under CRA Annex I Part II that means a component inventory and SBOM, documented vulnerability decisions, records of regular testing, and disclosure of fixed vulnerabilities. See "Proof Is the Part Nobody Plans For" above for why reconstructing this after the fact tends to fail.