CISA's voluntary Secure by Design Pledge and the EU Cyber Resilience Act both promote more secure products, but they serve different purposes and carry different obligations.
Two approaches to secure products
The CISA Secure by Design Pledge is a voluntary, non-binding commitment for companies providing enterprise software products and services. Participants make a good-faith commitment to work towards specified security goals over the following year and, where possible, publicly document measurable progress.
The pledge is not a certification, a compliance assessment or evidence that a product is secure. CISA does not enforce or verify adherence, and does not attest to the security of listed products, processes or services. Its stated scope focuses on enterprise software and services; physical IoT and consumer products are outside that scope, although companies may report progress relating to them.
The seven pledge goals
The pledge encourages progress in seven areas:
- increasing the use of multi-factor authentication;
- reducing reliance on default passwords;
- reducing vulnerability classes;
- increasing customer installation of security patches;
- publishing a vulnerability disclosure policy;
- reporting CVEs transparently; and
- helping customers gather evidence of intrusions.
These goals can provide a useful practical prompt for product teams. They do not mean that every goal applies in the same way to every product.
The Cyber Resilience Act
The Cyber Resilience Act, Regulation (EU) 2024/2847, establishes legal requirements for manufacturers that place products with digital elements on the Union market, subject to its scope and exclusions.
Article 13 requires manufacturers to meet the applicable requirements in Annex I, perform and document a product-specific cybersecurity risk assessment, handle vulnerabilities during the support period, and maintain coordinated vulnerability disclosure policies and procedures.
Annex I includes requirements covering, where applicable, secure-by-default configuration, security updates, access controls, logging of relevant internal activity, vulnerability remediation, security testing, coordinated vulnerability disclosure and secure update distribution.
Where the approaches overlap
There is practical overlap between the pledge goals and CRA requirements. For example, both draw attention to access controls, vulnerability handling, disclosure practices, updates and the ability to investigate security incidents.
That overlap can help teams organise their work, but it does not make pledge participation evidence of CRA conformity. The CRA is risk-based, product-specific and extends beyond the pledge's seven goals.
Using the pledge as a planning prompt
Teams can use the pledge goals to identify useful records to collect, then map those records to the CRA requirements that apply to their products. Useful evidence may include product-specific security measures, configuration baselines, vulnerability-handling records and relevant dates.
Public progress reporting can support accountability, but it cannot replace the CRA risk assessment, technical documentation or conformity assessment required for an applicable product.