Product team testing a smart-speaker-style device with microphones in an anechoic chamber

Cyber Resilience Act

CRA vs Secure by Design: what overlaps, what is binding, and what one evidence set covers

Last updated: 2026-11-13

CRA vs Secure by Design comes down to the same engineering asks with different legal force: the EU Cyber Resilience Act (Regulation (EU) 2024/2847) and CISA's Secure by Design pledge both push for no shared default passwords, strong authentication, fewer vulnerability classes, patches that users install, a disclosure policy and usable logs. The CRA is binding law, with reporting duties applying since 11 September 2026 and the rest from 11 December 2027; the pledge is voluntary. One evidence set can feed both, but the filings stay separate.

This page maps the two side by side. It does not re-explain either one: for the pledge goals and signatory examples, see CISA Secure by Design: the principles and the pledge; for each Annex I point in plain English, see CRA Annex I explained. Both sit under the Cyber Resilience Act hub.

By SoftWSP Regulation Desk10 min read

Key takeaways

This page maps the two side by side.
The CRA sets legal requirements for products; Secure by Design sets principles and voluntary goals for manufacturers.
They overlap most on default credentials, access control, patching and vulnerability disclosure, and least on CVE record quality.
The CRA binds every manufacturer placing products with digital elements on the EU market, while the pledge binds no one.

What does each framework ask for?

The CRA sets legal requirements for products; Secure by Design sets principles and voluntary goals for manufacturers. The CRA text on EUR-Lex puts 13 product properties in Annex I Part I, 8 vulnerability handling duties in Annex I Part II, and manufacturer obligations in Articles 13 and 14. The European Commission's summary of the legal text calls it a "horizontal regulatory framework" that applies to hardware and software products made available on the EU market.

Secure by Design has two layers. The joint guidance "Shifting the Balance of Cybersecurity Risk", updated in October 2023 by CISA and partner agencies, sets out three principles and a list of secure-by-default practices. The pledge, launched on 8 May 2024, turns part of that into seven goals a signatory commits to show progress on within one year.

	Cyber Resilience Act	CISA Secure by Design
Instrument	EU regulation, directly applicable	Joint guidance + voluntary pledge
Unit of obligation	Each product with digital elements placed on the EU market	The signing company, across its products
Core content	Annex I Part I (product), Part II (vulnerability handling), Art. 13–14	3 principles; 7 pledge goals
Proof	Technical documentation, conformity assessment, EU declaration of conformity	Public progress note within one year

Where do the CRA and Secure by Design overlap?

They overlap most on default credentials, access control, patching and vulnerability disclosure, and least on CVE record quality. The table maps each pledge goal, plus two asks from the 2023 guidance, to the closest CRA provision. Goal wording follows the full goal text as reprinted by Okta in its one-year report; CRA references are to Regulation (EU) 2024/2847.

Secure by Design ask	Closest CRA provision	Overlap	What the CRA adds or changes
Pledge goal 1: measurably increase MFA use across products	Annex I Part I (2)(d): protection from unauthorised access through authentication, identity or access management	Partial	The CRA names no specific factor; it asks for "appropriate control mechanisms" chosen by risk assessment, and adds reporting on possible unauthorised access
Pledge goal 2: reduce default passwords	Annex I Part I (2)(b) secure by default configuration, read with (2)(d)	Strong	Applies to every product in scope, with a reset to the original secure state; deviation only by agreement for a tailor-made business product
Pledge goal 3: reduce one or more entire vulnerability classes	Part I (2)(a) no known exploitable vulnerabilities; (2)(j) limit attack surfaces; (2)(k) exploitation mitigation; Part II (3) regular tests	Partial	The CRA judges the product at placing on the market and through the support period, rather than a class trend; it sets no metric
Pledge goal 4: increase customer installation of security patches	Part I (2)(c) automatic security updates by default where applicable; Part II (2), (7), (8)	Strong	Updates must be free of charge (tailor-made exception), security updates separate from feature updates where feasible, each update available for at least 10 years (Art. 13(9))
Pledge goal 5: publish a vulnerability disclosure policy	Part II (5) CVD policy; Part II (6) contact address; Art. 13(17) single point of contact; Annex II point 2	Strong	The CRA asks for a policy that is enforced and listed in user information; it does not require the pledge's promise not to pursue good-faith researchers
Pledge goal 6: accurate CWE and CPE fields in every CVE record; timely CVEs	Part II (4) public disclosure of fixed vulnerabilities with description, affected products, impact and severity	Weak	The CRA does not mention CVE, CWE or CPE; it does require public advisories once a fix exists
Pledge goal 7: increase customers' ability to gather evidence of intrusions	Part I (2)(l) record and monitor relevant internal activity, with user opt-out	Partial	The CRA asks for the logging capability; the guidance's "at no extra charge" point has no CRA equivalent
Guidance: build and share an SBOM for each product	Part II (1) SBOM covering at least top-level dependencies; Annex VII point 2(b)	Strong	The SBOM goes into the technical documentation; publishing it is optional
Guidance: secure by default, security as a core requirement	Art. 13(1)–(2) and Part I (1): design, develop and produce based on a documented risk assessment	Strong	The risk assessment is a legal document, updated during the support period

Read the "Partial" rows carefully. A signatory that ships MFA on its cloud console has met pledge goal 1 for that console; under the CRA, the same team still has to show why the chosen authentication fits each product's risk, and do it for the device firmware too.

Where is the CRA binding and Secure by Design voluntary?

The CRA binds every manufacturer placing products with digital elements on the EU market, while the pledge binds no one. CISA's pledge page says it is "voluntary and not legally binding". The 2023 joint guidance, in the copy hosted by NCSC New Zealand, one of its co-authors, says it "does not automatically serve as a regulatory document".

Dimension	CRA	Secure by Design pledge
Legal status	Regulation, binding in its entirety in all Member States (Art. 71)	Voluntary public commitment
Who is covered	Manufacturers, importers, distributors of products with digital elements, hardware and software	Signing companies; scope is enterprise software, on-premises, cloud and SaaS
IoT and consumer devices	In scope	CISA says they are not scoped in; progress on them is welcome
Dates	Art. 14 reporting from 11 September 2026; the rest from 11 December 2027 (Art. 71(2))	One year from each company's signing date
Duration	Support period, set by expected use time (Art. 13(8)); documentation kept at least 10 years (Art. 13(13))	One-year goals
Enforcement	Market surveillance; fines up to EUR 15 million or 2.5% of worldwide turnover for Annex I, Art. 13 and Art. 14 breaches (Art. 64(2))	Public and customer scrutiny
Incident and exploit reporting	Early warning within 24 hours, notification within 72 hours, final report within 14 days of a fix (Art. 14(2))	None

The practical consequence: pledge evidence can support a CRA file, but pledge status cannot replace any part of it. The CRA's own routes to a presumption of conformity are harmonised standards, common specifications and EU certification schemes, and the pledge is none of these.

What does the CRA require that Secure by Design does not?

The CRA adds product-level legal process that the pledge never asks for. The main additions, all in Regulation (EU) 2024/2847:

A documented cybersecurity risk assessment per product, which decides how each Annex I Part I point applies (Art. 13(2)–(4)).
Reporting of actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform. The Commission's reporting obligations page confirms the platform has been operational since 11 September 2026. See CRA 24-hour and 72-hour reporting.
A support period of at least five years unless the product's expected use time is shorter, with free security updates during it (Art. 13(8), Annex I Part II (8)).
Third-party component duties: report a vulnerability found in an integrated component, open source included, to its maintainer and share the fix (Art. 13(6)).
Product properties the pledge leaves out: confidentiality and integrity of data (Part I (2)(e), (f)), data minimisation (g), availability under denial of service (h), limiting harm to other networks (i) and secure deletion (m).
Conformity assessment, technical documentation and CE marking, covered in CRA declaration of conformity and technical documentation.

What does Secure by Design ask for that the CRA leaves open?

Secure by Design is more specific on a few product choices and on public, measurable reporting. The 2023 joint guidance recommends that products make MFA for privileged users "opt-out rather than opt-in", that single sign-on through open standards ship by default at no additional cost, and that high-quality audit logs come "at no extra charge or additional configuration". The CRA requires authentication and logging capability but does not prescribe MFA, SSO or pricing.

Three further asks have no CRA counterpart:

CVE record quality. Pledge goal 6 asks for accurate CWE and CPE fields in every CVE record. Manufacturers that are CNAs control those fields; see CVE Numbering Authority rules.
Researcher safe harbour. Pledge goal 5 asks the VDP to commit to not pursuing legal action against good-faith researchers. Our vulnerability disclosure policy template includes that clause, and it also satisfies Annex I Part II (5).
Executive ownership and public metrics. The principles "Lead From the Top" and "Embrace Radical Transparency and Accountability" ask for named leadership and published numbers. The CRA asks for documentation held for authorities, not public metrics.

Which single evidence set can serve both?

One set of release-level records serves both, as long as each record is dated and tied to a product version. The table lists records a device or software maker keeps once and reuses twice.

Record	CRA use	Secure by Design use
SBOM per firmware or software release, in CycloneDX or SPDX	Annex I Part II (1); Annex VII point 2(b)	Guidance SBOM ask; input to goal 3
Vulnerability list matched against each SBOM, with exploitability decisions	Part I (2)(a) at placing on the market; Part II (2) remediation	Goal 3 class trend; goal 6 CVE issuance
Published CVE records and advisories, with CWE and CPE	Part II (4) disclosure of fixed vulnerabilities	Goal 6
CVD policy, security contact and security.txt	Part II (5), (6); Art. 13(17); Annex II point 2	Goal 5
Credential provisioning record (unique per device or set at install)	Part I (2)(b), (d)	Goal 2
Authentication design, including MFA on consoles and cloud services	Part I (2)(d)	Goal 1
Update records: release dates, signing, auto-update default, installed-base share	Part I (2)(c); Part II (7), (8); Art. 13(9)	Goal 4
Logging specification: events recorded, export path, opt-out	Part I (2)(l)	Goal 7

What stays separate. The CRA technical documentation and the EU declaration of conformity stay with the manufacturer, at the disposal of market surveillance authorities for at least 10 years (Art. 13(13)). Article 14 notifications go to the CSIRT coordinator and ENISA. A pledge progress note is public. Draw all three from the same records, and never let a public note disclose details of an unfixed vulnerability that the CRA lets you hold back until users could patch (Part II (4)).

How does this play out for different makers?

The overlap depends on what you sell. Three common cases:

Connected-device maker with a cloud app. A cloud management console sold to businesses fits the pledge's enterprise-software scope; the devices themselves are outside it. All of it is in the CRA's scope. Start from the device: SBOM per firmware build, default credentials, update path, then reuse that evidence for any pledge report.
Machine builder or OT component vendor. The pledge rarely applies directly to controllers and field devices. The CRA applies to the controller firmware and engineering software you place on the EU market. For component-level requirements, see IEC 62443-4-2 vs the CRA.
Enterprise software or network-appliance vendor that signed the pledge. Most of the seven goals map onto existing work. The CRA gaps are the risk assessment per product, the support period, the SBOM in the technical file and the 24-hour reporting route.

What can AI-assisted analysis cover here?

AI helps narrate the vulnerability side of the shared evidence set; it does not decide compliance. SoftWSP's deterministic pipeline extracts an SBOM from a firmware image as CycloneDX 1.6 JSON and matches each component version against NVD, the CISA KEV catalogue, FIRST EPSS scores and CISA CSAF ICS advisories. A fixed lookup table then marks which CRA Annex I clauses each finding is indicatively relevant to, labelled as a working aid and not a conformity assessment. AI drafts the report text on top, and the report is stored only if its citations check out, for an engineer to review. The code scores, AI narrates. MFA design, logging, VDP terms and pledge metrics stay with your own team.

To see where a product stands against the CRA, run the free CRA readiness check, then work through the CRA checklist for device makers. For firmware SBOM and vulnerability evidence that serves both the CRA file and a pledge report, see device firmware security.

This guide is general information, not legal advice.

Put this guide to work

ServiceDevice & Firmware SecurityFirmware SBOM, vulnerability match and fix.See the service

ComplianceCRA readiness self-checkA short self-assessment against the Cyber Resilience Act Annex I categories. Informational only, not a conformity assessment.Free

Frequently asked questions

Does following CISA's Secure by Design pledge help with Cyber Resilience Act compliance?

Yes, as engineering work, not as a legal shortcut. Six of the seven pledge goals have a related point in CRA Annex I, with the closest matches on default passwords, patches and a disclosure policy, and the evidence behind them can go into the CRA technical documentation. The pledge itself gives no presumption of conformity: CRA conformity is shown through the Article 32 assessment procedures, the Annex VII technical documentation and the EU declaration of conformity.

Is CISA's Secure by Design pledge legally binding like the CRA?

No. CISA's pledge page states that the pledge is voluntary and not legally binding, and the 2023 joint guidance says it does not automatically serve as a regulatory document. The CRA, Regulation (EU) 2024/2847, is directly applicable law in every EU Member State; under Article 64(2), breaches of Annex I or Articles 13 and 14 can draw fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.

Do the seven pledge goals map one-to-one onto CRA Annex I?

No. Default passwords, patches and the disclosure policy map closely onto specific Annex I points. MFA maps onto the general access-control point, and reducing vulnerability classes only partly onto exploitation mitigation and regular security testing. The CVE goal (accurate CWE and CPE fields) has no direct CRA counterpart and the intrusion-evidence goal only a partial one, while the CRA adds duties the pledge does not have, such as the SBOM, a support period and 24-hour reporting of actively exploited vulnerabilities.

Does the Secure by Design pledge apply to IoT devices?

Only optionally. CISA scopes the pledge to enterprise software products and services, and says physical products such as IoT devices and consumer products are not scoped in, though companies may report progress on them. The CRA covers products with digital elements, hardware and software alike, so a connected device sold in the EU falls under the CRA whether or not its maker signed the pledge.

Can one SBOM and vulnerability record serve both the CRA and a pledge progress report?

Yes. An SBOM per firmware release, the vulnerability list matched against it, CVE records with CWE and CPE, the disclosure policy and update records are the same underlying facts for both. The outputs stay separate: the CRA needs them inside the technical documentation kept for at least 10 years, while the pledge asks for a public progress note within one year of signing.